Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Five reasons your software testing career is harder than necessary

No job is perfect, but software testers do have a few things to complain about. Expert Amy Reichert shares the five things that make her want to polish her résumé.

A software testing career is a good choice; the pay is higher than average, and it can serve as valuable experience...

that's useful for those wanting to move into product management, development or continue in quality assurance. I love testing software because I enjoy learning often complex technology under pressure and racing to find issues before customers do.

However, there are several elements of software testing that I find annoying and nonproductive to the point that I start scanning job boards or tuning up my résumé. Here are the top five most frustrating elements of a software testing career -- in my experience -- along with tips on how to mitigate their effect on your job satisfaction.

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 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.

Top five software tester stresses

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.

Next Steps

Now more than ever, lean into your testing career

Make sure you're ready for the next big thing in testing

Do you know where testing is headed next?

This was last published in April 2017

Dig Deeper on Software Testing Methodologies

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are the most annoying things about your testing job?
Cancel
How can it be an Agile process without automated tests? Or even Requirements as Tests?
Cancel

I personally can’t understand why people with useful experience on testing would migrate to product management, or even development, when real testing experience is offering you a better visibility over the technology, processes and especially the product itself.

Even within an agile methodology or not, all team members should be involved into the team’s activity and all need to contribute to avoid the nontestable acceptance criteria. Ofcourse there might be times when there is not enough information, but this should be fine since all people share the same information and all put effort to make it work. The team should have a common understanding over the project, tasks and acceptance criteria and all the members should be made accountable to improve any of these. 

A better way to deal with the compressed testing cycles is to realize the new role of a Test Engineer; the one of evangelizing testing to the development team and helping them realize that testing is a team activity. This way you add more prevention to the actual testing process. Plus, those teams doing fairly heavy regression testing, have they found that the team has just accepted the risk of regressions rather than continually looking to address the root cause of why they are having regressions in the first place?

Dealing with the bugs in a way that can make a difference between the effects and the root cause of the problem might help; a zero bugs approach (close to zero, as zero would not be healthy for a development process), might help understand the quality we produce and take some actions to look into some root cause of the problems (I would make a difference between addressing the effects of the problems - fixing the bugs; and the problem itself - what generates those bugs).

Sometimes might help working with the chaos and prefer simplifying instead of overorganizing; testing should help simplify the processes (prefer collaboration over the code and tests to the one on GUI tools). 

Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close