From Software Development to QA: Daniel Paiva shares his experience

Daniel Paiva, who’s part of Exaud’s Quality Assurance Team, shares his experience on moving from Software Development to Quality Assurance and some insights on what is a typical work week.

Last year I shifted my professional career. I was working as a Software Developer at Exaud, and an opportunity came up to start working as a Quality Assurance Engineer. At the time, I was not happy with my work as Developer, and I was always intrigued by what the job as QA Engineer would entail. To me, it was a “no brainer” and as it turns out, the job “entails” everything I love about working in IT and (almost) none of the parts I enjoy less.

After nearly one year working as a QA Engineer, mainly focused on functional testing, I believe I’m able to provide some insights to anyone intrigued about this “turn” as much as I was before I took it, and hopefully help you figure out the answer to the question: “Should I change from Developer to QA?”.

This is based on my personal experience, a lot of these things will vary from person to person, project to project… you should not take this text as gospel, but I do hope it enlightens you if you are considering a similar change in your career.

How My Work Week Usually Goes

Currently, I am doing manual testing – which means I do not write or look at any code (that honor belongs to QAs that work with Automated Tests). I have to be hands-on with the app for any behavior that I need to test. When there is a new build, the first thing to do is run the Smoke Tests which are a short list of Test Cases that should not take long to execute and should be enough to provide the team with quick feedback on the most essential behaviors. The goal is to make sure that nothing major is broken and, if so, to catch it as soon as possible. I also use this test phase to record videos of the app running (God Bless OBS) – this helps me to get a general idea of any behaviour that I will need to test later and it allows to easily get evidence for the QA Review phase, which comes later.

Regression Tests

Regression Tests are, usually, the next step. They are also a list of Test Cases (“TC”), but they go much deeper. While Smoke Tests will have, for example, a TC to test if “Login” is possible, a Regression Test will have a TC for every button and text on screen. The goal is to make sure that all features (literally, all) are working as expected and were not broken by any new additions. If any of them is not working correctly, I have to create a Ticket that explains how this TC failed and how it is expected to work.

Reporting a Bug

Reporting a bug, or creating a Ticket, is the part that I find the most essential to the good flow of the development process. It is up to the developer, with our help, to figure out “Why” a bug is happening, but it is up to whomever is reporting the issue to point out exactly “How” this bug is happening – what steps should I perform for the bug to occur? If the Internet was off when the issue was reproduced, was that part of what caused it or was it a coincidence? Investigate and report – and describe “What” the bug is – this is never as clear as you think and it needs to be written down clearly.

All of this information must be concise, more than everything, it is important to make it clear to the developer what is “currently” happening and what “should” happen but the ticket should not be written like an essay either. Short and precise, this is how the structure usually looks like this:

“Steps” – how to make it happen

“Actual result” – what happens

“Expected result” – what should happen

This is usually enough, but never underestimate the power of a screenshot with a well-placed red circle or a video with a good description.

“In QA” Phase

Lastly, I need to go through everything the team worked on during the latest sprint and review it. Any new feature or bug fix should go through a “In QA” phase. During this stage I have to read the ticket description and make sure that everything that was asked was implemented correctly, that the feature works, that it doesn’t break anything outside of its scope and that is unbreakable – this is impossible, you have to rely on your creativity to be as thorough as possible, but there will always be a way to break it. The client finds a way.

If the ticket is well written, it will be clear to you what to look for exactly, but it is not always the case. When that happens, it is good to not be afraid to talk directly to the team. At the end of the day, communication is the best asset in the QA’s arsenal, whether it is to clarify a ticket description or to get more info on what is happening “behind the scenes”. No one knows the insides of the app better than the development team, so you should always take their input seriously.

Final Thoughts

Before I did this career change, I had some doubts but now, a year onward, I believe I made the right choice. My years as a developer were not wasted, they gave me a deep understanding of how software development works and I would never be the QA Engineer I am today without them (also some of my code is still holding some app together out there and I think I can be proud of that).

The job demands patience, communication skills and awareness, and I enjoy using and developing those skills every day. So, there you go, the short of what my daily life is, currently. I hope this “insider information” is useful for your career path and, whatever your decision is, I hope you make the right choice.[/[/[/