Software Testing Life Cycle (STLC) & 7 Critical Principles Of Software Testing
Previously, we have discussed the 8 basic types of software development life cycles and the 8 steps to mobile app development life cycle. In both articles, we mentioned the software testing phase as a crucial step in SDLC. And as we have also talked about the importance of software testing and quality assurance services, in this article, we would like to share with you the information answering your question of What is software testing? Software Testing Life Cycle? And the 7 critical principles when it comes to software testing.
Let’s delve in!
Software Testing Background
After completing the application concept with an excellent user interface and compelling copy, the next phase is testing the application / software in different scenarios to discover and correct any technical issues.
However, the trends and competency of software testing are changing rapidly. Testers must pay more attention to the process and technical now. Back in 1960, after the coding phase and all features were implemented, there was no such thing as “testing”, but with the booming in the computing industry, tech companies started to realize the importance of the testing phase since there were many bugs in production. Up till now, testers’ responsibility is extremely important, requiring all of them to learn and work harder, and moreover, to deliver products faster.
Software testing is required from the beginning of the project or sometimes even before the requirements are finalized. Because the testing phase is also standardized, just as software development has a life cycle, the phase also has a life cycle.
So what is Software Testing Life Cycle Anyway?
First, let’s explore the term Life Cycle. In simple terms, life cycle refers to a series of conversions from one form to another. These changes can happen to anything, whether it is tangible or intangible. Every entity has a life cycle, from inception to retirement / collapse.
Likewise, software is also an entity. And as software development consists of a series of steps, testing also contains steps that need to be performed in a certain order (standardize), which makes these a life cycle.
The phenomenon of systematically and planned execution of test activities is called the software testing life cycle (STLC).
The term refers to a testing process where specific steps are taken in a defined sequence to make sure that quality goals are met. Meaning: In the STLC process, each activity is carried out in a planned and systematic manner. Each stage has different delivery goals and tasks.
Also, different organizations have different stages in the STLC. However, the foundation remains the same.
When involving in the STLC, there are 8 phases to expect:
By thoroughly understanding each phase, you can ensure a successful testing stage, leading to your software can work properly in all situations.
8 phases of software testing life cycle
In this STLC stage, there are three entry criteria:
- Requirements specification document,
- Application design document,
- User acceptance criteria document.
In order to fulfill these criteria, you need to have a brainstorming session (1) with your team to create a list of requirements and get any doubts clarified (2), understand the feasibility of the requirements (3) if they can be tested, and do the automation feasibility study (3) if your projects require automation.
You or your software development team expect to release a requirement understanding document, testing feasibility report and automation feasibility report at the end of this stage.
In the real-world scenarios, the test planning phase is the first step to take in the software testing process. During the planning process, some actions needed to be performed are defining the scope of the project (1), risk analyzing and preparing the risk mitigation plan (2), performing test estimation (2), determining the overall testing strategy and process (3), identifying the activities and resources that will help achieving the test goals (4), and identifying the environment (5).
In the test planning stage, the two important factors that affect the whole plan and testing strategy and risk analysis / management and mitigation.
Therefore, at the end of this stage, you or your software development team expect to release a test plan document, risk mitigation document and test estimation document.
This phase helps the testing team to identify what to test via the test conditions document released at the end of the phase.
Essentially, the team needs to define test conditions via the requirement document, test plan, risk mitigation document, and other testing documents mentioned above. The test conditions should be identified based on the requirements.
There are many factors that influence the test conditions’ identification: the level and depth of testing (1), the product’s complexity (2), risks (3), other related software development life cycle phases (4), test management (5), the team’s skills and knowledge (6), stakeholders’ availability (7).
Test conditions should be documented in detail. For example, when testing an E-commerce web application, a test condition can be “User must be able to make a payment via the website”, but in order to clarify any doubts (if there is any), you can detail it out by writing “User can pay via NEFT, Debit Card, Credit Card”.
Since the test cases will be written based on the test conditions, the test coverage can be increased because when you have detailed test conditions, these details will trigger more detailed test cases.
Additionally, you can identify some conditions when you should stop the testing.
This phase helps the testing team to identify how to test via the test conditions document released in the previous phase. Therefore, the testing team needs to detail out the test condition (1), identify the test data (2), and create the traceability metrics (3).
At the end of this phase, you or your software development team expect to have a detailed test condition document, requirement traceability metrics, and test coverage metrics.
Based on the detailed test condition document from the designing phase, in this phase, the team will create and review each test case (1), create and review the automation scripts (only if your project involves automation) (2), identify the candidate test cases for regression and automation (3), identify and create the test data (4), and take sign off of the test cases and scripts (5).
At the end of this phase, you or your software development team expect to have test cases, test scripts, and test data.
As you can guess from the name, this is the phase where the testing team actually executes the test, log bugs or defects in case of discrepancy, and report the status.
Make sure that you have all documents ready, and your entry criteria are met (test cases, test scripts).
At the end of this phase, you or your software development team expect to have test execution report, defect report, test log and defect log, updated requirement traceability metrics.
This STLC phase focuses on the exit and reporting criteria. According to your project selection and your stakeholders, you can decide to submit a daily report of the weekly report, etc.
You can submit different types of reports like Daily Status Report (DSR), Weekly Status Report (WSR), but remember, the content of the report varies and depends on the individual whom you are sending your reports. Your project manager might pay more attention to the technical aspect of the project if they belong to the testing background; therefore, remember to include the technical content in the report, such as the number of passed / failed / error / severity 1 defects test cases. Or you’re sending your report to upper stakeholders, they might not be interested in technical issues and care more about the risks that have been mitigated during the testing phase.
To summarize, at the end of this phase, you or your software development team expect to have an updated traceability metrics, test summary report and an updated risk management report.
This is the last phase of the STLC, tasks for the closure activities including:
- Checking if all test cases are executed (1)
- No severity 1 defects opened (2)
- Lesson learned meeting with whole team (3)
At the end of this phase, you or your software development team expect to have a lesson learnt document for future improvement, test matrices, and a test closure report.
7 principles of software testing
Because the aim of software testing is to find errors, if the testing is done right and successfully, your product will be error free, promising a high quality software / application that meets the needs of your customers.
In order to assure you can run a successful testing phase, besides providing information of 8 essential steps you should take in the software testing life cycle, we would like to introduce you to the 7 principles to keep in mind.
- Defective test: The purpose of software testing is to make one software reveal its errors. Software testing reduces the presence of bugs / defects; therefore, it can guarantee that there are defects, but it cannot prove that the software is defects free. Even when you do 10 times testing, your product is not 100 percent error free. This is the first point we want to stress. So don’t freak out when the more you test, the more errors you find!
- Exhaustive testing is impossible: Keep in mind that exhaustive testing cannot be carried out. Because some software can never be tested under every test case. It can only be done under some and assume that the software is correct (we’re not saying 100 percent error free), and will produce accurate results in each test case. If you test your software under every test case, it will cost a lot of resources and effort, which is not practical.
- Early testing: Like we mention at the very beginning of this article, software testing sometimes can be executed before the requirements are finalized in order to find defects in the software soon. Defects discovered in the early stages of the SDLC will cost less. To get better software performance, software testing can be started from the initial stage, like in the requirement analysis phase.
- Defect clustering: In a project, several modules may contain most of the defects. Pareto principle states that for many outcomes, roughly 80 percent of the consequences come from 20 percent of the causes. Therefore, there is a high chance that 80 percent of the software errors are from the 20 percent of the modules.
- Pesticide paradox: Remember, repeating the same test case again and again will not guarantee you to find new bugs. Therefore, it is necessary to check test cases and add or update the new test case to find new bugs.
- Context-dependent testing: The testing method depends on the context of the software developed. Different types of software need different types of tests. You can execute the same test for an E-Commerce website and an Android app.
- The absence of errors fallacy: Even if a software is 99 percent errors free but does not meet the user’s requirements, it will not be used. This point is quite obvious. But there are still some neglects toward it; hence, we strongly recommend you to go back to the goal of your product: what problem can it solve for the user?
We hope that this article is helpful at answering all of your questions toward software testing. A friendly reminder: you can check this article to understand why we need software testing. Now that you understand the key process in each step of the software testing life cycle, you can easily overcome one of the very last stages when developing a software.
At TP&P Technology, we run software testing and quality assurance services in Vietnam. As one of the top software companies in Vietnam, we have more than 16 years of experience in business management solution consulting, software development and outsourcing. By partnering with us, we believe that together we can build amazing products that truly bring value to your business!
Contact us now to speak to our consulting expects team!