Category Archives: Experiments

Rhythm section

03 Wednesday Apr 2013

Posted by in Acceptance Criteria, Approaches, Experiences, Experiments, User Stories

≈ Leave a Comment

camarolf-zydeco_tie

When I was a little girl, my mother took me to New Orleans. I was enchanted with the city and my experience there, not the least of which was experimenting with Cajun dancing and learning to play the washboard. As the New Radicals say, when “you’ve got the music in you / don’t let go,” so I suppose it was only natural that I decided to try becoming a percussionist in high school. Although I had the muscle memory for patterns involving 4 mallets and a foot pedal that garnered me vibraphone solos, I never learned to read music or march on the football field properly. In the Christmas show, our sleigh ride had a lame horse because I got out of sync and didn’t know how to recover, being an inexperienced musician.

Undeterred, I was always excited by the idea of playing the “toys” or strange percussion instruments that lurked in the back of the band classroom gathering dust. Sure, I’d tried playing a güiro, bar chimes, and maracas in elementary school music class, but the vibraslap, cabasa, and flexatone were new to me. Regrettably, most high school football game pep songs don’t call for that sort of thing, though indoor drumline competition allowed us a brief glimpse of the promised land in the form of tubular bells.

In recent years, my musical performances have been primarily vocal, though Michael Bolton can vouch for the my lack of skill with the bodhrán. (For the record, he rocks out on the mandolin.) And while I’ll never feel the rhythm of testing quite like Pete Walen, I keep my options open to try new instruments and approaches.

Telling compelling stories

One of the dozen books I’m currently reading is Edward de Bono’s Lateral Thinking. He mentions many useful ways to train yourself to become creative. I was thinking about these methods when considering the relationship between a user story’s acceptance criteria and the implementation that satisfies that need. In my daydreams, I am considering who to recruit for my next musical endeavor.

For every one with dollar signs in his eyes
There must be hundreds that look at you as if you’re some kind of
Rhythm section want ad
No others need apply to the rhythm section want ad
And here’s the reason why
- Rhythm Section Want Ad, They Might Be Giants

I immediately start down the list of musicians I know and don’t have a handy drummer to call. Then, I realize wanting to recruit a drummer is really just an attempt to satisfy my need for rhythm – and as I’ve seen with so many other performers there are so many more ways to accomplish that goal. If I’d phrased my requirement thus “As a person wanting to create a musical act, I want a drummer so that my song has rhythm,” I would have missed out on so many useful possibilities that occur to me when I challenge the assumptions in my own formulation of the problem and reject the dominant idea of a drum kit in favor of the crucial factor of rhythm.

By delaying my judgment, I open up the opportunity to brainstorm and generate alternatives to the cliché 90s rock band pattern that jumps out at me. So the key to my dilemma seems to be figuring out the right acceptance criteria (or user goals) that will tell me when I’m satisfied and then chatting up several of my musician friends who can propose diverse solutions to my problem (e.g. a sampler could give me all of the above).

I might even take some cues from established bands I’ve had the remarkable experience of seeing live and in concert who made alternative choices for their rhythm section, feeding the wannabe percussion geek in me. OK Go performed a gorgeous rendition of their song “What To Do” using handbells during a show here in Atlanta. During a visit to a friend, I saw Tilly and the Wall, a band that routinely performs with a tap dancer on a box providing some fascinating beats for their music.

While I might pull out a slide whistle to jam with my kids or spin a ratchet on New Year’s Eve, I’ll never be a hippie with a djembe. (Who knows? Perhaps I can find someone to teach me how to play a few beats at the DragonCon drum circle or the Georgia Renaissance Festival.) At least I know there are many more possible solutions for my future projects. And though I’m still holding out hope for that next ridiculous musical number, you won’t see me on Song Fight! any time soon… that is, unless a Zydeco Tie shows up magically on my doorstep.

Image source

Short cuts

28 Thursday Feb 2013

Posted by in Approaches, Context, Experiences, Experiments, Social media

≈ Leave a Comment

Pinterest Mobile App
For more than a year now, I’ve been shopping around for a hairdresser who could provide the ideal haircut. The first two attempts were incomplete, poor likenesses of the beauty I had in mind. I had a clear vision of the intended result, but I lacked the vocabulary to communicate that vision to professionals who could implement the solution. I had fallen victim to one of the classic blunders! (No, it’s not never go in against a Sicilian when death is on the line.) I knew it when I saw it but I couldn’t articulate it. So frustrating!

So I turned to the internet for solace. I perused numerous galleries of smiling women with hair of various lengths, shapes, and hues. In order to find the images I needed for my initial point-and-grunt interface – a printout of images pasted into a document for my first two appointments – I had to first identify the search terms that would produce optimal matches. I quickly cycled through searches from the generic “short haircuts” to the slightly more specific “bob hairstyles,” feeding my learning back into my process. As I progressed toward an exemplar of the captivating coiffure, I began to build a jargon file – and a Pinterest board.

Natural language is ambiguous and context dependent, so any requirements described in natural language are rarely complete. … This is especially problematic when something seems obvious but we need domain expertise or knowledge of a particular jargon to understand it fully. - Gojko Adzic

Stylist jargon:
  • short haircuts
  • cropped hair
  • bob hairstyles
  • asymmetrical bob
  • graduated bob
  • stacked bob
  • angled bob
  • long bob
  • layered bob
  • inverted bob
  • severely angled stacked bob

I don’t know whether those terms produce crystal clear images in your head, but I could see that these terms had a wide range of interpretations even among fashionistas.

An example would be handy right about now

I have heard it said that social media is a time suck, with Pinterest often held up as the mother of time sucks. However, I disagree. For my purposes, Pinterest was a fabulous tool for collecting all these visual bookmarks in one place, building a virtual gallery of hairstyle models as a communication tool.

When I booked my appointment online, I had included only a link to the first image I had found that was a rough approximation, leading her to ask upon my arrival whether I was the one who had sent her the Rihanna photo. (Of course not! That was Nicki Minaj!) That early draft of my request submitted in advance had given her time to mull over the idea.

I am pleased to say the result was exactly what I had hoped for and I will be visiting the Madam LV Salon again. Ultimately, being able to show this gallery to my hair craftswoman convinced her that my request was not a lark, that I had done my homework, and that my Pinterest board was in fact a specification by example.

Last Family Lunch

14 Friday Dec 2012

Posted by in Experiences, Experiments, Retrospective

≈ Leave a Comment

It’s been a nostalgic week for me as I’m finishing up my time at Daxko today. (Case in point, I’m wearing this year’s bight purple Kickoff shirt as I type this.)

I’ll miss finding you on Twitter, displacing the printer, walks to Taco Mac, counting down my check-ins, dueling LifeSize remotes, commit message mentions, dangerous Centurion helmets, Plank A Day Nation pix, 2 drink tickets, the gangsta Ashoka Scrum-board avatar, mysterious moustaches, Monster-fueled afternoon shenanigans, Keep Calm and…, Portal references,  being kind of a disaster, Hackathons, a closet full of branded T-shirts, sticky notes everywhere, launch party, singing on the patio until we shut down the restaurant, winning The Go Game, the quote of the day, attempting Cajun accents, the Women of SWE, surprise attacks by Angry Birds, Family Lunch indecision, punchy road-trip conversations, Whirlyball, batting long eyelashes, last-minute costuming, musical parodies, calling dibs on the napping couch after family lunch – we love free food! – and most of all the people. (Special shout out to my Atlanta crew! I’ll follow you to whatever end.)

I expect to see some ridiculousness coming out of next month’s talent show, so make it count, people!

So Long and Thanks for ALL THE THINGS!

“Now, bring me that horizon.”

Seize the Initiative

15 Thursday Nov 2012

Posted by in Agile, Context, Experiences, Experiments, Retrospective, Soft Skills

≈ 1 Comment

Antistress Autoreverse

So last year I joined the YMCA. My employer works in this space and they supplement our memberships … on the condition that we attend with a minimal frequency. Nothing to understand your customers quite like becoming their customer! However, working out isn’t really my thing. The “race to nowhere” has no appeal for me. But I went anyway, determined to learn something. Despite my stubbornness on that point, the inertia of years of study was hard to overcome. I needed backup.

Joining the coach approach program was explicitly about wanting to make improvements. The Y coaches promote “adopting healthy habits and changing the way [the participants] live their daily lives.” I knew I wanted to make a change, but I also knew that I didn’t want it badly enough to go it alone quite yet. Having never had a personal coach, I wasn’t quite sure what to expect. What I encountered resonated with my recent experience learning about the role of ScrumMaster.

In particular the sprint activity of retrospective is “an opportunity to learn how to improve.” Defining success in this particular context was the first step. My ScrumMaster watched the process and guided it, making it okay to talk about uncomfortable topics, but it was up to me to do the work. The first big step was being able to establish a safe environment to talk with a more experienced and professional person about a potentially sensitive topic.

In the case of my workout routine, this was my minimal compliance rather than wholehearted adoption of lifestyle change. My Coach Approach coach helped me to develop a vision for the future that would be better than the past. We focused on setting goals while recognizing that the plan had to fit into my work/life balance with the loose structure of frequent check-ins rather than plugging my height, weight, and weight loss goal into a one-size-fits-all spreadsheet.

I was surprised to find that discussion about my health could be fun when my counselor was so friendly and supportive. I would have expected an intervention to be really uncomfortable. Retros can be that way sometimes. But they can also be a welcome change of pace. Roughly every 2 weeks – after we catch up on socializing and the excitement we’ve had since our last chat – my coach and I looked at the artifacts of my progress, paying attention to the time line of events going on in the background and how that influenced the results. Keeping this cadence allowed us to build a healthy relationship that encouraged risk-taking and speaking from the heart. So when my coach suggested adding a weights routine to my cardio, I felt fine with scoffing openly and she felt fine with reminding me of my goals, not allowing my emotions to derail the discussion but remaining fully present and focused.

As our meetings progressed, she offered appreciation of the progress I made, while encouraging me to try new approaches that could yield better results. Even when I felt like I was backsliding, she found a way to put more emphasis on understanding what I had accomplished and focused on encouraging me to keep going. We talked about what parts of the routine were working well, what lessons I learned (like when I hated the treadmill but loved the AMT – hey, participation in individual exercises is optional!), what I could do differently next time, and what might need more scrutiny. We tried to analyze the problems and propose solutions to the boredom, considering a variety of alternatives. It was honest but not accusatory. (Hey, eveybody gets bored with the routine.)

So I’ll admit she’s done me some good. I agree with another participant who said, “My personality is better, my production has gone up, my mental clarity has improved, and my energy level has increased dramatically.” Granted, I just have a lot of energy in general, so I wasn’t likely to sit back and passively take it in – well, as passive as you can be while sweating profusely. I started to recognize my excuses as just excuses, feeling more empowered to modify the situation, learning to manage that impulse to excuse myself from the hard work of changing. Accepting that I actually knew something about working out and lifting weights and could be responsible for designing more of the workout and analyzing my progress on the path to wellness? Yeah, last week was weird.

One ScrumMaster wrote, “At the end of a successful project, everybody says, ‘Gee, I wish we could do it again.’ Using this definition, was the project a success?” Well, I can’t say that I’ve enjoyed every moment of it, but figuring out that I could test software and sweat profusely at the same time? Priceless! But seriously folks, having my coach express sincere and significant appreciation for the care and work I put into making progress sent the message that she cared about and me personally, not just reducing the failure rate of some anonymous gym member. And that’s where the magic happens.

(Special thanks to my dev James who pointed out that coach approach is workout retro!)
Image source

Big Visible Testing

07 Tuesday Aug 2012

Posted by in Agile, Approaches, CAST2012, Context, Experiences, Experiments, Publications

≈ 1 Comment

Presented as an Emerging Topic at CAST 2012

This was my talk proposal:

I have always thought of myself as an agile tester. After all, my development teams have always delivered features in 2 week sprints. My testing activities included reviewing requirements or stories before the planning meetings to assemble a list of questions and test ideas that I would use to approach the work proposed. I participated in a review before code completion that allowed for some exploratory testing, brief and informal though it may have been at times. In the past couple of years, I also planned and coded test automation.

However, over the past year, I have been transforming from a pseudo-agile tester to a true agile tester. Rather than sitting apart from the software developers in my own quality engineering department, I am now seated in the same room as the other employees from a mix of disciplines who are on my product delivery team. Rather than testing in a silo, I have been gradually increasing the visibility of testing activities through exploratory test charter management, defect backlog organization, and paired exploratory testing with both testers and non-testers. The feedback loops have shortened and the abbreviated time between activities necessitated adjusting how I provide information.

Testers are in the information business. We take the interests and concerns of the business as communicated through the product owner – or in my case the product owner team – and combine those with the needs of the customer as expressed in the story and further augment those with our experience using and analyzing software for deficiencies, abberations, and oddities. We draw upon a variety of resources including the experience and perspectives of fellow testers, heuristics, and product history to approach the goal of delivering a product the customer values, focusing especially on the quality aspects of that value.

Now that the audience for my testing comprises a mix of disciplines and the work environment has shifted from a heavier process to transparent, quick information access, I have been experimenting with different ways to execute testing and to represent the outcomes of that testing activity so that the information consumers understand it in ways that best suit each of their perspectives.

In my brief presentation, we will examine 3 different agile team member personas and their implications for presenting and maintaining testing information as well as the inherent tensions between their distinct and various needs. I will trace my learning curve of adjusting to their needs through the various experiments I have completed in this context, though these lessons extend beyond a purely cross-functional agile product development team.

Other testers will come away with a fresh perspective on viewing their product team members and focus on the value testing artifacts provide to a software development team.

See me live!

16 Monday Jul 2012

Posted by in Agile, CAST2012, Context, Experiences, Experiments

≈ Leave a Comment

CAST is online streaming the keynotes and Emerging Topics track again this year.

Last year, I was haunting the interwebs watching, Tweeting, and chatting. This year, I’ll be coming to you live through the magic of technology. (This is the first reason I’ve had to crack open PowerPoint so it should be entertaining!)

Catch my agile software testing emerging topic talk Big Visible Testing at 10 AM PDT today!

Again, here’s the link to watch me:
http://www.ustream.tv/channel/CASTLive

Update: Recording uploaded to YouTube

Image source

Ruby Anniversary

14 Saturday Jul 2012

Posted by in Automation, Experiences, Experiments

≈ Leave a Comment

A year ago this week, I first picked up Brian Marick‘s Everyday Scripting with Ruby and gave it a whirl. This week saw me branching out past automating web application checking to creating my own Ruby application.

I haven’t been a code monkey in many a moon, but my company’s recent innovation week gave me the perfect opportunity to try an alternate role. I anticipated either glorious success or failure – and as a tester I’m seasoned at failing gloriously so I was set to be happy whatever the results.

This time around, anyone in the company could propose an idea, perhaps even customer requests of suitable scope. The projects had to be related to our core business but the Lab Days crew encouraged us to try new teams or even new team roles.

Getting to hear and understand ideas from of our team and our customers. Small things that are annoying, new things that will open the door for a myriad of other possibilities and things I never would have thought would complement our existing solutions are all displayed during Lab Days. — Concetta

Since I had only a week of development time available, I chose a project with limited scope: a small utility that would detect information in the data warehouse and email an interested party about it. I planned to develop the simplest thing that could possibly work, which was important working as a team of one. I did not have any software developers to help me with structuring the program, though I did describe my plan to my regular product team folks, who also estimated that it would achievable.

Test-driven development was one of my goals for this project and this was my first time trying it as a programmer. Granted, I have been writing RSpec stubs for my web automation for a year, but I didn’t have to build all of that from scratch on my own. This time around, I began as usual for a story in our Scrum sprints by writing out the tests that I knew would indicate success before delving into the code mines.

As a result of coding solo, I spent quite a bit more time evaluating and troubleshooting Ruby gems than I would otherwise. While this was frustrating at times, I had a chance to form a better impression of the Ruby community and the problems they were trying to solve, gleaned from the gems tailored to different purposes. As it turned out, there aren’t a lot of Rubyists working with MSSQLServer in a Windows environment, as I was trying to do. I even went down the rabbit trail of evaluating Rails development until self-taught MVC under a tight deadline sounded questionable to me.

Undeterred, I dug up some promising leads and made some experiments, most of which failed. I learned a lot of ways not to solve my problem! However, for success you only need one and I found a way. Once I was able to communicate with my data and my email, all that remained was the business logic. Granted, by this time I was halfway through my week, but I had my infrastructure and I had my tests as goals.

I began with familiar code structures I’d used formerly in pseudocode, Visual Basic, and Java. However, I knew Ruby had its own interesting expressions, as I had noticed while studying my pickaxe. At this point, I decided to learn a bit more about the Ruby idioms and so cracked open an ebook version of Why’s Poignant Guide. This made for an entertaining intermission and pointed me in the right direction to enhance my code to be Ruby-style. I’m sure my Rubyist friends would still cringe, but I wasn’t expecting to have production-ready results as a Ruby newbie.

One-by-one my tests went from red to green. All of this gave me much more confidence that my changes were stable, which turned out to be essential. The morning of the competition presentations, I discovered a fatal flaw in my project: although it worked as designed, the data warehouse SLA for the data I was analyzing had a lag of 24 hours rather than the real-time I had anticipated. With the help of some coworkers in the know, I went to the source and found the real-time data. Fortunately, this last minute coding was an alternate implementation of the database interface and did not affect my program’s overall structure. Here here for modularity and DRY principles!

Out of time but satisfied with my progress, I was able to live demo the first solution against the data warehouse. However, I knew that what I really wanted was an end-to-end test from the source application all the way through to the email account, so I continued working and completed that while the competition voting period was still open. While I didn’t get a chance to present my enhanced code to the group, I had the satisfaction of knowing that my tracer bullet had found its target. And what’s more I had a backlog of enhancements needed for production-readiness prepared for the next iteration – if there is one. Anticipating that this project will become a product in the future, I also completed a proof of concept using tests against an API for the source data that’s in the works, applying some of my learning from Alex Kell‘s recent interface testing presentation to the Agile Atlanta group.

While my project did not find a place in the innovation week competition winners circle, I felt like a winner for having the drive and execution to complete even a small application on my own. Since I learned more about my company’s product suite, data warehouses, interface testing, Ruby, and TDD through RSpec in the process, I call the experiment an unquestionable success. I carry forward all these skills to my day-to-day work and can plan my usual testing with much more context.

So while Ruby and I are still in the early stages of our relationship, I think our first anniversary together was a shining moment.

Image source

Staying on track

24 Tuesday Apr 2012

Posted by in Agile, Automation, Experiences, Experiments, STAREAST2012, Volunteering

≈ 1 Comment


A while back, I was talking to Matt Heusser about my sticker shock when it came to conference attendance and he pointed me to his blog post on creative ways to reduce the cost:

No, you don’t have to be a speaker. That may be the most obvious, easy, usual way in, but there are plenty of ways to serve for people not interested in public speaking: you might serve on the program committee, work the registration desk, introduce speakers, organize lightning talks, or serve as a “runner” in some capacity.

I took one of his suggestions to heart and volunteered to be on staff at STAREAST this year, which gave me the opportunity to look behind the scenes this past Wednesday and Thursday. (Sure, I missed out on the awesome tutorials this time around, but I did get that one key day of floating peacefully in the pool.)

This is a considerable shift from last year’s STAREAST, when I was free to simultaneously learn about my professional needs while designing and executing my conference schedule. This became particularly apparent to me as the week progressed and I made new tester friends who turned out to be speakers, inviting me to their sessions and I just couldn’t shirk my duties. Bummer. I’ll know to look for their names in the program next time around.

This year, I put in my bids for track selections about a month ahead of time, based on the published schedule, and hoped at least one of my first choices would appear on my list. When my track chair packet arrived, I delightedly perused the list of my tracks and my speakers. On my roster were several notable testers and several newcomers. I loved knowing I would get a glimpse into the processes of both the polished professionals and the fresh first-timers.

I read over the instructions with a highlighter and multicolored pens, calling out the relevant details so that I could support these live performances without a hitch. I’m not good with form letters, and I feel that it’s fair warning to let others know that I have a more casual and enthusiastic style of interaction, so I drafted my own email for first contact. From there, all of the advance preparation went off without a hitch and I eagerly anticipated getting settled in on Wednesday morning.

Fortunately for me, my first track was Agile Testing, so the speakers were predisposed to understand iterating to better and better results. It helped that I knew the first few speakers from in-person and online interactions. Speakers aren’t the only ones who get nervous! One of my tester friends from Twitter was in the audience to help me work out the kinks of the tasks set before me and to tune my results to make things easier on all the session participants and to keep me from stressing out.

One thing I quickly realized was that my introduction of a speaker could hardly do him or her justice, especially when we had just met for the first time, so I resolved to keep it short and sweet, trusting everyone could read the program’s bio and knowing that we were all there for the benefit of the speaker’s wisdom, not my scintillating 30-second background recap.

Though troubleshooting the hardware was certainly on my mind, I was particularly concerned with making sure the session feedback was collected and returned to the conference organizers so that they could tabulate results and provide it to the speakers in a more succinct and organized way. I know from observation and discussion how much work speakers put into their presentations and how open they are to comments. Speakers care for their audience members!

The hardest part of track chairing for me was not being free to type, scribble, or live tweet all the wonderful information flying past me! Normally, I write everything down, but I had to take it in stride and trust that my familiarity with some of the material would carry me through. However, I was also supporting sessions I might not have chosen from the program since they seemed to have a focus that didn’t match my day-to-day duties or needs – so I snuck a moment here and there to note some new revelation. As it turned out, I gleaned some value from every session, despite my expectations. Sure, I don’t work on specialized medical hardware or ERP systems, but the generalizable lessons will stand in good stead as I broaden my understanding of the variations of software testing.

When it’s all said and done, when the conference attendees have all gone home, it’s the information transmitted that can make a difference in people’s work lives – and perhaps even their personal lives – that gave me a warm fuzzy feeling to go along with the sore feet.

Image source

Testing Bliss

03 Tuesday Apr 2012

Posted by in #testchat, Context, Experiences, Experiments, Soft Skills, Techwell

≈ 5 Comments

It’s no secret: I adore testing software. It’s my weapon of choice, despite having happened upon it by chance many moons ago. (What other career transforms forgetfulness and clumsiness into strengths since they result in unexpected, non-happy path usage? Ultimately, I think it’s the variety that keeps me coming back for more on a daily basis.)

Given my feelings about testing, it came as no surprise to me that others would agree and rate this profession highly, whether on CareerBliss or elsewhere, as reported by Forbes. (I’ll also admit to having been a bit of an I/O Psych nerd back in the day, so this survey appeals to me in various ways.) I can’t seem to leave my curiosity at the door, so I had to go see for myself what questions were used as the basis of this data. (Yes, HR folks, that’s my story and I’m sticking to it.)

With categories like Company Culture, Work-Life Balance, The Place You Work, The People You Work For, The People You Work With, It’s Party Time!, Work Freedom, and Growth Opportunities, it almost felt like attending a company meeting at my current employer. (Did I mention we’re hiring a developer for my team?)

I was curious to see whether other testers had the same reaction to the questions used to generate the data that CareerBliss analyzed, so I culled out 5 questions of at-most-140-characters designed to find out.

  • Q1) Which people at work most affect your happiness: co-workers, boss, CEO?
  • Q2) How does the level of challenge in your work influence your feelings about your testing job?
  • Q3) Is there a job-provided perk/reward/tool that keeps you happy as a tester?
  • Q4) As a tester, do you have a good balance of freedom and growth?
  • Q5) How does the support at work make testing a great career?

Check out the storify-ed version of our #testchat on Twitter.

Not everyone has the same experience of software testing and my experience has certainly changed over time. I wanted to take a moment to consider the various aspects of software testing that the article identified:

  • requirements gathering – been there, done that both before and after implementation
  • documentation – frequent contributor, sometimes sole author
  • source code control – only for my automation code, but I didn’t set it up myself
  • code review – if you consider pairing with a developer on code during a sprint, then I’ve tried it and with some success
  • change management – not so much, though we did have a composition book in the testing lab to log all hardware changes to a system I worked on; sometimes it was more like a log of who I should hunt down to get the hardware back…
  • release management – the closest I get to this is being able to deploy to my cloud test environment and boy am I happy about that
  • actual testing of the software – bread and butter for me

I love having been involved in the entire software development process at various times during my career. (I’ve even prototyped some UI ideas, though I wouldn’t call that an area of strength or concentration. Glad to have those UXers on board these days!) I do feel that I’m an integral part of the job being done at the company. I am quite happy that my job involves frequently working with people.

However, I do take issue with this being presented as a positive aspect of the job:

software quality assurance engineers feel rewarded at work, as they are typically the last stop before software goes live

Doesn’t that smack of Gatekeepers to Quality to you? I don’t ever want to set up an adversarial relationship with my developers that says I need to defend the users against their disregard, and I don’t want to be involved only at the end as a last stop before kicking a product out the door. I know that happens at times but it’s not my preference. Positive personal interactions and preventative measures certainly contribute to my testing bliss.

Take the survey yourself at CareerBliss and let me know how your experience compares!

I’ll be analyzing the tagged responses from Twitter over on Techwell soon!

Here is some related reading that has come up in recent days:

Q3) Is there a job-provided perk/reward/tool that keeps you happy as a tester?

Jon Bach on tools for testing

Ajay Balamurugadas on tools for testing

Q5) How does the support at work make testing a great career?

Horizontal careers: “each of us will need to overcome our personal assumptions about moving up the career ladder, and think more about how we add value across.”

Scott Barber disagrees

Image source

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