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

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.

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?

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?
–
Steve MiskiewiczOct 1 '12 at 0:47

4 Answers
4

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.

@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.
–
Steve MiskiewiczOct 1 '12 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.
–
user246Oct 1 '12 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?
–
Flash Jack From GundagaiOct 1 '12 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
–
Suchit ParikhOct 1 '12 at 21:42

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.

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?

Have you looked at the agile testing quadrants ?
–
Phil KirkhamOct 2 '12 at 0:08

@Flash Jack, I improved formatting for you, so I hope it is easier to read it now.
–
dzieciouNov 3 '12 at 13:14

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?
–
dzieciouNov 3 '12 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 '12 at 16:10