At recent test conferences it seems one of the phrases of the moment is “Shifting Quality Left”. If you test as early as possible bugs are found when they are easier and cheaper to fix. Ideally catch them those you can before coding even starts!
Possibly because the industry has pivoted towards Agile one method that seems to have fallen somewhat out of favour in recent years is Fagan Inspections. If you’ve not come across the term before I’m going to describe it here, it may be something you want to try. A Fagan Inspection is a document review process to make sure that the objects you’re working with are defect free. I say document review, it’s also applicable to code although personally I’ve not used it in that context. This makes it a type of static analysis, testing without actually running the software being created. It’s called a Fagan Inspection as it was devised by Michel Fagan at IBM in 1976. Personally I came across this while working at Sony Ericsson where known as a Granska Bra (“well review”). Sony Ericsson had taken the concept from SAAB and applied it to mobile phone development.
A Fagan Inspection is a formal review process where objects (documents or code) are examined team of people to check to see if they’re ready for use. When I was using this process at Sony Ericsson we estimated that we had a ten fold return on the time we invested in it. So for every hour each person spent reviewing and preparing for reviews, we would save ten hours of time down the line.
How does it work? Well, when the object owner thinks what they’re working on is ready they take it to a moderator and the two of them have a pre-inspection run through just to make sure things really are ready to review. The moderator then sets up a panel of relevant experts to examine the object. For example, when using this at Sony Ericsson we would generally have a developer, a UI designer, a tester and an architect. These reviewers should run through the object from their domain perspective before the meeting.
During the meeting a presenter presents the object. This could be the object owner or it could be the moderator. The reviewers then step through the object and comment where they feel the need to.
There are two dangers at this point and it’s the moderators job to tackle them. Firstly, the moderator has to ensure that the review is a fair review and that the owner of the thing being inspected doesn’t feel like they’re being picked on. Secondly, it’s easy for people to drift onto finding solutions at this point “Ah, we could try doing this instead!” .That’s not the point of the meeting and if you let it start happening the meeting will soon be derailed. A two minute rule works well for this, rigorously enforced by the moderator. People can arrange follow up meetings to work on solutions if they need to.
At the end of the meeting the an exit decision is taken. Does the object need reworking and a subsequent re-review or can it be passed (perhaps with minor modifications with that won’t need re-review).
Adding this process can be seen as a drag, an extra step for people who just want to get on and code. However, ensuring our inputs are actually fit for purpose and clearing up misunderstandings before work is created based on those misunderstandings pays massive dividends.
Bill's test thoughts 