Очень часто встречаю проблему с задачками на тестирование на собеседованиях. При обучении и подготовке ребят к собеседованиям большая часть времени уделяется теории и практике с инструментами и подготовке к собеседованию, но на самих собеседованиях ребята робеют перед такими задачами.
Эти задачи, я думаю, известны всем:
- Протестировать калькулятор
- Протестировать форму регистрации (да и любую форму вообще)
- Протестировать лифт или какие-то более абстрактные задачи
Суть и цель этого поста — рассказать о некой структуре, по которой мы будем двигаться при тестировании таких задач, чтобы показать себя с лучшей стороны на собеседовании.
Допустим, возьмём за пример задачу «протестировать лифт». На первый взгляд кажется задача достаточно простой, даже слегка детской. Ну, что там тестировать? Нажал кнопку — приехал лифт. Но тут есть подвох, и, как всегда, он начинается с вопросов и уточнений.
Когда мне дают задачу вроде «протестируй лифт», первое, что я должен сделать, это начать задавать вопросы, чтобы не попасть в ловушку собственных допущений. Когда мы начинаем сразу с разбега тестировать, опираясь на какой-то личный собственный опыт или на какие-то свои субъективные суждения, мы допускаем ошибку, потому что это задача, поставленная сверху, поставленная бизнесом. А у бизнеса должны быть определённые требования.
Здесь мы возвращаемся к теории тестирования (инфа по требованиям) и начинаем уточнять:
- Лифт грузовой или пассажирский?
- Может ли он ездить ниже первого этажа (подземные парковки, складские помещения)?
- Есть ли ограничения по весу или количеству человек?
- Как устроена панель управления: что происходит при нажатии нескольких кнопок сразу?
- Что делает лифт, если его одновременно вызывают снаружи и внутри?
Тут можно накидывать много разных вопросов. Для чего это нужно? Человек, который проводит собеседование, хочет увидеть, как ты подходишь к решению задач, и намеренно не даёт изначально все вводные данные, чтобы посмотреть, как ты будешь с ними работать.
После того как я уточнил весь контекст, задал все интересующие меня вопросы, получил все интересующие меня ответы, я имею полную картинку по вводным данным, по требованиям и понимаю, как должен работать наш лифт, как он должен выглядеть и что он должен уметь.
Дальше мы накидываем проверки, опять-таки идя структурно. Например, сначала тестируем внешнюю панель. Здесь просто важно понять, как лифт реагирует на вызовы с разных этажей. Очень простой сценарий: нажал кнопку «Вверх» на первом этаже, лифт приехал, дверь открылась — супер, кейс пройден. А что, если одновременно вызвать лифт на первом и на пятом этажах? Какой вызов будет приоритетнее?
Далее переходим к следующему блоку — панель внутри лифта. Здесь кейсов может быть больше. От простых: нажал этаж — приехал на этаж, до сложных: нажал три разных этажа, и лифт должен доехать в правильной последовательности (по возрастанию). Или нажал кнопку «открыть дверь», когда лифт уже поехал — сработает или нет?
Отдельная тема — двери. Если я застрял в дверях, двери откроются обратно или нет? Реагирует ли он на какие-то преграды при закрытии (например, руку)? Будет ли лифт закрываться и ехать дальше или нет?
Затем мы можем применять техники тест-дизайна. Например, проверяем граничные значения: либо количество людей, либо вес (грузоподъёмность), либо количество этажей. Здесь же мы можем дополнять негативными кейсами: что будет, если лифт перегружен? Он будет стоять на месте или подавать сигнал? Что будет, если пытаться вызвать несуществующий этаж? Опять-таки, мы можем подразумевать, что вызвать такой этаж невозможно, но проверить это обязательно должны.
Ну и отдельно я всегда проверяю нефункциональные требования:
- Как быстро приезжает лифт?
- Какой шум и вибрация?
- Что произойдёт, если отключится электричество?
- Как он выглядит, соответствует ли дизайн реальным требованиям?
ПРОДОЛЖЕНИЕ В КОММЕНТАХ!