Wednesday, 30 October 2013

A quick way to start doing exploratory testing

Whilst following the tweets from Agile Testing Days using the hashtag #agiletd I came across the following quote made by Sami Söderblom -  http://theadventuresofaspacemonkey.blogspot.co.uk/ during his presentation of 'Flying Under the Radar'

"you should remove 'expected results' and 'steps' from test cases"

Others attending the presentation tweeted similar phrases.
Pascal Dufour @Pascal_Dufour#agiletd @pr0mille remove expected result in testcases. Now you have to investigate to get the expected result.
Anna Royzman @QA_nnaRemove Expected Result from 'test case' - to start thinking @pr0mille #agiletd
Dan Ashby @DanAshby04"you should remove 'expected results' and 'steps' from test cases" - by @pr0mille at #AgileTD - couldn't agree more!!!
Pawel Brodzinski @pawelbrodzinskiRemoving the expected result thus safety net from the equation enables creativity. Ppl won't look for compliancy anymore. @pr0mille #agiletd
This was a WOW moment for myself, I have struggled sometimes to get people to adopt exploratory testing with people struggling to create charters and making them flexible enough.  It may not be an ideal solution but for me it is way in to teams that may be deeply entrenched in test cases and test scripts.

Thanks Sami - another creative idea that I most certainly will put into use.
Posted by at
Labels: , , , , , ,

6 comments:

  1. Simon Morley30 October 2013 at 05:10

    Hi Steve,

    Petter Mattsson gave an experience report in SWET1 - taking a team executing 000's of test cases to an ET approach. During the open season there was a discussion about introducing ET and one strand was about removing test steps from existing test cases -> partly to get the tester think (or re-think) about the purpose and also to "enable" them rely more on their senses/awareness. This needs support, of course, but uses an existing framework to start changing mindsets.

    Some fragments, recorded by Rikard Edgren, here: thetesteye.com/blog/2010/10/swet1-fragments/

    ReplyDelete
    Replies
    1. John Stevenson30 October 2013 at 05:17

      Thank you for the comment and the link Simon.

      regards

      John

      Delete
    2. Simon Morley30 October 2013 at 07:26

      Sorry John - I wrote Steve whilst thinking John...

      Delete
  2. Srinivas Kadiyala30 October 2013 at 07:05

    I didnt understand, if we remove the expected results and steps: only the actual result column with test case scenario will be left.

    do you mean, after/while testing, just writing bug report with respect to actual result and test scenario ?

    ReplyDelete
    Replies
    1. John Stevenson30 October 2013 at 07:15

      Hi Srinivas

      This is before you start test execution. You will not have anything in your actual results so you are basing your testing only on the scenario name you gave the test case (or test case title).

      The idea is to make you think about your testing and make you observe more (avoid the invisible gorilla) and see what the system is actually doing which hopefully will allow you to come up with more ideas to test from what you actual see.

      Does that clarify?

      Delete
  3. halperinko4 November 2013 at 14:55

    Thanks John,
    Yes - Leaving just Test Name & Purpose have several benefits:
    1. It leaves room to think.
    2. It allows quicker review.
    3. It ensures that you document ALL your *initial* test ideas, rather then fully document some features, while having No Time to document anything at all on others (so it is always best to at least start that way, even if you elaborate further later on)
    4. Maybe the most important of all - it makes you focus your writing on the Purpose of the test - something many forget to write down due to all the surrounding written details - So it enables the next tester to truly understand it, and therefor be able to question it and the way to reach that purpose.
    (As opposed to run blindly and have no idea what was the intention behind that test case)

    When ever you can - remember to write in a way that will promote diversity, so each test cycle will be different from previous one.

    On the other hand, sometimes you might want to leave a partial checklist of sub-issues below the generic purpose of test, you want to verify you will not neglect in next sessions - still you can leave these generic enough to improvise around them, and indicate its an initial list one should enhance while testing.
    How detailed should that list be - is an issue for consideration.

    BTW - nothing holds you back from having that partial level of details still managed within an ALM / Test Management tool.

    @halperinko - Kobi Halperin

    ReplyDelete

Subscribe to: Post Comments (Atom)