CAST 2015: How I’m Using Reason And Argument in My Testing

Scott Allman and Thomas Vaniotis condensed an introductory logic course into an hour-long presentation at CAST this year.  Their focus on deductive reasoning was a great template for how to write a solid bug report or how find the crux of an issue when talking to a colleague. Scott and Thomas’s statements are in bold and my takeaways for how I’m applying it to my work follow below.

Assume your opponent is attempting to construct a valid argument.

Assume the developer read the ticket, implemented the feature in a way that made sense to them, and pushed the code to the testing environment. What could you be missing? Have you downloaded the most recent build or cleared your cache? Do you need to be logged in? Are you on the right page?

When you’re trying to prove a premise is invalid, provide evidence. 

If a developer tells you a feature works on their machine, attach a screen shot or a log file of an instance when a feature did not work on your machine. Include relevant environment information and steps to reproduce to determine which premises you don’t share.

What kind of argument would someone construct to disagree with you?

If you’re writing a bug that says something’s taking too long, say how long it should take and why. If you’re writing a bug that says something is the wrong color, cite the style guide or use the WebAIM contrast checker to prove the item is not accessible to color blind people.

Use as few premises as possible so your argument and conclusion shine through.

Look at the steps to reproduce you’ve included in your bug report. Is there anything you can remove? Are there any crucial steps your developer may not have taken that you did?

I’ve never seen such an engaging presentation where the presenters were reading off pieces of paper. The mindmap below includes more of what I enjoyed about the presentation and about testing software.

Reason and Argument for Testers Mindmap

In the open season after the session, Scott and Thomas went into other types of reasoning (inductive for example) testers use when investigating software. Most follow-up questions were about soft skills. Scott and Thomas suggested that examples would be better received than lingo-heavy accusations.

Respond to my jibber jabber

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s