Should it be QA’s role to be the keepers of the repository (history) of requirements via their test cases?

5 pts.
Tags:
Agile
Quality assurance
Software testing
At my job, management wants the QA team to be the "keepers" of all the requirements for the system. This is because when we write the tests and uncover changes to requirements or code, the Feature Design and Implementation docs are never updated to reflect the "actual" functionality, because in an Agile world, those teams are on to the next sprint. So it's QA's job to keep these tests as living breathing documents and organize and make available to all worker teams this requirement repository. We are also updating the requirements (per our tests) as a feature is enhanced is subsequent sprint. Thus, it is now our jobs to manage these requirements.  I believe the designers and product teams should be managing this repository. What do you think?
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Interesting question with pros and cons to both sides. Being a developer I have seen it both ways. I like keeping track of it personally. We have had issues where people were blaming us of a flaw in a piece of software. We could go back and take a look at what user(s) signed off on the project and then they would have to explain why it happened. Sometimes we did not get all the specs needed to develop the program/app and the user would point blame at us. By them signing off they said it provided all the features and functionality they requested. Just my 2 cents.

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Justin Rohrman
    The question of what testers "should" do is difficult and is generally based on what works for your team/project/company. 

    I personally would not be happy being responsible for updating requirements for a few reasons.
    • Product people generally have a deeper understanding of this subject because of their proximity to the customer. Having testers responsible for this creates a disconnect in the same way that putting testers in charge of fixing broken unit tests would create a disconnect. You just aren't close enough to the subject matter usually.
    • Do you really use those documents? Are you sure? really sure? In my experience, it is uncommon for people to go back and reference old product documentation. Maintaining that creates extra work that isn't valuable.
    • I'm not sure what you mean by requirements here, but it feels like it is a little counter to your teams goal of being "agile".
    If you absolutely have to do this, and maybe you do, I'd probably make it the responsibility of everyone on the tech team to make updates when they discover something out of sync. 
    2,130 pointsBadges:
    report
  • Kevin Beaver
    It seems this content – and responsibility – should be upstream a bit from QA. At least that's where I typically see it. That said, if it works for your organization then it can be wherever it needs to be. I'm not necessarily convinced that QA should own this especially given all the factors involved including security requirements/standards, threat modeling, and so on.
    27,505 pointsBadges:
    report
  • Matt Heusser
    You can declare that ... but I've never seen it work.

    Test cases have this bizarre mix of stakeholders. The obvious one is they tell testers what to do to test a feature, but they also describe the requirements and common complex operations.

    If the actual change orders don't contain what to do, how do we think test cases will? (And btw, testers behind is an agile smell, adding more work to them will make them behinder.)

    Your best bet here is to express the test cases as executable specification, with testers involved before code is created. It seems to me like you are pretty far away from doing that.

    In that case, I would make your test cases as light, breezty, and simplistic as humanly possible.

    The reality is your test cases are probably a mess. Management has no idea how junky and huge they are and is asking you to do more. To be successful in this, you need to think different: Simplify, simplify, simplify. Express tests on a wiki, with tags by feature. Tests now become lists of acceptance criteria of what the software should do. Use exploration to cover the rest.

    good luck.
    4,805 pointsBadges:
    report
  • Lori Rangel
    In our case, QA and Product are the keepers as Product sets the requirements based on the customer needs, market impact, yada yada and QA is tasked with making sure those requirements are adhered to. The "repo," however is the product management software and the final scope gets imported as a reference into our test case management software.
    30 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: