Basics of Software Testing - Part-V : Software Testing Life Cycle (STLC)

A little background about this - Each person may have their own way of testing or finding issues. They may not necessarily find my method helpful to understand the basics, this is something i'm trying to generalize for the newcomers in software/ firmware testing.  My intention is to make a series out of it, if i can and get enough motivation to write the basic stuffs.

It is really hard to summarize the 4 year course, i’m just touching some topics which may give you an overall idea about the software. Details can be found on Google/ Wiki as well, if interested.

Basics continues…… previous Topics

Software Test Life Cycle (STLC):

Unfortunately, there is no normal recognition of the term, not at least from wikipedia, for the Software Test Life Cycle. I think it’s a good term to describe what we do as a tester.

Testing has its own life cycle. Starting with the Specs. When we get the Specs, we kind of know what the software going to develop and what are the expected functions from the end user. When we get that, we can start the master document of the Testing- Test Plan. Graphical representation is always better for a life cycle.

Following is the Chronological steps that we perform during the testing life cycle.

1. Test Planning - This is the first phase of designing the test. Usually the outcome of this phase is the Test Plan document of the project/product. Test Plan defines what type of testing will be performed in which manner. There are different kind of testing that is defined in terms of the product/ software. We need to define which testing will be performed on which product.

Here is a link for Test Plan that will describe in details what and how to prepare it, something that I wrote couple of years back.

2. Test Cases Development- Derived from the Specs for each functionality with different combination of scenarios. Outcome of this phase would be the Test Case Documentation. On my first writing of this series, I tried to give an idea about how many combinations/ scenario that may happen just for a simple function.

I have not found any specific format or template that can be used as a standard Test Case document, but as long as any documentation that specifies all the scenarios will do. It could be word document, could an excel, could be scripts (for automation testing). The idea is to document the ideas so that we can keep the track of it.

3. Test Execution - We do the testing in different phase and each has its own definition. There is not hard and fast rule, but the following one that i made, at least it make senses in terms of testing a product. There are different types of testing we do for Software testing in phases. Following will give an idea what we do in different phases. There could be many more testing types depending on product/ project. I just tried to give an overall steps here. Instead of boring you with the definition of each test type, just mentioning the name.

4. Bug Reporting & Fix Verification - As we do our testing, we will find issues (intentionally used the word Issues, as developer often comes with argument if it is mentioned as Bug.). Once we find issues, we need to record them. We need to record them in a way so that developer can reproduce the issues. I have mentioned how to report a good bug in one of my previous post. Please see the post for the details of Bug and it’s life cycle there. Reporting an issue does not end the job there. When developer fixes it, we have to make sure that fix works as well as the that fix does not have any consequences. Regression testing should be running as we go towards the RC.

5. Release Candidates (RC) - After we finish all the testing, it then comes to a stage where we can say it is ready to release it. Before that, to get another pair of eyes, we release it to our internal customers to check it. Once it is satisfied, then the version becomes a release candidate for Beta testing.

6. Final Release - Once the software is tested enough, it then released to production and thus it becomes available to the end user. One thing to mention here, when a software is released, it is better to document it with Release Notes. Release note will describe the Description/ New  Functionalities/ Changes/ Bug Fixes for that release version. Note here that, some company has their own Release cycle and may not include under the STLC. Regardless where it is, this step has to have a systematic process.