Software development is an oddly consistent occupation filled with inconsistencies, dead ends, and a more-than-nominal amount of keeping one’s fingers crossed. Within this cycle of losing and gaining focus, we try our damnedest to complete our tasks, often as fast as possible. Speed comes with a cost, one which rapid iteration seeks to mitigate. By decreasing meantime to failure, a feedback loop is formed and takes on a life of its own, resulting in more robust, constantly reviewed, and high quality code. This is the dream promised in little “a” and big “A” “Agile” methodologies. The QA process within this cycle must act not only as arbiter of truth, but moderator. The QA Engineer (tech, analyst, person, etc.) must become a “Feature Hipster,” cradling features in loving, critical arms from concept to release.
Moustache Wax for Untamed Agile Whiskers
Agile (in all forms) has a pretty brutal Achilles’ heel. When met with resource constraints and tight deadlines, the iteration process must reach maturity at a faster rate than is often possible. This is doubly true when working in an agency setting wherein deadlines are tied not to demonstrable release milestones, but, instead, to the whim of an often non-technical client, and contract stipulations (read: money/time). That sweet hipster ‘stache needs to be tamed.
In this contracted lifecycle, the role of QA is often relegated to a sort-of gatekeeper. Code comes flying out of pull requests and into a release branch, and QA is expected to grab it, confirm it based on specs (if there are any), and send it back should it be found lacking. This often takes the form of regression testing — following a giant script of actions linked to expected results. This is, quite obviously, not an ideal feedback loop. The length of time between pushed code and feedback is far too long. By the time a bug is filed to put a feature back into development, the author has moved on to other tasks. The “flow” that we all seek when staring into the abyss of an IDE has been lost.
Feature Hipsters
ustwo has some amazing clients. Google has been one of our most loyal in large part due to the work we’ve put into helping shape the Android Wear ecosystem through extensive work building watchfaces and apps for Android Wear. When I joined the Google x ustwo team at ustwo eighteen months ago, the QA process had been defined by the development team. A large regression test doc had been created and the entire team would halt work and run the test in parallel in the week before the release. Those of us in the QA game know the document in question: a gigantic spreadsheet teeming with macros and links to specifications. It was thorough, but, as a filter, was only really helpful at the end of the SDLC, and designed, as all regression tests are, as a final confirmation that no one messed up so badly that the software couldn’t be shipped.
Early in my career, I was lucky enough to have a boss that believed so thoroughly in the value of QA that he stopped coding and hired me as a foundational member of his new ideal of a QA team. He coined the term “Feature Hipster”, and put us to the task of living it out.
The basic idea is that QA shouldn’t just be a security guard at the end of a long hallway. QA should be deeply invested and embedded in the scoping, planning, creation, and building of a feature. Each QA person should know so much about a feature that they’re working on that they can safely say that they know more than any one individual on the team. “Oh, I knew about that already” should be a constant response in conversation; Like a hipster telling someone that they knew about a band before they were popular. We even had hoodies made (of course, we did) that said “We Know” on the back in giant Impact font.
I brought this, full-force, to my time on the ustwo Wear team, and even went a bit more extreme in order to see where it would take us.
How to be a Feature Hipster (Hint: Lots of Reading)
The following is an expounding of my to-do list from when I started on the team. It might serve as a how-to if you’re so inclined.
- Begin by reading. Read anything related to the features to be released that you can get your eyeballs scrubbing against: spec docs, email threads, GitHub, README files, design files, old demo decks. If it is in the project team’s Google Drive, or any document repo, read it.
- Talk. With. Devs. Regularly. Understanding the features that are being released is important, but so is understanding how those creating them do that work. Getting a feel for production cadence and work-style allows a QA person the opportunity to find the best way to assert an issue to a given individual without being unnecessarily disruptive or insensitive. An empathetic, familiar face gets results and encourages. Sending back a ticket with little comment does not.
- Attend all of the meetings. Whether design, production, development, or UX, a representative from the QA team (usually just, you know, you) should be present in as many meetings about the feature under development as is feasible. Being there - and taking notes - allows the QA person to become a domain expert, and putting in the face-time, as previously-mentioned, has the delicious side effect of endearing your cause (quality) to the rest of the team.
- Create a testing pipeline. Each feature - and subsection - should be tested as soon as it is coded. Getting this right takes time, but the work that is put in to understand each feature and developer workflow will make testing in this way both quick and efficient. It also tightens the feedback loop to the point where near-immediate response to a `git push` is possible. This division in testing also makes regression testing far less stressful as the amount of bugs that will come out of it will undoubtedly be far fewer than average.
- Be proactive. The amount of times that developer has told me that they forgot about a bug is nearly immeasurable. This is to be expected. They have a lot of work on their plates, especially in small teams on a deadline, and their job requires getting into a groove, often for hours on end. This leads to stuff falling by the wayside. Your job as QA is to keep those things from hitting the floor. Often, a friendly reminder in the morning (standups are perfect for this) does the trick, at which point you’ll sometimes hear “I forgot”. Smile, be friendly, and make sure that the issue being presented is actually important and not nit-picky. Your job isn’t to nag, but to be the person that picks up the dropped wallet.
- Create an agreed-upon scale for issues. Simply labeling something as “blocking” doesn’t mean anything to anyone but yourself. One must present issues appended with priority the scale of which is agreed-upon by the entire development team (if not the whole team). Get a room and hash it out. Write the rules down. Put it on paper. Put it on a wall near your desks. Adjust the scale as needed.
- Learn the codebase. Alright, admittedly, this one is a tough nut to crack, and time-consuming, but hear me out. Learning the basics of the codebase you’re working in (architecture, dependencies, the language syntax) helps to debug issues like you wouldn’t believe. Imagine tailing a log and knowing what is breaking and - potentially - why. This is the magical line between black- and grey-box testing. Cross it. You’ll be glad that you did.
- Learn the toolset. Often in testing, there are developer tools inherent in a given SDK, as well as third-party tools which make grokking a feature - and later debugging it - a whole helluva lot easier. Learn all of the SDK tools, at least. Ask the developers on your team which to begin with, and which are best to use. They know the SDK/language very well and are an invaluable asset to testing. Learn from your peers!
- Make quality everyone’s problem. Alright, this is the last bullet, but probably the most important. Eighty percent of my effectiveness as a QA person is derived from my ability to spread the gospel of quality. Evangelizing quality is easier than it sounds. Be a bug in everyone’s ear at all of the meetings that you’re attending. Relate everything back to the end-user (oh, yeah, people actually use our software!) and their journey through your app. Soon enough, your voice will be replaced by their own inner monologue saying something biblical about quality. Then you can stop talking so much, which everyone will like, and will give you more time to review specs and be proactive.
“Learnings” Isn’t a Word
As a result of this to-do list, several things happened, some good, some bad. Cool kids call these “learnings.”
The first was that our development team began thrumming along at an incredible rate and the quality of our first-draft code became impeccable. The tighter feedback loop meant, counterintuitively, that there was more emphasis on getting it right the first time so that my job, and those of other teammates, wasn’t made harder. We were functioning as a team. As comrades. It was glorious.
The second was that having a top-level understanding of the guts of the code (the architecture, etc.) meant that I was frequently able to present solutions or, at the very least, excellent isolations to bugs once found in a feature. I even wrote a bug fix a couple of times, which felt a lot like an inappropriate, non-Agile thing, but I loved it.
The third, less awesome, thing that happened was that I became bogged down with meetings and conversations, which meant that I had to dramatically step up my organizational abilities to keep ahead of the workload. All things considered, that lesson might have been the best to come out of my experiment with whole-hog Feature Hipsterdom. Not enough credit can be given to people with organizational prowess. I’m glad to have found a little bit of that on this journey.
The result of all of this effort and documentation - no guff, I’ve got a folder on the team drive with tips and tricks - has been to make the development team more efficient, more cohesive as a unit, and allowed for the team to be more generally cognizant of their stake in the quality of the product as it is being designed and developed. The process helped to buck the idea of a “QA machine” where features go into a bin for later judgement, and realigned that viewpoint to understand the role as being more comprehensive… and hip. Well, maybe not the last part. A girl can dream.