The entrance and exits to my professional building are both accessed through a common lobby. A set of elevators service the lobby level to a set of three other floors. From those three other floors, people must walk to another set of elevators to proceed to higher floors.
It is a sort of rite of passage to master this system and be able to get out of the building for lunch in the most efficient manner possible. You can spot the newbies, wondering why everyone is not going directly down to the Lobby (the first car doesn’t go there.) They tenuously follow the crowd and hope a sandwich is near. Ah, I remember those days.
The calculation of the fastest lunchtime route out of this particular building is somewhat of an art. Like poker, you need to read the faces of the people in the elevator and think, how many are going to get off at the main floor, which is the fastest way to the lobby-bound elevator shaft way all other things remaining fixed, and how many people are going to take the longer route through the lower level, which runs 7 floors below the fastest route possible but given the lunchtime traffic, may actually result in faster service because of the resulting fewer people attempting to use the elevator.
It’s a veritable game of rock-paper-scissors. A group of people will get out of the building first, but it’s anyone’s guess as to who will be the victor, and who will go hungry for a precious few more minutes. There is a fascinating twist to the elevator puzzle that rock-paper-scissors is missing, though – once you make your selection of main floor or lower level, you can silently change your mind and exit on whatever floor you want. This is a fascinating twist to the game – you can press a floor, and in the relative anonymity of a full elevator car full of hungry lunch-goers, decide to stay on to the lower level and pretend it wasn’t you who chose the main floor.
There are five kinds of people who ride the elevator.
1. The Committer. These people get on, make their selection, and stick to it, exiting on the floor they selected. Many of these people have very nice suits and straight ties or pressed separates. They probably all have a 5-year plan. A couple might even have a whiteboard at home. One of them has a whiteboard instead of a television.
2. The Waffler. These people get on with an initial selection, and flip a coin as to which to get off on if both levels are lit, and usually laugh or talk about their decision. Many of these people have untucked shirts and jeans. Some might even be laughing about last night’s awkward drinking memories. One of them probably has untied shoelaces.
3. The Switcher. These people use reverse psychology to select the lobby floor, but purposefully get off at the lower floor after having suggested nonverbally to the riders that since they chose the lobby, they should too. These people sometimes have eyes that dart this way and that, and love Lolcats.com. One may have returned a retail item damaged and blamed it on someone.
4. The Delorian. These people were the ones who pushed the button for one floor, changed their mind somewhere between the time they selected the floor and the time the door opened, and they walk out on another floor, but with full belief that it was not they who selected the button for the other floor. They have fully convinced themselves that they made a decision that they in fact they did not. It is as if they went back in time in their mind and changed the memory, even though the reality of the replay on tape would reveal they did not decide what they believe they did.
5. The Buddy-Buddy. These people talk from the time they get onto the elevator until the time that a herd of people exit the elevator. They pay marginal attention to the floor and aren’t concerned about how fast they exit the building. Most of them are probably in sales.
You probably work with every one of those people in some regard in one way or another. And so, as systems theory predicts, each and every one of these personality types will affect your work and impede your perfect little world where software lands neatly in your lap and you catch all the bugs and they are fixed and every business day ends with confetti and apple pie.
I… hope that wasn’t out loud just now.
The moral of this story is that everybody gets what they’re looking for (lunch, sure, but also what they’re going for in business) but they all go about it in very different ways, with very different internal and external processes. QA will find this situation common in Agile or Extreme programming. These personality types are probably all part of your software team, especially an Extreme (Agile) software team, which tends to welcome diversity. Just as the end goal of “lunch” has many different paths, extreme programming for enterprise web applications usually undergo changes to product and architectural decisions all happening under the radar of anybody not in the room or within earshot.
This can be complicated for QA. These decisions, which are often very important decisions and made quickly by a minimum set of people involved (again, this is an Extreme principle and a tenet of minimizing the overhead of decision making), are often both proactive and reactive in nature:
Proactive as a result of intellect being applied to forecasting activities based on the quality of user interaction and the quantity of data being moved, and
Reactive as a result of the actual results observed as a result of real-world production use versus anticipated or best-guess usage scenarios that QA plans were based on. QA must adjust to product design changes, architectural tenet updates, production patches, scheduled updates through regular deployments, and emergency one-off product features that are needed ASAP.
This begs the question, how can QA keep their understanding of test scenarios updated so that they can:
- manage the changes necessary to manual testing,
- update smoke tests,
- update automated test changes needed,
- update performance test strategy and code, and
- update the regression codebase?
There are two modes of solution to the QA process: proactive and reactive. Neither is better than the other; both are necessary.
QA Managers that need to have everyone working under the same set of heavy rules will fail. They will attempt to load process and documentation into the problem, and may even have some small victories, but will ultimately fall asunder to the pure volume of changes that must be tracked and processed within this paradigm of “throw rules and process at the problem.” QA Managers that can shed this Welchian command-and-control approach and adopt a more Agile-principled mindset know that the secret to succeeding in these situations, especially when you also happen to be understaffed (common to smaller shops, startups, and larger shops that want to squeeze innovation,) will find a great opportunity to problem solve.
Squeezing the organization can be a tactic to encourage underperformers out by pressuring high performers to socially ostracize the slower team members, or it can be a result of simply failing to acquire new resources and capabilities. is a professor at , and the research director of the . Both Capron and Will Mitchell, a professor at Duke University’s Fuqua School of Business in Durham, North Carolina, write in August 2010’s Harvard Business Review that studies reveal that the typical firm relies on one primary method of acquiring resources. Capron and Mitchell write,
In a 10-year global study of 162 telecom companies, we found that only one-third actively use all the methods available to them. Some still develop almost all resources in-house; others focus on licensing or joint ventures; others are M&A specialists. When a firm does add a string to its bow, its usually just one: for example, M&A to complement internal development. What’s more, when asked to explain why they struggle to build new resources and capabilities, few of the managers in our sample seemed to suspect that it’s because they’re doggedly applying the wrong approach. More than half flagged implementation as the primary cause of problems– in particular a lack of people and skill s (67%) and a poor ability to integrate acquired businesses (50%).
By blaming implementation rather than looking at corporate-development strategy, companies leave a lot on the table. Our study demonstrates conclusively that firms using all the resources-acquisition methods outperform those with a narrow approach. Specifically, firms acquiring resources in multiple ways are 46% more likely to survive over a five-year period than those relying mainly on alliances, 26% more likely than those focusing on M&A, and 12% more likely that those sticking with internal development. It’s also worth noting that 54% of managers who haven’t paid close attention to the tactics they’ve used report a high failure rate in resource acquisition, compared with only 20% of those who have looked at the full range of options and made careful choices about which ones to explore.
Ah, the full range of options. It’s like a breath of fresh air, isn’t it? These principles apply to QA teams in that QA staffing is a constantly moving balance between internal resources, hiring external consultants, and outsourcing.
The proactive piece of this approach has a theme of nurturing a personal relationship with the decision makers.
QA Managers must step out from behind the spreadsheets and get personally involved in meetings, lunches, and dinners with other managers, sometimes with people completely out of their immediate sphere of influence, to always be striving to be more worldly in the company. In fact, Harvard Business Review’s argues on that the only thing managers can really deliver on consistently is TLC – tender loving care. Kanter writes,
People respond well to a sympathetic ear and frequent communication. Knowing that leaders care about their success can help people let go of the rest.” Management demands such as Absolutely Clear Expectations About Everything, Perfect Certainty About The Future, Yes All The Time, and The Ending At The Beginning are all management demands that no leader, QA or otherwise, can give an organization.
Manual testers should be sitting within earshot of their product managers or be speaking with them twice daily – once in the morning to get a wrap up of what really happened yesterday versus what they thought would happen, and what they expect to happen today. A SCRUM standup is perfect in this regard.
Test engineers who update automated test scripts, performance scenarios, re-balance performance script v-users and use case balance, and who keep regression code bases up to date are, in a perfect world, all part of the same daily stand-up with the product owner in the morning in order to hear the latest news of what third party vendor relationships are changing, what features in the product are growing, what bugs are the most important to fix, and what is on the horizon for that week or for next.
As a QA Manager, look to encourage your Project Manager and Product Manager to have meetings in the dev area whenever possible. Try to convince business champions to do the same at least once a week. Do whatever it takes to get a round table with 8 chairs physically dedicated to the team area. Put a wastebasket nearby for lunch/dinner cleanup and dead Expo markers.
There is a fine line between micromanaging and keeping news social – listen to your staff by sitting close to them or stopping by to check in. Come up with a question to ask if there isn’t something pressing. Make a habit of stopping by even when you don’t need anything. This will take effort on your part. This is by design.
A consistent set of simple, consistent QA tools is key. Follow Occam’s Razor – implement no more than the base set of functionality needed. Don’t implement spreadsheets or open-source bug-tracking solutions without careful consideration of the cost to set it up, maintain it, fix it, and to report data out of it. If you do not have a crack team of engineers that can code in the mother language of the open-source tool: Most open-source tools have an ROI similar or worse than an off-the-shelf solution. Be wary of tools implemented by people who cannot program in the tool’s mother language. In most cases, managers implementing tools in this manner have the best of intentions but are making purchases that their hopes can’t pay for. When in doubt, never trust a vendor’s ROI formula. A vendor provides an ROI formula as a stop-gap to fill the void of the client not going through this due-diligence exercise on their own. If you don’t know how to create an ROI formula for your organization, spend a few hours this weekend doing research on how to build an ROI for your own organization. Poke around on google. Encourage your team to take the same approach in logging defects, classifying them, and bundling features and bugs together as work products to deliver.
The reactive — but not negative — solution to this problem is to be ready to adjust to inevitable changes to product, and technical architecture. The more you invest in a tool that only performance tests 20 user scenarios through a Selenium interface using Ruby, the less flexible you will be if you suddenly lose your Ruby programmer and need to backfill with a C# programmer with little to no Selenium toolkit experience. Well-written Ruby code for a Selenium tool suite can be converted to C# code in less than a week (for less than 1000 lines of code) if the code is written with good modular practices and just enough commenting. Ruby formatting can be pattern matched and converted to C# syntax, and common modules written for compares or harnesses can be adjusted and re-implemented in the new converted code. This is not necessarily always straightforward, but in these cases persistence and focus usually win.
QA code must be code reviewed to ensure these sorts of best practices are being followed. “Saving time” by not code reviewing always comes back with a price tag of double to triple the cost 6 to 8 months later. (Most contractor gigs and offshore contracts are a result of trying to “save time.”) Java, C#, Ruby, and Python are common languages all well-suited for Selenium, Cucumber, and other open source functional, performance, and smoke tests. Use the language your developers know. Decide what sort of shop you want to be and make an investment in training. Each language has advantages – a good QA coder will have 2-3 O’Reilly books on each of the four languages and be ready to spend a weekend studying up on the language before a new engagement or after an announcement of switching to a new language for a specific project. Investment in training and books are such easy ways to increase employee satisfaction, morale, and effectiveness. It amazes me that some companies are so restrictive in providing training and education… it seems to me it should be a core value of most technology firms that really want to attract and maintain quality development and QA talent. When in doubt, shower one with!
Being reactive means being unresisting, unhesitant, and even downright OPEN to change and learning. Most people are not, period. Most people don’t like learning and they don’t like things changing. To be a QA manager or a QA professional and not like change is very strange – this is generally our advantage. We get so used to crazy things going wrong with software that we sort of look forward to it in an odd sort of way.
Implement tools that are so simple they do not take a lot of modification to change direction. Do not heavily decorate open source tools with customizations – you may think this makes the tool more usable and makes you more marketable (and it may in the short term) but in the long term it will not serve you or the company to build up complexity where none is needed. Document just enough to get by, but document. Put the minimal set of information on the team whiteboard (maybe it’s a Scrum board, maybe not) in communicating what is broken, what is in QA, and what is heading to production. Keep these things limber, light, on dry erase, not in complex spreadsheets and emails. The easier you make the mechanism of tracking, the more apt people will be to suggest and manage change. Humans are trainable in this sense – we ultimately prefer the path of least resistance. It’s in our animal instinct… it’s our intellect that wants a problem to solve and creates complications where there don’t have to be. Nip this in the bud and you’re on your way to a very successful career.
Keep your eyes and ears open and prepare for change before it happens. Keep your tools lightweight and always, always be learning. Buy books to line up to read even if you don’t have the time – you might dive into one or two of them for 30 minutes one day.
Get into this mode of being flexible and visiting people not just when you’re in a panic and you’ll be far more effective at Agile / Extreme QA and may even have more fun at your job. Enjoy!