• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Anyone come across Requirements Based Testing?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Anyone come across Requirements Based Testing?

    Hi,

    I am a BA who has come across a testing methodology called Requirements Based Testing. Has anyone worked in an environment which uses Requirements Based Testing? I have a checked docs online and i have some understanding, however i have a few questions:

    1. Are the testers/developers involved during the requirements stage in order to help make the requirement clear and easier to test/code (i.e. expected results?)

    2. Can someone who has experience please provide me with a flow of how things work if using Requirements Based Testing, i am thinking it will flow something like this:

    2.1 Requirements Gathering - BA/PM
    2.2 Testers/developers/business review - Testers/developers to remove ambiguity
    2.3 Update Requirements with feedback from above
    2.4 Get sign off from the business
    2.5 Handover to the developers to code
    2.6 Handover to the testers once the BA as completed system testing.

    Obviously there might be a few iterations of points 2.2 - 2.3

    Any help appreciated!

    Thanks in advance!

    #2
    Originally posted by speedo View Post
    Hi,

    I am a BA who has come across a testing methodology called Requirements Based Testing. Has anyone worked in an environment which uses Requirements Based Testing? I have a checked docs online and i have some understanding, however i have a few questions:

    1. Are the testers/developers involved during the requirements stage in order to help make the requirement clear and easier to test/code (i.e. expected results?)

    2. Can someone who has experience please provide me with a flow of how things work if using Requirements Based Testing, i am thinking it will flow something like this:

    2.1 Requirements Gathering - BA/PM
    2.2 Testers/developers/business review - Testers/developers to remove ambiguity
    2.3 Update Requirements with feedback from above
    2.4 Get sign off from the business
    2.5 Handover to the developers to code
    2.6 Handover to the testers once the BA as completed system testing.

    Obviously there might be a few iterations of points 2.2 - 2.3

    Any help appreciated!

    Thanks in advance!
    Morning Speedo

    Testers can only really test from requirements - what else have they to test against ?

    I have have worked in some organisations where they are trying to bring the testers in, earlier in the cycle, i.e at the requirements phase, which I think is what you are getting at.

    point 2.6 I would have thought the testers would be involved with the integration / system test before the BA gets involved with 'business testing / UAT', but using the BA to clarify any points raised in system testing.


    is this methodology used where you are working now ?

    how experienced is the test team ?

    have you spoken to the test manager ?

    Comment


      #3
      I have contracted as a developer where they used what they called risk based testing.

      They analysed the risk of what would happen if the individual mods in the project didn't work, then only tested the the mods that had the highest risk.

      There argument was that it didn't matter if things of low risk didn't work to the end customers.

      Seriously.


      Funnily enough I am still in touch with some of their permie developers, who were all made redundant recently because all of their customers had refused to pay because the software was tulip.
      Still Invoicing

      Comment


        #4
        The problem is people implement these fancy methodologies without knowing what they actually mean.

        My last place, I was on at them to introduce Risk Based Testing, which if implemented properly could have saved them a hell of a lot of time. Testers were spending as much time on writing and executing tests to check more trivial aspects of the system as they were on the more complex aspects.

        They refused to implement because they had tried and failed to spot a live issue using it on one project. (What actually happened was the test manager and his boss sat in an office and decided to get the project in quicker they would cut out x number of non risk tests - how they did this is beyond me as they tests weren't marked up based on risk ! )

        Comment


          #5
          Yeah it can be useful on internal projects.

          But I would never ever ever implement risk based testing on a software product or bespoke system that you are selling.

          To the customer, who is paying for the software, any failure of the system no matter how small gets to be an issue and affects system confidence if it happens regularly.
          Still Invoicing

          Comment


            #6
            Originally posted by blacjac View Post
            Yeah it can be useful on internal projects.

            But I would never ever ever implement risk based testing on a software product or bespoke system that you are selling.

            To the customer, who is paying for the software, any failure of the system no matter how small gets to be an issue and affects system confidence if it happens regularly.
            The point I was trying to make is that risk based testing does not mean you don't test low risk areas and what is low risk on one project is not low risk on the next.

            Comment


              #7
              Ahh, got you.

              Yes I completely agree.
              Still Invoicing

              Comment


                #8
                Originally posted by speedo View Post
                Hi,

                I am a BA who has come across a testing methodology called Requirements Based Testing. Has anyone worked in an environment which uses Requirements Based Testing? I have a checked docs online and i have some understanding, however i have a few questions:

                1. Are the testers/developers involved during the requirements stage in order to help make the requirement clear and easier to test/code (i.e. expected results?)

                2. Can someone who has experience please provide me with a flow of how things work if using Requirements Based Testing, i am thinking it will flow something like this:

                2.1 Requirements Gathering - BA/PM
                2.2 Testers/developers/business review - Testers/developers to remove ambiguity
                2.3 Update Requirements with feedback from above
                2.4 Get sign off from the business
                2.5 Handover to the developers to code
                2.6 Handover to the testers once the BA as completed system testing.

                Obviously there might be a few iterations of points 2.2 - 2.3

                Any help appreciated!

                Thanks in advance!
                Some people have these crazy ideas surrounding software development that Business Analysts should map out how a new piece of software should behave, and Testers should make sure that the finished software does behave as specified.

                Where I have seen anyone attempt "Requirements Based Testing" what they have done is link all the tests in the test plan back to each of the requirements in the business spec. The test frameworks are therefore produced after the requirements spec with the Business Analyst's input (at this stage it is not always possible to create concrete test plans if the software is still vapourware).

                The testers will also usually review the requirements from a "how the f*k am I supposed to validate that?" point of view.

                All it is really is a fancy-arse way of saying "make sure that testing covers everything in the requirements specs", it is not a new form of testing alchemy.

                Wait, you are all going to tell me that testing against requirements is actually quite a rare thing for anyone to do now aren't you?

                Comment


                  #9
                  Actually, writing requirements in a clear and concise way that testers understand what they need to test is rare in my experience Gonzo...

                  Sadly, some of the projects that I've been on in an ITIL capacity often have junior BAs writing up requirements as they're seen as not important/easy (go figure ).Even when I voiced concerns this situation doesn't change.

                  That's when I know to take the money and run...

                  (PS - yes get the testers in at an early stage, but the BA is the person running the show. I've seen one project go belly up when they thought that they could dispense with BA by getting the testers to write requirements - what a fook up that turned out to be... )
                  "I can put any old tat in my sig, put quotes around it and attribute to someone of whom I've heard, to make it sound true."
                  - Voltaire/Benjamin Franklin/Anne Frank...

                  Comment


                    #10
                    And the morale of the story is let a BA do BA's work, and let Testers do Testers work!!!

                    The number of times I have seem people try to blur the roles, usually because some deadline is coming up and they need to try and find a way to frig it all together in time to hit the deadline, and it has gone tits up is just not funny.

                    People being forced into doing roles they are not supposed to be doing (be is lack of a person who can do it, or to hit deadlines) is just a way to screw a decent project up.....

                    Comment

                    Working...
                    X