Unit II: Testing in the Software Lifecycle
The general V-model, Component Testing, Integration testing, System Testing, Acceptance
Testing, Maintenance testing
V-Model
V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC must complete before the next phase starts. It follows a sequential design process same as the waterfall model. Testing of the device is planned in parallel with a corresponding stage of development.
Verification: It involves a static analysis method (review) done without executing code. It is the process of evaluation of the product development process to find whether specified requirements meet.
Validation: It involves dynamic analysis method (functional, non-functional), testing is done by executing code. Validation is the process to classify the software after the completion of the development process to determine whether the software meets the customer expectations and requirements.
So V-Model contains Verification phases on one side of the Validation phases on the other side. Verification and Validation process is joined by coding phase in V-shape. Thus it is known as V-Model.
There are the various phases of Verification Phase of V-model:
Business requirement analysis: This is the first step where product requirements understood from the customer's side. This phase contains detailed communication to understand customer's expectations and exact requirements.
System Design: In this stage system engineers analyze and interpret the business of the proposed system by studying the user requirements document.
Architecture Design: The baseline in selecting the architecture is that it should understand all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology detail, etc. The integration testing model is carried out in a particular phase.
Module Design: In the module design phase, the system breaks down into small modules. The detailed design of the modules is specified, which is known as Low-Level Design
Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable programming language is decided. There are some guidelines and standards for coding. Before checking in the repository, the final build is optimized for better performance, and the code goes through many code reviews to check the performance.
There are the various phases of Validation Phase of V-model:
Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/ units.
Integration Testing: Integration Test Plans are developed during the Architectural Design Phase. These tests verify that groups created and tested independently can coexist and communicate among themselves.
System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans, System Tests Plans are composed by the client?s business team. System Test ensures that expectations from an application developer are met.
Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It includes testing the software product in user atmosphere. Acceptance tests reveal the compatibility problems with the different systems, which is available within the user atmosphere. It conjointly discovers the non-functional problems like load and performance defects within the real user atmosphere.
When to use V-Model?
When the requirement is well defined and not ambiguous.
The V-shaped model should be used for small to medium-sized projects where requirements are clearly defined and fixed.
The V-shaped model should be chosen when sample technical resources are available with essential technical expertise.
Advantage (Pros) of V-Model:
Easy to Understand.
Testing Methods like planning, test designing happens well before coding.
This saves a lot of time. Hence a higher chance of success over the waterfall model.
Avoids the downward flow of the defects.
Works well for small plans where requirements are easily understood.
Disadvantage (Cons) of V-Model:
Very rigid and least flexible.
Not a good for a complex project.
Software is developed during the implementation stage, so no early prototypes of the software are produced.
If any changes happen in the midway, then the test documents along with the required documents, has to be updated.
What is 'Component Testing'
Definition: Component testing, also known as program or module testing, is done after unit testing. In this type of testing those test objects can be tested independently as a component without integrating with other components e.g. modules, classes, objects, and programs. This testing is done by the development team.
Description: Component testing is like unit testing with the difference that the developer uses real data instead of dummy data for testing of the written code.
Suppose there is a software application which consists of five components modules. The testing of each module is done independently by the developer as part of the development cycle before it is ready for integration testing. By doing component testing, bugs can be found at a very early stage in the cycle and helps save time.
Debugging tools or unit test structure tools are used for this type of testing since this is done by programmers on the code written by them and with the support of integrated development environment. Defects are fixed as soon as possible when they are found without formally recording incidents.
Component testing plays an important role in finding the issue. Before we proceed with the integration testing it’s always advised to do the component testing in order to ensure that each module of an application is working correctly and as per requirement.
What is Integration Testing?
Integration Testing is defined as a type of testing where software modules are integrated logically and tested as a group. A typical software project consists of multiple software modules, coded by different programmers. The purpose of this level of testing is to expose defects in the interaction between these software modules when they are integrated
Integration Testing focuses on checking data communication amongst these modules. Hence it is also termed as ‘I & T’ (Integration and Testing), ‘String Testing’ and sometimes ‘Thread Testing’.
In this tutorial, we will learn:
A Module, in general, is designed by an individual software developer whose understanding and programming logic may differ from other programmers. Integration Testing becomes necessary to verify the software modules work in unity
At the time of module development, there are wide chances of change in requirements by the clients. These new requirements may not be unit tested and hence system integration Testing becomes necessary.
Interfaces of the software modules with the database could be erroneous
External Hardware interfaces, if any, could be erroneous
Inadequate exception handling could cause issues.
Why do Integration Testing?
Although each software module is unit tested, defects still exist for various reasons like
A Module, in general, is designed by an individual software developer whose understanding and programming logic may differ from other programmers. Integration Testing becomes necessary to verify the software modules work in unity
At the time of module development, there are wide chances of change in requirements by the clients. These new requirements may not be unit tested and hence system integration Testing becomes necessary.
Interfaces of the software modules with the database could be erroneous
External Hardware interfaces, if any, could be erroneous
Inadequate exception handling could cause issues.
Click here if the video is not accessible
Example of Integration Test Case
Integration Test Case differs from other test cases in the sense it focuses mainly on the interfaces & flow of data/information between the modules. Here priority is to be given for the integrating links rather than the unit functions which are already tested.
Sample Integration Test Cases for the following scenario: Application has 3 modules say ‘Login Page’, ‘Mailbox’ and ‘Delete emails’ and each of them is integrated logically.
Here do not concentrate much on the Login Page testing as it’s already been done in Unit Testing. But check how it’s linked to the Mail Box Page.
Similarly Mail Box: Check its integration to the Delete Mails Module.
What is System Testing?
System Testing is a level of testing that validates the complete and fully integrated software product. The purpose of a system test is to evaluate the end-to-end system specifications. Usually, the software is only one element of a larger computer-based system. Ultimately, the software is interfaced with other software/hardware systems. System Testing is defined as a series of different tests whose sole purpose is to exercise the full computer-based system.
In this tutorial, we will learn:
System Testing Video Explanation
Click here if the video is not accessible
System Testing is Blackbox
Two Category of Software Testing
Black Box Testing
White Box Testing
System test falls under the black box testing category of software testing.
White box testing is the testing of the internal workings or code of a software application. In contrast, black box or System Testing is the opposite. System test involves the external workings of the software from the user’s perspective.
What do you verify in System Testing?
System Testing involves testing the software code for following
Testing the fully integrated applications including external peripherals in order to check how components interact with one another and with the system as a whole. This is also called End to End testing scenario.
Verify thorough testing of every input in the application to check for desired outputs.
Testing of the user’s experience with the application.
That is a very basic description of what is involved in system testing. You need to build detailed test cases and test suites that test each aspect of the application as seen from the outside without looking at the actual source code.
Software Testing Hierarchy
As with almost any software engineering process, software testing has a prescribed order in which things should be done. The following is a list of software testing categories arranged in chronological order. These are the steps taken to fully test new software in preparation for marketing it:
Unit testing performed on each module or block of code during development. Unit Testing is normally done by the programmer who writes the code.
Integration testing done before, during and after integration of a new module into the main software package. This involves testing of each individual code module. One piece of software can contain several modules which are often created by several different programmers. It is crucial to test each module’s effect on the entire program model.
System testing done by a professional testing agent on the completed software product before it is introduced to the market.
Acceptance testing – beta testing of the product done by the actual end users.
Types of System Testing
There are more than 50 types of System Testing. For an exhaustive list of software testing types click here. Below we have listed types of system testing a large software development company would typically use
Usability Testing – mainly focuses on the user’s ease to use the application, flexibility in handling controls and ability of the system to meet its objectives
Load Testing – is necessary to know that a software solution will perform under real-life loads.
Regression Testing – involves testing done to make sure none of the changes made over the course of the development process have caused new bugs. It also makes sure no old bugs appear from the addition of new software modules over time.
Recovery Testing – is done to demonstrate a software solution is reliable, trustworthy and can successfully recoup from possible crashes.
Migration Testing – is done to ensure that the software can be moved from older system infrastructures to current system infrastructures without any issues.
Functional Testing – Also known as functional completeness testing, Functional Testing involves trying to think of any possible missing functions. Testers might make a list of additional functionalities that a product could have to improve it during functional testing.
Hardware/Software Testing – IBM refers to Hardware/Software testing as “HW/SW Testing”. This is when the tester focuses his/her attention on the interactions between the hardware and software during system testing.
Acceptance testing
Acceptance testing is formal testing based on user requirements and function processing. It determines whether the software is conforming specified requirements and user requirements or not. It is conducted as a kind of Black Box testing where the number of required users involved testing the acceptance level of the system. It is the fourth and last level of software testing.
User acceptance testing (UAT) is a type of testing, which is done by the customer before accepting the final product. Generally, UAT is done by the customer (domain expert) for their satisfaction, and check whether the application is working according to given business scenarios, real-time scenarios.
In this, we concentrate only on those features and scenarios which are regularly used by the customer or mostly user scenarios for the business or those scenarios which are used daily by the end-user or the customer.
However, the software has passed through three testing levels (Unit Testing, Integration Testing, System Testing) But still there are some minor errors which can be identified when the system is used by the end user in the actual scenario.
Reason behind Acceptance Testing
Once the software has undergone through Unit Testing, Integration Testing and System Testing so, Acceptance Testing may seem redundant, but it is required due to the following reasons.
During the development of a project if there are changes in requirements and it may not be communicated effectively to the development team.
Developers develop functions by examining the requirement document on their own understanding and may not understand the actual requirements of the client.
There's maybe some minor errors which can be identified only when the system is used by the end user in the actual scenario so, to find out these minor errors, acceptance testing is essential.
Once the application is bug-free, we handover it to the customer, no customer accept the application blindly before using it. Hence, they do one round of testing for their satisfaction, which is known as user acceptance testing.
Who performs user acceptance testing?
The acceptance testing can be performed by different persons in different cases.
For example, the blue-dart company gives the requirement to TCS for developing the application, and the TCS will accept the needs and agree to deliver the application in the two releases as we can see in the below image:
On August 10, the test manager tells the project manager that there is a critical bug in the application, and that will take another four days to fix it.
But the project manager said we have to deliver the software within a given time. It takes another 30 days to fix the defect, or otherwise, we will have to pay the penalty (fine) for each day after the given release date. Is this the real situation? NO, let us see three different cases and understand who perform the acceptance testing.
What is Maintenance Testing?
Once a system is deployed it is in service for years and decades. During this time the system and its operational environment is often corrected, changed or extended. Testing that is provided during this phase is called maintenance testing.
Usually maintenance testing is consisting of two parts:
First one is, testing the changes that has been made because of the correction in the system or if the system is extended or because of some additional features added to it.
Second one is regression tests to prove that the rest of the system has not been affected by the maintenance work.
What is maintenance testing?
Maintenance Testing is also known as post-release software testing. This is a type of software testing that takes place when the software has been released into production and any changes have been made to fix bugs or add new features to the existing system.
Maintenance Testing provides feedback on how well the latest release is working in real life, whether it solves the problems identified by pre-release testing. This also helps developers find any new bugs that may have been introduced by the corrective and emergency changes in development, and it ensures that these don’t break functionality with other parts of a system. This testing is performed at no cost to clients who contract for post-release updates or maintenance support from software vendors.
This can be performed at any time after release: it doesn’t have to wait until another major version update or has been released.
Maintenance Testing is performed by the same team of testers who perform Pre-release testing to already deployed software, and it usually requires a similar level of skills from the tester as well.
This can also be used to test new releases of a software product that has not yet been released to the existing system before any major changes are made and without the need for an expensive re-testing phase.
Maintenance Testing often takes place on local servers or in an operational environment in an effort to mimic production environments more accurately and for long periods of time with high usage rates. Maintenance Testers also often have to perform regression testing, which means they may need to retest features and existing operational system parts of the software that were already tested before a new release.
It is usually provided for free by vendors who offer post-release updates or maintenance support contracts in order for their customers to identify bugs quickly when system changes are made in the existing software. Maintenance Testing is also often used by SMEs who want to release their products more quickly than would be possible with traditional testing.
Types Of Maintenance Testing
When the maintenance testers are validating the application, they need to consider two things. Based on the test types
Confirmation Testing: On this confirmation maintenance testing, the Testers or QA have to mainly focus on the modified functionalities. They have to verify every aspect of the application is working as it should be.
Regression Testing: Testing the existing functionality to ensure that it is not broken or degraded by the new functionality.
Benefits of maintenance testing
By doing regression maintenance testing it helps catch bugs before the pre-release stage, ensuring major changes in development don’t break other parts of the system without regression maintenance testing, and it ensures bug fixes work properly with new features.
Risks of not doing Maintenance testing
When not testing changes before release they can break other parts of the system, bug fixes won’t work properly with new features introduced in new releases, and will require more time to fix them if regression maintenance testing was done.
in simple words, If it is not done, bugs will be missed and the fixes won’t work with new features.
No comments:
Post a Comment