When do you write Automated Test Script

When do you write automated Test script?

A TEST SCRIPT is a set of instructions (written using a scripting/programming language) that is performed on a system under test to verify that the system performs as expected. Test scripts are used in automated testing.
Sometimes, a set of instructions (written in a human language), used in manual testing,  is also called a Test Script but a better term for that would be a Test Case.

In today’s world, testing can not be efficient without automation. We need automation for avoiding repetitive work, making sure that the time from development to deployment is reduced with good quality. We need good, quality automation tests, not just automation tests. We need tests which are reliable, robust, easy to code, debug, scale and can run in parallel on distributed environment.

Typically, you can do testing at any point in the development cycle, therefore you can write test cases and test scripts at any point. If you have requirements to build from, you have the building blocks for test cases in the future. If you have code, you can write test cases while the code is being built. If you already have the code, you can write tests too. Do you have data? You can write test cases. Do you have configurations? You can write test cases.

When do you run your automation test cases

When do you run your automation test cases?

A test script in software testing is a set of instructions that will be performed on the system under test to test that the system functions as expected. In the test execution phase tester run automation test scripts.

How do you choose test case to be automated

How do you choose test case to be automate?

Test cases to be automated can be selected using the following criterion to increase the automation ROI:

• Business critical paths the features or user flows that if they fail, cause a considerable damage to the business.
• Tests that need to be run against every build/release of the application, such as smoke test, sanity test and regression test.
• Tests that need to run against multiple configurations different OS & Browser combinations.
• Tests that involve inputting large volumes of data, such as filling up very long forms.
• Tests that execute the same workflow but use different data for its inputs for each test run e.g. data-driven.
• Tests that can be used for performance testing, like stress and load tests.
• Tests during which images must be captured to prove that the application behaved as expected, or to check that a multitude of web pages looks the same on multiple browsers.
• Tests that take a long time to perform and may need to be run during breaks or overnight.

When do you choose what test case to be automated

When do you choose what test case to be automated?

It is impossible to automate all testing, so it is important to determine what test cases should be automated first. The benefit of automated testing is linked to how many times a given test can be repeated. Tests that are only performed a few times are better left for manual testing. Good test cases for automation are ones that are run frequently and require large amounts of data to perform the same action.

There are many situations, when you realize that Automation Testing must be done:
1) To Optimize the Speed & Efficiency

2) To Increase the Quality and Decrease the Cost: In software development processes, time-to-market is always on priority. Automation test design for Regression testing, Functionality testing, Re-testing the existing modules, so that auto-scripts run fast and frequently. It’ll surely reduce the time, cost and increase the speed.

3) When there is a repetition or a need to run the test cases a lot number of times in a test cycle.

4) When there are number of test cases under one test-suite: In this case you’ll feel tired after executing each test cases from that test suite, then automation can provide you better results.

5) When there is a requirement of running the test cases in a defined order: While doing software testing, there are scenarios in which you need to test specific feature/module before the others. To achieve this in manual testing its required to remember the order, or you’ll write the order in some other file(.doc, txt, excel) and will refer that. But with automated testing, you can design the scripts in such manner as per our needs.

6) To Increase the Test Coverage: As a human, there are some areas remain left while doing Regression/Retesting. So Automation test helps you to cover all test cases for each module.

7) When you need to run the same test cases on different machines at the same time: When there is a requirement to run the same set of test cases simultaneously on multiple machine, then automation is your answer. Under manual testing process, you cannot execute same test case at the same time on several machines.

8) When you need to test single functionality with multiple data sets: At the time of testing process, you need to run the same test case with multiple data. Then data driven automation testing framework comes in picture to minimize your effort & time. The data is fetch from an external source (e.g. Excel) and pass the multiple and big-size data to each test case. In manual testing, you get bored of testing same functionality and chances of error can increases.

9) When you need to run Regression/Sanity/Smoke Test Suite: Regression test suite consists selected number of test cases, which need to be tested after every defect fix cycle. For regression/sanity testing there is a need of automation testing, because:

• Its test cases never/rarely change.
• Repeated execution of test-cases (after each new functionality).

10) Generation of Detailed Reports: Mostly all automated testing tools generate test reports automatically once the testing cycle completes. This eases the job of identifying defects and allow the test team to make decision to reliability of the product. So Automation is the solution.
You should refer this cycle before starting with automation:

Automation Testing

What is Automation Testing?

Automation testing is an Automatic technique where the tester writes scripts by own and uses suitable software to test the software. It is basically an automation process of a manual process. Like regression testing, Automation testing also used to test the application from load, performance and stress point of view.
In other word, Automation testing uses automation tools to write and execute test cases, no manual involvement is required while executing an automated test suite. Usually, testers write test scripts and test cases using the automation tool and then group into test suites. Automation testing is a technique uses an application to implement entire life cycle of the software in less time and provides efficiency and effectiveness to the testing software. The main goal of Automation testing is to increase the test efficiency and develop software value.



Testing tool selection: Phase where you identify and select the automation tool for automation testing. Test Tool selection largely depends on the technology the Application Under Test is built on.

Define scope of automation: What are you going to automate and won't you automate. The scope of automation is the part your application that needs to be automates. It can be determined with the following..

• Common functionalities across the application
• Features that are crucial for your business
• The complexity of test cases
• Capability to use similar test cases for cross browser testing

Panning, Design And Development: Once you have identified the test cases to be automate, you can design and develop the automation suite, implementing relevant design pattern and framework. During this phase, you create an Automation strategy & plan, which contains the following details-

• Automation tools selected
• Framework design and its features
• In-Scope and Out-of-scope items of automation
• Schedule and Timeline of scripting and execution
• Deliverable of Automation Testing

Test Execution: Execute the above designed test case and record the test result.

Maintenance: As new functionalities are added to the System Under Test with successive cycles, Automation Scripts need to be added, reviewed and maintained for each release cycle. Maintenance becomes necessary to improve the effectiveness of Automation Scripts.

Role of a developer in different phases of SDLC

(Q). What is the role of a developer in different phases of sdlc?

The Software Developers (front-end and back-end) are responsible for using the technical requirements from the Technical Lead to create cost and timeline estimates.

The Software Developers are also responsible for building the deliverable and communicating the status of the software project to the Technical Lead or Project Manager.
It is critical that the other team members effectively communicate the technical requirements to the Software Developers to reduce project risk and provide the software project with the greatest chance of success.

Role of a Test Analyst in different phases of SDLC

(Q). What is the role of a Test Analyst in different phases of sdlc?

Software Testers are involved in identifying test conditions and creating test designs, test cases, test procedure specifications and test data, and may automate or help to automate the tests.

Requirement: Tester understands the requirements and analyse the requirements and also checks whether given requirements are testable requirements or not. If the tester finds any defects in requirements, the tester directly reports those defects.

Design Phase: In this phase, the tester identifying high-level test Condition and test cases for given requirements and develops test scenarios and test cases and preparing test data if necessary.

Build Phase: In this phase, tester do the static testing like design review, test cases review, checking we cove all requirements or we miss any requirements.

Testing Phase: In this phase actually we execute the test cases, log results and if any test case is failed we have to report the defect using any defect management tool after fixing those defect again retest those defect to ensure that the defect is fixed or not. If not again reopen the defect. After finishing all test cases our test manager will sign off on the testing.

Role of a Business Analyst in different phases of SDLC

(Q). What is the role of a Business Analyst in different phases of SDLC?
In Software development life-cycle a Business Analyst is closely related with each of the steps involved in the Software Development Life Cycle (SDLC). The series of steps which involves a BA in the SDLC process are as follows:

Planning Phase:
At first when a prospective project is put forth in front of the team, the Project Manager, Business Analyst and the Technical Architect is involved in the Initiation and Planning phase. Key points for discussion are as follows:

• Feasibility of the project?

• Will the project be profitable?

• Technical challenges?

• Project technical risks?

Requirement Analysis:

In this phase a Business Analyst is heavily involved in making appointments with the client and start with interviewing them about the requirement of the project. This process is commonly known as Requirement gathering. This is where the BA will also use their modelling skills to document business requirements and prioritize activities. The information gathered is documented using MS Word or any similar software to represent use cases, use case diagram, activity diagram and data flow diagram etc.

Design and Development: The requirements have now been designed into a solution which is being implemented. The Business Analyst doesn’t have much to do in this phase. At times, it can happen that the BA is asked to clarify requirements or in certain Agile Scrum projects the business analyst will be asked to review prototypes. Business analyst should frequently have meeting with the team or developer in case of clarification to ensure that the project is on the right track. 

Testing and Implementation: During the Testing and Implementation phase the Business Analyst can assist with reviewing the test scripts to ensure all functional requirements are being tested. The BA can also make use of a Tractability Matrix to trace the requirements during implementation. After which the project is sent for User Acceptance Testing, in which business analyst makes an appointment with client and the client performs a sanity check. In case of bugs the project is sent back to the development team, else client will accept the project and beta version is implemented.

(Q). What is the role of a developer in different phases of sdlc?

The Software Developers (front-end and back-end) are responsible for using the technical requirements from the Technical Lead to create cost and timeline estimates.
The Software Developers are also responsible for building the deliverable and communicating the status of the software project to the Technical Lead or Project Manager.
It is critical that the other team members effectively communicate the technical requirements to the Software Developers to reduce project risk and provide the software project with the greatest chance of success.

Why do we need a separate environment for developers and testers

(Q). Why do we need a separate environment for developers and testers?

Because developers have often lot of other tools running on their environments which might affect the outcome of the test and hence needs to be separated from a test environment.
A test environment would be setup as close to the production as possible so as to ensure good quality testing. It would also allow setup and installation testing.
A separate environment also allows QA to test installation issues and fulfillment of all software requirements. You usually setup a separate QA environment, because you want to give the testers an isolated environment on which to test, so that developers and testers can work at the same time.

Different environments in Software development...

Difference between BRD and FRD

(Q). What is the difference between functional requirement document (FRD) and Business requirement document (BRD)? 

BRD	FRD
Business requirement document highlights “Business Requirement” i.e. high-level business goals of the organization developing the product or solution with the help of IT.	Functional requirement document highlights “Functional Requirement” i.e. Functionality of the software in detail.
A formal document illustrating the requirement provided by the client.	It describes at a high level the functional and technical specification of the software.
Created by a Business Analyst who interacts with the client.	Usually created by Business Analyst under the supervision of technical expert, for instance system architect.
BRD used by upper and middle management.	FRD used by technical lead, development teams and testing team.

Which Phase of SDLC does the tester begin to write test case

(Q). Which Phase of SDLC does the tester begin to write test case?

After completion of FRS (functional requirement specification) document, the test lead prepare the use case document and test plan document, then the tester role is start.

But Testing should involve in all phases of SDLC. Test planning should be started from beginning of the project. It also depend on Project to Project. If the project timing is flexible then this is not an issues at all. But if the release date is fixed and not going to change then it make direct impact on quality of software application, as very less time get to test entire application. Also to fix the bugs which are found at later stages are costlier than found in early stage. So start testing early in the software development would solve the problem, as the earlier you find a bug the cheaper it is to fix it. 

Stakeholders involved in different phases of SDLC

(Q). Who are the stakeholders involved in different phases of SDLC?

• Requirements - Business Analyst

• Design - System Architect

• Coding - Software Developer / Development Team

• Testing - Tester / Testing Team

• Implementation- Operational Team

• Maintenance-Production Support Team

Difference between Use case and Test case

(Q). What is the difference between an use case and test case?

In the software testing these two terms are important and are also closely related, but from a different perspective.

Use Case	Test Case
A use case is used to define the system that how to use to the system for performing a specific task.	Test case is a set of actions executed to verify a particular feature or functionality of your application.
A use case is not a part of execution it is only a diagrammatic presentation of a document that specifies how to perform certain task.	Test case is used to validate the software which is developed by testers for validating that the software is in working as per requirement or not.
Use Cases are prepared on requirements.	Test cases are prepared on Use cases.
Business User executes the use case.	Testers executes the test cases.
Use case follow the different paths.	Single test case is tested a time.

Requirement Traceability Matrix

(Q). Explain Requirement Traceability Matrix (RTM) in simple terms.

The Requirements Tractability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Tractability Matrix is to ensure that all requirements defined for a system are tested in the test protocols. It is a single document that serves the main purpose that no test cases are missed and thus every functionality of the application is covered and tested.

Difference between SDLC and STLC

(Q). Explain the difference between an SDLC and STLC?

SDLC	STLC
Software Development Life Cycle.	Software Testing Life Cycle.
The main object of SDLC life cycle is to complete successful development of the software including testing and other phases.	The only objective of the STLC phase is testing.
In SDLC the business analyst gathers the requirements and create Development Plan.	In STLC, the QA team analyse requirement documents like functional and non-functional documents and create System Test Plan.
In SDLC, the development team creates the high and low-level design plans.	In STLC, the test analyst creates the system and Integration Test Plan.
SDLC defines all the standard phases which are involved during the software development process.	STLC process defines various activities to improve the quality of the product.

Test design and Test execution

(Q). What are the activities performed in test design and test execution?

Test Design:

The test case development activity is started once the test planning activity is finished.Based on the requirement analysis, test conditions are written first and an approval is obtained from the QA lead.

This is the phase of STLC where testing team write down the detailed test cases. Once the test cases are ready then these test cases are reviewed by peer members or QA lead. Once the preparation of Test Case Development and Test Environment setup is completed then test execution phase can be kicked off.

Test Execution:

In this phase, testing team start executing test cases based on prepared test planning & prepared test cases in the prior step.

Once the test case is passed then same can be marked as Passed. If any test case is failed then corresponding defect can be reported to developer team via bug tracking system & bug can be linked for corresponding test case for further analysis. Ideally every failed test case should be associated with at least single bug.

Once the bug fixed by development team then same test case can be executed based on your testing planning.

End to End Testing

(Q). What is End to End Testing?

End to End testing is a technique to check whether the behavior of the application flow right from start to finish meets the expectation. It is designed based on the end user’s scenarios to validate the application and the integration of its components. E2E Testing also helps you prevent the risk of whole system collapse due to subsystem failures. The purpose of performing end-to-end testing is to identify system dependencies and to ensure that the data integrity is maintained between various system components and systems.

Why End to End Testing?

Modern software systems are complex and are interconnected with multiple sub-systems.

A sub-system may be different from the current system or may be owned by another organization.  If anyone of the sub-systems fails, the whole software system could collapse. This is a major risk and can be avoided by End-to-End testing. End-to-End testing verifies the complete system flow. It helps detect issues with sub-systems and increases confidence in the overall software product.

System Integration Testing

(Q). What is System Integration Testing?
System Integration Testing is defined as a type of software testing carried out in an integrated hardware and software environment to verify the behavior of the complete system. It is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirement.

System Integration Testing (SIT) is the overall testing of the whole system which is composed of many sub-systems. The main objective of SIT is to ensure that all software module dependencies are functioning properly and the data integrity is preserved between distinct modules of the whole system.

Example of Software testing and Software integration testing:

A car manufacturer does not produce the car as a whole car. Each component of the car is manufactured separately, like seats, steering, mirror, break, cable, engine, car frame, wheels etc. 

After manufacturing each item, it is tested independently whether it is working the way it is supposed to work and that is called Unit testing.

Now, when each part is assembled with another part, that assembled combination is checked if assembling has not produced any side effect to the functionality of each component and whether both components are working together as expected and that is called integration testing.

Once all the parts are assembled and the car is ready, it is not ready actually. The whole car needs to be checked for different aspects as per the requirements defined like if car can be driven smoothly, breaks, gears, and other functionality working properly, car does not show any sign of tiredness after being driven for 2500 miles continuously, color of car is generally accepted and liked, car can be driven on any kind of roads like smooth and rough, sloppy and straight, etc and this whole effort of testing is called System Testing and it has nothing to do with integration testing.

System testing

(Q). What is System testing?
System Testing is conducted on the entire system that consists of numerous coordinated components. It helps you ensure that the system meets functional requirement specifications and operates as designed to satisfy user’s expectations.

System Testing is a black box testing technique performed to evaluate the complete system the system's compliance against specified requirements. In System testing, the functionalities of the system are tested from an end-to-end perspective.

System Testing is usually carried out by a team that is independent of the development team in order to measure the quality of the system unbiased. It includes both functional and Non-Functional testing.

Sanity Testing

(Q).What is Sanity Testing?

1. Sanity testing is usually not documented and is unscripted.

2. Sanity Testing is like specialized health check up of the software/ application.

3. It is the surface level testing where the QA engineer verifies that all the menus, functions, commands available in the product and project are working fine.

4. Sanity testing is performed after the build has clear the Smoke test and has been accepted by QA team for further testing. 

5. Sanity testing checks the major functionality with finer details.

6. Sanity Testing is done to check the new functionality/bugs have been fixed.


The key differences between Smoke and Sanity Testing can be learned with the help of the following diagram -

Smoke testing

(Q).What is Smoke testing?

Smoke testing is non-extensive software testing which makes sure that the most crucial functions of a program are working fine, but not bothering with finer details because in smoke testing we only check the major functionality of the software.

Smoke testing is performed by developers before releasing the build to the testing team and after releasing the build to the testing team it is performed by testers to determine whether to accept the build for further testing or not.

Build: A build is the version of software, typically one that is still in testing stage.

Continuous Integration, Continuous Delivery, Continuous Testing

What is CI, CD, and CT?

1. Continuous Integration: Continuous Integration (CI) is the process of automating the build and testing of code every time someone commits changes to version control. Many think this is the most critical component to making an effectively agile development team.
CI puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch. Developers can share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test and validate the full master branch. Simply, it ensures bugs are caught earlier in the development cycle, which makes them less expensive to fix - and maintains a consistent quality.

2. Continuous Delivery: Continuous Delivery (CD) is the practice is the practice of streamlining and automating all the processes leading up to deployment. There are a number of steps in CD, such as validating the quality of the build in the previous environment. When done manually these steps can take significant effort and time. However, using cloud technologies and proper orchestration, they can be automated.
Teams should ensure they have a monitoring dashboard for your production environment in place in order to eliminate performance bottlenecks and respond fast to issues. This will complete an efficient CD process.

3. Continuous Testing: Continuous Testing (CT), which can also be referred to as Continuous Quality, is the practice of embedding and automating test activities into every “commit”. CT helps developers use their time more efficiently when trying to fix a bug for code that was written years ago. To fix the bug, developers should first remind themselves of which code it was, undo any code that was written on top of the original code, and then re-test the new code; not a short process. Testing that takes place every commit, every few hours, nightly and weekly, not only increases confidence in the application quality, it also drives team efficiency.

Working together and how to do it well

These three processes are often viewed as distinctly separate identities, fighting for the top spot in the DevOps pipeline. However, CT, CI and CD are better together.

CT, CI and CD are important to the success of one another throughout the delivery cycle, and it’s only by incorporating the CI/CD/CT trifecta that teams will be able to achieve the velocity and quality needed for success in today’s rapidly transforming industry.

But with distinct personalities and distinct jobs to do, how can DevOps teams bring these jobs together? If avoiding the drama of a love triangle is a priority, what characteristics are necessary to keep business running smoothly?

The first, is perhaps the most obvious - communication. Communication is vital, and this is something that CI enables. It allows teams to be Agile by ensuring they are all on the same page, so if they leave a project or move on to a different step in the process, they can easily integrate once they return without having to start over from the beginning.

The second is trust – CD alleviates any unknowns by automating and streamlining all the processes leading up to deployment, such as validating the quality of the build in the previous environment and promoting to staging. By eliminating the element of doubt, teams can trust both the process and the product - assured that continuous quality is being prioritized.

And finally, honesty. If CT is leveraged when developing apps in different environments and with different criteria, it will prevent larger issues from happening once the app is in the sprint or live, keeping developers honest about the status of their code.

DevOps Practice

(Q). What is DevOps Practice?

For a long time, development and operations were isolated modules. Developers wrote code; the system administrators were responsible for its deployment and integration. As there was limited communication between these two silos, specialists worked mostly separately within a project. That was fine when Waterfall development dominated.  But since Agile and continuous workflow have taken over the world of software development, this model is out of the game. Short sprints and frequent releases occurring every two weeks or even every day require a new approach and new team roles.

DevOps is Development and Operation’s Collaboration, It’s a Union of Process, People and Working Product that enable continuous integration and continuous delivery of value to our end users. DevOps accelerate the process to deliver applications and software services at high speed and high velocity. So that organizations can learn and Adopt the market at its earliest. Also, it minimizing the risk factor by continuously delivering and getting end-users and stakeholders feedback at the early stages.

How DevOps Works

DevOps is the practice of operations and development engineers that work together in the entire project life-cycle, from design and development process to production releases and support.

Starting from design and development to testing automation and from continuous integration to continuous delivery, the team works together to achieve the desired goal. People having both development and operations skill sets working together and use various tools for CI-CD and Monitoring to respond quickly to customers need and fix issues and bugs.

Why DevOps Matters

In today’s competitive software Industry, Automation and AI plays a major role and to stay ahead in the market and attract your stakeholders and customer we must transform and adapt the DevOps Best Practices. So Why you need DevOps in First place, well

• To stay ahead in the market as competitors are already doing this.
• To increase velocity of the team as well as product delivery.
• To reduce downtime and within a minimum time limits, update the changes on the production.
• To reduce human error by doing all work automated.

Advantages of DevOps

Following are the main benefits of DevOps Practices.

1. Break down the Silos:

I believe the most important benefit using DevOps is to break down the Silos as the Cross-functional development team and operation team works together that is possible due to the self-organized approach of work.

2. Speed:

Delivering the highest business value item quickly and faster product delivery in the market as DevOps follows Agile Principles.

3. Rapid Delivery:

Frequently release the working product in the market to satisfy the market and more importantly customers need, that improves the ROI (Return on investment).

4. Reliability:

By following DevOps best practices and using the best tool for Continuous Integration, Testing Automation, and Continuous Delivery and monitoring the logs helps the team to stay updated and take the real-time decision quickly.

5. Team Collaboration:

DevOps improves the collaborations between the Dev Team and Ops Team, Team works together towards the common business goal.

6. Security:

While implementing automation Security is a very important factor, By Following DevOps model and using Infrastructure as code and by doing automation of process and compliance policies, one can take control security configuration.

7. Risk Management:

Using this practice we can Identify the risk factor early in the application lifecycle stages. Early detection of any issues or bug and quick correction or fixes helps to stay ahead in the competition.

Source By: https://www.dotnettricks.com/learn/devops/what-is-devops-and-devops-advantages

Deffered Defect

(Q). When does a defect gets deferred?

If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status "Deferred" is assigned to such bugs.

The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

Priority and Severity of Defects

(Q). Why do defects have priority and severity?

Priority is defined as parameter that decides the order in which a defect should be fixed. Defect having the higher priority should be fixed first. Severity is a parameter to denote the impact of a particular defect on the software. Priority indicates how soon the bug should be fixed. Severity indicates the seriousness of the defect on the product functionality.

In Software Testing, Defect severity can be categorized into four class

Critical: This defect indicates complete shut-down of the process, nothing can proceed further.

Major: It is a highly severe defect and collapses the system. However, certain parts of the system remain functional.

Medium: It causes some undesirable behavior, but the system is still functional.

Low: It won't cause any major break-down of the system.

Defect priority can be categorized into three class

Low: The Defect is an irritant but repair can be done once the more serious Defect has been fixed.

Medium: During the normal course of the development activities defect should be resolved. It can wait until a new version is created.

High: The defect must be resolved as soon as possible as it affects the system severely and cannot be used until it is fixed.

Importance of Defect Management

(Q). Why is defect management process important in software development teams?

Defect management can be defined as a process of detecting bugs and fixing them. Hence, every software development project requires a process that helps detect defects and fix them. The process of defect management, or bug tracking, is usually conducted at the stage of product testing.

The process of defect management, or bug tracking, is usually conducted at the stage of product testing. Without realizing this it would be hard to understand is the nature of defect management. Software testing can be conducted in two different ways. Usually, the developers test their product themselves. However, there is also a type of testing that is based on user involvement. The final users are often provided with an ability to report on the bugs they found. Nevertheless, this is not the best way of testing, because the users could hardly find all bugs.

The process of defect management usually includes four steps:

1. The first step is the stage of defect detecting.  It can be conducted either by the team of developers or by the users. Regardless of the type of testing, its main goal is to detect all bugs in the final product or its part.

2. The second step of the bug management process is dedicated to the formulation of bug reports. These are the documents that include all necessary information about certain bugs. Usually, they contain data on the type of bug, and the possible ways of its correction.

3. The third step is the stage of bug fixing. After the bugs are fixed, they should be tested once more to make sure that the software works properly.

4. During the final step the bug list is created. This is the document that contains information about all bugs that occurred during the project’s performance. The team often uses the bug list because similar bugs’ occurrence is not rare.

Fields in Bug Report

(Q). What are the fields in a bug report?

Bugs can be reported in a number of ways. However, using a bug tracker is probably the best way for your organization to move bugs from reported to fixed and help your developers stay focused.

Defect_ID: Unique identification number for the defect.

Defect Description: Detailed description of the defect including information about the module in which defect was found.

Version: Version of the application in which defect was found.

Steps: Detailed steps along with screenshots with which the developer can reproduce the defects.

Date Raised: Date when the defect is raised

Reference: where in you Provide reference to the documents like . requirements, design, architecture or maybe even screenshots of the error to help understand the defect

Detected By: Name/ID of the tester who raised the defect

Status: Status of the defect , more on this later

Fixed by: Name/ID of the developer who fixed it

Date Closed: Date when the defect is closed

Severity: which describes the impact of the defect on the application

Priority: which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively.

Difference between Agile Scrum and Kanban

(Q). Difference between Agile Scrum and Kanban?

Scrum is an agile process that helps to deliver the business value in the shortest time. It rapidly and repeatedly inspects actual working software. It emphasizes on teamwork and iterative progress of the software. Its goal is to deliver new software every 2-4 weeks.

Kanban is a visual system for managing work. It visualizes both the process and the actual work passing through that process. The main objective of implementing Kanban is to identify potential bottlenecks in the process and fix them. Kanban goal is that work flow should proceed smoothly at an optimal speed.

	Kanban	Scrum
Role and Responsibilities	There are no pre-defined roles for a team. Although there may still be a Project Manager, the team is encouraged to collaborate and chip in when any one person becomes overwhelmed.	Each team member has a predefined role, where the Scrum master dictates timelines, Product owner defines goals and objectives and team members execute the work.
Due Dates / Delivery Timelines	Products and processes are delivered continuously on an as-needed basis (with due dates determined by the business as needed).	Deliverable are determined by sprints or set periods of time in which a set of work must be completed and ready for review.
Why Use?	Kanban methodology is designed to meet minimal resistance. So, it allows continuous small incremental and evolutionary changes to the current process. It also helps to achieve improvements regarding throughput, lead time and quality.	Scrum methodology can offer project management for every business, and even across life in general. By using Scrum, the development team becomes more Agile and discovering how to react quickly and respond to the sudden changes.
When to use?	Kanban boards allow visual management of software development project work. This helps team members to see work in progress. It also helps them to understand complex information like processes and risks associated to complete work on time.	Scrum methodology is used in a project where the requirement is rapidly changing. It works on a self-organizing, cross-functional team principle. The Scrum Framework usually deal with the fact that the conditions are likely to change quickly or most of the time not known at the start of the project.
Modifications / Changes	Allows for changes to be made to a project mid-stream, allowing for iterations and continuous improvement prior to the completion of a project.	Changes during the sprint are strongly discouraged.

Roles in agile scrum

(Q). What are the Roles in agile scrum?
The roles in Scrum are quite different from the traditional software methods. Clearly defined roles and expectations help individuals perform their tasks efficiently. In Scrum,there are mainly three roles Product Owner, Development Team, and Scrum Master.

Product Owner: 

• A Product Owner owns the Product backlog and writes user stories and acceptance criteria. 
• A Product Owner is responsible for prioritizing the Product Backlog is prioritized and decides the release date and the content. 
• A Product Owner accepts or rejects product backlog item.
• A Product Owner has the power to cancel the Sprint, if he thinks the Sprint goal is redundant.
• A Product Owner is the one who is responsible for the Return on Investment of the product.

Scrum Master: 

• A Scrum Master is not typically a manager or lead, but he is an influential leader and coach who does not do direct command and control. 
• A Scrum Master is a facilitator and Servant Leader who encourages and demands self-organization from the development team.
• A Scrum Master enables close cooperation across all roles and functions, addresses resource issue and disobedience of scrum practices. 
• A Scrum Master protects the team from external and internal distractions.        

Development Team:

• The Development Team is self-organizing, with a very high degree of autonomy and accountability.
• The Development Team decides how many items to build in a Sprint, and how best to accomplish that goal.
• The Development Team is a cross functional, small and self-organizing team which owns the collective responsibility of developing, testing and releasing the Product increment.
• The Development Team may not appoint any team lead since decisions are taken collectively by the team.