Тестирование.com Part 2

Продолжаю цитировать книгу Романа Савина Тестирование.com.


8. Тестировать пограничные значения. АП - Думаю все знакомые с тестированием хорошо представляют о чём идёт речь. Но я всё же расшифрую. Мы имеем какое либо поле, которое поддерживает значения от 1 до 99. Соответсвенно, чтобы хорошенько проверить это нужно ввести следующие значения: 0,1, 50,99,100,-1
-1,0 и 100 не должны приниматься системой, как выходящие за рамки требований.


9. Тестирование процесс творческий. АП - Баги находят не тесты, а люди. Значит проверять можно не просто напрямую по тесту, но и всё что хочется рядом. Да и вообще, если потянуло что-то проверить, не стоит себя ограничивать. Но при этом надо себе помечать шаги, чтобы сразу можно было бы проверить воспроизводимость баги и радостно отрапортавать в виде баг-репорта.


10. MRD (marketing requirements document) АП- я это пометил, тк для самого стало сюрпризом, что основа требований для разработчиков и тестеров является документ от маркетинга. В своей практике я пока такого не встречал. В моём текущем проекте требования пишет разработчик уже после создания программы и то только потому, что мне нужно писать тесты по требованиям. :)


11. Спецификации должны иметь уникальный ID. AП - Я конечно это знал давно, но просто отметил для себя, это действительно важный момент. Если спек поменяют и удалят требование, а на его место поставят другое, то сложно будет для тестеров понять. Почему в тесте ссылка на спек, который описывает совсем другую функциональность.


12. Излишняя детализация тестов усложняет поддержку, а излишнее абстрагирование ведёт к непониманию. АП - Часто вопрос выбора стратегии написания тестов, вопрос времени, денег и ресурсов. При наличии всего в достатке, можно писать очень подробные тесты. А при отсутствии оного, просто следовать в тестировании некому чек-листу, списку наиболее важных моментов для тестирования. Я сам на данный момент нахожусь в промежуточной ситуации, поэтому тесты пишу, но без лишних подробностей.


13. Шаги и настройки повторяющихся сценариев можно вынести в отдельный документ.
АП - Чувствую, что очень полезная вещь. Но пока в практике у меня не было такого, попробую в текущем проекте.


14. Два и более ожидаемых результата в тесте - нормальная практика. АП- При написании тестов я часто пользуюсь таким приёмом, это сокращает время на создание теста. Но начинающим тестерам, это не всегда понятно, почему тут сразу несколько результатов.


To be concluded