- Software Testing is a method to check whether the actual software product matches expected requirements and to ensure that software product is Defect free. It involves execution of software/system components using manual or automated tools to evaluate one or more properties of interest.
- Software testing is the process of evaluating and verifying that a software product or application does what it is supposed to do. The benefits of testing include preventing bugs, reducing development costs and improving performance.
- Testing is important because software bugs could be expensive or even dangerous.
- Software bugs can potentially cause monetary and human loss, and history is full of such examples.
- The testing is important since it discovers defects/bugs before the delivery to the client.
- which guarantees the quality of the software.
- It makes the software more reliable and easy to use.
- Thoroughly tested software ensures reliable and high-performance software.
- It assures the quality of the product and satisfies the customers as well as users.
- it promises better business optimization (less maintenance cost), reliability, and superior user experience.
-
4 Key Benefits of Software Testing for Your Business
-
Saves Money. First and foremost, software testing saves money. ...
-
Inspires Customer Confidence and Satisfaction. That translates directly to your customers. ...
-
Improves Security. ...
-
Improves Product Quality.
Software Testing Type is a classification of different testing activities into categories, each having, a defined test objective, test strategy, and test deliverables. The goal of having a testing type is to validate the Application Under Test (AUT) for the defined Test Objective.
-
Testing is Classified in to Three Categorys.
-
Functional Testing
-
Non-Functional Testing or Performance Testing
-
Maintenance (Regression and Maintenance)
| Testing Category | Types of Testing | Testing Category | Types of Testing | Testing Category | Types of Testing |
|---|---|---|---|---|---|
| Funtional Testing | Automation Test | Non-Funtional Test | Performance Test | Maintenance Testing | Regression |
| Manual Test | Endurance Test | Maintenance | |||
| Unit Testing | Load | ||||
| Integration Test | volume | ||||
| Smoke test | Scalability | ||||
| UAT Test | Usability | ||||
| Localization | SECURITY TEST | ||||
| Globalization | SYSTEM TEST | ||||
| Interoperability |
| TYPES OF TEST | TYPES OF TEST | TYPES OF TEST | TYPES OF TEST | TYPES OF TEST | TYPES OF TEST | TYPES OF TEST |
|---|---|---|---|---|---|---|
| Acceptance Testing | Accessibility Testing | Active Testing | Alpha Testing | Assertion Testing | API Testing | Beta Testing |
| Agile Testing | Age Testing | Ad-hoc Testing | All-pairs Testing | Automated Testing | Basis Path Testing | Backward Compatibility Testing |
| Benchmark Testing | Big Bang Integration Testing | Binary Portability Testing | Boundary Value Testing | Branch Testing | Breadth Testing | Black box Testing |
| Code-driven Testing | Compatibility Testing | Comparison Testing | Component Testing | Configuration Testing | Compliance Testing | Condition Coverage Testing |
| Compliance Testing | Concurrency Testing | Conformance Testing | Context Driven Testing | Conversion Testing | Decision Coverage Testing | Destructive Testing |
| Dependency Testing | Dynamic Testing | Domain Testing | Error-Handling Testing | End-to-end Testing | Endurance Testing | Exploratory Testing |
| Fault injection Testing | Functional Testing | Formal verification Testing | Fuzz Testing | Gorilla Testing | Gray Box Testing | Glass box Testing |
| GUI software Testing | Globalization Testing | Hybrid Integration Testing | Integration Testing | Interface Testing | Install/uninstall Testing | Loop Testing |
| Manual Scripted Testing | Manual-Support Testing | Model-Based Testing | Mutation Testing | Modularity-driven Testin | Non-functional Testing | Negative Testing |
| Operational Testing | Pair Testing | Passive Testing | Parallel Testing | Path Testing | Penetration Testing | Performance Testing |
| Qualification Testing | Ramp Testing | Regression Testing | Recovery Testing | Requirements Testing | Security Testing | Sanity Testing |
| Scenario Testing | Scalability Testing | Statement Testing | Static Testing | Stability Testing | Smoke Testing | Storage Testing |
| Stress Testing | Structural Testing | System Testing | System integration Testing | Top Down Integration Testing | Thread Testing | Upgrade Testing |
| Unit Testing | User Interface Testing | Usability Testing | Volume Testing | Vulnerability Testing | White box Testing | Workflow Testing |
Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. This testing methodology is done during the development process by the software developers and sometimes QA staff.
A unit is a single testable part of a software system and tested during the development phase of the application software. The purpose of unit testing is to test the correctness of isolated code
- The process becomes agile. This is the main benefit of unit testing
- Quality of Code. Unit testing significantly improves code quality. ..
- Find Software Bugs Easily. ...
- Facilitates Change. ...
- Provides Documentation. ...
- Debugging Process. ...
- Design. ...
- Reduce Costs.
• NUnit.
• JUnit.
• TestNG.
• Mockito.
• PHPUnit.
• https://www.youtube.com/watch?v=jFQfuIEd8sU • https://www.youtube.com/watch?v=SOhM7UP-C0I
- Integration testing -- also known as integration and testing (I &T) -- is a type of software testing in which the different units, modules or components of a software application are tested as a combined entity. However, these modules may be coded by different programmer
- Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements. It occurs after unit testing and before system testing.
- The purpose of the integration testing is to expose faults in the interaction between integrated units. Once all the modules have been unit tested, integration testing is performed.
Big-bang, mixed (sandwich), Risky-hardest, Top-down, Bottom-up.
Collaboration integration,
Backbone integration,
Layer integration,
Client-server integration,
Distributed services integration
High-frequency integration.
https://www.youtube.com/watch?v=8UfQ8quw0Eg https://www.youtube.com/watch?v=xZSYh4JxzTY
What is meant by system testing? System testing, also referred to as system-level tests or system-integration testing, is the process in which a quality assurance (QA) team evaluates how the various components of an application interact together in the full, integrated system or application.
System Testing is a level of testing that validates the complete and fully integrated software product. The purpose of a system test is to evaluate the end-to-end system specifications. Usually, the software is only one element of a larger computer-based system. Ultimately, the software is interfaced with other software/hardware systems. System Testing is actually a series of different tests whose sole purpose is to exercise the full computer-based system.
The purpose of system testing is to ensure that a system meets its specification and any non-functional requirements (such as stability and throughput) that have been agreed with its users.
System Testing is the level of software testing performed before Acceptance Testing and after Integration Testing. It comes under Black Box testing, i.e., only external working features of the software evaluated during this testing.
System Test is renowned as end-to-end testing, as it verifies the entire software. It provides a comprehensive report on the performance and compliance of the system with the business specified requirement. Also, at this level, the whole system is validated with unit-level performance.
- Regression Testing.
- Load Testing.
- Functional Testing.
- Recovery Testing.
- Migration Testing.
- Usability Testing.
- Software and Hardware Testing.
-
Acceptance Testing is a method of software testing where a system is tested for acceptability. The major aim of this test is to evaluate the compliance of the system with the business requirements and assess whether it is acceptable for delivery or not.
-
It is a formal testing according to user needs, requirements and business processes conducted to determine whether a system satisfies the acceptance criteria or not and to enable the users, customers or other authorized entities to determine whether to accept the system or not.
-
Acceptance Testing is the last phase of software testing performed after System Testing and before making the system available for actual use.
- User acceptance testing is used to determine whether the product is working for the user correctly. Specific requirements which are quite often used by the customers are primarily picked for the testing purpose. This is also termed as End-User Testing.
- BAT is used to determine whether the product meets the business goals and purposes or not.
- BAT mainly focuses on business profits which are quite challenging due to the changing market conditions and new technologies so that the current implementation may have to being changed which result in extra budgets.
- CAT is a contract which specifies that once the product goes live, within a predetermined period,
- the acceptance test must be performed and it should pass all the acceptance use cases.
- Here is a contract termed as Service Level Agreement (SLA), which includes the terms where the payment will be made only if the Product services are in-line with all the requirements, which means the contract is fulfilled.
- Sometimes, this contract happens before the product goes live.
- There should be a well defined contract in terms of the period of testing, areas of testing, conditions on issues encountered at later stages, payments, etc.
- RAT is used to determine whether the product violates the rules and regulations that are defined by the government of the country where it is being released. This may be unintentional but will impact negatively on the business.
- Generally, the product or application that is to be released in the market, has to go under RAT, as different countries or regions have different rules and regulations defined by its governing bodies.
- If any rules and regulations are violated for any country then that country or the specific region then the product will not be released in that country or region.
- If the product is released even though there is a violation then only the vendors of the product will be directly responsible.
- OAT is used to determine the operational readiness of the product and is a non-functional testing. It mainly includes testing of recovery, compatibility, maintainability, reliability etc.
- OAT assures the stability of the product before it is released to the production.
- Alpha testing is used to determine the product in the development testing environment by a specialized testers team usually called alpha testers.
- Beta testing is used to assess the product by exposing it to the real end-users, usually called beta testers in their environment. Feedback is collected from the users and the defects are fixed. Also, this helps in enhancing the product to give a rich user experience.
- To find the defects missed during the functional testing phase.
- How well the product is developed.
- A product is what actually the customers need.
- Feedbacks help in improving the product performance and user experience.
- Minimize or eliminate the issues arising from the production.
- User Acceptance Testing (UAT) is a type of testing performed by the end user or the client to verify/accept the software system before moving the software application to the production environment. UAT is done in the final phase of testing after functional, integration and system testing is done.
- The main Purpose of UAT is to validate end to end business flow. It does not focus on cosmetic errors, spelling mistakes or system testing. User Acceptance Testing is carried out in a separate testing environment with production-like data setup. It is kind of black box testing where two or more end-users will be involved.
- Client
- End users
In VModel, User acceptance testing corresponds to the requirement phase of the Software Development life cycle(SDLC).
- Business Requirements must be available.
- Application Code should be fully developed
- Unit Testing, Integration Testing & System Testing should be completed
- No Showstoppers, High, Medium defects in System Integration Test Phase –
- Only Cosmetic error is acceptable before UAT
- Regression Testing should be completed with no major defects
- All the reported defects should be fixed and tested before UAT
- Traceability matrix for all testing should be completed
- UAT Environment must be ready
- Sign off mail or communication from System Testing Team that the system is ready for UAT execution
- Prepare UAT plan early in the project life cycle
- Prepare Checklist before the UAT starts
- Conduct Pre-UAT session during System Testing phase itself
- Set the expectation and define the scope of UAT clearly
- Test End to End business flow and avoid system tests
- Test the system or application with real-world scenarios and data
- Think as an Unknown user to the system
- Perform Usability Testing
- Conduct Feedback session and meeting before moving to production
https://www.youtube.com/watch?v=lCMBtr4wfRc
- Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. STLC involves both verification and validation activities. Contrary to popular belief, Software Testing is not just a single/isolate activity, i.e. testing. It consists of a series of activities carried out methodologically to help certify your software product. STLC stands for Software Testing Life Cycle.
- Requirement Analysis
- Test Planning
- Test case development
- Test Environment setup
- Test Execution
- Test Cycle closure
https://youtu.be/Dq5IYYqnnGQ?list=UU19i1XD6k88KqHlET8atqFQ
Requirement Phase Testing also known as Requirement Analysis in which test team studies the requirements from a testing point of view to identify testable requirements and the QA team may interact with various stakeholders to understand requirements in detail. Requirements could be either functional or non-functional. Automation feasibility for the testing project is also done in this stage.
- Identify types of tests to be performed.
- Gather details about testing priorities and focus.
- Prepare Requirement Traceability Matrix (RTM).
- Identify test environment details where testing is supposed to be carried out.
- Automation feasibility analysis (if required).
Test Planning in STLC is a phase in which a Senior QA manager determines the test plan strategy along with efforts and cost estimates for the project. Moreover, the resources, test environment, test limitations and the testing schedule are also determined. The Test Plan gets prepared and finalized in the same phase.
- Preparation of test plan/strategy document for various types of testing
- Test tool selection
- Test effort estimation
- Resource planning and determining roles and responsibilities.
- Training requirement
The Test Case Development Phase involves the creation, verification and rework of test cases & test scripts after the test plan is ready. Initially, the Test data is identified then created and reviewed and then reworked based on the preconditions. Then the QA team starts the development process of test cases for individual units.
- Create test cases, automation scripts (if applicable)
- Review and baseline test cases and scripts
- Create test data (If Test Environment is available)
Test Environment Setup decides the software and hardware conditions under which a work product is tested. It is one of the critical aspects of the testing process and can be done in parallel with the Test Case Development Phase. Test team may not be involved in this activity if the development team provides the test environment. The test team is required to do a readiness check (smoke testing) of the given environment.
- Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment.
- Setup test Environment and test data
- Perform smoke test on the build.
Test Execution Phase is carried out by the testers in which testing of the software build is done based on test plans and test cases prepared. The process consists of test script execution, test script maintenance and bug reporting. If bugs are reported then it is reverted back to development team for correction and retesting will be performed.
- Execute tests as per plan
- Document test results, and log defects for failed cases
- Map defects to test cases in RTM
- Retest the Defect fixes
- Track the defects to closure
Test Cycle Closure phase is completion of test execution which involves several activities like test completion reporting, collection of test completion matrices and test results. Testing team members meet, discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from current test cycle. The idea is to remove process bottlenecks for future test cycles.
- Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical Business Objectives, Quality
- Prepare test metrics based on the above parameters.
- Document the learning out of the project
- Prepare Test closure report
- Qualitative and quantitative reporting of quality of the work product to the customer.
- Test result analysis to find out the defect distribution by type and severity.
Defect Life Cycle, also known as Bug Life Cycle, is the journey of a defect, the cycle which a defect goes through during its lifetime. It varies from organization to organization and also from project to project, as it is governed by the software testing process and also depends upon the tools used.
The following diagram shows the workflow of a Defect Life Cycle.
Following are the different states of a Defect Life Cycle.
-
New − Potential defect that is raised and yet to be validated.
-
Assigned − Assigned against a development team to be addressed.
-
Active − The Defect is being addressed by the developer and investigation is under progress. At this stage, there are two possible outcomes – Deferred or Rejected.
-
Test / Fixed / Ready for Retest − The Defect is fixed and ready for testing.
-
Verified − The Defect that is retested and the test has been verified by QA.
-
Closed − The final state of the defect that can be closed after the QA retesting or can be closed if the defect is duplicate or considered as NOT a defect.
-
Reopened − When the defect is NOT fixed, QA reopens/reactivates the defect.
-
Deferred − When a defect cannot be addressed in that particular cycle it is deferred to future release.
-
Rejected − A defect can be rejected for any of the three reasons – duplicate defect, NOT a Defect, Non Reproducible.
A Test Case is a set of actions executed to verify a particular feature or functionality of your software application. A Test Case contains test steps, test data, precondition, postcondition developed for specific test scenario to verify any requirement. The test case includes specific variables or conditions, using which a testing engineer can compare expected and actual results to determine whether a software product is functioning as per the requirements of the customer.
https://www.youtube.com/watch?v=g0PrXoWKM2Y
Create test cases that are as simple as possible. They must be clear and concise as the author of the test case may not execute them.
Use assertive language like go to the home page, enter data, click on this and so on. This makes the understanding the test steps easy and tests execution faster.
The ultimate goal of any software project is to create test cases that meet customer requirements and is easy to use and operate. A tester must create test cases keeping in mind the end user perspective
Do not repeat test cases. If a test case is needed for executing some other test case, call the test case by its test case id in the pre-condition column
Do not assume functionality and features of your software application while preparing test case. Stick to the Specification Documents.
Make sure you write test cases to check all software requirements mentioned in the specification document. Use Traceability Matrix to ensure no functions/conditions is left untested.
Name the test case id such that they are identified easily while tracking defects or identifying a software requirement at a later stage.
It’s not possible to check every possible condition in your software application. Software Testing techniques help you select a few test cases with the maximum possibility of finding a defect.
Boundary Value Analysis (BVA): As the name suggests it’s the technique that defines the testing of boundaries for a specified range of values. Equivalence Partition (EP): This technique partitions the range into equal parts/groups that tend to have the same behavior. State Transition Technique: This method is used when software behavior changes from one state to another following particular action. Error Guessing Technique: This is guessing/anticipating the error that may arise while doing manual testing. This is not a formal method and takes advantages of a tester’s experience with the application
The test case you create must return the Test Environment to the pre-test state and should not render the test environment unusable. This is especially true for configuration testing.
The test case should generate the same results every time no matter who tests it
After creating test cases, get them reviewed by your colleagues. Your peers can uncover defects in your test case design, which you may easily miss.
Test management tools are the automation tools that help to manage and maintain the Test Cases. Main Features of a test case management tool are
-
For documenting Test Cases: With tools, you can expedite Test Case creation with use of templates
-
Execute the Test Case and Record the results: Test Case can be executed through the tools and results obtained can be easily recorded.
-
Automate the Defect Tracking: Failed tests are automatically linked to the bug tracker, which in turn can be assigned to the developers and can be tracked by email notifications.
-
Traceability: Requirements, Test cases, Execution of Test cases are all interlinked through the tools, and each case can be traced to each other to check test coverage.
-
Protecting Test Cases: Test cases should be reusable and should be protected from being lost or corrupted due to poor version control. Test Case Management Tools offer features like
-
Naming and numbering conventions
-
Versioning
-
Read-only storage
-
Controlled access
-
Off-site backup
-
Popular Test Management tools are: Quality Center and JIRA
- The Description of what requirement is being tested
- The Explanation of how the system will be tested
- The test setup like a version of an application under test, software, data files, operating system, hardware, security access, physical or logical date, time of day, - prerequisites such as other tests and any other setup information pertinent to the requirements being tested
- Inputs and outputs or actions and expected results
- Any proofs or attachments
- Use active case language
- Test Case should not be more than 15 steps
- An automated test script is commented with inputs, purpose and expected results
- The setup offers an alternative to pre-requisite tests
- With other tests, it should be an incorrect business scenario order
A Test Scenario is defined as any functionality that can be tested. It is also called Test Condition or Test Possibility. As a tester, you should put yourself in the end user’s shoes and figure out the real-world scenarios and use cases of the Application Under Test. https://youtu.be/wMN0pCyjQ9E
- Consider a hypothetical situation: There is a vast ocean. You have to travel across the ocean from one seashore to another. For example, from Mumbai, India Seashore to Colombo, Srilanka seashore.
- The mode of travel you can opt for are:
- (i) Airways: Take a flight to Colombo
(ii) Waterways: Prefer a ship to travel to Colombo
(iii) Railways: Take a train to Srilanka
Traveling from Mumbai seashore to Colombo seashore is a functionality that is to be tested.
- Traveling by Airways,
- Traveling by Waterways or
- Traveling by Railways.
- These test scenarios will have test cases.
- Test Scenario: Travelling By Airways
-
The flight is as per the scheduled time.
-
The flight is not as per the scheduled time.
-
An emergency situation has ensued (heavy rainfall and storm).
-
In the same way, a separate set of test cases can be written for other remaining scenarios.
-
Now let’s get to the technological test scenarios.
-
Anything that can be tested is a Test Scenario. Thus we can state that any software functionality that is under test can be divided into multiple smaller - functionalities and can be termed a ‘Test Scenario’.
-
Before delivering any product to the client, the quality of the product needs to be appraised and evaluated. Test scenario aids in assessing the functional quality of a software application that is in conformance with its business requirements.
-
A tester scenario is a process wherein the tester tests a software application from an end-user perspective. The performance and quality of the software application are thoroughly assessed before implementation in the production environment.
- One Test Scenario can have multiple ‘Test Cases’. It can be figured as a big panoramic image and test cases are the small parts that are important to complete the panorama.
- It is a single line statement and test cases comprise step-wise description to complete the purpose of the test scenario statement.
Test Scenario: Make the payment for the cab service availed.
(i) Payment method to be used: PayPal, Paytm, Credit/Debit Card. (ii) The payment done is successful. (iii) Payment done is unsuccessful. (iv) The payment process aborted in between. (v) Not able to access payment methods. (vi) The application breaks down in between.
- Test Scenarios thus assist in evaluating the software application as per the real-world situations.
- Test scenarios when determined, help in bifurcating the scope of testing.
- This bifurcation is termed prioritization which helps in determining the important functionalities of the software application.
- Prioritized testing of the functionalities, assists to a great extent in the successful implementation of the software application.
- As the test scenarios get prioritized, the most important functionalities can be easily identified and tested on priority. This ensures that the majority of the - - - crucial functionalities are working fine and defects related to it are duly captured and rectified.
- Test scenarios determine the business process flow of the software and thus end-to-end testing of the application is possible.
| Test Scenario | Test Cases |
|---|---|
| Test scenario is a concept | Test cases are the solutions to verify that concept |
| Test Scenario is a high level functionality | Test cases are detailed procedure to test the high level functionality |
| Test Scenarios are derived from Requirements/ User Stories | Test cases are derived from Test Scenarios |
| Test scenario is ‘What functionality is to be tested | Test Cases are ‘ How to test the functionality |
| Test Scenarios have multiple test cases | Test case may or may not be associated to multiple Test scenarios |
| Single test scenarios are never repeatable | Single test case may be used for multiple times in different scenarios |
| Brief documentations required | Detailed documentation is required |
| Brainstorming sessions are required to finalize a Test Scenario | Detailed technical knowledge of the software application is required |
| Time saver as minute details is not required | Time consuming as every minute detail needs to be taken care of |
| Maintenance cost is low as resources required are low | Maintenance cost is high as resources required are high |
- Take the example of a test scenario for Cab booking.
- The scenarios could be cab booking options, payment methods, GPS tracking, road map displayed correctly or not, cab and driver details displayed correctly or not, - etc all are listed in the test scenario template.
- Now suppose the test scenario is to check whether the location services are turned on, if not turned on, display the message ‘Turn on-location services. This - scenario is missed and not listed in the test scenarios template.
- The ‘Location service’ scenario gives rise to other test scenarios related to it.
- Creating Test Scenarios ensures complete Test Coverage 0- Test Scenarios can be approved by various stakeholders like Business Analyst, Developers, Customers to ensure the Application Under Test is thoroughly tested. It ensures that the software is working for the most common use cases.
- They serve as a quick tool to determine the testing work effort and accordingly create a proposal for the client or organize the workforce.
- They help determine the most important end-to-end transactions or the real use of the software applications.
- For studying the end-to-end functioning of the program, Test Scenario is critical.
- Read the Requirement Documents like BRS, SRS, FRS, of the System Under Test (SUT). You could also refer uses cases, books, manuals, etc. of the application to be tested.
- For each requirement, figure out possible users actions and objectives. Determine the technical aspects of the requirement. Ascertain possible scenarios of system abuse and evaluate users with hacker’s mindset.
- After reading the Requirements Document and doing your due Analysis, list out different test scenarios that verify each feature of the software.
- Once you have listed all possible Test Scenarios, a Traceability Matrix is created to verify that each & every requirement has a corresponding Test Scenario
- The scenarios created are reviewed by your supervisor. Later, they are also reviewed by other Stakeholders in the project.
- A defect in a software product is also known as a bug, error or fault which makes the software produce an unexpected result as per the software requirements.
- For example; - incorrect data, - system hangs, - unexpected errors, - missing or incorrect requirements.
-
A defect report is a document that has concise details about what defects are identified, what action steps make the defects show up, and what are the expected results instead of the application showing error (defect) while taking particular step by step actions.
-
Defect reports are usually created by the Quality Assurance team and also by the end-users (customers).
-
Often customers detect more defects and report them to the support team of the software development since the majority of the customers curiously tries out every feature in the application. Now, you know what actually defect and defect reports are.
-
The reason behind why defect reports are created is to help developers to find out the defects easily and fix them up.
-
A defect report is usually assigned by QA to a developer who then reads the report and reproduces the defects on the software product by following the action steps mentioned in the report.
-
After that, the developer fixes the defects in order to get the desired outcome specified in the report.
-
That is why the defect reports are important and created carefully.
-
Defect reports should be short, organized, straight to the point and covers all the information that the developer needs to detect the actual defects in the report by doing what and how the one written the defect report detected the defects.
It is usual for QA teams to get defect reports from the clients that are either too short to reproduce and rectify or too long to understand what actually went wrong.
Defect Description : The application doesn’t work as expected.
-
Now, how in the world does a developer or QA know what went wrong which doesn’t meet the client expectation?
-
In such a case, the developer report to the QA that he couldn’t find any problem or he may have fixed any other error but not the actual one client detected. So that’s why it’s really important to create a concise defect report to get bugs fixed.
-
All right. You have a pretty good idea about what, whys and how’s of a defect report. So it’s time for what is inside the report.
-
Defect ID : Nothing but a serial number of defects in the report.
-
Defect Description : A short and clear description of the defect detected.
-
Action Steps : What the client or QA did in an application that results in the defect. Step by step actions they took.
-
Expected Result : What results are expected as per the requirements when performing the action steps mentioned.
-
Actual Result : What results are actually showing up when performing the action steps.
-
Severity : Trivial (A small bug that doesn’t affect the software product usage).
- Low – A small bug that needs to be fixed and again it’s not going to affect the performance of the software.
- Medium – This bug does affect the performance. Such as being an obstacle to do a certain action. Yet there is another way to do the same thing.
- High – It highly impacts the software though there is a way around to successfully do what the bug cease to do. Critical – These bugs heavily impacts the performance of the application. Like crashing the system, freezes the system or requires the system to restart for working properly.
-
Attachments : A sequence of screenshots of performing the step by step actions and getting the unexpected result. One can also attach a short screen recording of performing the steps and encountering defects. Short videos help developers and/or QA to understand the bugs easily and quickly.
-
Additional information : The platform you used, operating system and version. And other information which describes the defects in detail for assisting the developer understand the problem and fixing the code for getting desired results.
- Defect Triage Meeting is generally called to resolve and fix defect.
- Different participants i.e. Test Lead, Project Manager, Technical Lead, and Development Team Lead are important participants of meeting. Without them, no decision can be taken and meeting cannot be completed.
- In three different phases i.e. pre-meeting, during meeting, and post-meeting, defect triage meeting is completed.
- After the meeting, a triage report is generated that contains full descriptions and detail about each of everything that happened during meeting.
- This triage report contains all information starting from identification of defect until root cause of defect.
- This report is shared with all participants of meeting
- Various Fields in a Defect Triage Report
Defect ID is an identity document that is generally used to verify or identify defects. Defect ID is basically a unique identification number that is given to each defect to differentiate them from each other.
Defect description generally includes detailed description of defect. It also includes information regarding module in which defect was identified. It also includes defect causes and how it affects working of the system.
Creation date is the date on which defect was identified or found or raised. On creation date, defect was reported for first time.
Creator is the tester who has raised or identified defects. Creator might include name or ID of tester who has reported defect.
Severity basically explains impact of defect on system or application. It includes how defect affects system. It simply measures degree of severity i.e., how severe defect is.
Priority is basically related to resolving or fixing defect. Priority code simply indicates effects of particular defect on system. Priority code can be high, medium, or low.
- High – If priority code is high, that means defect is needed to resolved or fixed immediately. Without resolving this particular defect, project cannot be successful.
- Medium – If priority code is medium, that means particular defect is not needed to resolved or fixed immediately. It can be resolved later as it doesn’t require any immediate action. Defect causes less impact on the system.
- Low – If priority code is low, that means defect is not needed to resolved or fixed. It may or may not be resolved. Defect causes very low and negligible impact on system.
This indicates present status of defect i.e., whether defect is new, or is in progress, or completed.
Assignment date is the date on which defect was given further for fixing or resolving it. On this date, defect was assigned to particular team or person for resolution.
Developer is the tester who has fixed or resolved defects. Developer might include name or ID of tester who has fixed defect.
Resolution generally includes detailed description of how defect is being resolved. It includes what all things are done to resolve defect.
Date of resolution is the date on which resolution of defect is to be done i.e. date on which defect will be resolved or fixed completely by developers.
Estimated time is basically value expressed in hours of work required to complete resolution i.e., estimated time required to fix or resolve defect.
Actual time is basically value expressed in hours of work taken by developers to complete resolution i.e. actual time taken to fix or resolve defect.
This field explains what is the main cause of defect to arise. It explains why defect appeared and raised.