10

I am in the in-house development team of my company, and we develop our company's web sites according to the requirements of the marketing team. Before releasing the site to them for acceptance testing, we were requested to give them a test plan to follow.

However, the development team feels that since the requirements came from the requestors, they would have the best knowledge of what to test, what to lookout for, how things should behave etc and a test plan is thus not required. We are always in an argument over this, and developers find it a waste of time to write down things like:-

  1. Click on button A.
  2. Key in XYZ in the form field and click button B.
  3. You should see behaviour C.

which we have to repeat for each requirement/feature requested. This is basically rephrasing what's already in the requirements document.

We are moving towards using an Agile approach for managing our projects and this is also requested at the end of each iteration.

Unit and integration testing aside, who should be the one to come up with the end user acceptance test plan? Should it be the reqestors or the developers?

Many thanks in advance.

Regards
CK

ckng
  • 201
  • 1
  • 2
  • 5
  • 1
    The only input to this the devs should have are suggesting areas and possibly some edge cases that should be tested (and not forgot). But they should not give step by step details on how exactly to test. – CaffGeek Feb 16 '11 at 18:25

7 Answers7

11

The test plan should NOT be written by developers. Part of what the test plan is to do is to check to see if the developer correctly interpreted the requirement. A developer cannot effectively write a test plan on the code he is going to write. Test plans should be written by the people who are going to be doing the QA or by the business analysts. If developers must write the plans, do not ever assign someone to write the plan for the part of the program he is going to write.

Note that this is different from designing unit tests which must be written by the developer as he should be testing the code he wrote to see if it does what he is expecting. But test plans are to test to see if the application works the way it was expected to work and this must be done by someone who does not know how the application was technically designed to work in order to be effective.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
  • This is what I was saying for years at one job. – David Thornley Feb 16 '11 at 21:21
  • 1
    Good up till the last sentence, but testing should never stick merely to checking the application follows expectations (but should also cover the unexpected!), and knowing at least a bit about how the application was technically designed ALWAYS helps me as a tester to identify the cracks I can get my tester crowbar into to lever the thing wide open. ;) It's a bit of an old-fashioned notion to imagine that testers are better not knowing anything about the implementation. – testerab Feb 19 '11 at 00:10
  • 1
    Exactly, @testerab. Not knowing internals helps to design some types of test cases, while knowing internal helps in gray box testing, e.g., I know the risk area in the code, I just need to prove the app to reach that code. – dzieciou Mar 15 '13 at 22:27
7

The QA team should write and execute the test plan.

Ideally the test plan should be written in parallel with the functional specification - it's amazing how thinking about how to test functionality concentrates the mind and improves the specification.

Chris Card
  • 2,101
  • 1
  • 14
  • 6
  • 3
    Possibly with help from the developers, but mostly the QA team. – Zachary K Feb 16 '11 at 16:02
  • What if we don't have a QA team? Should this task then fall on the requestors? From the answers here, this would be most logical. – ckng Feb 17 '11 at 03:38
  • If you're moving towards Agile, try to hire some people who specialise in testing into your current development team. (Note: read up on the different schools of testing first, some are not compatible with an Agile approach - http://redcanary.mypublicsquare.com/view/hiring-software ) – testerab Feb 19 '11 at 00:06
  • 2
    If you don't have a QA team you'll need to come together with the requestors to make that decision. On one hand the devs shouldn't need to do test plans. On the other hand many/most business customers don't know a lick about testing, and you'll spend A TON OF TIME TRAINING AND HAND HOLDING in the beginning. We tried this once and the business customers struggled big time. The regular cases weren't a big deal, but when it came to detailed cases and especially negative testing cases they struggled. Better would be to get/designate a QA guy or a business analyst than to assign to the customers. – sdek Feb 19 '11 at 00:30
4

A Scrum answer: If you wish to define the 'Definition of Done' you will notice that having a test plan rapidly becomes one of the items. How else can you describe the story to be done, if it has not been tested.

Who is then responsible for creating the test plan? The Team

Who is The Team? Any person committed to realizing the product should be a member of The Team.

So in your case, you could include (or hire) the person that can write the test plans into your 'development team'. If you are moving to Agile, you will notice that creating a test plan occurs in parrallel of the development. Both start from the same story, and through communication end up being in sync and delivered at the same time. You should not declare your story 'done' before having passed the test cases the Stakeholders see as critical.

Rudi
  • 131
  • 4
2

I find that functional test plans should be written by functional/business analysts. They write the functional analysis ( even if you're working agile, I'm assuming you have some analysis ), and so they should be the write down what paths in the application should be followed for test purposes.

It totally depends on how you're working, but in my opinion developers shouldn't be writing functional documents on how to test the application, what data to use to test it, etc.

koenmetsu
  • 341
  • 1
  • 8
2

Here's an idea that might make both groups happy, and fit in well with moving towards an Agile approach:

Automate your user acceptance checks, and screencast them.

http://pragprog.com/magazines/2009-12/automating-screencasts

It sounds like part of the problem you're having is that the test plans you're writing are very repetitive and purely confirmatory. To be honest, I wouldn't call what you're writing testing at all - if it's just confirming the requirements, it's checking. Automating this and screencasting it will let you package up a neat demo for your customers regularly (you could even send them over a short daily) - they'll be more likely to click on a demo and watch it than to open a test plan and start working through it, so hopefully you'll get faster feedback (very important if you're moving towards a more Agile approach). You'll be able to re-use components so it'll reduce the workload for you, and developers usually enjoy writing code a lot more than writing documents.

It also provides a way of actually executing the requirements - have you come across Gojko Adzic's executable specifications? Take a look here: http://gojko.net/2010/08/04/lets-change-the-tune/ If you're thinking of this as a way to get the requirements into an executable form to demo to your customers, then it suddenly seems a lot less pointless.

Now, putting my tester hat on, I'm honour bound to point out that if the screencast thing takes off, it will free you/your stakeholders up to do some proper testing - i.e. trying edge cases, and tests that actually challenge the app, rather than just confirming requirements. I'd suggest that you provide the screencasts along with short questions or suggestions for areas you'd like more feedback on, for example:

1) Here's our new registration form - watch this screencast to see how it works!

What we'd like feedback on: We've added a lot of extra checking on this form to make sure customers aren't able to enter the wrong data - we'd really like you to look at the error messages customers get when they put in the wrong thing and tell us whether our customers will find them easy to understand.
We'd also like to know whether we've been too strict in some cases - if you've got any particularly unusual customer data (maybe a really long name, or a really short one, or someone with unusual characters in their name, or something else we didn't think of, or maybe their address doesn't have a street name or something weird like that?) then perhaps you could spend a few minutes trying those out?

I.e. you present a nice screencast, and then ask for feedback, framing it without being too specific, get them thinking about potential issues rather than just confirming. Get them thinking, instead of just clicking blindly through a test plan. You're basically writing an exploratory test charter for them. (If you look at the Agile Testing Quadrants, these would be tests in Quadrant 3).

testerab
  • 832
  • 6
  • 11
1

Take renovating your house as an example. Would you accept a checklist done up by your contractor asking you to check off what he has done for you? Or would you come up with your own checklist and check if the contractor has done what YOU specified?

The answer is clear: the requestor should check to see if what he/she requested is done according to specs. He/she should come out with his/her own checklist and test the app. against this list.

The developer, however, should have their own checklist and ensure proper internal testing is done and bugs cleared before handling app. over for UAT. Ideally, the developer should automate most of these testings in the form of test scripts. Remember TDD? Ideally, test scripts (in this case, unit test cases) should be written for testing components of applications. Test suite should then be written to combine these unit test cases to perform integrated and subsequently regression tests.

1

The end-user acceptance test plan is usually written by the clients or a business associate at the company who represents the customer. It is supposed to represent the features the client wants, and complements QA's integration testing. Neither QA nor Development can effectively plan user acceptance tests, as one of the primary goals of user acceptance tests is to ensure that what QA and Development thought the customer wanted is actually accurate.

Ethel Evans
  • 5,329
  • 1
  • 23
  • 42
  • http://en.wikipedia.org/wiki/Acceptance_testing#User_acceptance_testing for more information. – Ethel Evans Feb 16 '11 at 18:14
  • +1 for pointing out that user acceptance tests need to be designed by the user. Although I've suggested an alternative approach in my answer (as it doesn't seem that they actually have any QA resource), user acceptance testing can't be done effectively by non-users. In this situation, it sounds like both dev and users are at a bit of an impasse, so I think dev needs to try to break that somehow. – testerab Feb 19 '11 at 00:16