Допустим, вы пришли на собеседование и я предложила вам протестировать… ключ. Требования? Нет требований, просто скоро вам дадут ключ, а пока нужно подготовить тесты. Что будете делать?
Еще даже не зная всех мудреных техник типа классов эквивалентности, граничных значений, таблиц решений и прочая, прочая, вы уже можете выполнить это задание. Потому что знаете, с чего начинается тестирование:
- Выясняем суть — что за ключ, нафига он нужен
- Проводим тесты —проверяем в первую очередь, что объект тестирования делает то, что от него ждут. А всякие извращения и попытки сломать оставляем «на потом».
Запомнили? Правда-правда? Вы уверены? 😊
В своей
школе для начинающих тестировщиков я в первой лекции говорю все то же самое:
— Выясняйте суть, иначе будете делать ненужную работу.
— Да-да, мамми, мы все поняли, так и будем поступать!
— Ну вот вам ДЗ, тестируйте ключ.
Угадайте теперь, какие домашки я получаю? Правильно. Половина студентов присылает примерно такое ДЗ:
Осмотрим ключ, есть ли на нем царапины? Какой внешний вид? Насколько походит к замку? Вставляем ключ в замок, откроется ли?
Некоторые добавляют:
Возьмем простой ключ от квартиры. Что нам надо проверить? …
Или так:
А что за ключ? Для чего он будет использоваться?
Наши проверки:
- Визуальный осмотр ключа
- Подходит ли к квартире.
- Не отопрет ли и соседнюю дверь тоже
- …
Хм, то есть вроде как в теории знаем, что задавать вопросы надо, но ответы нас на самом деле не особенно волнуют, проверки то вот они! Уже готовы!
А что, если на самом деле это ключ-карта? Или ключ для шифрования данных? Как вы будете осматривать пиксели в программе? А если это 3D-модель в метр высотой, какую квартиру отпирать будете?
Нет смысла заранее составлять набор проверок, не уточнив детали. Потому что иначе окажется, что тесты надо проводить в другом порядке, а то и вовсе выкинуть. Не додумывайте, уточняйте!
См также:
