Since business is continuously changing very fast, and we might find that what was crucial yesterday might not be that important today, the solutions designed for supporting the business might require to be built as flexible as possible.
How is testing changing in an dynamic world?
How can continuous change be validated?
Accommodating flexibility into your solution might not be something so unusual nowadays as experience thought us that a very rigid solution can become a bottleneck at one point. Nonetheless accommodating continuous change into your solution might get challenging along the software lifecycle “ride” even though you designed the most flexible solution. Then clear vision is what you need on the long run to make all this work and support business.
But for the time being lets move at the very end of the software lifecycle – as it was once known only as the testing phase.
How is testing changing in an dynamic world?
How can continuous change be validated?
Can you rely on the test result if you build a flexible, always changing solution?
Is testing still required or it doesn’t bring any value?
The answer to all these worries and lot more others similar would be that testing as once was known only as a phase should now be more flexible as well. The rigid, very clear testing phase is replaced by continuous collaboration and input from testing perspective starting from the solution planning until the very first tests can actually be performed. Building a “testable” solution will give you the opportunity to trust the testing result and to accommodate the change that you need while building a very difficult to test solution will most probably be leaving you with some question marks.
Speaking about validating a core function of your solution means that you are able to conduct series of different test techniques in order to trust that what is ‘under construction’ will fit in the overall landscape. In theory one will have a very clear vision about what he or she wants or need but in practice this is not always the case. A tester might find itself in the situation of validating a solution without clear specification or without having a clear vision of the actual needs. While in the old testing phase you would have the whole delivery on the table and you would not touch it until the very end of the software lifecycle, in the dynamic agile approach the role of a tester have changed and the input can and is encouraged to be given as soon as possible.
Can you test something at all when a solution is under construction?
No. But you can provide input from a testing perspective, you can build a testing strategy, you can document yourself about the solution, the architectural landscape, the requirements, the needs. Just by being involved in delivery cycles will give you the possibility as a tester to be informed and to participate in the current activities. You can address issues earlier because you are educated earlier to do so.
Since a testing professional is involved in the delivery cycles and can and will express it’s opinion regarding the developed solution – how is testing properly accommodating the input from other participants? In the supposition that testing actually is an isolated phase it is difficult to see from the outside how testing is conducted and even you might not completely understand what was tested and what was not. If testing is completely transparent for all, and able to receive and accommodate input and feedback, an educated choice of the tests to be conducted will increase the confidence in the product and will save you from unnecessary expenses. The approach has changes but the goal is the same – testing should provide trust and assurance that the product is reliable and the quality is not affected.
