Do you know what makes you want to go to work, even when the work’s not great? Do you know what keeps you strong when all tests are failing and people constantly ask you what’s going wrong?
Well, I didn’t. At least not consciously.
But life as a consultant teaches us many things about people, their interactions with team members and how decisions are made and implemented.
I paid attention to myself and to what made me happy even when the days were not that bright. This helped me come up with a list of principles. So whenever something doesn’t feel right, I ask myself how hard am I trying to apply these principles to my day. They've helped me immensely, so try them yourself and let me know how they’ve worked for you!
Principle # 0 | Be open-minded
Stuck with a legacy application? Even the worst technology has had its time.
It’s hard to agree with everything that goes on in legacy applications. But people go to work to do their best and that’s what we need to keep in mind. They choose a technique, tool, platform, language or methodology with their best intentions. Before abandoning a technology, understand the context of past choices and see if it can used in a better way.
Principle # 1 | Mind the future
Prepare for the future. Tests are the documentation that your system will keep forever.
Learn how to write tests. Learn how to read them as well. Share that knowledge and teach others how to read and write tests. Review the documentation and delete tests which are no longer useful. Change tests when it’s necessary - they aren’t set in stone.
Principle # 2 | Think big
Design your tests for something bigger than just a user acceptance criteria.
When designing a test, understand the user journeys and build long living tests, not short user-story focused scripts. When facing a test, ask yourself a few questions: “What will this test tell me five months from now?” “What’s the appropriate level for my test? Is it a unit, a service or a UI?”
Principle # 3 | Think wise
Don’t automate everything just because you can and the tool is cool.
It’s hard to resist getting your hands on the tool that everyone’s talking about. But do you really need to automate that much? If you write too many tests, you will end up with too many extra work hours, so think before you automate!
Principle # 4 | Keep calm
Red build is not a bad thing.
As long as you can tell why it’s red. If you’re unable to do that, then sleep on principles #1, #2 and #3. Ask yourself, “Is our build pipeline really a pipeline?” or “Do I know exactly what changes were involved in that failure?”
Principle # 5 | Be gentle
Treat your test automation code with all the respect that your app code deserves.
There’s no such thing as a test code base and a dev code base. They may have a different focus, but they’re the same thing. And they will be, as long as that system exists.
These are my principles to become an awesome QA at work. Have you thought of any? Spend some time over this and let me know what you come up with! It’s amazing how much a piece of paper and minutes of introspection can help you turn a bad day into a great consulting opportunity.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.