> For the complete documentation index, see [llms.txt](https://ultimatewebsolutions.gitbook.io/qa-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ultimatewebsolutions.gitbook.io/qa-knowledge-base/qa-and-a-developer-have-different-standpoint.md).

# QA and a developer have different standpoint

The key is to show that you don't make it personal—you use **evidence and requirements**.

Be polite!

#### Good approach

1. **Check the requirement / acceptance criteria**
   * What was actually expected?
   * Is the behavior documented?
2. **Reproduce the issue**
   * Make sure you can reproduce it consistently.
   * Provide clear steps.
3. **Provide evidence**
   * Screenshots/video
   * Logs
   * API request/response
   * Environment and browser/device
   * Test data
4. **Discuss it with the developer**
   * Explain your perspective.
   * Listen to the developer's technical explanation.
   * Sometimes the "bug" is actually a misunderstanding of the requirement.
5. **Involve the Product Owner / Business Analyst if necessary**
   * If the requirement is ambiguous, the **business expectation** should decide what the correct behavior is.
6. **Document the decision**
   * Update the bug/requirement so the same disagreement doesn't happen again.

#### Example

You report:

> **Expected:** User should be redirected to the dashboard after login.\
> **Actual:** User remains on the login page.

Developer says:

> "That's not a bug. The API returns a successful response."

You shouldn't simply argue.

You could say:

> "I understand that the API returns 200 OK. However, according to the acceptance criteria, successful login should redirect the user to the dashboard. Let's check the requirement together."

If the requirement is unclear:

> "Let's involve the Product Owner to clarify the expected behavior."