Category Archives: Automation

Keep your options open

27 Wednesday Feb 2019

Posted by in Automation, DevOps, Experiences, Training, Uncategorized, Unconference, Volunteering

≈ Leave a Comment

Tags

, , , , , ,

In DevOps, there’s a pervasive theme of automating toil, which many would say contains all of testing. I’m just gonna say it: I come from the testing community. We’re people who constantly look for things we haven’t seen yet, who collaborate across roles, who explore the unknown, and who care about doing the right thing. Does that characterization surprise you? Yes, testing is complex enough to be a viable career and not just a thing we do until we can script it for a computer to execute.

So when I reached my limit of “X is going to kill Y” (in this case, DevOps and the testing profession), I finally went for it and joined a DevOps team as an agile tester. I wanted to see for myself that DevOps was the cultural sea change that would make my job role obsolete. If giving up my vocation was the right thing to do, I wanted to be ready with a deep understanding of the value of the new practices and to embrace the mindset shift. I wanted to be ready to bring others along with me on my voyage.

Free electron
Free yourself, electron!

When I attended DevOpsDays Atlanta 2018, I didn’t know what the community would be like. Sure, I’d helped to review their proposals as part of the program committee, but who would I meet who would change me for the better? It was my first time hanging out at an event for people who might identify as “operators” instead of just “developers.” Would they welcome me, a person without any operations background?

Inclusive collaboration wasn’t just the theme of the conference: attendees and speakers shared their authentic selves and wholly embraced it.

Although my discernment of future direction is ongoing, I see as much diversity of thought in DevOps as in agile. The afternoon unconference was my favorite experience! This format is less structured, as you might expect from the name, allowing for free-flowing conversations that address the most current burning questions of the attendees. I found operators wrestle with similar collaboration conundrums. My questions and concerns found ready listeners and new proposed solutions (in addition to new questions!). This diversity of thought helped to open up my perspective on what is possible.

Collaboration with people from diverse backgrounds and viewpoints is a competitive edge. It’s also the right thing to do. We want to keep our professional and organizational options open. Distinct perspectives provide a greater ability to handle the breadth of competitive situations we face. We need new voices and different perspectives to make change possible.

I’m particularly excited about the possibilities this year in bringing 3 communities together! Whether you’re someone looking to refine your role in the context of today’s accelerating software delivery cycles or just curious about how much DevOps, serverless, and (Wardley) mapping enthusiasts have in common, this year’s event is for you!

Our call for proposals ends February 28th (that’s today, procrastinators!), so there’s still time to share the unique experiences that only you can bring, whether through a 30 minute session or a 5 minute ignite talk. If you prefer to attend and then propose topics on the fly like I do, the afternoon unconference provides that space for emergent value.

Let me assure you that constant learning isn’t easy! Change is hard – and worth it. I expect the supportive environment I’ll find at DevOpsDays Atlanta / serverless days Atlanta 2019 / Map Camp 2019 is exactly what I need to just keep swimming. We could all use some help staying afloat.

E v A

05 Friday Oct 2012

Posted by in Automation, Exploratory Testing, Podcast, Publications, TestCoachCamp 2012, TWiST

≈ Leave a Comment

EvA

Back during Test Coach Camp 2012, Michael Larsen made some great recordings of our open space sessions. Subsequently, he published Ken Pier‘s session topic E vs A – Huh? under the title Exploratory vs. Automation in the TWiST podcast feed.

I had fun explaining our testing team’s approach to exploratory testing and automation while learning from some helpful members of the testing community, including Cem Kaner, Doug Hoffman, Matt Barcomb, Phil McNeely, and Michael Larsen.

Check it out!

You can stream these podcasts online or download after registering for the Software Test Professionals’ website, and membership is free.

Here are the direct links (once you log in):

Exploratory vs. Automation, Part 1
Exploratory vs. Automation, Part 2

Image source
(P.S. I can’t resist reading this article that pointed me to the image: The Semiotics of Hello Dolly!)

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, STAREast 2012, 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

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!

Taking on Water

27 Tuesday Sep 2011

Posted by in Automation

≈ Leave a Comment

Tags

Composition

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

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

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

Prevent a Bail Out

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

Image source