From d3c5fb87feb5b36fc8a95e93fe0bf311d84bca36 Mon Sep 17 00:00:00 2001
From: Johnatan Kayevo <60711683+kayevo@users.noreply.github.com>
Date: Wed, 21 Aug 2024 21:50:06 +0100
Subject: [PATCH] refactor: add acceptance criteria validation in functionality
 test

The documentation talks that its hard to understand how some changes will impact a user just reading the code.
However, just the UI changes are mentioned. Actually, the acceptance criteria and business necessity also cannot be validated just by reading the code.

I wrote an article about it right here: https://www.linkedin.com/pulse/fac-review-strategy-johnatan-kayevo-obgof/
---
 review/reviewer/looking-for.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/review/reviewer/looking-for.md b/review/reviewer/looking-for.md
index c27e26ed..f6d20d61 100644
--- a/review/reviewer/looking-for.md
+++ b/review/reviewer/looking-for.md
@@ -26,10 +26,9 @@ thinking about edge cases, looking for concurrency problems, trying to think
 like a user, and making sure that there are no bugs that you see just by reading
 the code.
 
-You *can* validate the CL if you want—the time when it's most important for a
+You *can* validate the CL if you want to certify that the code matches the acceptance criteria and user necessities. The time when it's most important for a
 reviewer to check a CL's behavior is when it has a user-facing impact, such as a
-**UI change**. It's hard to understand how some changes will impact a user when
-you're just reading the code. For changes like that, you can have the developer
+**UI change**. It's hard to understand how some changes will impact a user or if the technical solution fulfills all the business necessities when you're just reading the code. For changes like that, you can have the developer
 give you a demo of the functionality if it's too inconvenient to patch in the CL
 and try it yourself.