When I first started at Tiny, I joined as a QA Intern. The job description implied that it would mostly be manual testing - following test case steps for hours on end, just clicking buttons and typing things in. Most of my friends said it would be boring and not at all educational for my degree in software engineering, and that I shouldn’t apply. But I knew of TinyMCE and was interested in working on it, even as part of QA, so I applied. And I don’t regret it at all.
Apart from the fact that my QA role didn’t end up just being manual testing all day every day, I found that I did learn quite a bit from doing manual testing. I learned about TinyMCE at a high level, including what all the parts of it were and how they fit together. I learned how customers tend to use TinyMCE and the kinds of crazy things users try. And it gave me an opportunity to practice my critical thinking and creative analysis skills in a slightly less stressful environment than actual software development.
So, where some people might say that doing QA - especially manual testing - is a boring task, I believe it can be very helpful. It just depends on how you approach it.
Whether you are looking for ways to improve your current career prospects as a developer, starting a career as a programmer in software development, or thinking of switching from QA to development, here are 4 developer skills you can learn from doing QA, based on my own experience.
1. Critical thinking
Critical thinking is a crucial skill for software developers. Being able to observe, analyze, and evaluate something then make a good decision on what to do next is a core part of our job. This applies whether we’re identifying and fixing bugs, implementing a new feature based on some specification, or even choosing between two or more technologies.
This is also a crucial skill for QA. When you’re trying to find bugs in a feature, you have to think about it in a similar way to how the developers would when implementing it, especially if they’ve followed test-driven development. You read the specification or documentation for a feature and try to think of all the ways it should and shouldn’t work, then create test cases based around your understanding.
So if you, as a developer, find yourself doing QA, take the opportunity to practice your critical thinking. If you’re writing test cases – great! – you’ll already be critically analyzing the feature or product. But even if you’re just following test steps, don’t let it become a mindless activity. As you’re testing features, keep in mind what you know about them and which parts the test cases are, or are not, testing. Some of the worst bugs I’ve found came from trying something that wasn’t even in a test case, and as a developer you might have a unique insight into the project that could help you find such things.
2. Creative analysis (or thinking outside the box)
Users will always do weird, unexpected things with your software. Therefore, unfortunately, thinking of and testing for every single use case is almost always impossible. However, that doesn’t mean we shouldn’t try to cover as many as is sensible.
I believe that doing QA well isn’t just about testing what the specification for a feature or product says it will do, but also the things it doesn’t say. What combinations of this feature and another feature might break one or both of them? What configuration settings might cause functionality clashes? What odd actions can users do that the developers might not have accounted for?
Finding and internally reporting these kinds of weird bugs is good for preventing support tickets. But it’s even better, as a developer, to be able to think of such things during or even before development, and implement the feature or fix to deal with them from the beginning. This saves both engineering and QA a lot of time; and fewer bugs in a release makes life easier for everyone.
There is another benefit though, outside of just heading off weird bugs earlier in the development cycle - being able to anticipate problems during planning, even extremely early planning, and make decisions about potential approaches or feature viability before development starts. For example, maybe someone has proposed a new feature that sounds great by itself, but when you consider it as part of the greater product, you realize it will clash with another existing feature. Or maybe it does something similar to another existing feature, but the proposed approach would make the UX very different.
The more awareness you have of your immediate and surrounding environments, and sometimes seemingly unrelated environments, the more creative you can be when looking for a solution to a problem. This isn’t just useful to developers either - if you’re looking to move into a leadership or management role, improving your creative analysis skill could be a great career move.
3. High-level product understanding
I’m a big-picture kind of person - I like knowing what all the parts of something are and how they fit together. But when I’m working on a ticket, sometimes I find myself focusing too much on whatever piece of code I’m working on, and not thinking about it within the context of the broader product, especially if it is very technically complex.
In comparison, the QA team usually needs a higher-level understanding of a product. They don’t need to worry about details hidden down in the guts of the code. But they do need to be familiar with the components, how they fit together, and, most importantly, how they interact with each other, because that is often where you find bugs. They also need to understand how users will interact with the product and what a typical workflow looks like, and that usually requires understanding more than just one part of the product.
Understanding a product like this gives you a broader context for the tasks you work on, helping you to find and deal with interactions between different parts of the code. It can help you ensure that similar functionality across different parts of the product is consistent for users. It can help you know if a bug you’re fixing in one part of the code might affect another part. And it might help you learn about how the product works in a different environment to what you usually use for development, like on a different browser or operating system.
Maybe you already have this kind of knowledge from using the product you work on on a regular basis. Or maybe the product is small enough that understanding it in its entirety is quite easy. But if not, I can recommend helping QA out with a test run or two. You can learn a lot from having to test a product - or even a section of a product - in that kind of structured manner.
4. Empathy for customers
I believe that QA should write test cases based not only on specifications, but also on use cases and user workflows. After all, QA is about ensuring quality for users, and that means needing to know how users will actually use the product. It’s important to not only test features in isolation, but as part of the greater product and in a way that reflects how a user would normally interact with the feature.
Developers need to keep users in mind too if they want to create something great that solves problems (and doesn’t create them) and makes users happy. Of course, you can also get feedback from users via user testing and research, but not all companies do this. And reading reports on how users interacted with the product - while very useful - isn’t quite the same as playing with the product yourself. Spending time using the product gives you a practical, not just theoretical, understanding of its features and flaws. It can also highlight issues that theoretically have a small impact on users but in practice might affect users more often than expected and are therefore quite annoying. And doing this as part of a QA test run can be better than just trying to poke around the product, because the structure of a test run ensures you consider the product from a holistic perspective.
Final thoughts
Next time an opportunity comes up to do QA, whether as a job, or to help out your colleagues, give it serious consideration. And if you do find yourself doing QA, don’t take the easy route of simply following the test steps laid out for you. Use it as an opportunity to practice thinking critically and creatively about what you’re testing, to see if you can think of any other cases that might expose bugs. Also, take the chance to learn about the product, especially any parts you don’t usually work on, and to learn about how customers would usually interact with it.
Doing QA, and working on these four essential skills, can set you up for more success as a developer and open up new and exciting opportunities...and, it can be really enjoyable, contrary to what some people believe.
