Levels Of Testing and QA Life Cycle
The unstoppable process of the high-tech industry’s growth leads to an increasing number of vacancies for QA Engineers. Do you remember when a few years ago some experts predicted a general downfall of the IT sector because of its oversaturation with candidates? The truth is our Linkedin inboxes are swamped with recruiters’ messages about the search for the strongest QA professionals. This has become a more frequent occurrence in a post-covid reality when new online solutions emerge every day to simplify and improve people’s existence globally. Our QA testing pros are definitely NOT an exception and get these messages quite often.
Even the brave guys who were once confident enough to release raw apps without reasonable checkups are now facing the reality. Today QA Testing is placed on a pedestal as it is now considered among the most important stages (we talk about other stages, too) of the Development Life Cycle (also known as SDLC). It doesn’t matter if you have decided to invest in an m-commerce app, an event streaming app, or something else (according to the top mobile app trends in 2021), such assessment is essential if you plan to come up with not only competitive features but also gain popularity and respect from customers, as well as increase the quality standards and user satisfaction levels, all of which will lead to a company’s profit growth.
Our mission is to explain exactly what a QA life cycle looks like. Why is testing required for both tiny and gigantic organizations no matter what they come up with? What are the different levels of testing? Too many questions and we’re here to answer them! Here at ein-des-ein we are sure that it could definitely save you from making a wrong choice and from making costly errors! In this article, we have collected tips that will help you understand the whole process better.
What is STLC? How does it differ from SDLC?
Software Testing Life Cycle (STLC) is a number of systematically performed steps to ensure that a program operates correctly. Any production mess will likely be fixed quicker and in a more cost-efficient manner (thanks to other companies’ failures that we learn from). To better comprehend an STLC position in the development process, it is crucial to understand distinctions between Software Development Life Cycle (SDLC) and Software Testing Life Cycle (STLC).
Beginners easily mix up these abbreviations, but (spoiler alert!) they greatly differ from one another. A rocky path from scratch to an actual working application is run by SDLC: it is a more convenient way to keep up with updates for both customers and developers. Moreover, an outline of an entire procedure helps with deadlines, task assignments, and risk prediction (everyone wants to have aces up their sleeves!).
Stages of SDLC
Requirement analysis and planning
Both stakeholders and responsible individuals should have a clear project scope picture to follow. It is essential to ensure an app would stand out among others, requested features would be exceptional and each feature would positively impact UX (that is why a design-driven development approach is the best, in our opinion). Then it’s time to work on a budget, resources, timeframes as well as evaluate possible problems and weaknesses. Usually, this information is added to a formal SRS document. It is developed mainly for PMs, business analysts, engineers.
Software design
It’s all about turning specifications mentioned earlier into a plan (aka Design Specification). Stakeholders browse it and give their feedback. All the necessary details about UI, network, databases, etc. should be mentioned here. At this point, a messy SRS turns into a more logical and structured guide.
Software development
Software development starts right away. Once design papers are ready, eventually, module coding starts. Since all the components are already implemented, the team receives a functioning program ready for its first assessments. And don’t forget about composing a Source Code Document.
Testing
Testing is executed next to ensure the created code has no issues, totally meets the client’s expectations, correctly integrates with other programs together with the selected hardware (see the detailed info about QA testing milestones down below).
Deployment and Maintenance
This stage is the overall process finalization as the product is almost ready for its User Acceptance Test. The development team together with the client closely monitors the performance. After deployment, it’s best to continue with maintenance and support. So if any difficulties occur later, developers can fix them fast and efficiently.
So, what is QA in SDLC and what’s the connection? When we refer to QA testing, it’s hard to believe that just a few years ago there wasn’t an SDLC process in place, and programs crashing every 0,01 seconds was a common thing. Furthermore, a decade ago we did not observe the competition we have now — users can choose a new application in seconds and easily delete the previous one. So even high-tech giants constantly need to follow trends, create exceptional features and, of course, achieve better quality assurance.
Software testing turned into an independent SDLC constituent and was complicated enough to have its own life cycle — STLC!
Differences between SDLC and STLC models
If we talk about key differences between these concepts, we highlight the following:
Needless to say, STLC is quite significant due to many reasons. First of all, a high-quality end product requires lower costs in the long term so it is a smart choice to invest in its proper production. Furthermore, software stability is crucial so existing users would always come back to your application and recommend it to other users. As a result, excellent reviews and word-of-mouth could attract more users, resulting in revenue growth. As a provider, you gain a good reputation so existing clients (as well as potential ones) could confidently rely on you (once again, now we see the strongest competition game happening!).
While each project establishes its own STLC, they all would have the exact same structure.
Stages of STLC
Requirement Analysis
The QA testing team should determine functional and non-functional requirements for ongoing tasks. Here the QA department should have requirements for automated and manual testing too. The “ideal version” should be outlined so all specialists would take it into account during each assessment and there would be no need to regret that you overlooked something significant.
Move on if you’ve got an approved RTM table and automation feasibility report.
Test Planning
Here we face some boring but obligatory paperwork so brace yourselves. There will be all the following steps such as:
- test plan documentation preparation (which contains all detailed data about testable aspects);
- deadline setting;
- tools/platforms selection finalization;
- task allocation;
- (and don’t forget to include) the risk-cost-benefit analysis.
Test Case Designing
We are getting closer to an interesting research part! But before that, we have to say that each test case defines testable aspects, procedures, conditions, and supposed deliverables, like in a good detective book where the crime scene details are thoroughly explored in the beginning. Test cases should be extensive enough so they could cover generic occasions and verify which ones have the biggest influence. Automated scripts for test cases should also be ready at this stage.
Test Environment Setup
Lights, camera…almost action! During this stage, all criteria are considered as both soft- and testing hardware are configured. Testers prioritize and set up a Test Environment and perform smoke tests to identify basic mistakes and bugs (for example, installation not launching). By the way, the smoke tests were actually named after real furnace smoke!
At this point, such tools as TestComplete, Selenium, Appium, etc. come in handy.
Test Execution (no bug will survive!)
Finally, after all the previous actions, app features are ready for an assessment. The QA engineer compares the expected results with the actual ones. And if any missing areas are detected during the tests, they are fixed so that the regression testing could be executed (to see if the latest changes did not affect any processes).
Test Closure
This is the QA testing stage for making sure obligatory checkups are done, preparing the documentation, and summing up processes. The final report should contain details about the whole checkup process and also show differences between planned and actual deliverables. List time constraints, costs, assessment coverage, etc. here.
Levels Of Testing In Software Engineering
Now, the goals are set, the paperwork is finished, so it’s finally time to have the main dish— different types of QA testing! If we mean actual levels of testing specifically, there are a lot of many little interactions, but they all can be divided into four main ones, also called the levels of testing in software engineering. Each of them has its own unique purpose so any level shouldn’t be eliminated.
Unit Testing: the first bastion in a fight against bugs
Unit Testing (UT) is an initial element of testing. During this stage, each part of the software is divided into individual components that are evaluated separately to ensure units are functioning properly as separate pieces.
Tests are prepared for every non-trivial function or method: this allows you to quickly check if any small change in the code has eventually led to regression (problems in already monitored parts) and also facilitate a detection/elimination of errors.
Integration Testing: connecting modules
Integration Testing (IT) is performed when the first stage is complete: modules are combined/checked as a group — that’s why it has such a name. Typically, a product has several program modules (which can also be written by different people) so IT is essential to find interface defects between functions.
IT mainly focuses on interfaces and data flow (between modules). Here, the validation priority is assigned to integrating links — not to block functions that have already been validated.
For example, there are three modules: “Log in Page”, “Mailbox” and “Delete email” (logically integrated). There is no need to examine the first page because it has already been executed in Unit Testing. But now we are able to clear up how it’s integrated with the mailbox module. Similarly, we analyze the mailbox integration with the “Delete email” module.
System Testing: meeting all possible requirements
After dividing units and then combining them together again, a complete and integrated software needs an evaluation of the system’s compliance with the requirements. Normally, (for small projects in particular) the QA engineer chooses manual testing:
- QA tester opens a programme
- Clicks on all buttons and checks all attributes
- Verifies that elements operate accordingly.
System Testing can also be automated! Each type of system testing reveals:
- incorrect use of system resources,
- unexpected combos of user-level data,
- environment incompatibility,
- unexpected UCs, etc.
Acceptance Testing: putting finishing touches
Acceptance testing (AT) is the last step and it’s carried out at the delivery stage for quality determination. It is usually obvious by playing scenarios and cases based on requirements. AT results in submitting the project for revision and its acceptance by customers.
This is the final destination where the application is checked before its release. AT is carried out either by the customer themselves or by an IT service provider. It’s a matter of preference.
STLC vs Agile, Waterfall, V-Model, and other methodologies
If you are not a newbie on a high-tech battlefield, you are most likely familiar with common SD methodologies. Otherwise, take a look at these materials before you dive into understanding how STLC actually works in some popular methods.
STLC in a Waterfall Model
Have you ever been to Niagara Falls? Like a tourist boat that welcomes you aboard only after the previous one has sailed away, in our case, each next phase only begins if the previous one is accomplished. There is the only pier for our “boats”: two stages are not executed parallel! To those readers who might wonder why so many large companies still prefer this method, its fans proudly claim it produces far better quality code, documentation, and proper testing of outliers before it goes to production.
STLC in a V-Model
The good old V-Model is still well-known in the industry. In the US it is still considered the official standard for software projects by federal agencies (whether in commerce, military, or a public sector) which definitely benefit from implementing it to their type of business: a chance something important gets skipped is getting smaller.
Rather than going downward in a linear form like a waterfall, steps go up after the encoding phase to create a recognizable V-shape. The model displays a connection between each DLC milestone and its checkup. They are inseparable and work simultaneously, there is no specific stage for it (see the scheme below).
STLC in Agile
Many companies (so do we) prefer Agile due to its flexibility when it comes to constant product improvement. Moreover, such methodology is the most popular nowadays: 7 out of 10 enterprises implement its approaches in their daily routine.
QA, PM, DevOps, and all involved individuals act as one mechanism, constantly communicating about different aspects throughout the workflow, repeating the motto “work together to achieve the main goal faster” constantly (nothing new to those who are living with Agile every week). Everybody benefits from it as there is room for ASAP changes. Here is an Agile testing life cycle diagram:
Final thoughts
To sum up, we could say that chaotically following the software testing phases might give you the results, but the truth is the bigger the project is, the more strict QA testing system is required. Eventually, why not simplify the workflow and make it more effective, less expensive, and pleasant for everyone? Try implementing this testing system within your business if you still haven’t yet, because it’s worth a try!
Make sure to check out more articles on mobile app development and design in our blog!