Test case challenge from uTest forum

Reading Time: 3 minutes

Last week I found at the uTest forum a test challenge. Details about the challenge could be found hereThe challenge has two main objectives and a set of explicit requirements. First part of challenge is to identify the test cases and second part is to group them, so customer could easily understand and rerun them.

uTest is growing testing company and I think that they created this challenge in order to attract good testers. My goal is opportunity to learn testing by testing my current testing knowledge and practice. By posting my solution I will receive feedback from the test challenge author, Lucas Dargis, and other testers interested in this challenge.

I choose following approach for this test challenge. In order to structure and group test cases, I first created the state machine model of the application. My drawing of state machine model is here. More about using models in software testing could be found in this great Michael Bolton blog post. So I would like to emphasize that this is just one of the possible models of the application, and it represents just some part of the application under test. This model tries to capture  implicit functional requirements not listed in testing challenge. If the application under test was alive, by using that application I would expand this model. But it is a good starting point for functional testing. 
Here is explanation of the state machine model. It has three states and six transitions.
states = [ ‘DISCRETE’, ‘CONTINUOUS’, ‘ARRAY’ ]
Every state represents what application displays in its output filed. For example application is in ‘DISCRETE’ state means that user entered valid discrete number, pressed ‘Go’ button, and output filed displays only that valid discrete number. Application remains in ‘DISCRETE’ state. Two possible transitions could happened.
Model has six transitions.
transitions = [ ‘no input or discrete’, ‘no input or continuous’, ‘no input or array’, ‘continuous’, ‘discrete’, ‘array’ ]
Transition name is what type of input user used before entering the ‘Go’ button.
On previous example on user action, depending on the starting state and assuming that application is in ‘DISCRETE’ state (we can assume that any of possible states is starting application state), the transition triggered by ‘Go’ button is ‘no input or discrete’.
Following spreadsheet contains test cases. It contains four sheets:
test case groups = [ discrete numbers, array numbers, continuous numbers, state display ]
First three groups represents checking the explicit  requirements. However, fourth group is based on state machine model transitions. For example, by observing the model I created test case ‘stay in ‘DISCRETE’ state’. My goal with that test case is to observe application behavior when only discrete numbers or empty input are used in a row for some time. Other test case could be what is application behavior when transits to array state? Would application be able to detect invalid array input? Or would application properly display just array input? 

Using application state machine model tester could come up with test cases that are connected with state transitions. That means that tester could easily structurally test case execution order. When application has states, test cases for checking explicit requirements are not sufficient. It is important to have a tool that can help testers to group test case execution in particular orders. State machine model of application under test is one of the tools. Using it with test automation, tester could easily execute those state transition test cases.
Also, by presenting the customer application state machine model, customer gets the visualization of the application. Observing that picture, customer gets the idea how application actually works. 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Testing in 140 characters (or less) #4

Reading Time: 1 minute

Making GUI test automation less fragile often means making it resistant to change it should detect, and therefore less valuable. #Paradox
— Ben Simo (@QualityFrog) August 11, 2012

@jarilaakso It doesn’t necessarily make a tester worse, but a tester drawn to or obsessed with coding is probably not studying testing.
— James Marcus Bach (@jamesmarcusbach) August 12, 2012

@mheusser There is more to testing than finding bugs.Building trust and collaboration with the team is half the battle that is to be won
— Mohinder Khosla (@mpkhosla) August 13, 2012

Want a reasonable first-order measurement for an exploratory #testing session? Ask: how many new leaf nodes did you add to your mind map?
— Michael Bolton (@michaelbolton) August 22, 2012

Don’t take bit.ly/O4Kzynas a rigorous measure, but discovering new coverage areas is a valuable outcome of exploratory #testing.
— Michael Bolton (@michaelbolton) August 22, 2012

A well-framed story about bit.ly/O4Kzynis a fine *qualitative* way to measure the productivity of exploratory #testing sessions.
— Michael Bolton (@michaelbolton) August 22, 2012

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather