Category Archives: Hackathon

Est testing parfait?

19 Tuesday Nov 2013

Posted by in #testchat, Agile2013, AgileConnection, Experiments, Exploratory Testing, Hackathon, ISST, Lean Coffee, Podcast, Retrospective, Skype Test Chat, Social media, Software Testing Club Atlanta, Speaking, Tea-time With Testers, Techwell, Test Retreat, Testing Circus, TWiST, Volunteering, Weekend Testing

≈ Leave a Comment

I heard that Gerry Weinberg has an exercise called “Mary had a little lamb,” in which you analyze each word in the sentence to elicit implicit meaning that might be important. This sounded interesting enough to try, so when the opportunity came to propose a topic at Test Retreat 2013 I went for it. My topic “Is testing for me?” didn’t end up formally scheduled but made a nice interstitial topic to discuss with those milling about in the main room.

I chopped the sentence into separate words and wrote them top-to-bottom on a large sticky note. Then, instead of giving some sort of prepared remarks, I elicited brainstorming from the gathered participants. Having received interesting feedback on my professional and personal strengths at Agile2013 that had left me questioning how best to use my evil powers for good, I wanted to hear how others were thinking about the testing field and how it fit them.

The resulting scrawled notes ended up a mindmap, the path of least resistance for me. I won’t say the discussion solved all my problems, but it did give me some direction for future exploration – exploration that might also be helpful to a newbie wondering whether to pursue a career in testing.

Is testing for me?Which brings me to some interesting recent events:

I started composing a list of things I’d recommend to people just starting out as testers to help them to evaluate whether to continue. I wanted to encourage them to jump right in but also think big, not waiting them to wait 5 years to reach out to the wider world of testing (like I did).

Here’s my current list. I blogged about various experiments I tried, so you can read for yourself to see what it’s like to select what’s a good starting point for you.

No matter how many times I think I’ve found all the meaning in my testing career, suddenly I realize there are more layers… but like a parfait, not an onion.

Donkey: Oh, you both have LAYERS. Oh. You know, not everybody like onions. What about cake? Everybody loves cake!
Shrek: I don’t care what everyone else likes! Ogres are not like cakes.
Donkey: You know what ELSE everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait”? Parfaits are delicious!
Shrek: NO! You dense, irritating, miniature beast of burden! Ogres are like onions! End of story! Bye-bye! See ya later.
Donkey: Parfait’s gotta be the most delicious thing on the whole damn planet! – Shrek

Thanks for the inspiration to write, EmJayKay80 and Niyi!

Yo dawg, I herd you like ET

19 Monday Mar 2012

Posted by in Context, Experiences, Experiments, Hackathon, Retrospective, Testing Humor

≈ 1 Comment

I wrote out my Lab Days experience recently but didn’t get to bring you down the rabbit hole with me to experience the recursive testing goodness.

My project for Lab Days was an enhanced logging tool, but the logging is the heart of the matter, with users putting it through its paces much more stringently then the analysis functionality.

Since I usually do exploratory testing of applications at the day job and the time pressure of Lab Days left little room for formal test cases anyway, I decided to try out a new exploratory testing session logger: Rapid Reporter.

I didn’t have a lot of time to devote to learning Rapid Reporter, so I didn’t bother reading any documentation or preparing myself for how it worked, essentially exploratory testing my exploratory testing tool while exploratory testing my application under test.

It turns out this kind of recursive testing experience was just what I needed to liven things up a bit, all in the spirit of trying something new! I discovered that rapidly learning about a session logger while testing/learning a session logger, pulling log entries from an original session log, and reporting bugs via a session/chat room (HipChat) made for some perilous context-switching. More than once during the day, I had to stop what I was doing just to get my bearings.

I clearly enjoyed the experimentation because I decided to repeat the experience, though with a little less context-switching, when we upgraded our usual ET tool: Bonfire. The funniest thing about using Bonfire after working on my Lab Days project was that I realized there were tags available for log entries but the tagging indicators weren’t the same as our choice for our usability testing tool. I kept trying to use the tagging that I’d been testing all week and had to retrain myself, improving their documentation as a result of my questioning.

Still, seeing how another logging tool uses tags gave me some functionality to consider for our usability logger: how would users want to interact with tagged log entries? Clearly time to circle back with my UX designer to discuss some enhancements!

Image generated here

The status is not quo

09 Friday Mar 2012

Posted by in Context, Experiences, Experiments, Hackathon, Retrospective, Tester Merit Badges

≈ 3 Comments

Dr. Horrible http://drhorrible.com/

We tend to run “FedEx” with a fairly open format where you can do whatever you want as long as you can somehow relate it to our products.
– Atlassian

Last week, my company gave us an exciting opportunity: 5 days of work on a project related to our business.

Apparently, they’ve done something like this before, long before my time, so you’d have to ask some of the more tenured folks at Daxko about it.

I worked with the same folks who volunteered with me at the WebVisions Hackathon earlier this year and we kept in mind what my colleague Will said about that experience: “The short time box and no feature constraints necessitated a laser-sharp focus on one thing.”

So we noodled over several viable candidates and finally settled on building a better mousetrap – or, in this case, UsabLog.

A clarification on terminology from my UX colleague:
“Logging” in this context doesn’t mean “system logging of events.” It means human capture of what the user said, what the user did in the app (e.g., where user clicked), and any additional comments to provide context. The point of logging is to provide us with a record of what went down so we have an accurate recollection for later analysis.

I had the good fortune to be a user of the original UsabLog application over the course of many usability sessions as a session logger, so I was rather familiar with its strengths and weaknesses. I was able to contribute some bug reports and feature suggestions for consideration during our lunchtime planning discussions, but my Scrum team’s UX designer was our team’s sponsor. She compiled an experiment plan that identified our purpose and detailed the problems we considered in the pre-existing Usablog and the opportunities we had to satisfy those needs.

Our usability sessions up to this point involved an interview led by the facilitator (i.e. UX designer) and logged by another team member (e.g. me) via the free, open source, web application Usablog, which then exported logs to CSV for use in a program such as Excel and which we in turn manually fed into a mindmap program such as FreeMind. While this process did work for us, the export and manual copy-paste was rather tedious and laborious, or as she put it “it would directly contribute to user research process efficiencies.” We knew there could be a better way.

Goals of the experiment:

  • Rapidly capture rich user feedback during research interviews and usability tests through logging of user events and comments
  • Organize logs from multiple sessions into one study for ease of access and visibility
  • Use log entries to synthesize findings
  • Quickly jump to a spot in the session’s video by clicking on the associated log entry

In particular, we wanted these features:

  • Multi-session logging.
  • Log entries are timestamped when the logger starts typing for video synchronization.
  • Custom tags.
  • Multi-logger logging.
  • One tool for logging and post-session analysis.

We established a definition of done and recognized our dependencies since any impediments would have serious impact on our progress during the limited time of the competition.

I would love to tell you that we were entirely successful in meeting our goals and implementing all of our features, and then going on to take first prize in the competition. Alas, this was not to be. We only accomplished some of our goals and features and awesome projects from other teams placed above us.

However, the experiment was a roaring success in many ways:

  • I had first-hand experience with paired UX design under the tutelage of my UX designer colleague. She suggested that I man the helm and she steered me back on course when I went astray. I won’t claim that my first UI mockups were beauties, but the process and conversation certainly were.
  • I made my first commit to a Github open-source repository and thereby qualify for the Open Source Nerd Merit Badge (which happens to feature the Github mascot Octocat) which I had been hankering to do ever since I discovered its existence. Also, this was the first time I fixed a bug in the source code, so even though my changes were minor it was thrilling.
  • Exploratory testing based on Github commit notifications in the HipChat chat room we used for the team. Rather than pursuing session-based test management, I tried a looser structure based around the latest and greatest changes instead of setting charters and time-boxing exploration around the stated goal.
  • Real-time bug reporting of issues found during exploratory testing via HipChat messages and screenshot attachments was new and interesting. This is the lowest overhead asynchronous bug management approach I’ve tried and it was effective. Granted, we didn’t come out with a backlog of known issues written down somewhere, but we rectified the most critical problems before they had a chance to fester.
  • We didn’t let a little thing like heading home for the day stop us from collaborating remotely when we got back to business after hours. Being able to work at odd hours put some of my insomnia to good use. I also learned a bit about .NET and model/view/controller architecture, which turned out to be good preparation for the following – and last – day.
  • When one of our programmer teammates fell ill, I paired with our remaining developer to push on toward the goal. Although I think I spent more time asking questions to help think through the implementation than actually contributing code, it was a fruitful day, wrapping up an important feature a mere 30 minutes before the Big Reveal.
  • I used the resulting product to real-time log the presentations during the Big Reveal. Oh so meta, but also hopefully illustrative of the capabilities of the application for future use. If nothing else, it gave our sick friend a way to catch up on the excitement as he recovered over the weekend.
  • We accomplished only some of our goals and features but they were the most essential. Our product is usable as-is, though with some known bugs that do not inhibit happy-path use.
  • Why do they call it FedEx days? Because you have to ship! Our resulting application is ready for use – or enhancement if you’re feeling ambitious!
  • And last, but certainly not least, victory lunch! Nothing so sweet as celebrating effective teamwork.

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