Becoming a better QA in 2018!
A new year usually means a new start, a new chance to do something different. Really 2018 is just another year, just another number, just another 365 chances to become a better version of you and learn something new. And everyone loves becoming better at something.
Below is a list of a few suggestions that a QA can advance themselves in 2018. There’s only 9 ideas on the list, so it’s pretty small, but I hope it will get you thinking about goals for yourself.
1. Try to get more involved in testing that isn’t manual. It could just be writing a some short scripting or a few lines of code that help you through a laborious manual task. You need to compare a 100,000 entry database table with another 100,000 word document given to you by a PO, to find if the document entries match or don’t match and which entries do not match and what each non-matching entry is. You could learn to write a Python script in the time it takes to manually go through that document line by line. You may think it seems challenging and probably not something you can do and probably a waste or your time…..but it’s not something that you can’t try. And if you value being better at something then why would it be a waste of your time to learn this new skill? Do you not like being better at something?
Also bear in mind that your efforts don’t have to be beautiful, you don’t need to write efficient, double-spaced code, you just need to show your creativity and problem solving skills. Do this enough and your colleagues will be impressed.
Another idea is that you could make your testing less manual too, like learning to use dev tools that come with a browser, or writing small Powershell/Bash scripts/cron jobs, whatever, to do those menial testing tasks that you hate.
2. A bigger task this one but it sort of fits with the first idea: learn a programming language. Take this further by learning to read and write code fluently. It doesn’t have to be a programming language, it could just be something new. You could raise a few bugs with the design of something. They turn out to be bugs in the UX. So maybe you could get more involved in how the UX team solve and fix these bugs. Maybe they might involve front-end developers who are using React JS and you realise you know nothing about React JS.
3. The fact is that it’s 2018 and that like it or not, automation means less people to do a job. Examples are DevOps and Testers. I’m not saying that automated testing will completely overtake manual testing — far from it. The human element will be vitally important if human’s are making software for other humans to use. But a willingness to learn new skills is going to be important. To survive as a QA you will need to have manual testing skills as well as automated testing knowledge. It’s time to get skillz or or get out, and do your best to survive the change with an open mind.
4. As software creation and delivery become more complex, it is increasingly necessary to work in larger teams. Teams won’t necessarily become larger with more QAs doing the same job as oyu, but you’ll be working with a larger, more diverse group of people, from Developers to Sales to Business Development to DevOps.
2018 will involve more team playing and less more solo testing.
5. A new year is all about trying something new. As a Tester you can embrace this by getting more involved into how and why the product you’re testing does what it does. You don’t know why you need to use a VPN to access a certain test server, or why a certain HTTP Response Code was chosen over another — it’s time to find out why.
6. There is no such thing as a Perfect Test Case. Practice writing better test cases. You could emphasise objectives and outcomes rather than just the boring test steps.
In addition to this, there is the myth of the Perfect Bug Report — a classic QA interview question. It’s good to have steps, expected behaviour, actual behaviour…and that’s really it. Add anything that you think will be helpful in proving the bug exists, make sure to label screenshots appropriately, you just don’t need to add to much irrelevant information.
7. Gathering metrics, making them pretty and displaying them on dashboards are jobs that aren’t really for a QA. However, if one of your specific job requirements is that you gather and display metrics, then you should still do this.
For many QAs this job of gathering metrics is for POs, BAs, Product Managers. Spend your time as a QA doing what you do best; finding and documenting bugs. You should spend more effort into thinking how a product could be tested in a better way or if requirements, acceptance criteria or user stories are good enough.
You can of course document your own metrics and learnings — stuff that is important to you, things that you could turn into a shared-document or into a test case. In fact, I recommend doing this. It is important to show something has been tested and that each test case has its own test result. But sometimes that is not possible.
8. If you’re already an automation tester, think more about how you can improve your automation scripts. Are you testing the right things? Are your scripts smart automation, or are you just delivering more automation? Having an Automation Strategy is helpful too. What do you plan to test, what don’t you plan to test. Blockers, potential blockers.
If you’re not an automation tester, maybe you have ideas about how something that you’re working on could benefit from automation testing, or maybe a suggestion for an automation script. It’s great to bear in mind that
9. This ties into the previous idea, your automation scripts should actually be testing something, not just a manually executable test. Pick the tools and frameworks that fit best with your strategy — there is no perfect solution for everyone.
The above are just ideas and things that I see as important for a SQA in 2018 to be aware of. They are actually transferrable skills that a tester in 2010 or 2022 should be aware of. Now, 1 month of 2018 has already passed, what are you waiting for?!