diff --git a/README.md b/README.md
index a4afd3e..a40b2f8 100644
--- a/README.md
+++ b/README.md
@@ -43,7 +43,7 @@ Selectors are located in `cypress/selectors` folder [only difference from cypres
 ## :grey_question: Q&A
 1. Why keep selectors separately (not hard-coded to tests)
     - **tests are much more readable** - css selectors are by nature hard to read - even if we add data-test attributes. We might need 2nd child or want to verify that selector is a child for another element, like `.class2 > ul:nth-child(2)` (alternative `get().find()` or `get().parent()` is bad practice because of [this](https://docs.cypress.io/guides/core-concepts/retry-ability.html#Only-the-last-command-is-retried) )
-    - in large projects, we might need to re-use the same selectors. Example: in login test, we want to verify that login was successful and we check settings link in header. But the same settings link is also tested in header test.
+    - in large projects, we might need to re-use the same selectors. Example: in login test, we want to verify that login was successful and we check settings link in header. But the same settings link is also used in header test.
     - selector and test logic is separated - when selector is updated, we just need to update selector file and not tests
 2. Is it still E2E test if we use API to login in settings test?
      - since end result will be the same - it will catch exactly the same bugs as `full flow/user journey` E2E test would find, (we need to be careful not to leave 'gaps' tho), it is E2E - tests are just separated and independent with this approach, **test suite is E2E**, one test might not be.