Of Paths and Cycles

06 Tuesday Mar 2012

Posted by in Context, Experiences, Experiments

≈ 1 Comment

virtual ride

I joined the YMCA last summer and have been trying out different ways of being more active. (My active lifestyle resolution wasn’t just aimed at professional development.) Recently, I came to the conclusion that having more structure seems to work for me in learning testing and so might be helpful around my fitness progress as well.

To that end, I made a Coach Approach appointment and met with my coach to learn how the program works. She and I talked for nearly an hour about what my goals would be (set up along the SMART guidelines) and how I could work my current interests into a structured plan. She suggested that I try out some of the exercise equipment that they have and talked over different ways to cope with the boredom that creeps in and deters people from continuing their progress.

One of the machines she suggested for me was an exercise bike with a computerized screen. Today, I decided to give it a go. I dressed out, filled my water bottle, and found an available bike. Since I’m interested in taking up cycling, this seems like a nice way to build up my stamina until the weather warms a bit. I plugged in my headphones and turned my attention to the log in menu on the screen. Realizing this was not a touchscreen application, I observed that there were a variety of buttons to interact with the system.

Since I wasn’t sure I was going to stick with this workout method, I selected guest log in just to try out the system. I selected a beginner course, put my hands on the handlebars, and began pumping the pedals. I immediately noticed that the handlebars and foot pedals provided information to the system as did the buttons on the panel below the screen. I found some good music to keep my ears busy and started observing the software.

Happy Path

Normally, I bemoan working out on exercise equipment as “the race to nowhere,” finding myself immediately unsatisfied with the experience of running in place and staring straight ahead in a gym environment. However, having an application to test while burning calories certainly was a welcome change. I don’t think my coach realized just how easily I could avoid boredom with some software to occupy my attention!

I tried a couple of different paths, or courses as they called them, each with a different scenery motif and points of visual interest. I was amused to discover that steering with the handlebars was entirely unnecessary since the program forced me to stay on the path and stopped displaying any virtual cyclist I ran down. At first, I was a bit disconcerted when virtual cyclists would pass through me from behind and appear to pop out of my chest. Backpedaling served only as an indication that I wasn’t moving forward, as though I had stopped pedaling completely, and so didn’t help me to put more space between my virtual handlebars and the virtual chest-burster cyclists. I thought one of these virtual cyclists represented the “pacer” that appeared on my progress bar, but I eventually figured out that the pacer didn’t have a manifestation on the course, only in the ride-in-progress statistics reporting areas.

Push it real good

However, I noticed some issues during my first ride:

  • Objects in the scenery were drawn with perspective and would update with a jerk when they entered the middle of the field of vision.
  • A bush on the edge of the path happened to overhang the path enough that my virtual handlebars passed through it.
  • A virtual cyclist was stranded on the side of the path oriented sideways rather than in the direction of travel, as all of the other virtual cyclists were.
  • Another representation of a rider (ghost?*) appeared on the path oriented sideways but didn’t seem to be animated.
  • After I completed the ride, the screen showed my ride’s statistics as a modal dialogue, but I could see the heart rate monitor, RPM, speed, and ride timer were still updating on the disabled screen.
  • One of the post-ride statistics was the local facility’s leaderboard for that course and although my time ranked higher than the last person on the board my time was not displayed.

*I wasn’t clear on what the system meant by a ghost rider who could appear on the course, so this may have been correct software behavior.

Integration, schmintegration

After a trip home and a well-earned shower, I settled in with my laptop to check out the website that interfaces with the on-site system. The site proclaimed that their system engages your mind and I certainly found that to be true, perhaps in a way they hadn’t anticipated.

Although I had created an account through the log in screen of the exercise bike, the website prompted me to complete my profile online before I could access the information. Though I usually think of this as an annoyance, few required fields and a humorous selection of security questions made it a pleasant experience.

The News informed me that I could share my ghost through Facebook or Twitter, though I still had little idea of how that would be used, having not seen it in action. I declined to use the social media hook, deferring it until I have an opportunity for more investigation. I was happy to see that my first workout records and awards were available online, though I didn’t “post a ghost” through email or printable QR code. When I found the Ghost Selection options, I could see that a ghost was something like a pacer but more personalized or specific.

I noticed several issues online:

  • I was hopeful that the online system would show my ranking since the on-site exercise bike had not, but both the global leader boards and boards for my fitness facility omitted me.
  • The first attempt to view leaderboards for my fitness facility showed data from a location in some other state although subsequent refresh seemed to correct the problem.
  • I also encountered the server’s technical difficulties page.
  • Some header graphics failed to display, though sometimes page refresh corrected this.
  • Leaderboard page breadcrumbs did not always correspond to the displayed page (e.g. inaccurate, current page omitted).
  • Firebug showed me at least one typo in the Javascript that caused an error and one page’s source included comments in the code, which I have read is discouraged.
Game on

Although I was happy to know that my workout data was preserved and available online in some form, the leaderboards could use some work. While the software product team may not have been concerned with real-time updates to leaderboards, as a first-time user I really wanted to see how my performance stacked up against the more seasoned players, which is an important part of the gamification angle that this product leverages to defeat boredom and keep users involved in exercise. I’ll certainly try this system again and hope that I can ride out both the bugs and the boredom.

Image source

Tester Merit Badges live with 1 week to go for February!

22 Wednesday Feb 2012

Posted by in Approaches, Experiments, Exploratory Testing, Techwell, Tester Merit Badges, Training

≈ 1 Comment

With only a week left in February, I’ll be wrapping up my own trial of the first Tester Merit Badge and posting my results, so I encourage you to try it for yourself. Do let me know if you’re playing along at home!

For reference, here is the introduction and here is the motivation.

Originally posted on the Techwell blog, the badge description is reposted here for convenience:

Tester Merit Badge - Explorer

Tester Merit Badge: Explorer

Skill challenge: Try exploratory testing
Requirements
1. Know Your Maps.

Be able to explain different approaches to exploratory testing (e.g. testing tours, chartered session-based testing, freestyle)

Some web resources:
Session-based testing
Scenario testing
Exploratory testing in agile

Some books:
Crispin, Lisa; Gregory, Janet (2009). Agile Testing
Whittaker, James (2009). Exploratory Software Testing

2. North, South, East, West.

Who says scripted test cases can’t be exploratory? Just because you have a protocol written down doesn’t mean your brain turned off when you began to execute it. As you go along working through a set of instructions, perhaps drawing from a user manual if you lack test scripts or specific test cases, keep your eyes open for what is going on around you, not just what fits the happy path of the case. Make notes of testing ideas and chase down something that’s off-script and keep track of what you do as you go along. If no test scripts or highly structured test cases exist for a particular aspect you want to test, skip ahead to requirement #3.

3. How Long and How Far.

Using an existing reference (if any) estimate the time to exploratory test an aspect of a feature of a software product. If you have been using test cases or test scripts for this testing, then use those as jumping off points for your exploration but don’t follow them. I tend to make a list of some test ideas and then pick and choose which ones to attempt during a particular exploratory session. If no ready-made resources exist for a particular aspect you want to test, skip ahead to requirement #4.

4. Walk the Distance.

Estimate time exploratory test an aspect of a feature of a software product without the aid of any existing materials. Use your knowledge and experience to take an educated guess at what needs to be done and build up a guess-timate. We’re going for ballpark and not precision here. Then, try it and see how close you were. That’s the beauty of iterative learning.

5. Map Maker. Map of the Place. Make a Model.

I see these physical representations of travel as essentially the same when it comes to software testing. This one is about precisely describing what you observe, which makes it a perfect artifact of your exploratory session. This could be a site map, a pairing of requirements description snippets with implemented user interface components, or even a sketch of different paths through a block of code (if you’re doing some white box preparation for your exploratory testing). We want to show what we observed rather than what we expect, so you can explicitly record your expectations if that helps you to clear your mind for the road ahead.

6. Finding Your Way Without Map or Compass.

Freestyle! Do some testing without any more explicit structure than a time box. Give yourself 15 minutes to wander around in an application without stating a particular agenda. You might even try accessing a piece of software through a less favored access point (e.g. a traditional website viewed from a smart phone).

7. Trail Signs Traffic.

This is an opportunity to write a different kind of test guide for another tester to follow. If we stick to the trail metaphor, you want to provide indications of the way out of the woods but you don’t dictate how the hiker travels between the boles of the trees bearing the blaze (or if you’re a big nature nerd the piles of rocks and sticks with their encoded messages about the trail ahead). I think Whittaker’s landmark tour is particularly apt for this example, so I recommend picking a part of your app to extract some landmarks. Avoid step-by-step instructions about how to wander between these milestones! You want to recognize the variation in execution that naturally occurs, even in the presence of a test script. In this case, doing it differently is a strength since you collectively will cover more of the application over time, although you may not encounter exactly the same scenery along the way.

8. Bus and Train Maps.

Use a publicly available source to map out a test. If you have a user manual for the application under test, that would be a good source for producing an expected route through an application. Just like a driver stuck in traffic, you don’t need to adhere to the planned route, so feel free to follow any detours that seem like better alternatives if you are feeling blocked or just want to take a more scenic route. Lacking a user manual for this particular product, try a description of some similar or competing product. Again, we’re exploring here, so having an inexact guide is no barrier to the experiment.

 

When you complete any or all parts of these badge “requirements” take a moment to reflect on whether the technique could be helpful to you in your regular testing work. You don’t have to migrate away from your current approach, but having some options always helps me to switch it up a bit when testing starts to feel monotonous – and I really think I’m doing it wrong when testing bores me! There is always too much testing to complete, so I certainly need to go exploring more often.

Drop me a line or post a comment here to let me know how the experiment went for you and I’ll post my own results here within the month.

Happy testing!

Image source (embroidered version of this image)

This could be real good

03 Friday Feb 2012

Posted by in Agile, Experiments, Retrospective, Scrum

≈ Leave a Comment

It's Groundhog Day!

Something is different.
– Good or bad? (Rita)
Anything different is good…
but this could be real good. (Phil)
— Groundhog Day

I’m a relatively young ScrumMaster, so I adopted a retrospective pattern that a colleague suggested to me at the beginning of my tenure. We have been using that same approach for sprint retros for 6 months and it gets the job done. Still, I found myself bored with doing the same old thing for our release retro this month and was concerned about not getting the desired benefit from the process. So I grabbed a promising technique from the Agile Retrospective Resource Wiki called the Four L’s, which Mary Gorman and Ellen Gottesdiener of EGB Consulting developed as a variation of the World Café since they “wanted some variety in eliciting feedback, collectively sharing that feedback and exploring action possibilities.”

The wiki suggests using the Four L’s for “iteration and project retrospectives as well as for retrospection of training and conference events” with a duration of 30 minutes to 2 hours. My 6-member cross-functional team used this technique to reflect on a release and limited our time to an hour, though that wasn’t a hard cutoff. In the context of our release retrospective and the hospitable space of our team meeting room, we gathered our diverse perspectives to explore questions that mattered about how our release went. I titled each of 4 large sticky notes Liked, Learned, Lacked, and Longed For, hanging them side-by-side on a single wall, which was a variation of the suggestion to move around the room. We set a timer of 15 minutes to generate initial feedback for all 4 categories simultaneously and began scribbling madly on uniformly yellow stickies with our Sharpies. Our team ran dry of serious contributions before the time was up, but I think time-boxing activities tends to drive us to get ideas out more quickly.

We read each sticky note’s single idea aloud and then clustered the notes around themes when there was overlap, listening together for patterns and insights. Then, we discussed the whole category among ourselves, hearing out each person’s comments with understanding and humor (we don’t take ourselves too seriously) since we encourage everyone’s contribution to the conversation. We were happy with our technical skills and technologies, but more importantly we have jelled as a team, or made it through the Norming phase of Tuckman’s model. Characteristically, my team identified our successes but did not dwell on them as much as our areas for improvement. We decided we might use the gathered data to satisfy the lacked or longed for items. We posted the following collective discoveries prominently in our team room:

  • Iteration
  • Continuous Planning
  • Continuous Research
  • Communication
  • Feedback (outside the walls)

These needs resonate with some of the Agile Manifesto principles:

  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Business people and developers must work together daily throughout the project.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Continuous attention to technical excellence and good design enhances agility.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In our efforts to optimize our agility, we are learning from our team’s past and planning for the future so that our results could be real good.

Tester Merit Badges: Finding Your Way

31 Tuesday Jan 2012

Posted by in Experiments, Exploratory Testing, Tester Merit Badges

≈ 4 Comments

Recently, I began blogging over at Techwell with my Active Lifestyle resolution. As a follow up, I am writing a guest series there.

As I have mentioned before, I was a Girl Scout for a while when I was growing up and loved the exposure to new and different things that I wouldn’t have occasion to try in my everyday life as well as the structure around life skills that would later be essential to self-sufficiency. For me, there’s nothing new around the recent enthusiasm to game aspects of our day-to-day lives and, as I’ve blogged before, having structure around learning helps me to progress.

As a grown woman, I again found an interest in earning badges when a former-Girl Scout friend of mine mentioned Lauren Grandcolas’ book You Can Do It!: The Merit Badge Handbook for Grown-Up Girls to me. It’s full of experiments modeled in the style of Girl Scout badges and reduces the potential intimidation of attempting new skill acquisition.

One day, after I had seen a 3D-printed octocat at the Atlanta Mini-Maker Faire at Georgia Tech, I was searching for octocat images online and I discovered the Nerd Merit Badges that reference Github, the movie Office Space, and the book The Pragmatic Programmer among other wonderful and obscure aspects of geekery. These inspired me to apply the badge concept to software testing. After all, developers shouldn’t have all the nerdy fun, though I’m pretty sure I’ve already earned my Family Tech Support and Homonyms badges… (For my word nerds, contrast with homophone here.)

Allow me to preface this experiment by recognizing the interval of time a Girl Scout takes to earn a badge is not a month. Girls fulfill these requirements over time, probably interspersing activities from several badges over the course of many months. I recognize that neither you nor I will necessarily complete all the requirements for each month’s Tester Merit Badge and that’s fine. Checking everything off the list is not the point. We’re here to learn and step outside our comfort zones, so start where you’re comfortable and stretch yourself a bit!

For the inaugural Tester Merit Badge, I have designed the Explorer badge as an introduction to exploratory testing. I am modeling it after the requirements of the Girl Scouts of America’s Finding Your Way badge.

Girl Scout badge Finding Your Way

Girl Scout of America badge: Finding Your Way

Requirements
  1. Know Your Maps. Be able to explain 3 diff. types of maps.
  2. North, South, East, West. Show you know how to use a compass.
  3. How Long and How Far. Use map to determine time to specific place.
  4. Walk the Distance. Estimate time to walk distance and try it.
  5. Map Maker. Draw map of a route with a legend or key.
  6. Map of the Place. Draw map to scale of a specific place.
  7. Make a Model. Make 3 dimensional model.
  8. Finding Your Way Without Map or Compass. Use sun, stars and nature.
  9. Trail Signs Traffic. Use trail signs to set up a mini-trail for others to follow.
  10. Bus and Train Maps. Learn to use bus or train maps. Try your route.

See the first Testing Merit Badge on the Techwell blog!

Image source

Monkey testing

23 Monday Jan 2012

Posted by in Testing Humor

≈ 1 Comment

Monkey chain

I discovered the term “metal monkey” today and found myself quite amused. Though it sounds like a term a barfly might use in requesting the next round of shots for his compatriots, the metal monkey turns out to be a Chinese astrological symbol, an apt subject for today’s Chinese New Year.

Metal monkeys are like testers in that they are:

  • inquisitive in the extreme, needing continual stimulation to keep themselves interested and amused
  • highly adaptable and versatile
  • enthusiastic about everything, spending time broadening their minds
  • inventive and intelligent, solving most problems quickly and skillfully
  • assimilating facts, figures, skills, and techniques quickly
  • passionate, demonstrative, strong, sophisticated, and independent

Another interesting aspect of the Chinese astrological calendar is that the element metal and the animal monkey correspond not just to years but also to days within years:

Once in two months, in the night of a Metal Monkey day (according to the sexagenary cycle in the Chinese calendar), while one sleeps, the three demons leave the body and go to the Heavenly god and report to him the sins of the person they inhabit. Then the Heavenly god shortens one’s life span according to one’s bad deeds.
— Annie Pecheva

Here is another aspect of the 3 monkeys that mirrors what testers do: report on the failures of the whole to the powers that be. Now, we don’t want to be termed demons, so we must do this respectfully but honestly. We must also be careful to focus on what is most important or be accused of nothing better than random or automated testing.

See no evil, Hear no evil, Speak no evil

Ford! There’s an infinite number of monkeys outside who want to talk to us about this script for Hamlet they’ve worked out.
— The Hitchhiker’s Guide to the Galaxy

In contrast, monkeys are also used to reference randomly producing input, both for the infinite monkey theorem, in which monkeys on typewriters (or rather “an abstract device that produces a random sequence of letters and symbols ad infinitum”) produce Shakespeare, and for software testing. For programmers, a monkey test is a unit test that runs with no specific test in mind. For software testers, a manual monkey test would be on-the-fly random application tests that ignore typical usage. An automated “dumb monkey test” would be an automated testing tool sending random input to the application through the user interface, which although at first seeming to have little value can produce hangs or crashes in applications, “i.e. the bugs you least want to have in your software product.”

For user experience professionals, a wireframe monkey merely churns out rapid prototypes rather than performing ideation and problem solving. Yet another mindless monkey.

Given the choice between monkeys, I myself would prefer to be metal.

Image source

Test and Relaxation

29 Tuesday Nov 2011

Posted by in Approaches, Experiments, Weekend Testing

≈ Leave a Comment

hammock testing

When I was growing up, my mother enjoyed including a bit of education in our family vacations. She read to us from many sources about our intended destination, preparing us to be observant and appreciative. As a young girl, I read aloud – at her prompting – from guidebooks, tourist bureau brochures, and travel magazines. These days, my mother still e-mails me travel information from many websites, though reading aloud is now optional. Mom’s creative approach to vacation planning sought out off-the-beaten-path sights where we had a better chance of learning something. This early preparation also required us to think through the items we needed to pack to make our agenda attainable, from extra layers of clothing to special equipment.

She purposefully overloaded every day’s schedule, grouping our options for geographic areas of the destination. With three kids, she knew to expect the unexpected and that you can’t always plan for it, so instead she planned to accommodate the necessary flexibility. Sometimes the need for flexibility arose from external sources, so we always packed a map that we had studied in advance and could reference quickly on site. Likewise, we had already reviewed our transportation options so that we were familiar with the available means and routes to allow for quick on-the-spot adjustments. She raised me to embrace these interruptions, saying “sometimes the times you get lost are when you make the best discoveries.”

We joined docent-led architectural walks in Chicago, climbed the Mayan ruins in Costa Maya (Mexico), attended off-Broadway plays in New York City, attempted our limited French at the Quebec World Music Festival, and learned to play the washboard with spoons in New Orleans, though Washington DC was the mother-load of educational sight-seeing. All along the way, mom encouraged us to ask questions and to explore as we toured, capturing what we experienced and what we drew out of that in our daily journaling.

“The keyword for our vacation wasn’t relaxation, it was adventure.” — my mom

With this personal history, I found the idea of a testing vacation very natural when I participated in Weekend Testing Americas two weeks ago. In my daily work, I am familiar with exploratory testing as a chartered but loosely structured activity. I start with a time box and a list of test ideas to guide my testing in the direction of acceptance criteria for a story, but I never script steps of a test case. However, WTA presented us with this mission, should we choose to accept it:

We want to explore this application and find as many short abbreviated charters as possible.
You have 30 minutes to come up with as many “testing vacations” as you can consider. The goal is that no single vacation should take more than five minutes. Shorter is better.

I paired with Linda Rehme and we tested Google Translate in these ways:

  • testing in Firefox 8 and Chrome
  • prompt to use new feature of reordering text in the result
  • selecting alternate translations of phrases in the result
  • manually editing translations of phrases (or alternate translates) of the result
  • moving result text with capitalization
  • moving result text with punctuation
  • couldn’t reorder words within a phrase of the result text
  • re-translate to revert to the original result text
  • Listen to both source and result text
  • manually editing text of the result to include words in another language and then Listen
  • Listen didn’t work for both of us
  • icons for Listen and Virtual Keyboard displayed in Firefox 8 but not Chrome
  • different drag hardware controls (laptop touchpad, laptop nub)
  • virtual keyboard for German (Deutsch)
  • moving virtual keyboard around in the browser
  • switching virtual keyboard between Deutsch and
  • misspelling words
  • prompted to use suggested spelling
  • prompted to select detected source language
  • Turn on/off instant translation
  • translating a single word with instant turned off displaying a list of results

When time was up, our moderators prompted us, “First, describe your “vacation”. Then describe what you saw while you were on vacation. And finally, what you wished you had done while you were on vacation (because really, there’s never enough time to do everything).”

My pair of testers noticed that different browsers displayed different controls, features worked in some browsers and not in others (e.g. Listen), result phrases could be manipulated as a unit but couldn’t be broken apart, and moving result phrases around did not correct either the capitalization or punctuation. I really wanted to go down the rabbit hole of having instant translation turned off because I immediately saw that result text didn’t clear and then clicking the translate button for a single word produced a different format of results (i.e. list of options below the result text). In fact, I found myself full of other testing vacation ideas and it was hard to keep track of them as I went along, testing rapidly. The best I could do was jot them down as I went while typing up descriptions of the testing we had completed. I enjoyed the rapid pace of the testing vacation exercise with its familiar exploratory testing style.

Weekend Testers Americas: Claire, the idea when you find that you are doing too many things is to step back and try to do just one. It’s like touring the Louvre. You can’t take it all in in one sitting. (Well, you can, but it would be severe information overload. 🙂
Claire Moss: I liked that this accommodated my “ooh shiny!” impulses, so don’t get me wrong.
Weekend Testers Americas: Yes, testing vacations and “Ooh, shiny!” go *very well together 😀

Fortunately, my mom was always up for indulging those “Ooh, shiny!” impulses on vacations as I was growing up and now I have a new way to enjoy my testing time at work: testing vacations.

[I took the liberty of correcting spelling and formatting of text from the WTA #22 session.]

Image source

Initial Impact

21 Monday Nov 2011

Posted by in Experiments, Hackathon, Volunteering

≈ 1 Comment

Hackers Movie

Last week, I had my first experience of my company’s Impact Day “in which team members take a day to work outside of the office to give back to our local community.” We volunteered at the the Mobile Hackathon for Good, which the WebVisions Atlanta program described as:

Join mobile app development experts, developers and designers in an all day Mobile Hackathon for social good. The day will begin with short presentations by educators and representatives from non-profit organizations, followed by informational sessions on building apps for Windows Phone and other mobile platforms.

We had two charities proposing app ideas for us, but only one of them had specific tasks with loose requirements. Unfortunately, those oracles were not able to stay with us all day due to their regularly scheduled charitable duties, so we were left with concrete examples of activities that would benefit from a mobile app but no way to discover additional information, though I did get a chance to informally chat with a couple of the representatives before the schedule for the day began. I have volunteered with local charities through Hands On Atlanta before, so I knew from experience how frustrating it can be to part of a large group of volunteers waiting on manual, hard-copy check-in to start our volunteer work. That sounded like a good problem to tackle.

The technical informational sessions filled the morning of our “all day” Mobile Hackathon, leaving us with only 4 hours to build apps for the Windows Phone Marketplace, which none of us had done before. Although I do enjoy a good discussion on design and how to execute it well, as you can see from my tweets, I think concentrating on design was a lofty goal for such a compressed timeline. I wanted to incorporate the principles James Ashley advocated, but I first wanted to have some small piece functionality built up, such as navigating between screens. Also, I got a bit lost in the Expression Blend styles and had to have Shawn sort me out.

I think we had about a dozen folks on the Mobile Hackathon implementation crew, and we ended up informally splitting into two groups. About half of us did some whiteboard sketching and discussion of what we wanted the software to do. We had competing designs that were successively refined through an hour of discussion, leaving us only 3 hours to implement. We had many desired features and modes of entering volunteer data, but none of them fit well within our very limited time box, so we ended up abandoning the goal of adding people on site at the project location. We needed to focus on a very narrow implementation goal first. And as it turned out, we didn’t have very many developers present and not all had their own laptops installed with the Visual Studio 2010 Express for Windows Phone that we were to use as a development environment with either Visual Basic or Visual C#.

I profited the most from Shawn’s practical demonstration of building an app in a short period of time, which encouraged me to open up the software. I started several prototypes to explore the various installed templates, trying to get a feel for how to begin organizing the work. Figuring out where to start coding proved to be more of a hurdle for me, not being a programmer by profession, though once upon a time I was a Visual Basic coder for my employer while a co-operative degree student at Georgia Tech.

Since I had 4 co-workers with me, it might have seemed logical to form a unified team to attack problems like we do at work, but that wasn’t the way it worked out. Attendees Errin Calhoun and Eduardo La Hoz were on my implementation team to talk over some software design and implementation ideas, but I ended up writing the code. I wasn’t completely helpless, but I definitely benefited from collaboration with speakers Shawn Wildermuth and Moses Ngone. Even with their assistance, we ended up with a simple 3 screen app that could navigate through mocked data to a check-in view that displayed data collected as the user tapped through.

Afterward, several of us attended the Day One After Party, where my co-workers and I had an informal retrospective about the Hackathon with one of the organizers. Now, you should know that I am a reform-from-within kind of person and love to focus on opportunities to improve while recognizing what didn’t go well. I am specific in my concerns about problems I perceive in order to have the best chance of making a difference. Here are some things I noticed:

  1. Creating an actual shippable product in 4 hours was not realistic, especially with the paucity of developers.
  2. Part of the “understaffing” was a snafu in the communication surrounding the Hackathon’s location, which was incorrect on the website, printed tickets, and e-mail reminders. I think more devs would have been present without that wrinkle and I wish this had been tested in advance.
  3. However, we wouldn’t necessarily have effectively used more development talent because we didn’t have very strong self-organizing teams. Maybe it would have gone better to have a little more structure, like an event coordinator to help us identify the roles that Hackathon volunteers could fill and what our current talent pool included.
  4. We spent too much time on planning what we would want the app to do without attempting to iterate, too much like Big Up Front Design and creating requirements for stories that would have been far down the road (for sprints of that length).
  5. We could definitely have used more time to develop and less time learning about the Windows Phone Marketplace, which would never have accepted the partially completed apps that we ended up producing.
  6. In order to submit our apps, we needed to test on a Windows Phone device, which was not available. The other testing option was the Marketplace Testing Tool, which I never saw.

My design manager co-worker, Will Sansbury, had these comments:

  • Claire is fearless. [I didn’t have any development reputation to protect so I had no problem admitting a need and asking for help from strangers right away. – Claire]
  • I loved pairing with Dev through the whole process.
  • Expression Blend has a huge learning curve, and I’m not sure it’d be all that helpful once you get over that initial pain.
  • The short time box and no feature constraints necessitated a laser-sharp focus on one thing.
  • I feel bad that at the end of the day the world is no better.

We found out from our informal retrospective that this was the first Hackathon that WebVisions Atlanta has organized, so I am sure that subsequent iterations will take these lessons to heart – and in that unexpected way we have given back to our community.

Image source

Quality Is Undead

31 Monday Oct 2011

Posted by in Automation, CAST 2011, STARWest 2011, Testing Humor

≈ 6 Comments

QR Skull

Though many give credence to the sentiment that quality is dead, testers linger like ghosts with unfinished business who cannot move on from this plane. There is never as much time for testing as we would like and some of our bug reports are regarded with as much skepticism as messages from beyond the grave. We tend to haunt the developers with questions and carefully couched criticisms, and I daresay that some programmers might like to call for an exorcism.

We may think of ourselves as shuffling zombies toward the end of a long release cycle, when testing time is often sacrified for feature implementation and we can end up working long hours, though thrown under the bus may not be the worst way to go. Those carefully scrutinizing our exceptional strength to endure the inevitable crunch time, our keen powers of observation in uncovering bugs, and our cold appraisal of the software will realize our true nature and may start stocking up on stakes and garlic, peering into our cubes looking for the coffins where we sleep as we must surely be vampires instead. So far, I have no reports of testers biting co-workers, however tempting at times. After all, wouldn’t we want to pass on our dark gifts to our team mates, test-infecting them to become more like us?

Testing wants Braaaains

At STARWest 2011, James Whittaker and Jeff Payne heralded a dark future for testers without automation scripting skills. While I welcome the increasing testing prowess of software developers, their testing focus is on automation, whether at the unit level or something more closely approximating an end user’s interaction. I have started thinking of my automation test suite as my zombie horde: persistent but plodding on unthinking, repeatedly running into obstacles, requiring tending. It really want some brains to interpret the results, maintain its eccentricities, and perhaps play some games in the backyard shed. As Michael Bolton stated at CAST 2011, lots of automated checks versus doing human-observed testing is one of the hard problems of testing. “A computer executing automated tests only makes one kind of observation, it lacks human judgement.”

Even these fast zombies are not a replacement for the thinking mind of a tester, though how to think about testing is a question of much debate. Testers from different schools seem to regard one another with a bit of hostility. Each successive school of thought seems to bury the preceding one with great ceremony, including the departed’s whole entourage for the journey to the afterlife. Those thus interred seem like mummies, desiring a terrible vengeance on the ones disturbing their eternal rest or even grave-robbing their ideas. At CAST 2011, Michael Bolton encouraged us to take a more measured tone with people who disagree with us, referencing Cem Kaner’s sentiment that “reasonable people can disagree reasonably.”

Memento Mori

With the Day of the Dead celebration occurring this week, it seems fitting to ponder our own demise as testers. Those celebrating this holiday want to encourage visits by the dead, so the living can talk to them, remembering funny events and anecdotes about the departed, perhaps even dressing up as them. Some create short poems, called calaveras (“skulls”), as mocking epitaphs of friends, describing interesting habits and attitudes or funny anecdotes.

So here is a calavera for me:

Here lies our dear departed Claire Moss
We miss her because she could test like a boss.
When a defect appeared before her eyes,
Her lilting voice would intone “Hey guys…?”
At best, she was a code monkey,
but her sense of humor was always funky.
Though she claimed her heart was in her test,
we always know she loved us best.

I encourage you, the living, to visit me with events, anecdotes, or funny poems. Whatever undead creature your tester persona most identifies with, keep on pursuing excellence and have a happy Halloween!