WTA26 – Picture Yourself Coding

WTA26 – Picture Yourself Coding

Date: April 7th, 2012 11:00 a.m. – 01:00 p.m. Pacific

Attendees:
Michael Larsen, Molnár Zoltán, Robert Donahue, Lanessa Hunter, Pushpa Raj, Eugenia Yakhnin, Ranjit Shringarpure, Ashwin Maharaj, Rahul Vig, Victor Mclean

 

Session:
We focused today on looking at a site that offers to teach people how to program,

http://codecademy.com/

We set the session up today as a good old fashioned bug hunt…. with a twist. As an added bonus, we approached the application from the perspective of doing scenario based testing.

Scenario testing is a software testing activity that uses scenarios: hypothetical stories to help the tester work through a complex problem or test system. The ideal scenario test is a credible, complex, compelling or motivating story the outcome of which is easy to evaluate. These tests are usually different from test cases in that test cases are single steps whereas scenarios cover a number of steps.

We used the following resources to help explain the idea and rationale behind scenario based testing.

http://en.wikipedia.org/wiki/Scenario_testing
http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf

Example:

I am a beginning programmer, and I want to learn how to understand JavaScript better. To this purpose, I would like to work through an example and feel that I have successfully learned the topic being presented. To do this, I will work through the exercises provided.

Each of the testers were asked to go and spend some time on CodeCademy, work through the first example exercise, and then report back as to the following:

1. Describe the scenario you were able to construct.
2. Explain issues you encountered along the way.
3. If you found anything of note, share them in the chat transcript.

There were a number of interesting issues that were found, one of them being someone who entered in an Irish Name of “Danny O’Brien”. The very first screen had a problem with this, and couldn’t accept that value. This is an example of using a scenario (playing with not as common names) we were able to find a deficiency in the program. Other issues were also discovered using a similar technique, where instead of just looking at test cases, the tester created and processed a coherent story so that they could look at a broad range of criteria to determine if the program was doing what it should.

Full chat transcript is here.

About the Author

I’m a software tester working with Socialtext in Palo Alto, CA. I have worked in a number of different fields and in a number of different capacities. I started my testing career in March of 1991. I am co-founder and primary facilitator for Weekend Testing Americas. I am a black-belt in the Miagi-do School of Software Testing, a member and Teacher in the Association for Software Testing, and the producer of Software Test Professionals' "This Week in Software Testing" podcast (now on hiatus).