8

I have been having many issues getting bug/tasks provided with the correct information in them. And other points where a task is handed off along the workflow require the recipient to get certain bits of information.

For tomorrows meeting our PM has asked us to identify what checklists we need to create, and what we feel should be on them.

As a developer, I know what I require when getting tasks from the BA

  1. Detailed steps to reproduce (preferably on dev)
  2. Actual result
  3. Expected result
  4. Attachments of emails/screenshots where applicable
  5. And any differences found between dev/prod/staging when attempting to reproduce if they exist

Normally I just get a vague description, and need to ask for these things...I get them verbally, and they sometimes get written in, sometimes not...but since they are always needed they should be provided up front. Which is why we want to incorporate a checklist that the communicator must double check before passing on a task.

Our workflow typically goes as follows

  1. Anyone can identify an issue to the BA.

    • Detailed steps to reproduce
    • Screenshot if applicable

  2. BA creates Task and passes to PM for Approval.

    • Detailed steps to reproduce (preferably on dev)
    • Actual result
    • Expected result
    • Attachments of emails/screenshots where applicable
    • And any differences found between dev/prod/staging when attempting to reproduce if they exist

  3. PM assigns Task to Developer.

    • Same as above

  4. Developer passes to Tech Lead for Tech Review.

    • Location of source, including changeset numbers
    • List of db modification

  5. Tech Lead passes to QA.

    • Same as Developer requirements

  6. QA passes to PM for Implementation Approval.

    • User Signoff

  7. PM assigns to Tech Lead for Implementation.

  8. Tech lead passes back to BA or QA for Health Check.

What do you all think should be required items in a checklist at these points of contact? I've added what I think are required. I add points from the perspective of the recipient, it doesn't mean the communicator is the one providing it, but they need to ensure it's there before moving it along.

CaffGeek
  • 1,055
  • 1
  • 7
  • 12
  • I had thought many people would be chiming in from their points of view and what they require at each stage... – CaffGeek Apr 26 '12 at 13:35

2 Answers2

1

I think your initial items from 1 to 4 pretty much sums it up for 99% of all organizations. The problem is that even though you tell your testers 'what' information is needed, I find the content is usually very poor (spelling, unclear, etc).

As for other checklist items, it will probably depend on your actual company and product being tested (hardware model/revision), firmware version, etc.

But one thing that I like (or strongly encourage) people to do is to keep it in 'simple' innumerate sentence form, such as:

A. Post Conditions:

   1. Screen 'Some Name' has been loaded
   2. The 'Some Name' panel is showing along with the proper ID label

B. Steps To Reproduce:

   1. Select the ID label
   2. Start typing another label ID
   3. [...]

This way, it keeps things very simply organized, step-by-step (compared to a bunch of text in paragraph form).

Additionally, in the bug report, it's a lot easier to reference a step by saying "Can you elaborate on step B.2?" rather than trying to refer to a specific step in a part of a paragraphs, especially if the referred item is repeated several times.

When someone wants to add their two cents, they can also write:

Try this workaround:

B.2.a. Select the existing ID
B.2.b. Press on the 'clear' key

It becomes instantly clear to everyone as to where the recommendation is being suggested. And again, everything is in point-form rather than paragraphs.

Jeach
  • 221
  • 1
  • 2
  • 7
  • Oh and I almost forgot... we have an embedded product for which I coded a days worth of scripts (bash) which basically gets a really, really detailed system snapshot (files, logs, screen captures, memory dumps, process info, cpu load, etc, etc) and archives everything into a single 'tgz' file which is included as an attachment to the bug. It's really rare that I need additional info (apart from the 'steps to reproduce'). But then again, that info can be deduced because we can also log the screens being shown and all the mouse clicks during test mode. – Jeach May 01 '12 at 17:23
  • I agree 100% with point form steps. Clear, concise and detailed. – CaffGeek May 01 '12 at 18:52
1

Personally, I consider check lists a bit dangerous because they are hard to change and I see what should be there, but I usually have no clue what is missing.

If I were you I would write a script, which could collect all the information I need to fix the issue: log files, system information and screenshots. If you have a script, you no longer rely on unnecessary human interaction and possible errors. If you have a checklist the writer of the issue may forget something and you have to ask. A script doesn't forget. We reduced our response time with 3 days using a script like this.

The next thing I would do is write steps in the gherkin format:

Given I am on the login page
 When I enter my password
 Then I want to see its strength

You can use these steps for writing cucumber scenarios which can be executed against the system. We used this approach when we were dealing with defects. When I found a problem, I wrote my scenario and committed to version control. The developer who pulled the task, and started to work on the issue. He knew that when the scenario turned green it was fixed. So you can use these scenarios for

  • describing steps
  • fixing issues
  • testing
Zsolt
  • 11,928
  • 1
  • 27
  • 60
  • If I can't get a BA to talk to the user and tell me what product is displaying incorrect data, I'm 99.9% sure they can't write valid gherkin. For example, todays "Price has been revised from showing $2.20 to $4.95. However when I download the spreadsheet it still shows as $2.20. PLS ADV." I don't even know what application they are talking about. – CaffGeek May 02 '12 at 13:57
  • @Zsolt, I check out your gherkin link. I actually do like the 'Given', 'When', 'Then' steps along with the possible 'and' for each. It's another solution that fits and could further formalize the text in point form. But in regards to the cucumber thingy... still not convinced. I'll have to go back and try to read up on it again, but I think it will be hard to convince me :) – Jeach May 02 '12 at 14:38
  • @Chad, I think it's worth a try. Last week I talked to an old friend and he said that their project manager had learnt the gherkin because he found it very useful. It depends on the person, I assume. But you can have some argument and tell him that with this approach you can see a lot a time and writing gherkin isn't that different than writing sentences. – Zsolt May 03 '12 at 05:44
  • @Zsolt, with anybody remotely competent I'd agree, with this individual however....not so much. Gherkin would be fantastic, but given the requirements I get that contradict one another (in consecutive points) I have no faith they could write a Gherkin scenario that works. – CaffGeek May 03 '12 at 13:44