The first step which underpins the entire testing process is the definition of Acceptance Criteria (AC) that establish the correct operation and completion of the product.
More specifically, the AC is a set of instructions, which specify the functional requirements and not the product, defining the concept of quality of the same. The AC constitute our “Definition of Done” relative to an Epic, Feature and Story.
The definition of the AC allows the team to figure out when it’s done and not to forget important borderline.
AC are produced through collaboration between developers, testers and product owner and are created before the development, during the planning phase.
AC are expressed at high levels (conceptual, not detailed) and then in the form that works best for the team (keep it minimal).
During the Kick off QA and developer in a session of 10-15 minutes should achieve the Acceptance Test (AT) in order to define the behavior of the system and ensure the realization of the product as expected.
QA and developers agree, also, the tests to implement, sometimes also including the product owner and the other stackeholder.
The implementation of the test takes place during development (ideally test-first).
It is considered appropriate to build a Map of Acceptance Test automatic and / or manual to improve the process of testing and development. They will be designed at the level of Unit Testing, Integration Testing, End to End Test, UI Test and Boundary Test.
A basic rule during the writing test, especially when we talk about Unit Test, often difficult to understand, is to assign a meaningful name so that the QA and the developer can then maintain them. So once defined the test or set of tests anyone can test the story, feature or epic.