Что разрабатывают аналитики и от чего отталкиваются при составлении тестовой модели
Что проверяют
Различаете ли вы, что производит аналитик и что производит тестировщик. Вопрос отсеивает тех, кто ждёт готовую тестовую модель от кого-то другого, вместо того чтобы строить её самому от требований.
Как отвечать
Сначала про аналитика. Он разрабатывает требования и всё, что их описывает: пользовательские истории с критериями приёмки, спецификацию функции, схемы процессов, модель данных, контракты интеграций, макеты. Это вход для тестирования, а не сами тесты.
Тестовую модель строит тестировщик, и опор у него четыре. Требования: каждое проверяемое утверждение должно быть покрыто и прослеживаться до конкретной проверки. Техники тест-дизайна: классы эквивалентности, граничные значения, таблица решений для сочетаний условий, диаграмма состояний для сущностей с жизненным циклом, попарное тестирование, когда параметров много. Риск: где выше цена отказа и где чаще ломалось, туда больше глубины. Реальность системы: архитектура, интеграции, доступные окружения и данные.
Отдельно скажите, что работа начинается до кода. Разбор требований это уже тестирование: неоднозначная формулировка, неописанный отрицательный сценарий, отсутствующее поведение при недоступности смежного сервиса находятся на чтении спецификации и стоят несопоставимо дешевле, чем дефект после релиза.
Где спотыкаются
Пересказывают, что тестовую модель составляет аналитик. Это перекладывание ответственности: аналитик даёт требования, покрытие придумывает тестировщик, иначе проверки просто повторяют текст спецификации и не ищут дыр в ней самой.
Перечисляют техники тест-дизайна списком, но не применяют ни одной к конкретному полю формы. На собеседовании почти всегда сразу просят разобрать пример, и заученный список там не спасает.
Забывают про требования, которых нет. Модель строится и по неявным ожиданиям: поведение при пустых данных, при обрыве связи, при повторной отправке, при нехватке прав.