Hi, I’m the QA Lead here at Infinum. In the last 3 years, we’ve had to reinvent ourselves and adapt to significant growth and challenging projects. This gave me a unique opportunity to take part in forming new processes and proved a learning experience from which I distilled a few modest lessons.
This post will look at some of them from the perspective of a software tester, but they should ring true for anyone working on projects within the usual constraints of time, budget, and complexity. I will also try to pinpoint some organizational best practices that are often as significant as technical expertise.
Some of these might seem blatantly self-evident, but to pique your interest and prove a point, let’s see which lessons have avoided you in the past and how much value you bring to your projects. At the end of each paragraph, give yourself a point if the given statement pertains to how you conduct yourself in your day-to-day work. Sum up all the points as you go through the text and see where you stand on the bystander-revolutionary spectrum.
Keeping a routine
People need some time to settle into a workflow and optimize it to their liking. With time, their productivity has a chance to increase. Think of it as muscle memory.
For instance, you agree to create a test build each time you finish a feature. It gets tested, and then the development team can expect to work on fixes. By doing this over and over again, they will develop a certain confidence that their work is iteratively and continuously checked against requirements and tested to uncover the unknown unknowns so prevalent in software development. If this is inconsistently done, their work might become inconsistent as well.
You know the old adage – if it ain’t broke, don’t fix it.
[+1 point] if you try to never break processes without a good reason.
Breaking the routine
Consistency is a great thing until it isn’t. You should not be consistent in doing things ineffectively.
Breaking the workflow can both be a painful experience and a wake-up call. It can make the team realize which practices were actually good and which just became habitual.
For instance, it makes all the sense in the world to use a set of test cases when doing regression testing. But sticking to the same predetermined set 24/7 makes you the QA analog of the proverbial code monkey playing the “spot the difference” game build to build. You are paid for your intelligence, creativity, and experience which translate into the ability to spot issues and improvements where others just don’t look. Don’t be a zombie, explore and learn.
[+1 point] if you always try to break processes when you have a good reason.
What does this button do?
Imagine a scenario where a big red button is being discussed. The UI proposal shows a big red button. The requirement is “when a user clicks on the red button, a blue button appears.”
Everyone nods their head, shakes hands, and leaves the meeting. So far, so good?
I believe the naysayer asking what happens when you click on the blue button is the most valuable person in the room. The person saying “we’ll get to the nitty-gritty at a later point” is the most dangerous person in the room. At the end of the day, that person will still expect you to work your miracle and meet all expectations, holding you accountable if you fail to do so.
The blue button is where frustrations accrue, deadlines get broken, and money gets lost.
I don’t like waterfalls, but I also believe some amount of mise en place is necessary whether you’re building a birdhouse or a skyscraper. Issues will come up during implementation whichever way you spin it, but shoveling chaos into the process and expecting quality in return is software development utopia.
So what should you do instead? How about:
- Asking the right questions at the right time
- Turning implicit assumptions into explicit understanding
- Reaching compromises with team members
The point of the story? Someone raining on your parade today might save your ass in the long run. The devil’s in the details, so long live the devil’s advocate.
[+1 point] if you always try to openly question presented facts.
[+1 point] if you always try to define tasks to an optimal level of detail.
The mythical 15-minute meeting
This is what each meeting needs:
- A moderator
- A timebox
- An agenda or topic of discussion
- Attendees who use their ears and mouths
The moderator keeps track of time and makes sure decisions are reached.
You should listen when others speak and speak when you have something smart to say.
Each productive meeting should finish with action points delegated to people who take responsibility. Everything you could not discuss in time, leave for another meeting. This will give people time to reflect on the matter.
[+1 point] if you always finish your meetings in time with clearly defined action points.
Just write it down
This is really about mastering the subtle art of Getting Things Done:
- When you agree to do something with someone, write it down where it is easily accessible by everyone.
- When you tell someone else to do something, and you think they’ll forget, warn them to write it down. Be a friend.
- When you need to do something in a recurring fashion, let software remind you to do it.
- When you need to do something complex, break it down into digestible chunks. Don’t choke.
The space of undocumented and miscommunicated decisions is the black hole which sucks projects into oblivion.
[+1 point] if you continually strive never to lose track of what you are supposed to do.
Point out the bad stuff
You are not in the army; there should be no chain of command and no mushroom management. If project-related decisions are made solely on the basis of authority, there will be a point in time when the entire team will enter panic mode and start making amateurish mistakes.
Everyone should be able to influence how things are done and point out the bad stuff without being micromanaged or left to their own devices. As a software tester, imagine not having a say in the matter when someone has the bright idea to push into production a risky feature in order to satisfy some arbitrary deadline.
Let’s get down to brass tacks, if you cannot include yourself in the decision-making space at any level, you are at a very bad place and you should either try changing it or leave.
This has nothing to do with your level of experience. Experience might only dictate how often someone is right, but even a broken clock is right twice a day, so take experience with a grain of salt.
[+1 point] if you always attempt to improve things and push for ideas that you consider right.
Honesty is empathy
Respect and honesty are vital to nurturing healthy relationships with people.
If you give people feedback on their work, you will usually help them improve. People will recognize you care, and some will even pass on these values to others.
People approach honesty and empathy in different ways, but I can tell you what you should not be doing:
- Name-calling or attacking people on a personal level.
- Giving negative feedback without suggesting improvement points.
- Giving negative feedback without ever listening to other people’s feedback on yourself.
- Giving negative feedback without ever commending your colleagues.
Respect your colleagues and earn their trust. Your projects will be grateful.
[+1 point] if you always try to give spirited feedback in order to help others improve.
…and ownership is king
Do you ever hear people complaining? They are usually the same people that seem professionally trained to deliver one-liners such as “this is not my job” or “not my responsibility.” Those people suck.
Regardless of your project management framework of choice, some responsibilities overlap across roles or are so ambiguous that no one feels like taking charge. But nothing can really replace the effect that a motivated individual can have on a team of people. It does not require superhuman abilities, just an ownership mindset.
Issues that plague software development projects often boil down to a lack of ownership. The bigger the project or the company, the easier it is to hide and play a minor role in the proceedings.
What do valuable people do? They take initiative instead of waiting for someone else to pick up the slack. For team leaders, instilling and nurturing a culture of ownership is probably the best possible thing you can do for your team. Imagine working on a team where everyone is willing to step up.
Furthermore, it takes courage to own up to your own mistakes. It is the sign of a healthy environment when people are able and willing to point at their mistakes and say “I messed up but I’ll do it better next time” instead of covering it up and saying their prayers.
I believe a sense of ownership is the point at which software testing shows its value. Oftentimes, it takes moxie instead of testing to make software better.
[+1 point] if you always try to take action when action is needed.
[+1 point] if you always try to own up to your mistakes.
Fail again, fail better
Lessons are lessons only when they influence how things are done. As long as you keep failing and keep improving with each iteration, you are on the right track.
Now let’s have a look at your homework:
Score 0-3 – The Innocent Bystander
You start typing on a public channel in Slack but stop mid-sentence and go home instead.
Score 4-6 – The Freshman with an Attitude
You speak all the time and sometimes even make some sense.
Score 7-9 – The Leader
You are on top of things even when disaster strikes.
Score 10 – The Revolutionary
You build productive environments instead of software.
Anyone with a score of 4 or above, have a look at the Careers page. Let’s talk.
Thanks for tuning in.
