The question of how necessary testing is and from where in the process a tester should be called in is not new. More and more, the emphasis is on starting testing as soon as possible and including the tester himself as early as possible in the process. Even before the first line of code is written there should be an idea of what testing will entail. However, it is not yet a pervasive truth. However, that it is good practice to have a tester participate as soon as possible became painfully clear when I was tasked with testing a new functionality within my project – a new payment method.
The moment I was added to this project, the specifications had been written out and the tickets had been created. In short, I got the message: the documentation is complete and all the necessary was cast in the tickets. Development had been underway for some time and the first version of the software was test-ready. Given the previous message, I thought that everything had been thought of and that I could calmly focus on the tickets without too much fear of overlooking something. An assumption I had not heard made.
Indeed, it gradually became clear that while the documentation that was there was complete, not everything had been considered in the analysis. Late – too late – in the process, questions surfaced that should have been answered much earlier. It became clear that a tester has a broader or sometimes fuller picture of how different things hang together. In this case, it was my experience with the system as a whole compared to both the developer and the analyst that made the difference.
When you pay for something, you would have liked to have received that product. So there must be stock and it must be reserved. Now this part took place at a different time with the new payment method. Which means that stock reservation was also going to have to be retested. No thought had been given to this. The result was not only that the deadline was jeopardized – given that more testing was going to be required than expected – but also that new documentation had to be issued.
So it is always a wise lesson to involve everyone who will be working on a project as early as possible, “even” the tester. The perspective as a tester should not be underestimated. This one sees a system not just in parts, but as a whole. The cogs as well as the machine. Which can help create complete documentation, early testing strategies, and in time, therefore, a quickly delivered product, of good quality!
Watch our FREE ON DEMAND WEBINAR on Shift Left Testing