Reading Time: 5 mins
It is a sequence of activities carried out by testers to perform high quality software. Though STLC uses term ‘testing’ it does not involve only testing task done by tester but also includes task contributed by developers, quality analysts and other stakeholders.
Testing Process: Waterfall Method
- Requirement collection
- Analytical study
- Design
- Coding
- Testing
- Integration
- Operation and Maintenance
Software Testing Life Cycle
- Requirement analysis
- Test planning
- Test scenario preparation
- Test case preparation
- RTM
- Test case execution
- Defect logging/tracking
- Test execution report
- Retrospection meeting
- Approval/Confirmation
- Test case stored in a repository
Requirement Analysis
In this phase, the QA team gathers details about system study and specifications based on project requirements wherein, they interact with various stakeholders to ensure the necessity of AUT (Application Under Testing). The requirements discussed are based upon functional and non-functional specifications.
- Customer requirements
- System requirements
- Functional specification document
Test Planning
It involves a series of activities that are been followed to deliver a certified software product. It includes the overall approach of the software test methodologies;
- Hardware and software availability
- Entry and exit criteria
- Test plan
- Effort estimation
- Risk analysis
- Training requirements
Test Scenario Preparation
It is defined as whether any functionality can be tested, it is also called as a test condition or test possibility.
- It ensures creating a complete test coverage
- It also serves as a quick tool to determine the testing work effort
Test Case Preparation
This case is developed based on the detailed scope on test cases and test data. It includes: creation, verification and rework of test cases & test scripts.
- The test case must be simple, self-explanatory and filled with required test data.
- It must be precise, to the point and framed to be a valid one, so the new tester can easily execute the test case with ease.
- Directed towards the end user’s point of view and one expected result.
- It must be linked to the concerned Requirement ID and thereby, assured to be traceable.
- A unique identification number must be provided to every test case for ease of maintenance.
- Equal recognition must be given to negative and failure conditions.
- Create a variety of test cases as per the demand such as the valid date for the positive test cases and invalid data for the negative test cases.
- Create distinct test cases with regard to the different testing aspects such as the basic performance testing, security aspects and so forth.
- Must ensure the usability aspects and the overall style guidelines to confirm the product is user-friendly.
RTM (Requirement Traceability Matrix)
The Requirement Traceability Matrix (RTM) captures all the requirement proposed by the client and traceability into —– document. The main purpose of RTM is to see whether all test cases got covered so that no functionality will be missed while doing the slow testing. The simple way to trace requirement with corresponding test scenario and test cases merely termed as RTM. Traceability matrix is a typical worksheet that contains requirements with all possible test scenarios and cases.
Purposes
- To confirm 100% test coverage.
- To show overall defect or execution status with a focus on business requirement.
- To analyze the estimation impact on QA teams with respect to revisiting or re-working test cases.
Test Case Execution
The test case is something that is developed for a specific scenario by the tester to determine whether the application under test (AUT) meets the initial requirements and specifications. The test case usually comprises a set of test data, preconditions, certain inputs regarding the expected and actual results, post-conditions and so forth.
Sample Template:
Usually, the test case template will consist of the following elements and depending on the test management tool used, the pattern may vary from one tool to another.
Test Suit ID – It is the ID of the test suite which you going to execute.
Test Case ID – It is the ID of the test case which you going to execute.
Test Case Summary – An overview (or a summary) of the executing test case.
Related Requirement – The ID of the test case’s related requirement.
Prerequisites – Recognizing the pre-conditions of a test case.
Test Procedure – The steps involved while executing the test case.
Test Data – The data used while executing the test case.
Expected Result – The expected result of the test case, usually the initial requirements and specifications.
Actual Result – The arrived or the actual result of the executed test case.
Status – The status of the executed test case such as pass, fail, incomplete and blocked.
Remarks – Any other comments regarding the executed test case.
Created by – Name of the person who created the test case.
Date of Creation – Date when the test case has been created.
Executed by – Name of the person who executed the test case.
Date of Execution – Date when the test cases has been executed.
Test Environment – Whether it is a hardware, software or network environment.
Defect Logging/Tracking
Developing a product or application as defect-free is simply an unrealistic situation. Acknowledging this software trait, the aim of testing is always been to confirm that the application is less error-prone to defects.
- The Defect is a mistake or fault which is recognized during the development stage and subsequently fixed by the developers during the development stage itself.
- A Bug can be also regarded as an informal name of defect were the tester finds a mistake in an application or in a system during the testing phase.
- The Defect Logging gives an approach to log or register upon defects being found while testing the application and the defects are logged or tracked using defect tools like Bugzilla, Rally, DLM, JIRA, BogTrack.
The different status of bugs are as following,
- New
- Assign
- Open
- Fixed
- Retest
- Verify
- Reopen
- Duplicate
- Deferred
Test Execution Report
The test execution report helps to document the data (summary of the test activities and overall test results) obtained during the software development life cycle. It shows the testing results in comparison to the test objectives and usually comprises the test run details and defect information.
Further, it acts a memorandum to provide a detailed summary about the type and cruciality of errors found and the number of (open, resolved and closed) bugs to be addressed. Thus, the test execution report plays a significant role for the stakeholders to determine whether the Product is ready to launch or not.
What must be contained in a test report?
- Overview
- Variances
- Assessment
- Results
- Evaluation
- Summary of Activities
- Approvals
Test Report Template
- Project Title
- Type of Test
- Functions
- Summary/Description
- No. of Executed Test Cases
- No. of Passed Test Cases
- No. of Failed Test Cases
- No. of Pending Test Cases
- Priority
- Comments/Remarks
- Retrospective Meeting
The retrospective meeting is an important phase in Agile methodology, wherein the team conducts a meeting usually at the end of every iteration (or each sprint) to look back on the so far developments. The main motto of the retrospective meeting is continuous improvement and evolving as a team. The entire purpose of the meeting is to focus on three major questions such as:
- What we must STOP doing?
- What we must START doing?
- What we must CONTINUE to do?
How, Why, When?
Generally, the retrospective meeting is held soon after the sprint review meeting is completed. When the sprint review meeting is held on the view of what has been done, the retrospective meeting is held on the view of how it has been done (the sprint process). The product owner, scrum master and the team become the participants of this meeting, at times persons from higher authority are also invited.
Approval/Confirmation
At the time of product launch, the developers, development manager, QA team, deployment engineer, product owner and other stakeholders gather for an approval meeting. This approval meeting forms a subset of Test Cycle Closure, wherein the test completion is validated based on test coverage and software quality. The lessons learnt from the testing process are eventually documented and prepared for test closure reporting.
The primary task of this phase is to ensure whether all the test cases have been reviewed and approved.
Test Case Stored in Repository
Post the approval phase, it is significant to continuously maintain the test cases in a repository. Any change within the test case must be added within your repository too and the test cases which is no longer in use must also be eliminated from the repository. Further, building definite directories and adopting an effective test management tool leads to a better way of structuring the test cases in a repository.
- Add and constantly update (any new changes) the test cases in a repository.
- Construct distinct directories for effective organizing the test cases.
- Follow a test case management tool to prevent hassle-free maintenance of the test cases.
Are you looking for the best test management tools for creating and maintaining your test cases, establish traceability and defect management? Below are the top 10 test management tools to facilitate your testing activities:
- qTest
- PractiTest
- Zephyr
- Test Collab
- TestFLO for JIRA
- XQual
- Xray – Cutting Edge Test Management
- TestRail
- QACoverage
- Requirements and Test Management for Jira (RTM)
- SPIRATEST by Inflectra
- Kualitee
- aqua
- Testpad
- JunoOne
- ReQtest
- TestMonitor
- Klaros-Testmanagement
- JIRA