For years, we have been hearing only one thing in software development: “We have to become agile!”. Nevertheless, many companies are still developing their software products in sequential and linear processes, in which the requirements to the product are placed at the beginning of the software development process and testing is located at the far end. For this reason, this procedure with its clearly defined phases for all stakeholders can be understood and managed easily.
But does it always have to be the rigid waterfall, which stubbornly flows downstream without any detours? We know the answer: No. Especially if multiple companies work together – ordering parties, external software development companies and (software) testing services – and if the software products are embedded in a complex system environment with many interfaces, it is quality assistance, where all ends meet at the end of the project.
Agile testing methods sustainably increase the quality
At SDS, we have developed an approach to compensate potential weak points which a rigid, linear procedure may entail, and try to unite both worlds, waterfall and the agile procedure. As a result, we can selectively offer our customers the usage of agile methods in project operation to achieve the highest software quality without having to establish the completely formalised process, such as “scrum”.
A project which proves the success of agile methodology is definitely the testing of the new offer “FamilyBytes” of T-Mobile Austria. This summer, we had the pleasure to carry out the quality assurance for this new telecommunication product on behalf of our long-standing customer T-Mobile Austria . The special challenge for this project, on the one hand, was that the complete life cycle of a product had to be tested with many involved systems and interfaces (from mobile web applications up to complex database structures). On the other hand, a delay was no option in the tough timetable due to marketing and advertising plans.
More efficiency due to the elimination of the “black box”
The decisive agile factor for the project success of FamilyBytes was the intensive exchange already during the test specification and test case creation. In extensive coordination meetings the requirements were introduced and explained to the testers. The contact persons on the customer side (software architects, business analysts and delivery management) were available for further explanations of unclear points at any time. We were ideally prepared for the test start and could say with a clear conscience: Let‘s do it! The reasons for that were the intensive discussion and analysis of the requirements as well as their selective adaptation in case of changes and, above all, the active exchange in the project team during the test preparation.
Instead of testing in a black box and introducing the new software to the stakeholders from the specific department in a big launch event at the end of the testing phase, as customary in a linear development process, we maintained an intensive exchange also during testing in this project. Immediately after the software delivery to the testing environment, a meeting for an application integration test (AIT) was scheduled. Here all persons involved (design, architecture, business analysis, development and testing) met for the evaluation of the software maturity. Contrary to the classic AIT, our clear focus was not only to identify and analyse basic errors during the meeting but also their prompt correction. Therefore, already at the first QA the go/no-go decision by the project management regarding the market launch date was made easier. After all, it shall not be underestimated that these meetings strengthen the team spirit and the focus on the success of the project in case multiple companies work together.
Integration of the responsible departments already in the early project phase
The test reviews were another important agile element. They were held during the ongoing testing phase together with the stakeholders from product management and marketing and were similar to the sprint reviews with respect to structure and procedure. Also here the agile principle was able to benefit from having all stakeholders together at one table: the customers could get to know the software already before the official acceptance and at this point still had the possibility to provide input from a functional point of view. Due to the early review, it was also possible to improve the software quality within the same release through change requests, which originated from the customer‘s early analysis of the almost completed product. In the final acceptance meeting no unexpected surprises occurred, as all questions and potential misunderstandings had already been clarified beforehand.
The organisation of testing led to the big success of the entire testing project. Delivery management on the customer side and testing management at SDS were closely cooperating with each other on a continuous basis and therefore allowed a clear framework the implementation.
In a nutshell, the following agile aspects led to the project’s success:
- Bringing together all stakeholders for a shared information and expectation horizon instead of “thinking inside the box”
- Intensive exchange before and during the testing phase instead of one-way communication
- Short communication channels instead of a hierarchical system
- Open and transparent exchange among all persons involved, instead of silo mentality between departments and roles
Especially the last aspect is, of course, does not only depend on testing, but depends to a large extent on the modern and open approach of the involved companies. And here we were lucky to be part of a highly motivated project team. The above-mentioned agile measures, however, also had a positive effect on a solution-oriented “Let‘s do it” mindset in the testing phase, and hence selectively replaced the classic waterfall. The result: efficiency, transparency and high quality of the products!
