Despite the fact that QA steps are often being bond to specific techniques there are no certain rules existing. This isn’t Kung Fu we are talking about, right? So let’s walk through some descriptions of app testing steps, or levels how some call them:
Let’s start small and test a single unit.
What is a unit? The smallest part of the entire project that can be appropriately tested. Unit testing usually focuses on the sub-routine level although it will always be based on the tech and origin of the project itself. Testers usually tend to automate unit testing, it also often desires special stubs, drivers and harness.
The universe consists of atoms, projects include components.
A component is a cumulative of at the very least one, often more constituents. This level of testing extends unit testing and adds included data types as well as called parts. It’s very alike to the unit testing in its trend of automation and creation of stubs, harness and drivers.
Step by step we go.
Run through the new or modified statements of code with a sharp debugger and you’re done with single step testing. This step is usually manual.
It’s not just sitting on a bench in the park, you know.
You’ll need a system that is built in a local environment. And now you can start a functional testing of a component. That’s bench testing. It is also usually manual and informal.
Integrate this, developers!
This step offers engineers a chance of testing some of the constituents after they’ve been released and the system has been transported to its common environment. The data flow that is running in-between the new component and the rest of the tested software is being monitored carefully at this step.
Smoke without fire?
QA engineers perform smoke testing in order to find out if the system is prepared for further and more determined testing. There are no specific standards here, they vary from a project to a project.
What will this button do?
The name “feature testing” speaks for itself. After all the features components have been completed and released by the developers the test of the whole feature begins.
Let’s integrate a deeper.
This one specializes on verification, stabilizing of the entire system and it’s functional after the system is infiltrated with third party components.
Do we like the system?
So now all the system’s components have been officially released… internally. And the system needs to be in its standard environment. Now testers will be concerned with the entire system and whether it runs nice and smooth.
Release time? Already?
Release testing is mostly done before the official release. All the projects functionality that is dedicated to customers, like the installation process, the first steps of running the program, etc. is being properly tested on this step.
Need a hand?
Beta testing is basically allowance for third party trusted users to look through the app in hope that a fresh look might find new bugs. It also provides splendid opportunity for providing fixes for various deployment and release issues.
They really love us.
This step (acceptance testing) is comparing the system with a set of criteria that were discussed earlier. Basically it means checking if the end product is the same thing it was meant to be.
And we’re back at the start.
Application regression testing is a frequently automated step that is focusing on the not so expensive and effort consuming way of testing parts that has proven to be functional earlier. The thing is that properly functional code might have changed due to new lines added later. That’s why regression testing exists and is needed by every application.
Will we manage?
On this step (performance testing) testers tend to measure the product’s efficiency. The hardware is being tested under usual circumstances.
I’m so stressed up!
Not all users are nice and tender. This method is required for testing the product in extreme circumstances like limited system resources, etc. Welcome – the stress testing.
How will the app perform under very special system configurations? If you don’t know – try this step.