Quicktest

More than a quick (and dirty) test.

The years without quicktests

It is 1989. My first job is as a tester in a small software company. Software engineers develop on their local machines. Their individual developed programmes are written in Clipper Summer '87 by Nantucket Corporation. Software tests are also done locally at their developers' places.

Many years later, it is 2011. I pick up the idea of local tests but the former employer is against it. Luckily, quicktests are fine enough for my next - and my current - employer.

I work in a really huge project. In the beginning, up to eight "quality manager-developer" (QA-DEV) ping-pongs (iterations) are necessary. That is definitely too much. The agile software development process is usually like this (see Figure 1): Development process

QA-DEV ping-pong
One or more QA-DEV ping-pongs mean much more work (at least for QA and DEV), time, and budget (see Figure 2): Development process with QA-DEV ping-pong The steps for DEV and QA are the following:
  • QA
    • Oops, a defect is found whilst testing the new code :-(.
    • Create/report defect (my suggestion: do not create a defect if the tasks are still open; better: add a "Fix it" task and a comment in the QA task).
    • QA talks/clarifies/synchronizes with DEV.
    • [Optional] Schedule defect (e.g., if it is not a blocker or a side effect).
  • DEV
    • Fix defect (DEV usually already work on an other task).
And once again: (re)testing ...

Testing on the test environment
Many defects are found at a single glance when starting and trying to test new functionality. Found defects are, e.g., inconsistent or wrong wording, summary/zone is not updated, and not all necessary points of the acceptance criteria are implemented. These findings are sometimes really frustrating, because they are low-hanging fruits and not really a challenge for good testers.

Finding defects produce many additional work for QA members. In the end of day, there are often more defects than in the morning (i.e., more open work than before). But the main QA goal is often to retest and to close defects. Once again, motivation is decreasing.

And IMHO, these above mentioned points are common problems in (nearly) all projects (at least which I've done).

So what is a quicktest (QT)?

A quicktest is a local test on the developer's computer. Although everyone can do it, a QT is usually done by a QA member (optional with a requirements engineer together). If a user story or a single task are too big (i.e., complex), more (pre)quicktests are helpful. Similar to the tasks, you can split a quicktest into smaller ones.

Advantages

  • QT minimizes QA-DEV ping-pongs. With the help of the quicktests, the QA-DEV ping-pongs in the project decrease: up to max. four (really worst case), usually one or two now.
  • Many defects will be found at once. Especially big defects such as blockers are found very fast. Small ones such as orthography errors or wrong alignment of columns are easy to fix.
  • Quick feedback for developer by QA member. For example, when a blocker occurs, other teams or members can be informed quicker.
  • No big overhead for adding defects produced by new functionality/tasks (smarter defect handling). Information is written into QA task and a "Fix it" task for developers is created. Only create defects for already closed user stories.
  • Fixing of small defects or changes are immediately possible while quicktesting. No switching back to the branch is necessary.
  • Check is done to see if we all understood the problem in the same way. At least the acceptance criteria should be checked.
  • QA learns from DEV (e.g., how the system/new code works technically, what the problem of the defect is).
  • DEV learns from QA (e.g., how structured testing works).
  • If a local physical quicktest on the developer's place is not possible, of course, a QT can be easily done remote (e.g., desktop sharing).

Disadvantages

  • A quicktest takes a little bit time. Usually five to fifteen minutes (although longer ones, e.g., for one hour are also possible).

New software development process with quicktest

The new software development process with quicktest is shown in Figure 3: Software development process with quicktest

Begin of a new project project with quicktests

  • Cluster the most found defects of the first sprints.
  • Write down the top 10 of common defects.
  • Introduce this checklist to each developer.
  • Each DEV has to check this list, for example:
    • Before implementation: Read info of the user story and/or development task (if necessary several times). Ask if something is unclear.
    • Implementation: Check this top 10 of the most common defects.
    • After implementation: Check acceptance criteria of the user story or task.
    • ... and: do a quicktest ;-) (QA: Update this checklist if necessary).

    Conclusion

  • A quicktest is more than only a quick (and dirty) test. It is simple and effective.
  • Quicktests save at least time, budget, and nerves.