Sun Tzu Was a Tester??

When working with others, we should understand that we’re emotional creatures. Everybody brings “baggage” to the workplace. Some of our baggage will paint attitudes towards others. If you feel tempted to lash out when someone slights you, it’s better to take a step back and think, “Why are they saying this?” Are they really out to get you or are they just for themselves? It’s probably the latter. Good communication is key–defuse the situation by talking and understanding what they’re really after.

It’s good to bite off more than we can chew once in awhile, because that’s how we grow. Sometimes, though, we take on way more than we can handle. This is either because we overestimated our abilities, or we underestimated the difficulty of the project. Understand what you’re definitely capable of, and what you’re probably capable of. Also understand that there are known-unknowns, and unknown-unknowns in software, and account for learning what those might be in your effort.

Oftentimes we may get excited talking about what we’re going to do and how we’re going to do it. I call this “Nerd Mode” or “Geeking Out”. Testing is exciting, challenging work, and sometimes we talk more than we actually deliver. Or, we say way more than our target audience needs, for understanding what we’re doing.

Instead, talk a little less. You’ll surely run into snags, and when that happens it’ll look like you’re quietly adapting your plan, as opposed to flailing around if you’d broadcast what you were going to do, beforehand.

This is a great quote for consultants in general, but for testing it applies like this: If everything’s on fire, there are opportunities to land a devastating, calculated blow on one spot, and get rid of a lot of problems.

Most times, teams and companies are chaotic because of small decisions made before, that have built up a lot of technical debt, which then takes enough time that nobody can fix it, even if they know how. Staying out of the firefight, to get altitude on the problem and see what to actually do, is very valuable.

For testing, or for test automation, the best solution is one that requires no action. Either by not testing, or by not writing new test automation.

Instead, the solution lies in communication. Talk with people at the requirements stage and identify rickety places that could hide bugs, and they’ll be considered and fixed before the first line of code is even written.

Morale-draining death march releases suck. I’ve been through many. A continued string of huge big-bang releases is no way to foster a good relationship with your customers, or high morale with your team.

Strive for short, targeted wins. A smaller dopamine hit from a successful release is better than none at all, and having to furiously break/fix a release once it hits production.

Similar to testing personas, you can adopt different strategies at appropriate times. Avoid sticking to one type of testing–mix it up, and share tips with others.

Managers: I know you know testing is hard. If you do nothing to foster camaraderie with your team members, you will lose their heart, and then their spirit, and their body, possibly to a competitor.

When we test an application the same way each time, it might seem like it’s stable, but we’re really not putting it through the paces. Change up some things–use random data, or special characters, or something different every time you test. Hit it rapidly, make it work hard. The more variety you use the higher the likelihood of finding a bug. Don’t be afraid to fight dirty.

There are many ways to test. Some people will look for specific kinds of bugs, and everyone has their own style. When we mix different approaches together, there will be new approaches that show up as a result–things that neither person would think of by themselves, but together form a brand-new strategy.

If there’s a place in the system that’s been well-tested, don’t focus a lot of effort on it. The bugs likely aren’t there. Rather, they’ll be where the system is weak–where code was written hurriedly, or written by someone who is known to leave certain types of checks undone. Where requirements weren’t detailed enough. Where end users have control of what data can go into the system. Consider what weak points are in your system, and test accordingly.

The best testers are the ones who can communicate best. This goes back to using words to eliminate bugs before code is even written. The code quality metric goes WAY up when this starts happening.

Many testing efforts either fail or get drug out because we don’t correctly estimate the time and money for it. Determine first how long (and therefore how much) it will take to perform the testing, before beginning.

Some may know how to test without being able to really do it. Strive to be a person who contributes ideas, but also doesn’t have a mental lockdown as soon as an application is in front of them.

With exploratory testing, be aware of what else the software is doing, in response to your actions. Is there a pattern to it? Are there any oddities? Do either of these reveal a place where there may be a bug?

Be fluid all the time. Don’t do things the same way all the time–adapt based on what’s going on, and you will be successful.

Junior automators may try to “Automate All the Things!” but that rarely goes well. The more automation you have, the more you have to maintain. When you’re spending all your free time dorking around with the tools, you’re not contributing to quality.

If you stick to a particular way of doing things, the trend of software is that you’ll be obsolete before long. Software changes so much that we can’t afford to zealously guard a toolset or a methodology. We have to push into areas that we’re not familiar with and always keep moving and learning.

The spectacular manager won’t use the team as a step stool for themselves. Rather they will seek to encourage growth and camaraderie among the team members.

When developing test automation, it’s important to not architect in a way that causes lots of unstable behavior or a ton of upkeep. Keep things really small, very simple, and “unattackable”. The less time you spend fooling with your automation, the more effective it, and you, will become.

If your team is populated by people who know a lot but don’t share the knowledge much, the team will suffer. Nobody knows everything about testing. Ideas must flow for you and your team to be successful.