Exaud Blog
Blog
From Software Development to QA: Daniel Paiva shares his experience
Daniel Paiva shares his experience of moving from Software Development to Quality Assurance. Posted onby Daniel Paiva
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.[/[/[/