I have been interacting with a few practitioners who claim that they are in a ‘Quality’ role. Since I was curious about what exactly they do on their daily work, I spoke a bit with them. In this blog, let us look at one aspect of a quality initiative, which is requirements collection, and why I consider it as the most important aspect.
Subscribe to my YouTube channel: https://www.youtube.com/@STQTalks
“So what do you do as a Quality _______”, I asked a few people where the blanks stand for ‘Engineer’, ‘Analyst’, ‘Assurance Engineer’, etc. Their answers varied depending on their organisational needs but one answer struck me – ‘I make sure that the developers meet as needed to make the Quality happen’.
‘Well, aren’t developers supposed to be self-organized and take care of their own meetings? Should someone tell them why and when they should meet?’ I asked curiously.
‘Yes. But I am kind of a Quality enforcer. So I remind them about why and when they should meet’, they replied.
‘So what do they do in these meetings? Do they work on requirements? Do you do BDD or ATDD?’ I asked.
‘No, we don’t do requirements. We do things as they come’, was the reply.
I was confused. There should be at least one form of representation of the requirements (a document, an audio recording, a Microsoft Excel file, a BDD/TDD file, whatever. How do ‘things as they come’ be translated to software without any communication? Obviously something was wrong in that practitioner’s understanding.
The reason for asking them about requirements was because requirements are the most important aspect in a Quality initiative, in my opinion. The end-users’ preferences of how the software should work should be adequately captured in requirements (however informal the capturing method be). After all, Quality is all about providing what users want in the way they want. If I don’t put that down somewhere, how am I going to build a quality product?
Last year when I was speaking to a practitioner about their way of collecting requirements, I was told they do it in an Excel file. Although it looked weird to me, at least, they have a method in place. At least, they might have version-controlled Excel files of requirements!
So don’t forget to note down the requirements, even if you don’t call that as ‘documentation’. It’s so important!
Feel free to get in touch with me to guide about testers’ role in requirements collection process for your organisation.
Subscribe to my YouTube channel: https://www.youtube.com/@STQTalks