I have been reading about software testing again, just surveying the market to see what new techniques and approaches have been invented. I have found that the basics are still in well-respected planning, preparation, objectivity, etc. What is amazing to me is what I don't see. Everyone has suggestions about how to improve your testing—implement a testing process or methodology, utilize IEEE standards, work towards CMMI compliance, etc. No one mentions that improving requirements will improve testing!
Testing software is an extremely time consuming and expensive activity. As software continues to get more complex the difficultly with testing increases exponentially. Why does it take so long? I would argue that one of the main reasons is that poor (or missing) requirements slow down the process as much as any other issue. If you don't have good requirements, how do you write a test plan? If you don't have detailed requirements, how do you write a detailed test case with a step by step procedure? If you don't have excellent requirements, how do you evaluate the software's ability to address the business problem. Instead of focusing so much time trying to improve our testing methods – let's spend more time writing excellent requirements – which are "testable" or "verifyable" and make our tester's lives easier!
6 Comments
CMMI does handle requirements! In the staged model you already encounter it in the first step towards maturity level 2: the Requirements Management process area. I agree requirements engineering is a far more effective process than any kind of test process to develop high quality software products. In my blog I frequently write on requirements management and other process improvement techniques: and – Most useful requirements processes – Handling late requirements – Use Test Cases to Clarify Requirements (yes, as a tester you also can help in the requirements defintion, see also agile practices like test-driven development) Enjoy, Ronny http://software-quality.blogspot.com The Software Quality Weblog
I found that the business owners either partially communicate the business problem or due to lack of business process, they don’t identify the problem well. Of course bad requirements delay the project all together. But software testing can never be 100% satisfactory, so business needs to understand it and establish acceptance testing. It could be 90% -99% whatever is acceptable to the business. Also, test scripts can cover most often used scenarios or path; other tests can be done ad-hoc. I would also highly recommend a use of a testing tool where testing can be monitored and measured. With that said BSA really plays a vital role on a project especially software implementation.
What I try to do is the following- 1. Have the test plan approved by major stakeholders. 2. Schedule testing-time – gather users/testers for a while, lock them up in a room:) and try to get as many steps as possible. 3. Send a daily update and provide a deadline. 4. Hope for the best!
Great practical ideas by Raaj. I sometimes force the business to create their own UAT plan which the BA and development team then approve. This ensures that the expectations in UAT match the requirements laid out during the analysis phase. I find almost all project issues found in testing or UAT can be traced back to the analysis/requirements gathering phase. Which always brings us back to the question of responsibility. Typically the BA is a single person. It is his responsibility to guide the business through what it really wants and what it might be leaving out. The BA might not be completely capable of doing that, though, especially early in a customer relationship – they may not have full expertise in the system or strong enough knowledge of how the customer thinks. A full process including change request forms and budget/scheduling impacts help lead the business into better thinking in the future. Meanwhile it is important that the entire team – development & QA included – understands that ultimately the project is being done for a customer. Development & QA must be encouraged to push back on requirements that are unclear or sound like a bad idea. Ultimately it all comes back to requirements, and ultimately the BA must lead all components of the team to recognize their own responsibility and input into requirements. This improves the testing experience and the overall project delivery.
My aporoach – 1) req specs & detailed design from the development is matched. 2) prepare a high level test strategy and send the same out to business/solutions and development 3) sign off process on requirements & detailed design docs 4) send out scenarios on the project to business/solutions and development for review and sign off. This is a tested and really a practical approach. Thanks manesh
Very good article, i really like it. I am doing a bit on research about Software Testing and i found also macrotesting http://www.macrotesting.com to be very good source for software testing.
Thanks for your article
Regards,
Prem