Five reasons your software testing career is harder than necessary

Software testing career issue No. 1: Nontestable acceptance criteria, requirements

Agile methodology or not, there is simply no excuse for nonexistent acceptance criteria or requirement information. I cannot tell you how many times I've seen a completely blank user story with a one-line description. The one-line description is five or fewer words describing a random design thought that may, or may not, be related to the desired code outcome. I wonder why this type of software has defects?

Yes, it drives you crazy, and it's not part of any useful software development process to attempt to test stories with this type of detail. However, for your own job satisfaction, think of it as an opportunity to derive functional requirements from your team members. I first discuss what the developer coded with this information, and I get the expected functionality from their point of view. I jot down a rough functional outline and then meet up with the product manager responsible for the story. Based on our conversation, I create my tests.

Now, more often than not, there are contradictions in what the product manager wants and what the developer understood. When that happens, I schedule a meeting with the both of them and walk them through my outline of how I expect the feature to function.

Typically, from that meeting, the developer has fixes to make and, as a team, we have at least the outline of how the feature or the story functions. I update my outline and then create my test cases. In this way, I attempt to find any defects in understanding first before writing my test cases or testing. I can continue with my work knowing we all have the same understanding.

Software testing career issue No. 2: Continuously compressed testing cycles

I've never understood why project managers ask for testing estimates when we all know there won't be enough time granted for testing. I provide an accurate estimate because it fulfills my job responsibilities. But, frequently, it's a futile activity. Regardless of my estimate, testing time is whatever time is left before the release. Granted, I do my best to test as many pieces of the application as I can, including regression testing.

However, as a software tester I cannot really conduct full system testing unless all the pieces are in the release. If two or three stories are still outstanding in development, my regression testing is close to useless. I don't believe it's a complete waste of time, but it certainly isn't complete.

Leaving system, regression and integration testing to the bitter end of the development cycle creates defects quality assurance (QA) won't see. Unfortunately, this tendency has only increased with continuous integration and continuous deployment. Agile methodologies contribute to the hustle at the end, regardless of how well the process is adopted. The fact is, all the difficult and complex changes take longer, but are actually likely to receive less testing overall.

In order to ease my frustration, I simply do the best I can with what I have. In other words, I run my functional, integration and regression tests continuously.  When I'm done testing a story, I start over running the test suite for the release.  If I keep running my test suite continuously, I can catch any late incoming defects from those last-minute, critical stories or defect fixes.

Software testing career issue No. 3: Defects lost in space

Defects entered with full descriptions, video attachments and can be reproduced each and every time often get ignored and sit in defect backlogs for years. What is the purpose of entering defects for the sake of storing them? I've never worked anywhere where we released defect information to customers, let alone anyone else. Yet, we store them and continue to add to them.

I don't like to do work that isn't appreciated or isn't at least reviewed and discussed. I don't mind if my defects are closed, but I'd rather not have them out in the backlog for years on end. It's cleaner to close them. I can always reopen one using most defect tracking tools. Keep the backlog clean.

It's an annoyance to have your work taken for granted. However, as a QA, it's my job to report defects with as much detail as possible. I bring them up for discussion and review, and I keep a note of those that I believe customers will enter if they aren't fixed. I keep track in case someone claims QA is missing problems. I'll admit when I miss something, but don't complain about QA if the defect is in the backlog and has been ignored.

Software testing career issue No. 4: Prioritization chaos

QA priorities often change daily -- or even three or more times daily. It takes an enormous amount of time away from actual testing activity to keep track of priorities that change this frequently. Sometimes, you spend more time making sure you're working on the highest-priority item than actually testing it. 

Even daily standups don't necessarily help, because the priority change happens later in the day after the QA has already invested time in testing the first story when now the second story is the higher priority.

Unless it's an absolute crisis, I'd finish testing the first story if I'm already half or more of the way through the testing. Then, I'll switch gears and test the second. Otherwise, I continuously lose productive testing time switching gears, and that time is never regained.

Regardless of the chaos or disorganization that is the software testing development business you're in, stay focused and organized to the best of your ability. Try to focus on the testing you're currently involved in whenever possible. If you have to switch gears, do so and focus on testing the latest priority until it's completed.

Software testing career issue No. 5: Disorganized QA process, procedures

Simple organizational principles are lacking in many software application businesses. Application tools help, but they aren't a substitute for organization. One step you can take as a QA is to instill an organized, simple, step-by-step process or procedure document. It can be in any form that fits your needs, whether that's a document, spreadsheet, mind map or project plan. The type you use depends on your preference, and each can be done electronically or directly on paper.

Start by jotting down the processes you take when testing. Use it and share it with others who are interested. Keep it updated with any new processes that may come along. If another team member comes up with a more productive method, try it out and then add it to the QA document. If possible, have a QA meeting to review it and get input from other team members.

The important part is not that everyone does exactly the same thing, in the same order, at the same time, but that there is a standard. Having a standard helps communicate QA tasks to other teams and management. It means you know your tasks and how to get to the end result. It also serves as a reference or guide for new hires, or when questions come up about the QA process.

It'll change time to time, but having a known set of QA standards helps to keep chaos at bay and QA testing on track.