Ways To Boost The Value of Testers Who Don’t Code
Posted by Eric Jacobson at Wednesday, February 10, 2016Despite the fact that most Automation Engineers are writing superficial automation, the industry still worships automation skills, and for good reasons. This is intimidating for testers who don’t code, especially when finding themselves working alongside automation engineers.
Here are some things, I can think of, testers-who-don’t-code can do to help boost thier value:
- Find more bugs - This is one of the most valued services a tester can provide. Scour a software quality characteristics list like this to expand your test coverage be more aggressive with your testing. You can probably cover way more than automation engineers in a shorter amount of time. Humans are much better at finding bugs than machines. Finding bugs is not a realistic goal of automation.
- Faster Feedback – Everybody wants faster feedback. Humans can deliver faster feedback than automation engineers on new testing. Machines are faster on old testing (e.g., regression testing). Report back on what works and doesn’t while the automation engineer is still writing new test code.
- Give better test reports – Nobody cares about test results. Find ways to sneak them in and make them easier to digest. Shove them into your daily stand-up report (e.g., “based on what I tested yesterday, I learned that these things appear to be working, great job team!”). Give verbal test summaries to your programmers after each and every test session with their code. Give impromptu test summaries to your Product Owner.
- Sit with your users – See how they use your product. Learn what is important to them.
- Volunteer for unwanted tasks – “I’ll stay late tonight to test the patch”, “I’ll do it this weekend”. You have a personal life though. Take back the time. Take Monday off.
- Work for your programmers - Ask what they are concerned about. Ask what they would like you to test.
- What if? – Show up at design meetings and have a louder presence at Sprint Planning meeting. Blast the team with relentless “what if” scenarios. Use your domain expertise and user knowledge to conceive of conflicts. Remove the explicit assumptions one at a time and challenge the team, even at the risk of being ridiculous (e.g., what if the web server goes down? what if their phone battery dies?).
- Do more security testing – Security testing, for the most part, can not be automated. Develop expertise in this area.
- Bring new ideas – Read testing blogs and books. Attend conferences. Tweak your processes. Pilot new ideas. Don’t be status quo.
- Consider Integration – Talk to the people who build the products that integrate with your product. Learn how to operate their product and perform integration tests that are otherwise being automated via mocks. You just can’t beat the real thing.
- Help your automation engineer – Tell them what you think needs to be automated. Don’t be narrow-minded in determining what to automate. Ask them which automation they are struggling to write or maintain, then offer to maintain it yourself, with manual testing.
- Get visible – Ring a bell when you find a bug. Give out candy when you don’t find a bug. Wear shirts with testing slogans, etc.
- Help code automation – You’re not a coder so don’t go building frameworks, designing automation patterns, or even independently designing new automated checks. Ask if there are straight forward automation patterns you can reuse with new scenarios. Ask for levels of abstraction that hide the complicated methods and let you focus on business inputs and observations. Here are other ways to get involved.
7 comments:
Subscribe to:
Post Comments (Atom)
RSS
Wow! What a great list, Eric. I would add getting involved in the User Acceptance Testing process. A testers knowledge of a product under test can help in creating testing documentation used during UAT. Also, by managing a product through UAT a tester can confidentially report a product as ready for release.
Thanks for the great addition, Patrick! Totally agree.
Something in this post just ticks me off, and it's not the part that calls the automated scenarios "superficial" (because I can tell myself "this does not happen to *me*").
What bothers me is that the post seems to throw the non-coding tester into competition with automated scenarios, instead of with automation engineers. Advice like "volunteer to stay late" or "help code automation" are not stressing the value of the the non-coding tester, instead they are implying "Work harder to compensate for your deficiency", and "ring a bell whenever you find a bug" is not what I would call a professional behavior (to say the least). While a tester that can't code has a clear disadvantage when compared to a tester that can (same as a tester that can't do usability testing has a clear disadvantage compared to one that can), this is not the case when compared to "automation engineer", who is not a tester.
When comparing a tester with a non-tester, there is so much more that can raise the value of the non-coding tester: Familiarity with the product or an eye trained to look for problems. There are skills that can be acquired and raise the value of the non coding tester such as domain knowledge, and mediating between groups (More on that aspect in a blog post I really like by Brendan Connoly http://www.brendanconnolly.net/testers-translators/ ).
That being said, there are some advice I really liked such as "work for your stakeholders" (I know you wrote programmers, I just expanded it a bit), and those of "bring new ideas" or, to some extent, "show up at design meetings" (which is a bit extreme for my taste the way it is phrased, but I do value greatly being active at design meetings).
Dear Always fearful,
Thanks for your thoughtful comment. I agree, some of my suggestions are not that good. This was kind of like a brainstorm I decided to publish. Nevertheless, here are some clarifications, motivated by your candor:
I didn't say automated scenarios are superficial. I said most automation engineers are writing superficial automation. By that, I mean most automation engineers are writing full stack checks interfacing with their product's GUI. This type of automation looks great in demos to managers but rots over time and doesn't provide as much value as the stories people like to tell about it.
"Volunteer to stay late" does not mean work harder; note, I said take the time back. I'm speaking about the flexibility non-automated tests can often bring to the team. Non-automated tests can be performed on the fly with less consideration for design than automated checks. They can be thrown away for less cost. Testers who don't write code can leverage this skill and it often lends itself well to critical production patches or other timely test demands. I'm suggesting testers who don't code try to leverage said flexibility.
This is a great list! Along the lines of Being Visible, I'd add work to "de-criminalize" bugs. Work with the team so that when you do find bugs, it's something to be grateful for and resolved quickly (if warranted) rather than be shamed. Bugs are not bad, particularly when testers find them! I have run up against this several times, to the point of not even being able to use the word bug.
Here are some ideas I've used in past:
- Assist automation folks with creating/specifying test data
- Helping to determine best candidate paths/scenarios for automation
This reminds me of a blog post of mine about being a valuable member of your team:
https://testingfromthehip.wordpress.com/2016/01/08/am-i-really-a-valuable-member-of-my-team/
There are many ways you can make yourself indispensable to your teams.