1. Requirement Analysis – QA team tries to identify and understand testable requirements by analysing requirements document and so on. If there are any conflicts, omissions, or uncertainties, the team needs to ask the various stakeholders who have better understanding of the requirements.
2. Test Planning – This is where typically a test manager determines test objectives, the approach for meeting those test objectives, testing effort and cost estimations.
3. Test Design – Test conidtions are developed here based on the gathered requirements during the requirement analysis activity. Those test conditions are further developed into test cases. Identification of necessary test data will be done here as well.
4. Test Environment Setup
5. Test Execution – Test cases developed in Test Design activity will be executed here. If any of the test cases have failed then those will be logged into the defect management system for developers to pick up and fix.
6. Test Cycle Closure – This is where essentially the QA team comes together and do a final review or get a feedback of how things have gone for the current testing process and identify any process improvements. It also involves creating test summary report.

A test cycle is an execution of the test process on a particular build of the test object.

Usually test execution happens in at least 2 cycle. Typically in each cycle, all the test cases will be executed to identify any blocking, critical defects, and most of the high defects.
The goal of the second cycle is to identify remaining high and medium defects, correct gaps in the scripts and obtain results.

Essentially Requirement Traceability Matrix is a document that maps the requirementswith use cases. The purpose is to validate that all requirements have a corresponding test cases written and executed. This helps ensure a 100% test coverage.

This is to prevent developers and testers from stepping on each other’s shoes. Developers are continuously making changes for fixing defects or creating new enhancements. This may cause side effects which include but not limited to:
⦁ Unintentional adverse changes e.g. introduced new bug while fixing a different one or accidentally wiping out the database
⦁ Could slow the application/system by turning on debugging
⦁ Could bring down the application/system by applying/building changes while testing is in progress

Planning/Requirements Analysis : Clients/Customers, project managers, Subject Matter Experts (architects, business analysts, test lead, senior developer)
Define : Business Analysts
Design : Architects and testers, BAs
Build/implement : developers, testers, BAs
Test : Testers, BAs, developers
Deployment and Maintenance : operational team and production support team

Business requirements document (BRD) defines the business requirements of a system i.e. what the business wants/needs to do in order to solve a business problem.
Functional requirements document (FRD) is derived from the BRD and defines how the business requirements will be fulfilled.

‘Design’ phase of the SDLC is where the test cases are created by the QA team. This is because use cases are dervied from the use cases included in the Business Requirements Document. BRD is the product of the ‘Define’ phase of the SDLC. It needs to be written post Functional specification document.

Use case depicts the interactions between the actors and the system. It describes the process flows though a system based on its likely use. Use cases are derived from the client’s requirements and are documented in and are used by developers for building a software solution and testers for creating test cases.
Test case is a series of steps that testers use to validate that a feature of a system is working correctly as intended or is satisfying the business requirements.

In conclusion, use case describes the actions performed by the actors/users and the corresponding behaviour of the system to the user actions. Test cases, on the other hand, are derived from the use cases and are concerned with the input given to the system and the output produced by the system. These are more specific in a sense that each of the test cases cover a single use case scenario i.e. one transactional flow.

The purpose of regression testing is to make sure that the existing functionality of the system has been unaffected by the change and still work as expected. This involves re-running the test cases that were created when the affected functionality has been developed originally.

Smoke testing is carried out to test the health of a software build. It is a test done for the initial stage of the build where the software may not be stable. Testing team will only move onto a next set of tests only when smoke test passes first. Smoke testing is done by both developers and testers.