How to Get Practical Details from PMs to Reduce Defects & Missing Requirements

Amyreichert - Nov 23 '22 - - Dev Community

As a QA tester, you often find yourself with a set of user stories or requirements that are incomplete, or lacking sufficient user scenario details. What to do? The first logical step is to meet with or discuss the missing details with the product manager. Often the QA tester experiences pushback from the Product Manager saying the stories or requirements detail the business objective and not the specific use case scenarios.

Product managers are responsible for producing a quality product that works for customers. However, it often seems that customer supporting details or use case scenarios are extremely basic and frequently missing essential customer use case scenarios. Why are missing use case scenarios important? The most important reason is meeting customer expectations or the application providing a quality user experience. The next reason is missing use case scenario details result in defects, coding re-work or re-design, and release delays.

QA testers must get creative to discover the missing requirements while coding is still in progress. What are the options?

Gaps in requirements come from various places. The Product Manager (PM) may misunderstand the customer’s needs or fail to communicate the functionality effectively. The PM may not understand the inner workings of the application and not realize the impact of not supplying full user scenario details to code design, development, or testing.

Missing details results in developers and designers making assumptions on user functionality. Assumptions create defects or the need to re-code the feature. Re-work limits the team’s ability to release quality code to customers on time and meeting the customer’s expectations.

Key Takeaways:

  • Why are missing requirements or lack of user scenario details a problem?

  • Learn the importance of analyzing requirements or user stories for accuracy and completeness.

  • Discover steps for analyzing product manager documentation to determine the missing customer use case scenarios.

  • How can QA Testers fill in the missing customer use scenarios to reduce defects in the final product?

  • What is mind mapping and how does it benefit finding missing customer use details?

A comprehensive User Acceptance Testing (UAT) tutorial that covers what User Acceptance Testing is, its importance, benefits, and how to perform it with real-time examples.

What Problems do Missing Requirements or Missing Product Details cause?

Defects, additional stories, re-work, chaos, and frustration for the software development team are caused by missing user story details. For the business, missing details results in lost revenue from unsatisfied customers and a reputation for not meeting expectations. Customer use case scenarios are critical for getting the design, coding, and testing of the application correct.

Other problems caused by missing requirements or use case scenarios include:

  • Incorrect design and coding of features or defects

  • Missing support code for dependencies

  • Inaccurate test case development

  • Increased tech debt over time

  • User experience failures in production

Test website on different browsers on a cloud platform. Get instant access of Browsers like Chrome, Safari, Firefox, Opera, Yandex, Brave, 3000+ desktop & mobile environments. Try for free!

Why are Customer Use Scenario Details Important for QA Testing & Application Quality?

When details are not provided for all expected user scenarios, then developers and testers make assumptions on how the end user experiences the application. In other words, where details don’t exist, they’ll get created on the fly during code development. Developers must get coding done and will fill in any missing details with assumptions based on their understanding of the application and how it may be used by customers.

Developers and testers may individually or in combination analyze the story, define what’s missing, attempt to get further details and then continue to meet work deadlines. If their analysis is incorrect or the customer use scenarios inaccurate, then the resulting code and tests are also inaccurate. When Product Management performs UAT testing then defects may get entered for the misunderstanding of the user scenarios or customers receive the release and report defects and poor user experience.

Applications with poor user experience levels aren’t successful and reduce the brand’s value as well as business revenue.

How to Analyze User Stories & Requirements to Prevent Defects

If the Product Manager isn’t supplying details on user scenarios, then testers have several options:

  • Make them up on your own based on how the developer codes the features or discuss with the developer.

  • Create a prototype based on the information provided and then analyze and determine where there’s gaps, probable defects, or missed coding needs.

  • Use the mind mapping technique to flush out possible user scenarios.

  • Discussions with the software development team

Start with your own analysis first, be it using mind mapping or creating a prototype.

Mind mapping provides a visual method of brainstorming, problem solving, and evaluating software application workflows. Mind map diagrams allow testers to expand expected testing scenario paths and discover missing customer use case scenarios. By mapping out all customer workflows the testers create a visual map of user functionality and where options exist that aren’t covered by the user story or provided requirements.

Mind mapping is an effective method for analyzing user stories or requirements and finding defects or missing code especially with integrated dependencies and backend communication.

If mind mapping is too informal, try creating a prototype of the software application feature based on the supplied use case scenarios. Testers can draw up a wireframe prototype or use a tool to create a functional prototype that mimics the expected functionality.

Test through the prototype and document any gaps or missing features. For example, do the details in the story account for dependencies on data or data transfer? What about API integration or integration requirements with existing third-party applications?

Once you’ve done the analysis and documented any gaps or defects then schedule a meeting or discussion with the Product Manager and developers working on the story. During the meeting, resolve any missing requirements and misunderstandings with the user scenarios if possible. If missing requirements are not addressed, then enter defects for review and resolution. The most important factors is ensuring the quality of the application release and providing a positive customer experience.

The impact of defects from missing requirements or user scenario details affects the entire team, the application, the business, and the customer. As a QA it’s not technically your responsibility to fill in the missing details for the Product Manager. However, think of it as looking both ways before you cross the street. Yes, it’s the bus’s duty to stop, but you’re the one getting hit if it doesn’t.

Avoid the bus by using QA analysis skills to flush out missing requirements and gaps in customer use case scenarios. Use mind mapping or prototyping combined with active discussions with the team to avoid defects caused by missing customer scenario details.

A comprehensive Exploratory Testing tutorial that covers what Exploratory Testing is, its importance, benefits, and how to perform it with real-time examples

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .