Friday, 17 September 2010

Test Case Workshops

Hidden deep within Requirements and Functional Specification documents are the test cases we’re looking for. Like any hidden treasure they need to be discovered by effective exploration, deduction about the nature of the environment they exist in and who put them there and why.

When we (testers) review theses document or other sources that provide this information we have one question at the front of our mind, ‘what test cases does that need?’ We need to be thinking how we’d know that a requirement or acceptance criteria has been delivered on via the software functionality that’s been developed.

How are we going to quickly and efficiently find those needed test cases? The easiest way is to brainstorm them in a workshop with testers.

Get one or two other testers with you and a collection of requirements or acceptance criteria you want to find the test cases for. Assign one to write on the whiteboard, another to write up the test cases and another to perhaps just freely participate and shout out ideas. Everyone is equal, all ideas are to be explored, no negative comments or limiting of creativity and ideas.

As each item it talked through them up on the whiteboard, use flow diagrams, spray diagrams, UML type layouts, mind mapping – whatever allows a free form diagram of linked ideas to be created. Each idea is a possible test cases. Let’s see what we might draw up and talk about if the requirement was for a user to log-in to a system.

The user logs-in, so they must be able to logout. If they log-in there must be some log-in information such as a user name or password, Q) what’s the structure of the user name and password? Where are they stored? What characters are / aren’t allowed? How many? Where are unsuccessful log-ins recorded? How many failed log-ins are allowed? Etc, etc.

After more questioning and reading around the requirements, Functional Spec and acceptance criteria a diagram might look something like this:

Test Cases
From here we can start to capture test cases based on what we’re thinking. In the format I prefer these days they might include:

  GIVEN a user has an active account
  WHEN they log-in with a valid Username and Password
  THEN they are authenticated and an active session is started

Some might not be so tidy as they require multiple outcomes such as:

  GIVEN a user has an active account and the failed log-in count is 0
  WHEN they attempt to log-in with an invalid Username and valid Password
  THEN they are notified of a failed attempt
  AND the log-in failure is logged
  AND the failed log-in account is incremented to 1

This is fine, it’s still one test condition it just has multiple outcomes which is more like reality in complex software.

Have a go at writing some more test cases against the above diagram. Have we missed any other test conditions?

We’ll leave the idea of Concrete Examples, Analysis Techniques, etc. for another post.

For now reflect on the complexity of the above Log-In example, even if it seemed simple at first. Think about how much easier it is to brainstorm the test conditions with your testing colleagues and get the test cases written up in the same session.

Take a break, share the test cases with others (Dev, PM, etc.) and get their take on them. We also had a lot of questions so share those out and get clarification on them. This approach is much more efficient than one person being sat at their desk alone. It means knowledge sharing in equal terms and ready progress.