3. Understanding the Software Development Life Cycle (SDLC)…and where testing fits in! 

In this section, we will be looking at how software is developed, the process that it follows and where testing actually fits into the scheme of things.

Table of contents

1. The SDLC
2. Different SDLC Models
3. The “V” Model (aka The Verification and Validation Model)
4. So…how does testing fit into the SDLC?
5. Test Levels
6. Types of Software Testing
7. Summary
8. Test Yourself

1. The SDLC

Before looking at where testing fits in, let’s have a look at the Software Development Life Cycle (SDLC). Please note: SDLC can also be known as a Software Project Life Cycle (Project for short) in the IT world, where you will see me use SDLC or “Project” interchangeably in the following sections of this tutorial. 

The SDLC is a process used by the Computer Software Industry as a standard way to deliver a Software Project (capture requirements, design, develop and test high quality software systems). It aims to ensure that the customer’s (the users of the system) expectations are met or maybe exceeded and the delivery of systems are completed within time estimates and specified costs.

As you can see from the following diagram, the SDLC is made up of many phases:

Requirements Gathering and Analysis Phase

This phase is the most important phase of a project, it defines what is required. The Business Analyst collects requirements from a customer (user of the system) as per the customer’s needs and documents them as Requirements in the Business Requirement Specification. These requirements are then agreed with the Customer.

Design Phase

There are many views of design in the IT industry. For me, as a designer of multi million pound systems, I look at it as a two phased approach to design:

• High Level Design (Architectural / Functional Design)
• Low Level Design (Detailed Design)

The High Level Design takes the requirements and produces a design of how the system will functionally work and on what domain / platform (hardware). It does not detail the inner workings of computer components (programs / classes). It does, however, show how separate components will interface with each other. I personally use Data Flow Diagrams (DFDs) to show the flow of data within the system.

Once the outline of the system has been designed, then the Low Level Design can be produced to allow developers to code from (the program / component specifications). Here, I use Flow Charts or JSDs (Jackson Structured Designs) to show the component processing flows (Ifs, Elses and Iterations of a program) and produce pseudo code, which will, conveniently,  feed into a Test Analyst’s Decision Tree when it is time to test…but more on that in Section 5. Validation Test Process (Dynamic Testing)!

Development / Coding Phase

This is where the software application / system is built. Using Low Level Designs to work from, the code is written by the Developers. Unit tests are also written and executed for the individual components, delivering a product(s) ready for the Test Team. 

Testing Phase

This phase can be broken down into:

• Integration Testing
• System Testing
• User Acceptance Testing (UAT)

The Integration Testing will be testing the integration of modules within a specific functionality of the system, e.g. for an ecommerce website, then this could be the Logging On functionality, Search functionality,  Ordering functionality etc. They will be tested in isolation before moving to System Testing.

System Testing is done once all the functionalities have been tested and seen to work in isolation. We can then start testing that the different functionalities work and that they interface with each other.

UAT is the testing done by the Customers / Business Users who will be actually using the system. They will be aided by the SDLC Test Team.

Deployment Phase

Once all the development and testing has been done, the live deployment of the system will take place.

back to table of contents

2. Different SDLC Models

You will hear about many different SDLC Models, such as the Waterfall Model, V Model, Spiral Model, Iterative Model, Agile Model etc! All confusing, me thinks, because what they all boil down to is…that they all do the same thing! They go through the same Life Cycle phases…capture requirements, design, code, test and deploy! 

If we take the Agile Model for example…people will tell you that this is completely different from the Waterfall Model and the V Model…well, it isn’t! It is just a series of small Waterfall or V Model processes! Trust me…I’ve worked with them all 🙂 !

To this end, I’m going to show you how the V Model works and…how testing fits into the scheme of things! Finally, I hear you say, we’re now getting closer to showing you how you learn to test!

Real life testing: As a self employed Test Consultant, I have worked at many, many companies and been interviewed more times than I can remember. It amazes me how many times I have been asked “have you worked in an Agile Team?” or “do you have Agile experience?”! As I stated above…the Agile Method is simply a small Waterfall Method! Whatever testing you do, it really doesn’t matter what SDLC method is being used, they all work to something like a Waterfall Method and at the end of the day…testing is TESTING! 

back to table of contents

3. The V Model (aka The Verification and Validation Model)

Using this model, I will explain how testing comes into play. 

Looking at the diagram below, you will see the development phases of the SDLC on the left hand side (with the documents produced in brackets), and the testing phases on the right hand side. In between the development and the test activities, you will see the test document (deliverable) that is produced.

In test terms, the left hand side is known as the verification part and the right hand side is known as the validation part.

Verification

This is a static analysis technique where testing is done without executing the code. This is where documents are reviewed by other members of the SDLC Team and then a walkthrough (a meeting where people, who are qualified to, verify the correctness of a document) is performed. We will be covering this topic in more detail in Section 4. Verification Test Process (Static Testing).

Validation

This is a dynamic analysis technique where testing is done by actually executing the code, functionally and non-functionally. We will be covering this topic in more detail in Section 5. Validation Test Process (Dynamic Testing).

back to table of contents

4. So…how does testing fit into the SDLC?

In the V Model, the development and Quality Assurance (verification and validation) is done in parallel with each other. There is no real “let’s start testing” phase as such, as testing starts from the moment the Requirements Specification document is produced and only ends when the product / system is delivered.

The thing to note here is that we can produce test plans even when coding hasn’t even started! This way, the model assures quality throughout the development life cycle…documenting and reviewing at every step of the way!

Testing characteristics of using the V Model:

• Early test design: From the moment that the requirements are delivered, testing activities can start (e.g. the Test Team can produce tests for UAT). This early involvement is then continued throughout the project, allowing testing activities to be done in parallel with the development activities
• Each work-product is tested: Each development (verification) activity has a corresponding test (validation) activity, ensuring that testing is done against each document produced
• All SDLC documents will be reviewed by the Test Team: The Test Team have the opportunity to review all documents before they are released, notably, the requirements captured and all designs

Verification stage

First, let’s discuss the left hand side of the V Model, the Verification Stage, also known as the development phase, where the Requirements are expanded into a Design, ready for coding to take place. The V Model diagram shows the documents (in brackets) that are produced from both the Requirements Capture and the Design activities as follows:

• Requirements Specification

Once this document has been produced, then the Test Team can produce the:

• Test Strategy and overall Test Plan for the project
• User Acceptance Test Plan. This document being produced along with the Customer of the new requirements

• Design Specifications

The design stage will see the following design documents produced, with the corresponding Test Plans being able to be started:

• Coding

The coding stage will see developers working from the Technical Design and Program Specifications to develop the system. 

Note: All the above documents, both design and test, will have a walkthrough (as will all documents in the project life cycle) they will be reviewed and signed off. Albeit, they may be subject to change as the project proceeds and issues are found…in which case, amendments will be made to the documents and reviewed again to ensure correctness.

Validation stage

The right hand side of the V Model, where we validate what has been delivered, displays the testing activities that are performed. These activities are performed once code is delivered and are explained in section 5. Validation Test Process (Dynamic Testing).

back to table of contents

5. Test Levels

You will have seen in the V Model the progressive test stages that are adopted in the SDLC, from producing the Unit Tests at a coding level, to Integration Tests being produced when testing the integration of components etc. These stages are called the Test Levels. They are different levels in that they focus on different testing being performed at certain points of the Development Life Cycle:

Unit (Component) Testing

These tests are the most basic types of tests. They test standalone components that have been coded in the form of, usually, classes (for object oriented code e.g. JAVA or C# language) or programs (for procedural code e.g. COBOL language). Unit Tests will be designed by the developers themselves and embedded in the code. When the code is then built, the tests will run, ensuring there are no defects at a program level.

Integration Testing

This testing usually starts when there is a complete business function to test (e.g. in the case of an ecommerce website: Add To Basket Function or Checkout Function etc). It involves testing the integration (or interfaces) of multiple components that have been coded within a function. Whereas unit tests will test a single component (e.g. class), integration tests actually test how multiple components (classes) interact (integrate) with each other, ensuring the transfer of data (interfaces) between them is correct. 

If we look at the following diagram, the separate components (classes) are depicted by the blue boxes, whereas the boxes with the green borders depict functions that combine components within the function that interface (integrate) with each other.

System Testing

Once the functions have been tested at an integration level, they can then all be brought together so as to do end-to-end scenario tests. Again, if we look at the above diagram, the box with the red border depicts what would be tested for a System Test. Here, as an example, we could test the end-to-end scenario: Add Items To Basket -> Click Checkout Button To Display Checkout -> Checkout And Confirm -> View The Order Placed. 

User Acceptance Testing

This testing is usually done by the SDLC Customer or Business User. The testing is not about finding defects, but to ensure the system meets their requirements, albeit, if defects are found…then they will have to be raised and fixed!

back to table of contents

6. Types of Software Testing

Here, we will be taking a brief look at the 2 main types of testing, which are based on the user requirements that have been identified in the Requirements and Design Specifications, however, this tutorial will not be further expanding on the Non Functional part of testing:

• Functional
• Non Functional

Functional Testing

Functional Testing, which looks at the behaviour of a system, is about testing the system against the derived Functional Requirements which can be found in the Requirement and Design Specifications, ensuring that the system does what it is supposed to do. It tests slices of functionality of the entire system, one at a time  (e.g. for an ecommerce system the business functions could be: “Add to Basket”, “Checkout” or “View Order” functions). 

It is a type of blackbox testing. So, what is blackbox testing? We will be looking at this in greater detail in section 5. Validation Test Process (Dynamic Testing), but for now…Blackbox testing is a way of testing a system’s functionality without looking at its internal workings. Basically this means the tester will be testing the interfaces of components that make up a business function.

Functional Testing is used in the Integration, System, UAT and Regression Test Levels, as described in section 5 above.

Non Functional Testing

As the name suggests, this type of testing tests the non functional requirements, such as performance, scalability, security, reliability, usability etc. It looks at how the system performs under certain conditions or situations.

It ensures that the system is reliable and ready to be used! It looks at how the system operates, rather than looking at the behaviour of a system like Functional Testing, but ensures, for example, for an ecommerce website that:

• There is no buffering of the system
• The pages are displayed in a timely manner
• That the system can handle a specific increase of customers without crashing
• There is no downtime for a system that needs to be operational 24×7
• It is easy to use (intuitive).

back to table of contents

7. Summary

So, that was a look at what the SDLC (Software Development Life Cycle) is and where testing actually fits in the scheme of things.

In this section, you will have learned:

• How the SDLC organises and helps us: 
  • Capture what our Customers want, producing a Requirements document
  • Design from the Requirements to produce Design documents
  • Develop the system using the Design documents
  • Test the system using 4 different Test Levels:
    • Unit Testing. Where tests are produced by developers to test their own code
    • Integration Testing. Where testing is done by a separate Test Team to ensure coded functionality works correctly
    • System Testing. Where the Test Team will test the system as a whole…bringing all the Integration Tested functionality together
    • User Acceptance Testing (UAT). Where testing is done by the Customers, with the help of a SDLC Test Team

• That all testing should follow the V Model (aka The Verification and Validation Model), where 2 main types of V Model test tasks are observed:
  • Static testing. Which ensures that all documents are reviewed to ensure correctness
  • Dynamic testing. Which is where the actual execution of tests is done

• Where testing actually fits in the scheme of things with regards to the SDLC
  • You will have seen that testing starts as soon as a project starts and finishes when the new / amended system is delivered and signed off

• You will have seen that Software Testing can be divided into 2 main areas:
  • Functional. Which is what this tutorial is all about…the actual testing of a System’s functionality. Does it actually do what it is supposed to do and do it correctly?
  • Non-Functional. This is about testing the performance of a system, such as performance, scalability, security, reliability, usability etc. As stated, to keep things simple, we will not be looking at this in this tutorial

In the next section, 4. Verification Test Process (Static Testing), we will be looking at how Software Testing is not only done by executing the code, but also by getting involved with all the SDLC’s phases, liaising with all the members of the SDLC team, reviewing documents and providing feedback at each stage of a SDLC (Project).

back to table of contents

8. Test Yourself

Important to do well…

For this test, please do not be put off by the number of questions (32), as this section, along with Section 5. Validation Test Process (Dynamic Testing), is a little more involved than the others and warrants more understanding!

As with the first test, once complete, check your answers, if you do not score that well (let’s say not getting at least 26 correct), please either go back over the tutorial’s section again, perhaps making more notes as you go, or re-do the test to ensure you have a good understanding. 

It is always important that you understand the section that you have read / learned before you move on 🙂 !

Click here to Test Yourself.

back to table of contents