Testing approach
Why this process is required
Software is created to fulfill certain requirements and needs. Thus, software testing is carried out to ensure that all requirements and specifications were considered in the development of the software. In addition, testing also helps in detecting any faults that cause the software to go into error, which can lead to failures.
Software consists of several common components:
During testing, all of the above components will be covered, taking into account the specified levels and interfaces.
- Client Layer
- Presentation Layer
- Business Layer
- Data Layer
During testing, all of the above components will be covered, taking into account the specified levels and interfaces.
Core of the process
Define testing techniques
Each project faces different requirements for software testing. Given this, the QA engineer’s first goal is to determine what techniques will be most appropriate to ensure the highest quality of delivery. We need to remember that testing by itself has no business value. It becomes valuable when it connects with something valuable to the business. The goal of the test manager is to find this connection and establish the process from a wide range of testing types and in a way that is most beneficial for the client’s product and not for the testing team.
Typical testing objectives
While the specific mission and objectives for a test organization can vary, typical objectives include the following:
- Find defects that could affect customer or user satisfaction, and produce enough information about those defects so developers can fix them prior to release
- Manage risks by running important tests that relate to key quality risks, in risk order, reducing the risk to the quality of the system to a known and acceptable level prior to release
- Confirm acceptable level and amount of the defects with stakeholders
- Provide the project team with important information about quality, testing, and readiness to release
- Uncover non-critical defects, and help establish workarounds for them should the defects not be corrected prior to release
Building the test team
Once testing approach, strategy and goals are clear, it’s time to create the appropriate team to handle the testing. Depending on the size of the project a number of testing specialists might be required. Some of the most common specialists you can have on your project are:
Each specialist is processed and onboarded individually, so we can be sure in their skills and competencies.
- Black box tester (Test Analyst)
- White box tester (Technical Test Analyst)
- Performance test engineer (Technical Test Analyst)
- Test lead (Test Manager)
- Test architect
- Test automation specialist (Technical Test Analyst)
- Security test engineer (Technical Test Analyst)
Each specialist is processed and onboarded individually, so we can be sure in their skills and competencies.
Communication with developers
During the work process, a situation may occur when a standard communication in a bug tracking system is not enough to identify and fix the issue. For the project’s success, it’s important to have a clarified and confirmed way to communicate between the testing team and the development team. We encourage our testers to initiate quick calls with developers, to describe and explain the issue in real-time. This testing approach speed up the overall testing time significantly, compared to only dry messaging in the bug tracking system.
Differences between web & mobile testing
Graphical User Interface is one of the major differences that can affect the testing process and makes it different between web and mobile. While testing mobile apps, a tester should take into account not only a much smaller screen size, but also portrait and landscape modes.
The other point to consider is power management. The power in the case of web applications is not being cut – off frequently. Although the web applications can be used in the browsers of mobile devices, it is usually accessed using desktop computers or laptops. However, in the case of mobile applications, the power should be managed through the software, because it is depending on the battery of the device.
Besides, testing needs to take into account the application’s lifecycle. Because resources are limited, in mobile apps, taking care of the lifecycle is the responsibility of the application. Yet in web applications, the operating system is taking care of the “applications lifecycle”.
The other point to consider is power management. The power in the case of web applications is not being cut – off frequently. Although the web applications can be used in the browsers of mobile devices, it is usually accessed using desktop computers or laptops. However, in the case of mobile applications, the power should be managed through the software, because it is depending on the battery of the device.
Besides, testing needs to take into account the application’s lifecycle. Because resources are limited, in mobile apps, taking care of the lifecycle is the responsibility of the application. Yet in web applications, the operating system is taking care of the “applications lifecycle”.
Testing environment
The usual development process includes the creation of several instances with the product. One is the live version where the product visible to the users is located, only confirmation tests can be performed there to make sure that the new build was deployed appropriately.
The next instance is a UAT one, where the client and his team can do the testing of the product and check how newly implemented features are working.QA testing is done on the so-called Staging instance. Any kind of tests can be performed there, including product or user deletion, data removal, etc. More instances can be added if the end solution is really large, but the environments described above are the most common and usually are sufficient for the complete new functional testing.
The next instance is a UAT one, where the client and his team can do the testing of the product and check how newly implemented features are working.QA testing is done on the so-called Staging instance. Any kind of tests can be performed there, including product or user deletion, data removal, etc. More instances can be added if the end solution is really large, but the environments described above are the most common and usually are sufficient for the complete new functional testing.
Benefits for you
An established process with clear steps and visible results.
Experience with both web and mobile testing approaches.
A large number of testing devices AND tools for cross-browser testing.
The stable and working solution as the result.
Clarify requirements and discover bottlenecks before development is started.
A personalized approach in testing designed specifically for your needs.
Reliable engineers, who can easily cooperate with any development team.
Cost-effective solutions that bring the real value you can evaluate.
