In classical (waterfall) project management approaches, the requirements review is an essential gate before starting the actual software development phase. If you participate to these meetings as a software tester, your role is to make sure that the software requirements are testable during the acceptance testing process. In this article, Richard Ellison provides advice on how to handle the requirements validation process from a software testing perspective.
Author: Richard Ellison, The QA People, http://theqapeople.com/
“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along wound destroy civilization.”
– Gerald Weinberg (American computer scientist)
Requirements reviews for complex waterfall projects will probably be the most painfully boring thing you will do in your life. For one week you will sit in a room and listen to people going through misunderstandings that will crop up again and again. The easiest thing will be to tone out and not listen and review the requirements after the fact. Every time I review after the fact, I missed something, an odd expectation was put on the testing team or a non-testable requirement was created with the assumption that it would be tested. The worst scenarios I have run across is questioning the requirements after initial review only to identify that business analyst (BA) does not know what the requirement means and has to go back to the client to identify why we needed this in the list of requirements.
A few key points about the requirements review. Your role is to question and annoy the group as they go line by line through hundreds or thousands of requirements. People will roll their eyes and wonder why you are asking questions so your best bet is to review them before formal reviews and send questions to the BA in advance. The questions that she cannot answer, you write down to have a reference point to get clarification with the larger team. It is also fine to say I am not sure how a component would be testable and request to mark on the requirements document that you have an open question about mapping this requirement.
The best approach to these meetings is to document everything. I like to grab an spreadsheet and list the requirement number and the comments. If a new requirement will be added add, an additional row in the spreadsheet is added with the comments about the new requirement. Add a second column to identify as testable or not in a sortable format so you can easily reference it. List why it is not testable in a sortable format as well. This is something you will have to reference a few times.
The second thing is that if you do not understand an assumption or a requirement, you should keep asking until you do. Try to perform this prior to final review but you need to understand the requirements if you are to test them. Also in most instances, you or someone else will have to sign off that the requirements are testable.
I have run into issues where the BA is meeting with the stakeholder and does not understand what they have written. When your BA does not understand his/her requirements, it is time to make a respectable amount of noise within your department. Start with the next level up. Test manager, project manager, Director or head of software development and give them a heads up that you have a resource that does not understand the requirements they are writing. I would also follow up with the project manager to make sure you are seeing the same thing they are. Your real goal is to make sure you understand the testable requirements. Part of this is also talking to engineers and looking at the architectural set up to make sure you understand the changes.
Some requirements will be for server engineers or admins for the set up and request of machines. Confirm with your management if your software testing team has any role in confirming these steps are complete. For example, if you are performing testing for an application that will be on a new cloud platform. Your role may be the validation of the application while another group could be performing the validation of the hardware set up and software set up. All of these things should be clear before the final requirement review. If these questions remain open go to the project manager and let him know that the scope for testing is not clear and that the project will go to red. Once in red, the team should be meeting often to work out the open questions with a drastic sense of urgency.
The main thing to remember is this is written for you (among others) and is your tool, so making sure things are correctly identified is necessary to make testing a success.
About the author
Richard Ellison is the Director of The QA People. The QA People is a company focused on creating social mobility through software development with a focus on offering opportunities for people from various backgrounds to enter into software testing positions through workshops and online classes and certifications. Rich has worked as a QA and Project Manager Consultant in various industries such as health care, insurance, automotive and financial. His current book “How To Be A Tester” is available on LeanPub at https://leanpub.com/howtobeatester.
As you point out it is very important to verify if the requirenments are testable.
From my point of view there are three important issues mising in your review:
1. Verification if the requirements are feasible for example if you want to acheive certain precision – but the low of Fysics do not give/allow that kind of precicion. If you have multitasking requirement, task can’t be performed in the required time. Those requirements are testable but they ere not feasible, so the System can’t perform this kind of functionality.
2. Verification if there are contradictory in requirements, the requirements are testable but the System will not work as required (maybe it will even crash)with requirements that are contradictable.
3. Verification if the requirements are complete.
Hello Richard, I completely agree with your observations and will use your recommendations in my future test cases. Here, I would like to add another point which is equally important in complete software development cycle and that is “Requirement celerity”. For fast and better result it is better identify the requirement ambiguities and fix them in early stage of development cycle. This is because after completion of development, requirement changes are really painful. So, it becomes very crucial to have requirement analysis before design specifications.