TABLE OF CONTENTS:
Software testing is an everyday thing for us hence why we always keep a close eye on the evolution of standards and commonly-used guidelines.
And thus, at the end of 2021, we were brought a new version of the second and third sections of the ISO/IEC/IEEE 29119 testing standard. This particular one describes how the test processes are designed, along with their techniques and software documentation. In a nutshell, it’s all about software testing, no matter what industry.
The good news is the new version brings a bundle of improvements, that will help you. Sound interesting? Then keep reading on.
The new version of the 29119-3:2021 standard was made official at the end of October 2021 and the first thing that immediately caught our eye was its downsizing. From 127 pages in the 2013 version to “only” 84 in the current one.
Sounds great, right? So, how was it done?
This was mainly due to the editorial corrections of the previously placed points before each chapter. Rather than duplicating them, they have been explained only once, which considerably improved the content readability. And the best part is that it’s so much more than just editorial corrections.
Now it’s time to get a bit more technical.
One of the most significant changes is the removal of the Organisational Test Strategy document, replacing it with the Organisational Test Practices. We can find there are two separate chapters dedicated to the levels and types of tests covered by the document. What is more, sub-processes have been dropped, as they were in the previous version, and replaced by a breakdown by level or type of software testing. Surprisingly, the subsections outlining each level or type of test are virtually the same as for the sub-processes. The chapter on test data needed to perform a given level or type of test is a new addition and it’s also worth highlighting that the Test Policy, being the parent document, has remained unchanged.
As in the Organisational Test Practices, the Test Plan also contains references to specific levels or types of testing, rather than sub-processes as before. The latest additions here include chapters covering the test basis, levels, and types of software tests carried out within the scope of the Test Plan. Information on criteria for starting and ending particular test processes (such as test planning, design, implementation, etc.) as well as a chapter on the independence of testers are also new.
As we take a bit of a deeper dive into the document, we see that the Test Design Specification chapter has also been removed. As the authors of the standard explained, this had a lot to do with some concerns that were raised at the test conditions design stage and how they could impact test cases. Test Model Specification has been added instead. Here, the model is meant, for instance, either as a state transition diagram, equivalence class, or a set of boundary values that describes the software under test. It seems that this approach is more oriented towards keeping with the practical side of things rather than working with test conditions.
There are more amendments that followed in the Test Case Specification chapter, where we learn from the very beginning that test cases should result from applying appropriate test design techniques to the model at hand.
But there’s more to it. Moving from test conditions to a model makes the test design process much simpler – going from six steps down to the four outlined in the second part of the 29119 software testing standard.
In addition to the editorial amendments, there have been several significant changes affecting the structure as well as the content of particular test documents. For this reason, it is worthwhile to get yourself updated with the latest version of the standard. Keep in mind that you should apply the changes to your current test documents to remain partially or fully compliant with said standard.
Here at Solwit, we carry out thousands of tests every day. As a Platinum Partner of ISTQB, we always follow the world’s best practices and standards. We also support our partners in the process of “safety-critical” software certification.
