0

I'm looking for some ideas on how to improve our current Quality Assurance process. There is no official QA method in place right now, but we basically just get some requirements using a ticket system and we go back and forth until all the requirements are covered. The problem right now is some requirements change and we may spend a day or 5 days on multiple requirements but in the end they all get tossed because the end user decided it's not appropriate or wanted something else. So we lose time and money, but how can we have foreseen these situations? I have to believe there is an effective way to communicate with end users about their set of requirements so that we can EXTRACT and squeeze out any doubts to foreshadow a change in a range of requirements. And then we need to be very sure that the requirements won't be tossed or changed so drastically that our work was a waste. In some ways it is about understanding really really well what the user eventually wants. But what is this effective QA process? Any ideas are greatly appreciated. I'd be happy to clarify any concerns.

Thank you!

|improve this question

closed as too broad by gnat, EL Yusubov, user40980, Corbin March, GlenH7♦ Sep 5 '13 at 13:18

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    First, this is too open-ended; second, QA questions are generally better asked on Software Quality Assurance & Testing. – Aaronaught Jul 7 '11 at 0:50
  • @Aaron. First, please explain how it's open-ended and give constructive feedback instead of your opinion. Second, this is a community built upon the foundation of problem solving and answering questions. If the question lacks certain details let's try to build a better question. Third, I was not aware of the other site but now I do. – Eket Jul 7 '11 at 16:17
7

Users change their minds constantly, which is natural and healthy. It means they have learned more about what they want.

We know requirements today will be wrong tomorrow, so it makes no sense trying to get a definitive answer. It's all just speculations anyway. They wont be satisfied even if you deliver exactly according to specs, because what they wanted then is not what they want now.

So, you need to change your development process to work with this instead of against it. Here is what I suggest for requirements:

Come up with some initial "requirements" with your users. Implement them. Invite your users to try it out and then listen for their valuable feedback. Repeat until satisfied.

Great tools for this are user stories and a great process implementing what I just said is Scrum. Really, it works.

|improve this answer
  • 3
    +1: This is completely true. Requirements are like bodies of water - some are peaceful lakes that don't change, and some are fast-moving rivers. If you try to fight a river by swimming against it, you'll just wear yourself out and still wind up going wherever it's going. So "go with the flow". Agile processes like Scrum and Kanban embrace the idea that requirements change, and still provide a way for developers to be proud of what they're doing. – Bob Murphy Jul 6 '11 at 22:17
  • I love the river analogy Bob, thanks, and great response Martin. – Martin Blore Jul 6 '11 at 22:23
1

I don't think this is a Quality Assurance issue. This is more of a requirements gathering issue. I would suggest that your management draw up a requirements document, give it to the client for their approval, and only then should the work of implementing the requirements begin.

Keep in mind that people can change their minds, it's human nature. Minor changes should be acceptable. However, drastic changes by the client should not be permitted and should be penalized accordingly.

|improve this answer
  • Agreed. Work should begin until requirements have been signed. – FrustratedWithFormsDesigner Jul 6 '11 at 20:48
  • Why should changes be penalized? I see changes as feedback, that the client has learned more about her problem, which is a good thing. – Martin Wickman Jul 6 '11 at 21:30
  • @Martin Wickman: Major changes to requirements after they have been agreed to should be penalized because work has already been committed to and is in progress. Time is money. – Bernard Jul 6 '11 at 21:35
  • Interesting ideas. I do like the idea of a penalty but I'm not sure that fits within our "culture". But perhaps you could provide me with a reasonable penalty. My clients are in house so I see them everyday, I wouldn't want any sour feelings. I also agree changes are good, and often times the end users are very satisfied once their product is perfected to their needs. So their satisfaction is high, but ours is low. – Eket Jul 6 '11 at 21:53
  • 2
    Change is inevitable. How often do you show results to the clients? Increasing the rate of feedback should reduce the amount of rework. – kevin cline Jul 7 '11 at 2:14
0

I would agree with the others that this is definitely not a QA process. If attempting to tie it to something, it would most definitely be the the requirements phase, typically handled by a product owner or business analyst. Instead of doing development right off the bat, if you can, sit down with the customer for each of the requirements to find out what they actually want. An hour long meeting can often save a week or more in redone work, really no different than catching bugs in dev or QA rather than production.

In the past, if the whole process is new, I've seen it work very well when a representative from each part of the dev group (ie: BA, QA, DEV) meet in these discussions as everyone begins to get a feel for what's actually required. After a while, it gets to the point where the business analyst, or whoever, can comfortably sit down with the customer and discuss the requirements to come out with something that the customer actually wants.

|improve this answer
0

Personally, I feel that the most important step in a QA process comes after the specifications are somewhat confirmed (although they tend to be quite dynamic) and the tester start to work on a test plan.

Test plans are critical in making sure the QA process is organized. Since your requirements change often try and make the test plans more general and reserve specific test plans for essential requirements that you know will not change dramatically.

Test plan should be peer reviewed and I always try and get my test plans reviewed by the Developer(s) themselves.

In addition to test plans it is often advisable to create test scripts to support the test plan. It is standard practice to place these scripts in the QA Test Plan database (I am assuming one exists as it is rather essential for most company's). The project manager (assuming they have some tech knowledge) can now look at the scripts via the database and also observe the test plan to make sure the QA testing/ planning is going smoothly and efficiently!!

|improve this answer
0

I would echo @Bernard, @rrazd and @Lyndon: the test plan is a co-product of the requirements definition process. If a requirement isn't testable, it probably lacks specificity.

To put it another way: if your users will sign off (at least tentatively) on a test plan you are on the same page, at least for the time being.

Note:

  1. this would be an acceptance test plan (it doesn't address any other type of testing);
  2. as per @Martin, expect the requirements to change as the users (and you) come to understand the problem domain better.
|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.