Solution to Charlie Chainer

Charlie has been a manual tester for several years and is now very excited to be working on automation. The manual tests that he is familiar with tend to be fairly long, starting by setting up complex initial conditions, and then having a large number of transactions building on the initial data (with frequent intermediate checks for correctness). He was going to construct his automated tests along similar lines, until someone told him that automated tests should be short. So he has broken the tests up into shorter tests, each ending with one of the intermediate checks that he had done in the manual test. Although he has never had any training in automation, he is pleased that he was able to implement this good practice. It seems like a good idea to have all the short tests chained together, so one is using the data set up by the previous test - surely this should save a lot of time.

However, when he sets the tests up for overnight runs, it doesn’t go as smoothly as he had hoped. The series of tests usually start out ok, but since each test builds on what the previous test has done, if any test in the series fails, then all the other tests coming behind it either fail, produce nonsense because the data they needed was wrong, or don’t even get started at all. Now he is wasting a lot of time trying to figure out what’s going on, and over half of the tests are never even getting run.

Use the Diagnostic to identify Charlie's main Issue(s) and the Pattern(s) that would be most appropriate for him.

Solution:

• From the Diagnostic, LIMITED EXPERIENCE (Management Issue) is a possible issue.
• Alternatively, choosing improve or revive test automation leads to Lack of direction, since Charlie was not given enough information about how to structure the automated tests. (Other options may also apply.)
  • AD-HOC AUTOMATION (Management Issue) is a possible issue,
  • but more specifically related to Charlie’s situation is option 2 under “More reasons”, i.e. Automators believe that the manual tests should be automated “as is”. Althought Charlie is a bit beyond that, having made his tests short, he does have problems because his tests are linked or chained together. Hence the issue INTERDEPENDENT TEST CASES (Design Issue) is the closest to his situation. The patterns it recommends are:
    • FRESH SETUP ((Design Pattern)
    • INDEPENDENT TEST CASES (Design Pattern)
    • FAIL GRACEFULLY (Execution Pattern)
    • ONE CLEAR PURPOSE (Design Pattern)
    • PRIORITIZE TESTS (Execution Pattern)