1. Тест кейс соответствует минимальному requirement (not a feature)
2. Fail/Pass только в одном месте
3. Step-by-step - исполняет тест кейс
4. Для автора - тест кейс есть ситуация (с инструкцией как туда попасть), которую он создает
5. Можно автоматизировать - абсолютно конкретен
6. Исполнение НЕ ЗАВИСИТ от интерпретации исполнителя
7. Фишки тест кейса
	- requirement
	- the AUT (application under test) MUST be in testable condition to be tested (build acceptance)
	- pre-conditions (Login/Password - account exists)
	- test data (mikhail123/portnov345, invalid psw = portnow345)
8. Структура
	- ID
	- Title/Description/Purpose/(requirement)
	- Instruction (default base state -> verifiable application state)
	- Expected Result (не должен пересекаться с Title, должен его дополнять)
	* Actual Result
	* Pass/Fail
9. Как писать тест кейсы...
	- happy path - это самый первый тест кейс из группы
	- несколько happy path тест кейсов
	- Prioritizing: Each Next test case - спрашиваете себя "если я могу выполнить ЕЩЕ только ОДИН тест кейс - какой из всех оставшихся для меня самый главный" 






===============================НИКОГДА===============================
- test scenario (только в контексте)
- test script (автоматизация???)
- checking (test, verify, validate, make sure)