6

I am currently a business analyst, but increasingly as I am working on agile projects. I am including test cases as acceptance criteria for my user stories. I am also interested in becoming more directly involved in the testing side of things as an analyst, but I have some questions.

Background

  1. In a more traditional software development process (RUP, Waterfall) one would write test cases, the manual test scripts and test data for each scenario. The problem with this is the time it takes to write such documentation.

  2. In the user stories that I create, when I define the acceptance criteria, I write these as self-contained test cases.

In an agile development project

  • Would a test analyst then take each test case associated with the user story, write a test script and test data so these can be executed and the results recorded? or...

  • Would it be better that each acceptance criteria encapsulate not only the test case, but the test execution scripts (using Behavioural Driven Development techniques of "Given...., When.... And... Then...." format) and the associated test data for positive and negative tests?

What are the best practices here?

1
  • 4
    Could you better define your question? From the contents and the title I'm not sure what your question is. Is it what does a tester do in BDD if he isn't writing acceptance tests? Oct 1, 2012 at 0:47

4 Answers 4

11

Welcome to SQA, FJFG. As Bruce McLeod once wrote, "There are no 'best practices', there are only good practices in context." A good practice for you will depend upon your context. I will suggest some contextual considerations. You may be aware of others.

Your primary job, or at least your initial job, is to own and convey business requirements. Those requirements have an audience, and you try to tailor how you write the requirements to maximize the chances that your audience will share your vision.

Only you and your testers can determine how much detail you need to convey in order for them to do their jobs. If you trust each other, and if each of you listens and communicates carefully, and if all of you are skilled at your jobs, a lot can be left unsaid. In other words, it may be possible for you to focus on business requirements and for your testers to interpret those requirements from the perspective of testing. On the other hand, if there is a lack of trust, skill, or listening, you and your testers may need to spend more time in explicit communication. In other words, your testers may need to ask you for clarification around requirements and/or you may need to be more explicit about test cases.

A potential disadvantage of your providing explicit test cases is that your testers may not perceive the need to think about test cases for themselves. If you are comfortable with asking your testers to be button pushers and mouse clickers who follow a pre-determined script, that may be a appropriate. There is a time and a place for that kind of role. On the other hand, if you want your testers to think for themselves, diagnose problems, and question assumptions, then providing a lot of explicit test cases could put you at cross-purposes.

One alternative to writing explicit test cases is to review and provide feedback on the tester's written test cases. This will give the testers an opportunity to be better testers, and will give you an opportunity to be a better business analyst.

Regarding what an agile process requires in terms of test materials, that is really up to you. An agile process emphasizes communication over fixed processes. No one outside your organization can tell you what you must or must not do in order to be agile. I suggest trying something, paying attention to what happens, and then adjusting accordingly.

6
  • 1
    How could I not +1 :-) Sep 30, 2012 at 9:35
  • @user246 why would giving examples create a bad tester? A bad unmotivated tester is just that, examples or no. I would think that giving a tester examples would empower them to understand whats expected, allow them to automate and then exploratory test the remaining pieces. I'd say the missing piece is working together as a team to come up with the examples, Tester, Dev, and BSA together. To me reviewing later just leads to wasted work. Oct 1, 2012 at 0:34
  • Giving examples would not necessarily create a bad tester, just as depending on your testers to flesh out your business requirements would not necessarily make you a bad business analyst. Elaborating on why you want to be more directly involved on the testing side might clarify how you could change your practices for your new role.
    – user246
    Oct 1, 2012 at 1:50
  • Thank you all, but in my context, although I am currently a Business Analyst, I am finding increasingly in Agile projects I am being drawn more and more into the testing side of things [I hope this does not offend the shop stewards and the Union Reps!!], but I am wondering how important it is to develop manual test scripts and the associated test data in agile development projects when the development cycles are only two weeks in length? Is writing manual test scripts and defining test data still mandatory in Agile development projects, or have they become optional? Oct 1, 2012 at 17:11
  • In Agile, you would define your 'velocity': how much the team is getting done in a fixed period of time. If you have small team and writing manual test scripts and test cases to a certain level of detail is not allowing the team to achieve the desired velocity, then you need to find an alternative, less verbose way. Documenting tests would extremely important (a separate topic) - details are left to the team to figure out Oct 1, 2012 at 21:42
6

I see design of requirements (user stories) and test cases (acceptance criteria, scenario's) as a collaborative effort of business analysts, developers and testers.

BA typically kicks of with the initial user story and acceptance criteria.

Further elaboration (conversation, architecture meeting, story analysis,...) may - split the user story - make acceptance criteria specific by examples and (like Given-Then-When scenario's)

Both BA, dev and test perspective are essential to define and refactor.

This is not sequential process, but a result of interaction.

Google on "3-amigos meetings" to find more on this.

0
2

tl;dr

Read different blogs and people's perspectives while you build a set of practices that are best for you. Note that once you change a job, only a few of those practices might come with you. Don't get stuck with a few methodologies and practices marketed as the "best practices".

Long version:

"Best practice" questions will have numerous perspectives and responses, and maybe all of them claim that their theory is backed up by the results they have seen.

It is definitely not wrong or unproductive to read what people think is the best practice, but you will have to create your set of efficient practices for your work environment. The effectiveness is Testing / Quality Assurance is very relative and is strongly bound to the product, company, work environment, the people you work with and their skills and background e.g. Best practices in an online ad serving company might seem bogus to a person from defense IT background. The basics (or best practices) do not seem to appear until you have had significant experience, and hence I believe the absence of a formal education for a QA.

0

Thank you, this confirms my suspicions regarding the need to produce detailed test cases, manual/automated test scripts and data.

Proposal

I think that way forward is to encapsulate this in the acceptance criteria for each user story, and make acceptance criteria for each user story a test case that contains the minimum information to test and validate the functionality defined in the user story, something expressed using BDD. For example:

TC3145:Scenario: Email the XXXX Editor:

Given

  • the email address of the XXXX Editor for the is known and stored by the YYYY Content Management System as a known fixed variable,
  • And I wish to email the [page] XXXX Editor about my concerns concerning the site usage policies as elaborated in the Site Terms and Conditions,

When

  • I click on “Email the XXXX Editor”,

Then

  • the YYYY Content Management System presents me with the web form.

And when

  • I complete the form,

Then

  • the YYYY Content Management System sends the email message to the XXXX Editor.

What do you think? My thoughts would be not to do this for every function, as some could be simply checked with "verify that.... produces the "

What do you think?

Another question

And, just one more thing.... I have been asked about performing UAT testing for releasing the developed software application to production. In terms of the old V model, at this stage, there should be no bugs (one hopes!) and so, UAT is to validate that the application is "fit for purpose".

In that case, what would you advise?

In that case, would it be appropriate to create some high level end-to-end manual test scripts and data to validate the high level application and systems process to operate as per the business requirements as elaborated in the key user stories?

What would other suggest for UAT in an agile development project?

4
  • 1
    Have you looked at the agile testing quadrants ? Oct 2, 2012 at 0:08
  • @Flash Jack, I improved formatting for you, so I hope it is easier to read it now.
    – dzieciou
    Nov 3, 2012 at 13:14
  • 1
    Anyway, your answer does not answer your question but makes a comment about others answers. It also contains new questions. Could you please convert part of your answer as an update to your question or a comment to it? And for the rest create a new question on SQA?
    – dzieciou
    Nov 3, 2012 at 13:17
  • I agree with Dzieciou. An answer isn't the appropriate place to ask another question. You have a couple of questions here that should be evaluated on their own.
    – corsiKa
    Nov 5, 2012 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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