Пройти весь путь тестировщика на одной маленькой фиче: спланировать проверки, найти и описать дефекты.
Полный цикл работы тестировщика
От требования до закрытого дефекта
Работа тестировщика на любой фиче проходит по повторяющемуся циклу. Сначала нужно разобрать требование: понять, что именно должна делать фича, какие граничные случаи заложены в спецификации. Затем идёт тест-дизайн — продумывание проверок с помощью техник (классы эквивалентности, граничные значения, таблица решений). На этом этапе составляются тест-кейсы или чек-листы.
Далее тестировщик выполняет проверки и фиксирует отклонения. Найденный дефект оформляется в баг-репорт: заголовок (короткий и точный), шаги воспроизведения, ожидаемый результат, фактический результат, severity и priority. После исправления дефекта разработчиком тестировщик проводит re-test (confirmation testing) — убеждается, что именно этот дефект устранён. Затем выполняется регрессионное тестирование — проверка, что исправление не сломало другие части системы.
SQL вписывается в этот процесс на этапе выполнения проверок: когда интерфейс не показывает внутреннего состояния данных, тестировщик идёт в БД и смотрит напрямую — правильно ли сохранились записи, не дублируются ли они, не потеряны ли связи между таблицами.
В этом уроке вы пройдёте весь цикл на одном сквозном кейсе: форма регистрации с конкретными правилами. Ваша задача — спланировать проверки, распознать заложенные дефекты и оформить их баг-репорты.
Lesson notes
От требования до закрытого дефекта
Работа тестировщика на любой фиче проходит по повторяющемуся циклу. Сначала нужно разобрать требование: понять, что именно должна делать фича, какие граничные случаи заложены в спецификации. Затем идёт тест-дизайн — продумывание проверок с помощью техник (классы эквивалентности, граничные значения, таблица решений). На этом этапе составляются тест-кейсы или чек-листы.
Далее тестировщик выполняет проверки и фиксирует отклонения. Найденный дефект оформляется в баг-репорт: заголовок (короткий и точный), шаги воспроизведения, ожидаемый результат, фактический результат, severity и priority. После исправления дефекта разработчиком тестировщик проводит re-test (confirmation testing) — убеждается, что именно этот дефект устранён. Затем выполняется регрессионное тестирование — проверка, что исправление не сломало другие части системы.
SQL вписывается в этот процесс на этапе выполнения проверок: когда интерфейс не показывает внутреннего состояния данных, тестировщик идёт в БД и смотрит напрямую — правильно ли сохранились записи, не дублируются ли они, не потеряны ли связи между таблицами.
В этом уроке вы пройдёте весь цикл на одном сквозном кейсе: форма регистрации с конкретными правилами. Ваша задача — спланировать проверки, распознать заложенные дефекты и оформить их баг-репорты.