A day in the life of a Quality Assurance Engineer isn’t really all too different from that of the software developers. Every company you might work for has its own style. Some might have an independent quality assurance team, almost acting as external consultants to the development teams. Some might have only one or two people doing quality assurance in the whole company. The best have quality assurance personnel embedded with each and every development team.
In my company, we are getting more agile. Like most iterative firms, we get together every morning for scrum meeting, aka stand-up, aka anything you want to call the morning meeting. This is the forum for everyone to report on what they have been doing, what the plan is for the day, and if we have run into any problems. Likewise, if anyone else has questions about any of the work, this is a great place to bring them up! If any discussions looks to take more than a minute or two, we’ll save them for later so everyone can finish their status report and move on to get back to building stuff.
The rest of the day could can depending on where we are in the sprint. Working with the Business Analyst, I can clarify the requirements and acceptance criteria for each story or task the developers have to work on. Developers are excellent resources to make sure that I understand how we’re hitting the mark. These discussions can clear up any missed requirements or misunderstandings early on, saving lots of effort.
With my new understanding I’ll create or update test cases. We’re building out an automation framework, so odds are good the test will be manual first, and join the backlog waiting for transition into automation. Then, as you might guess, I spend my time running manual tests, or best of all, continuing to flesh out our automation and transition our manual tests (in priority order) into automated tests. Sometimes the tests will fail, and I’ll need to talk to the task’s developer about where the problem is, or if the failure is around something different, I’ll open a new issue to bring into our workload.
I’ll see where I am in regards to the goals I’ve set for quality improvement, whether they be increasing the percentage of tests I’ve automated, or reducing the number of bugs that escape my hands and reach the customer.
Sprinkled throughout, I might have one-on-one meetings with my director, or with the other engineers who report to me. Sometimes, I’ll be more directly involved with a software pilot, and will have status calls with our customers to make sure that we’re on the same page and making them the best product we can.
I went to school to be a software developer before I found QA. I love QA and it’s nice to scratch the coding itch by writing test scripts.
I work with a bunch of like minded geeks, from a number of departments across the company. Come lunch time, we usually get together and relax our brains over food and a board game. There’s a surprising number of games you can get in under an hour, especially when you’re all at least somewhat technically minded.
There is nothing more fulfilling in my work than releasing a product into the wild and seeing it flourish. It’s a great field to be in. No matter what product you’re working on, you are making people’s lives better by reducing the problems they have to deal with in their day. Depending on the product, you could very well be saving lives by finding problems and preventing them from ever reaching production. It’s a great industry to be working in, and a challenging and enjoyable role to fill.
If this sounds like a career you’d enjoy or you want to know more about qa testing careers, I would encourage you to check out DevMountain’s Software QA Testing course. It’s a great way to launch a career in this field!