На схеме приведены основные этапы тестирования, указаны виды тестирования, которые выполняются на этих этапах, а также показано, кто еще кроме команды QA так или иначе принимает участие в процессе тестирования:
Ниже приведено описание схемы
1. Unit Testing – разработчики поверяют работоспособность своего кода специальными автоматизированными тестами. На этом этапе проводиться проверка типа работает\не работает: если не работает, то продолжаем отладку, если работает – выдаем в тестирование
2. Sanity & Smoke Testing – общая проверка поставки или билда перед началом основного тестирования. Здесь также выполняется проверка работает или не работает поставка (в плане "запускаемости", основных функций): если не работает, то билд возвращается разработчикам с описанием дефектов (как правило тут все дефекты - блокирующие), если работает – можем приступать к более детальному тестированию
3. Functional & Regression Testing – здесь фактически выполняется 2 цикла тестирования (поиск, устранение и ретест (перепроверка) ошибок). Сначала выполняется функциональное и нефункциональное тестирование доработки (это минимум 2 полных итерации тестирования). Далее проводится цикл регрессионного тестирования, это еще как минимум 1 итерация.
Почему в цикле функционального тестирования минимум 2 итерации, а в регрессионном может быть и 1?
В части функционального тестирования даже если мы провели все запланированные тесты (хотя это очень маловероятно), исправили и успешно ретестировали все дефекты, то нам все равно необходимо убедиться, что в целом функционал работоспособен. Ведь на первой итерации мы только убедились, что все изначально найденные дефекты исправлены, но они могли скрывать за собой и новые ошибки, до которых мы не дошли.
В части регрессионного тестирования, мы выполняем итерацию тестирования для уже работающего функционала. В идеальном случае мы либо увидим, что влияния нового функционала нет, либо найдем ошибки, устраним их и проверим, что данное конкретное точечное влияние устранено.
4. Integration Testing – на этом этапе мы проводим минимум 1 итерацию тестирования в рамках общей интеграционной схемы
5. User Acceptance Testing – как правило на этапе приемки заказчика лучше сразу ориентировать на 2 итерации тестирования. Во время первой итерации выявляются дефекты, мы берем их в работу и проводим цикл исправления-ретеста. Далее проводится вторая итерация приемки, где заказчик (или пользователи) убеждаются, что все исправлено. Найденные во время второй итерации незначительные дефекты (если они значительные, мы просто не пройдем приемку) отправляются на второй цикл внутреннего исправления-ретеста
6. DryRun – команда L2 поддержки делает пробную установку ПО на тестовой среде, репетируя релиз. Собственно, на этом этапе выявляются и решаются все проблемы установки и настройки релиза. Т.о. проводится проверка выполнена или не выполнена установка: если что-то пошло не так, то определяются способы решения проблем и добавляются в инструкцию по установке, если все работает – можем устанавливать релиз в продуктивную среду.