Как начать тестирование календаря активности сотрудника?
Что проверяют
Начинаете ли вы с вопросов, а не с тест-кейсов. Требований в формулировке нет, и интервьюер ждёт, что вы их выясните и расставите приоритеты. Следом обычно просят назвать пять самых важных проверок или сказать, что из этого вы автоматизируете.
Как отвечать
Первые минуты посвятите уточнениям:
- что это за экран: сетка по дням с отработанными часами, статусы вроде отпуска и больничного, тепловая карта активности или всё сразу;
- источник данных: трекер времени, HR-система, ручной ввод. От этого зависит, где искать расхождения;
- роли: сотрудник видит только себя, руководитель свою команду, HR всех. Утечка чужих данных здесь серьёзнее любого визуального бага;
- производственный календарь: праздники, переносы рабочих дней, сокращённые предпраздничные дни, первый день недели.
Дальше тест-анализ, удобно в виде майнд-карты, и техники тест-дизайна:
- граничные значения: конец месяца, 29 февраля, переход года, событие через полночь, 0 часов и максимум за день;
- часовые пояса: сотрудник во Владивостоке, сервер в Москве. Запись в 23:30 по местному времени не должна уехать на соседний день;
- классы эквивалентности: полный день, частичный, выходной, отсутствие данных, пересечение отпуска с отработкой;
- права доступа: попробуйте открыть чужой календарь, подменив
employeeIdв запросе через DevTools или Postman; - производительность: годовой вид по отделу в 300 человек.
Порядок работы: сначала смоук основного сценария, затем функциональные проверки по приоритету, в конце нефункциональные. В автоматизацию разумно отдать API и расчёт часов по датам, а вёрстку сетки оставить ручной проверке или скриншотным тестам.
Где спотыкаются
Сразу пишут тест-кейсы на создание события. Интервьюер хотел увидеть вопросы, а кандидат придумал продукт сам.
Забывают про даты и часовые пояса. Именно там календари ломаются чаще всего.
Перечисляют все виды тестирования подряд без приоритетов: нагрузочное, безопасности, юзабилити. Это звучит как заученный список, а не план.