Программа не появляется сразу целиком. Она проходит путь: кто-то придумал идею, кто-то описал, что нужно, разработчики написали код, тестировщики проверили, продукт выпустили и дальше поддерживают. Этот путь называют жизненным циклом разработки — по-английски SDLC (Software Development Life Cycle).
Тестирование — не отдельный островок в конце, а часть этого пути, у которой есть свой внутренний цикл — STLC (Software Testing Life Cycle). Понимать оба нужно, чтобы видеть, в какой момент и как вы подключаетесь.
Этапы разработки (SDLC)
Классические этапы, через которые так или иначе проходит любой продукт:
- Требования. Решают, что и зачем строим. Аналитик и заказчик описывают, как всё должно работать.
- Проектирование. Придумывают, как это устроить технически: экраны, структура данных, архитектура.
- Разработка. Программисты пишут код.
- Тестирование. Проверяют, что получилось то, что задумывали, и ищут баги.
- Релиз (внедрение). Выкатывают продукт пользователям.
- Поддержка. Чинят найденное в бою, добавляют новое.
На бумаге этапы идут по очереди, на практике — переплетаются и повторяются. Но набор работ всегда примерно этот.
Waterfall и Agile — два способа пройти эти этапы
Есть два подхода к тому, как двигаться по этапам.
Waterfall («водопад») — строго по очереди: сначала все требования, потом весь дизайн, потом вся разработка, потом всё тестирование. Как водопад, вниз и без возврата. Проблема: тестирование стоит в самом конце, и если ошибку заложили ещё в требованиях, найдут её очень поздно и очень дорого.
Agile («гибкий») — маленькими кусочками. Продукт делают короткими циклами (спринтами) по одной-две недели: за цикл берут небольшую функцию и проводят её через все этапы — от требований до тестирования — сразу. Тестирование идёт вместе с разработкой, а не после неё. Сегодня так работает большинство команд; подробнее — в статье QA в Agile и Scrum.
Для тестировщика разница принципиальна: в Agile вы включаетесь постоянно и рано, а не ждёте, пока «всё допишут».
Жизненный цикл тестирования (STLC)
Внутри большого цикла у тестирования есть свой, поменьше. Когда приходит новая функция, тестировщик проходит примерно такие шаги:
- Разбор требований. Понять, что вообще нужно проверять, и задать вопросы, если что-то неясно.
- Планирование. Прикинуть, что и как тестировать, сколько времени нужно — это будущий тест-план.
- Дизайн тестов. Написать тест-кейсы и чек-листы, подготовить тестовые данные.
- Выполнение. Пройти проверки, завести баги на найденное.
- Завершение. Перепроверить исправленное, подвести итог: что проверено, что осталось, можно ли выпускать.
Эти шаги не обязательно длинные и формальные — на маленькой задаче они займут полчаса. Но порядок мыслей всегда такой: понять → спланировать → придумать проверки → проверить → подвести итог.
Почему тестировщик нужен с самого начала
Соблазн — подключать тестировщика в конце: «сделаем, а потом проверите». Это дорого. Самые злые баги закладываются на этапе требований: если недоговорились, что должно происходить при повторной оплате, то и код, и тесты будут неправильными, а поймётся это в бою.
Когда тестировщик читает требования заранее, он задаёт неудобные вопросы: «а что если пользователь нажмёт дважды?», «а что при отмене после оплаты?». Эти вопросы стоят десять минут на этапе требований и спасают недели на этапе поддержки. Именно поэтому в современных командах тестировщик участвует в обсуждении задачи с самого начала, а не получает готовое.
Где это применяется
Знание жизненного цикла помогает понять, когда делать вашу работу и почему что-то идёт именно так. Когда команда планирует спринт — вы прикидываете, что успеете протестировать. Когда обсуждают новую функцию — вы уже задаёте вопросы. Когда готовят релиз — вы говорите, можно ли выпускать. Всё это — ваши точки в общем цикле.
Где спотыкаются начинающие:
- Считают тестирование «последним этапом» и ждут готового продукта. В Agile так не работает — вы подключаетесь рано и постоянно.
- Пропускают разбор требований и сразу лезут проверять. Потом оказывается, что проверяли не то.
- Не подводят итог. «Вроде всё потыкал» — это не результат. Нужно ясно сказать, что проверено, что нет и какие есть риски.
Что учить дальше. Теперь, когда картина целиком понятна, переходите к сути ручной работы: уровни тестирования (что и на каком масштабе проверяют) и виды тестирования.