It’s easy to determine that you are testing too late. It is best to recognize the early warning signs and address them before the software quality begins to suffer. Here are four common signs you are testing too late and suggestions for what to do about it.
1. Separating developer and tester
Separating the developer from the tester affects the type of testing that is done because the tester will not have the level of understanding of the application’s internal operation and knowledge of the code as developers do. By separating the developer and tester you compromise your application quality by focusing on only the “black box” testing. With the “black box” testing, testers tends to focus on the usability test without any concern or of plan to deal with the internal operation, logic and the structure of the code itself.
In my observation, most of the organizations that are still following the waterfall methodology tend to lean too much on the “black box” testing which is happening at the system test or the system integration test level. To delivery a high quality application, there needs to be a combination of both “white box” and “black box” testing. The lack of the “white box” testing allows too many critical defects that should have been identified at the unit testing phase of the software development lifecycle to escape into the pre-production/production environment causes project delay and add costs to the overall software development project.
However, on the other hand, by paring the developer with test from the beginning of the project, we will no longer focusing just only the usability test. We will be able to look closely at the internal logic and structure of the code earlier, which helps reduce critical defects escaping into the production environment and minimize the project over all risks in the long run.
Often, test teams and developments are globally distributed, paring the developer with the tester might not be easily accomplished. However, the adoption of the application development platform will allow distributed team members to collaborate in real-time, which make this aspiration feasible.
2. Too much focus on the front-end User Interface (UI) Testing
Mobile architecture has a multi-tier architecture. The test coverage is heavily focused on the UI application front-end. There is not lot of focus on the middle tier and back-end services and protocols in the unit test, factional test and performance. This might be because the process of setting up the test infrastructure to support test execution of the code on mobile device can be time-consuming and costly.
If you find yourself focusing too much on the front-end UI Testing, look for the tools that will allow you to emulate the middle tier and back-end service and protocol using service and protocol virtualization. This will help your test team reduce cost and time on setting up the test infrastructure to support the test execution and setting up a complex environment. Adopt the solution to emulate the middle tier and back-end services and protocols so that the test execution can concentrate on the client tier of the mobile application running on the device itself.
3. Manual UI Testing very little test automation
Manual testing is the most common approach to mobile testing in the industry today. No doubt there are many great advantages to using manual testing. However, manually testing is still the most time-consuming, error-prone and costly technique. In my opinion, we can still use the manual testing as part of the UI testing use cases. However, the test team needs to think about a way to capture the UI test record and use it as part of the sub-sequential and include it as part of the automatic test execution later in the testing lifecycle.
This issue can be easily fixed by leveraging the test management solutions that organize the manual test cases, guide the tester through execution and store the test result. Implementing the testing solution that allows the developers/tester to record the UI interaction of the application and create tests is something that needs to be planned for as well. Once you have your test, then use the Test Management tools to launch the tests and orchestrate the execution of the test on the device automatically. The solution should allow your associated tests as implementations of the test cases and run the test automatically for the test teams.
4. Integrated end-to-end and System Integrated Test is being done later in the software development lifecycle
A red flag is raised, if there is no evidence that the integrated end-to-end system integrated test is being done for the functionality test, regression test and etc. In addition a lack of non-functional and usability testing occurring sufficiently early enough in the lifecycle is also shouldn’t be ignored.
In many organizations, the number one contributing factor that adds cost and creates delay for the test teams is the lack of the capability for them to run their test in the production like environment, the environment that will be available on demand for the test team to run their test whenever they want and how they want it. Furthermore, the complexity of the software and system that we are having to deal with are fully integrated and loaded with tons of dependencies with the various hardware, software and services. Testers are spending a lot of time waiting for the hardware, software and services to be available and accessible so, they can begin their testing efforts.
In order to resolve these testing challenges of testing too late in the software development lifecycle, we need to start adopting service virtualization.
Why wait for the services and software components to become available or accessible, start your testing effort earlier, use stubs and virtual components to model and simulate the real system bahaviour, so you can begin testing. Units that are not yet built can be simulated and tested against early on versus waiting for it to be available and/or accessible. By doing it this way compared to the big bang testing of testing every components all at once, units are introduced into the continuous integration cycle in a prioritized, controlled fashion. Therefore, help mitigate risks through earlier testing, improve quality and reduce defects escaping into the production environment.
Since applications are becoming more complex and highly interconnected with the various systems, processes and infrastructure, there is no doubt that doing any kind of application testing will continue to present challenges for the test team. It is imperative that we keep up with the demand to test, deliver high quality software at a faster pace and be competitive in the market. It is crucial for the test team to adopt a new testing strategy that will allow them to test earlier, test continuously and use technologies to help remove any kind of testing bottlenecks that could compromise the overall software quality.