2 Things to Consider for Better Understanding and Improving Your Testing Integration
There are many different organizations and many development approaches, but one common practice is testing. The companies treat testing as a necessary overhead – a cost center that the organization has to tolerate in order to release software, somewhat similar to the way project execution functions view finance departments.
This is not very true – the cost of not having an effective test department is clear to any organization who released a product with one or more major defects; it is an expensive behavior to have. Test teams can help deliver larger values to other areas of the business, and that’s what we will discuss in this article.
Testing is not “the bottom line”
We all know that the testing is referred to as the last step or the final phase of a release. This perception exists, because once testing has been successfully completed, the product can be approved for release. However, this ignores some of the associated functions that occur in most organizations. Since testing may lead to approval and release of the product, there is also a need for one or more of documentation, training and professional services. Testing can improve the effectiveness of each of these elements.
In general, the development of documentation and training material begins with the requirements documentation, and that’s appropriate. That will allow you to identify the areas of change, and potentially allows for the documentation and training frameworks to be developed. However, the requirements alone are not enough to develop detailed materials, for that the system is required.
Having a development environment is a good way to develop the understanding of the system, but it’s not enough to develop reliable end documentation or training products. Co-working with the testing team will get the documentation and the context of the application that is otherwise missing. They will understand what elements of the application are reliable, what aspects are subject to change, what defects have the potential to impact end users, etc.
For IT services, the situation is rather different. The main concern for IT services teams is not so much the application itself, but rather how the system can be managed and implemented for user needs. The use of requirements documentation can provide high-level concepts, and an understanding of the system architecture will assist in understanding the flexibility of configurations/implementations.
Testing could impact the future
During testing, one of the tasks that has to happen after the release of a project is the update of regression test scripts for the application. When a new version of a product is released, this will be a case of adding scenarios to the existing scripts; if it is a new product, then new scripts should be created to support testing of future releases.
Firstly, based on the ideas explored in the section above, test teams have an understanding of how the application actually works for users of the system. At least some of those conducting testing should have similar skill sets to real users – usually, this is the final step of business acceptance testing, and these individuals will have the most realistic sense of where the solution works well, and where potential problem areas exist.
Testing teams can also provide feedback to development teams on optimizing the development process. Organizations should develop guidelines and best practices around development – how code is annotated, for example. The more technically focused testing resources can provide input into the improvement of those best practices.
A large portion of this work will come out of peer-based code reviews within the development team. But the advantage that testing resources have is that they don’t have the unintentional bias that comes from being part of development. As a result, they can provide a more independent perspective and identify improvement opportunities that might otherwise be missed.
Today, the organizations constantly face increasing expectations to do more with less; thus, they cannot afford to have any function that is self-contained to just one function. Testing specialists will always be needed (and testing is a good example of such specialization), there are always opportunities to leverage that expertise in other areas of the business. Organizations that are unable to take full advantage of such opportunities will leave themselves vulnerable to their competition – and will end up with inefficiencies built into their project execution approach.
Testing is a part of project implementation that is often not fully understood, and as a result organizations as a whole – and perhaps project managers in particular – are unable to identify those opportunities to benefit from the work that testing undertakes. That leaves the function feeling isolated and separated, which not only reduces project effectiveness and efficiency, it has a negative impact on testing motivation and engagement. That, in turn, leads to further losses of effectiveness and efficiency, and that’s the kind of spiral that no organization should afford.