Test methodology…Test methods…Test levels…Test cycles…Testing types…Test artifacts…Test techniques…Confused? Anybody can get confused with different Testing terminologies. One of the common Software Testing Interview Question is – As a QA you have worked on what all Software Testing Levels?
Software Testing Levels
Software Testing Levels is nothing but different stages of software testing. How do you build anything? Generally a system comprises of multiple integrated components. First create all the components >> Join all the components to build a system >> Once the system is up & running, deliver it to the client. For an effective delivery, it is important to test the system at each level of development, i.e. during development, individual components, integration, complete system, integrated systems, etc. Hope you got an idea what Software Testing Levels is all about!
As a Test engineer, it’s important to understand the basic difference between all the Software Testing levels. Additionally it’s more important to have a diverse experience working on different Software Testing Levels – after all ‘Experience’ is the best teacher! Software Testing Levels are generally defined by the scope (or objective) and timelines (as the project progresses). There are generally five recognized Test levels: Unit testing, Component testing, Integration testing, System testing, and Acceptance testing.
Unit Tests (Developer)
Done by developers as soon as they develop a certain code, if it’s working or not. After all, developer don’t want to be embarrassed soon after deployment 😉 The smallest independent and testable part of the source code is referred to as a unit. Individual units of code (classes, functions, interfaces, procedures, etc. or a group of these) are checked by respective developers before handing over the build for deployment. As you might have guessed – Unit tests are basic checks just to verify that the developed code is at least working.
Component Testing (QA)
Individual component or module testing by the QA team, without integration with other components. This is to verify that standalone components are working as expected. Say an e-commerce site will have different components like Search engine, Filter setup, Payment gateway, User authentication, Cart management, Catalogs, Order tracking, etc.
Integration Testing (QA)
Testing of the interfaces between different components, so as to confirm that different components can work together in harmony. E.g. Order tracking module expects User details to be passed to it in a certain format >> What if the interface isn’t working correctly? I.e. There is a difference between the expected and actual formats used for communication? Integration testing aims to uncover any defects in the way components interact with each other.
Note: Stubs and Drivers are used to simulate missing components (not yet ready or available). We will cover the concept of Stubs & Drivers in another post.
Additionally Integration testing can be performed at component level – Component Integration testing – or can be done at system level – System Integration Testing (SIT). It depends on the type of application, i.e. apart from components, if different systems are also involved to deliver an overall functionality. E.g. In a payment processing system, there will be different systems involved like front-office, middle-office (routing) and back-office.
System Testing (QA)
Rigorous Testing of the integrated system as a whole, to ensure that the overall product meets the business requirements specified. Generally this is the most important of all the Software Testing Levels as the end-user is not bothered about the individual components or the integration. He/She is just bothered about the system as a whole – if it works as expected. System testing is typically performed by a specialized testing team and in an environment that is very close to the production environment.
Note: As pointed-out under Integration testing, additional System Integration Testing (SIT) can be performed after System Testing in case – apart from components, if different systems are also involved to deliver an overall functionality. E.g. In a payment processing system, there will be different systems involved like front-office, middle-office (routing) and back-office.
User Acceptance Tests (Business Users)
Whenever we purchase an electronic or electrical item, we always ask the seller to first give a demo so as to check if it’s working fine. In case of Software – it is not used by the client, instead by the end-users, i.e. client’s business reputation is at stake if it doesn’t work. In this case how do you think client would accept your tested system without a walk-through? As the name suggests – Business Users walk-through the system during the UAT phase to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery / release (mainly from user’s point of view)
Note: The goal of User Acceptance Testing is not destructive but to establish confidence in the system that it meets the end-user requirements and is fit for use. Ideally it should be done by a bunch of actual users or stakeholders from the client side but recently we have seen an increase in UAT outsourcing as well.
For Commercial off the shelf (COTS) software’s that are meant for the mass market testing needs (to be done by the potential users), there are two additional types of acceptance testing:
- Alpha testing: Done by potential users, at the developer’s site. Potential users or members are invited to use the system and report defects.
- Beta testing: Also known as pre-release testing, Beta test versions of the software are distributed to a sample of actual end-users to give it a real-world test and gather qualitative feedback.
Distributing QA in different Software Testing Levels helps in multiple aspects –
- Cost saving: The early the defect is identified, the cheaper it is to fix.
- Thorough Testing: By progressively testing the simpler components and then moving on the bigger, more complex groupings.
- Risk mitigation: Starting as early as Unit tests minimizes the project risks, as well as time and money (the later the defect is identified, more costly it is to go back and make the changes.
- Planning & Quality: Unlike common belief, Software testing is an intensive activity. Without multiple levels of testing, everything will be squeezed at the end of development cycle which puts a pressure on the Test team and impacts the overall schedule & quality.
Testing early and testing frequently is well worth the effort. By adopting a systematic approach to testing, the project management can save lot of time & money, whilst ensuring quality deliverable. All Software Testing Levels have the same goal – to verify the software is working to specification and validate that the software product is meeting the needs of customers and end-users.