Monthly Archives: September 2011

Taking on Water

27 Tuesday Sep 2011

Posted by in Automation

≈ Leave a Comment

Tags

Composition

Recently, I have been struggling with attacking a backlog of automation test cases. I took a much needed break to spend the weekend scrapbooking with a friend. We drove out of town to attend a crop, or gathering of scrapbook hobbyists for those not in the scrapbooking scene. I certainly wasn’t the most experienced, with some scrappers having been scrapbooking for more than 15 years, but I wasn’t the most novice either since one attendee had never made a page before. I met some new friends, ate too much, made some lovely art involving photographs, and learned something useful.

The scrapbooking consultant was pleased to have some newbies attending a crop for the first time. She shared this advice with us: start scrapping your most recent photos. When we started to protest, she assured us that we would have the most energy to attack this problem rather than trying to start at the bottom of the stack of photographs that we have accumulated for years and years. Then, we would feel encouraged to continue with the project of picking up older images to stylize in our layouts.

This suggestion appealed to me since I found the most enthusiasm for a recent trip I had taken to The Wizarding World of Harry Potter. I felt less concern about leaving earlier photographs to languish in their boxes and ended up producing much more in the time I had available. Since my friend was working on the same subject matter, we encouraged each other and even collaborated on some great design ideas.

Prevent a Bail Out

Now that I am back from this refreshing play and getting down to business at work, I find that this lesson resonates with my automation work as well. The most stale test cases are much less appealing and much less fresh in the minds of the developers who collaborate with me on the automation project. In addition, we have an opportunity to make this new code more testable and more automatable rather than having to work around some part of the existing code base that wasn’t written with this end in mind. The automation code becomes more maintainable. The real win is to stop the flow of automation opportunities straight into the backlog that we then have to bail out later, effectively plugging the leak. When we approach the stories in the current sprint as automation candidates, we know that we may have some rework in the future, but that is part of writing code, whether in a product or a a meta-product like automation.

Image source

ET, Phone Home!

09 Friday Sep 2011

Posted by in Approaches, Experiments, Exploratory Testing

≈ 1 Comment

Composition

Although I am no longer the newest recruit on my employer’s Quality team, I am still something of an alien creature to the folks back at the mothership (i.e. home office). However, I have been slowly getting to know them through video conferencing, especially my fellow Quality team members. We have been experimenting with paired exploratory testing, but in my case we cranked it up a notch to *remote* paired exploratory testing. (You know testers don’t like to keep it simple, right?) This added an interesting layer of exploration to an already exploratory experience. (This meta goes out to you, Jace and Will S.) Now, each member of the team has a Skype account, establishing a common medium for communication, and we are learning the basics together. While we contended with screen repaint, we were forced to discuss the products more in depth to make use of the lag time and to give some context for each newly displayed page. This also gave us a chance to discuss the testing process, the collaborative online Quality space, our documentation strategy, and a bit of product history. Oh yeah, and we did some testing.

Since I’m still a newbie, I pretty much expect to feel a bit lost in the woods when it comes to the rest of the company’s product suite. Paired exploratory testing (or ET for the testing aficianados among you) gave me a peek into the Daxko-verse. My fellow testers know the lay of the land and so are better positioned to provide test ideas inspired by the suite’s world as we know it – soon to be rocked by my team’s product! In return, I got to ask the naive questions about what we were looking at, what terminology meant, and how it all fits together. Sometimes, having a second set of eyes isn’t enough. You need someone to ask the dumb questions. Stand back, people, I am a professional at this.

Paired ET fosters the Agile Principles:
1. Continuous Feedback
2. Direct Communication
3. Simplicity
4. Responding to Change
5. Enjoyment

We are still working out how to run the sessions. Does the person on the product team pilot or co-pilot the session? Or do we take this rare opportunity to do some concurrent exploratory testing? How long do we test together? Do we test both products back-to-back or does that just leave us yearning for caffeine and a stretch break? Personally, I am loving this. It’s so much fun to play with the new and novel, and I hope that this livens up the regression routine for my home office folks. If nothing else, it is a great opportunity to geek out about testing methodology and learn a bit about what works in our context.

The best parts:
•Finding bugs!
•Communication
•Knowledge sharing

Can’t wait to get into it again this afternoon.

Addendum: Now that we have completed the initial experiment in the vacuum of ignorance, I am free to research other approaches to paired exploratory testing. I paid particular attention to Agile testing as a new mindset that encourages transferring testing skills to other team members so that the whole team shares responsibility for testing.

Read more from Lisa Crispin, Janet Gregory, Brian Marick, Cem Kaner, and James Bach