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

Source: Click Here

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.

Read More : Click Here