Testing enables teams to identify and address potential problems before they affect users. It could be a small application or one with millions of people accessing it each day. In either case, QA professionals must test the software to ensure performance efficiency and reliability.
To perform this QA, testers can follow six key phases of the software testing lifecycle.
6 key phases of software testing lifecycle
Many QA professionals follow well-established software testing lifecycle phases to ensure an application performs as expected.
1. Requirement analysis
During this phase, testers map the environments in which the software will run and determine who will use the app. They should consider any possible outcome that can occur, both immediately and in the future. Once this phase is over, the actual planning starts.
2. Test planning
Here is when QA professionals think about what's needed to complete the test and meet objectives. For example, they should consider the following:
- what is needed to test an application that's running in Kubernetes;
- whether it's necessary to test how the application will scale;
- how many users can access the application before it scales; and
- how many resources, such as CPU and memory, the application has before scaling out.
If those are all requirements, testing for Kubernetes will not be complete until all those requirements are met. Testers should plan for as many testing scenarios as they can think of.
Factors every QA professional should consider
There are many factors to think about during software testing, including the following:
- where, geographically, users are going to connect to the app;
- which OSes people will use to interact with the software;
- where the software will be hosted, such as in the cloud or on premises; and
- potential software bugs.
The types of infrastructure on which the application will run can make testing more complex. For example, if the software will potentially run on VMs, serverless platforms and containers, testing must occur for each of those environments.
3. Test case development
After QA professionals plan their tests -- and what they will test -- they must determine the technical details for each test case. For example, if it is necessary to deploy an application to Kubernetes to test it, the testers will need a Kubernetes manifest and some automation scripts to get the application up and running.
Details QA professionals should collect in the test case development phase include the following:
- any necessary automation code;
- where to store the automation code and who will need access to it;
- who's running the tests; and
- written-out test cases.
4. Test environment setup
In this stage of the software testing lifecycle, QA professionals should identify where the tests will run. For example, if a Kubernetes cluster is needed to perform testing, QA should implement one of the several options to deploy one. These include a local computer via Minikube, the cloud or an on-premises cluster.
Of these three options, a Kubernetes cloud service is likely the easiest and fastest way to deploy a testing environment. The reason being: Teams won't need to spend as much time configuring and managing the underlying infrastructure. The goal is to create a testing environment as efficiently as possible, while ensuring that the environment accurately mirrors how users will interact with the application.
5. Test execution
All QA engineers should have shared access to the testing environment and associated code. Contrastingly, it's not a best practice for team members to all store code on their local computers. Instead, testers should store the code in GitHub and execute the automation code via a CI/CD pipeline. This way, the entire team has access to the code, understands how it runs and sees the results.
6. Test reporting
Without reports, tests aren't entirely helpful. Stakeholders, including vice presidents and directors, may want to see initial test reports to understand if an application works as expected.
In this business-centric phase, management will review how the software performs and, from there, decide how to move forward. Management will look for answers to questions like the following:
- Will the app deploy to production?
- Does the code need tweaks?
- Are there any bugs?
Accordingly, the report should include as many details as possible about the testing results.