На практике всегда существовало целых шесть стадий эволюции процесса тестирования, которые демонстрируют, каким образом могут меняться подходы к обеспечению качества в конкретной компании.
Данная статья поможет читателю проследить всю эволюцию процесса тестирования, узнать какой этап уже пройден, а также понять, как можно упростить и улучшить процесс проверки программного обеспечения внутри компании.
Базовые стадии
Как было оговорено выше, выделяются сразу шесть базовых стадий:
- Специалиста по тестированию ПО на фирме пока нет, а его обязанности осуществляются либо менеджером проекта, либо самим программистом;
- QA-специалисты появляются, но проверяют продукт только на этапе подготовки продукта к официальному выпуску;
- Тестировщики проверяют выполнение программистами изначально поставленных задач и их соответствие запланированному конечному результату;
- Тестировщики занимаются только тест-дизайном;
- На проектах постепенно вводится система управления проверками;
- Есть автоматизация процесса тестирования;
Теперь можно поговорить о каждой стадии по отдельности.
Базовые стадии тестирования
Стадия 1: Тестировщика на фирме пока нет
«Сам сделал – сам и проверяй» — наверное, самый «инстинктивный» вариант при тестировании программного обеспечения. Обычная практика в небольших продуктовых фирмах.
Когда материальная возможность заручится услугами профессиональных тестировщиков отсутствует, или нет понимания в выполнении качественного тестирования ПО, данная отрасль действий осуществляется своими силами.
Проверять самостоятельно – очень нерациональная и проблематичная стратегия.Давайте выясним, почему:
- Сам менеджер проверяет только те пользовательские сценарии, которые реализованы с его подачи, и которые чаще всего исправлялись в процессе разработки. Как итог, жизнь будет постоянно добавлять свои коррективы и у конечных пользователей, как правило, будут появляться критические ошибки;
- Если ПО проверяет менеджер, то он выполняет такую работу в качестве вспомогательной нагрузки, совершенно не владея экспертизой и не имея должного времени и моральных сил, чтобы плотно заниматься процессом тестирования. Подобным методом можно найти очень грубые ошибки, но некоторые нюансы будут точно упускаться из виду;
- Субъективное отношение к проекту, внутреннее желание как можно быстрее покончить с веб-продуктом ведут к определенному соблазну «закрыть глаза» на некоторые «пустяковые вещи».
В худшем случае, процессом тестирования внутри компании вообще никто не занимается, а отчет о найденных ошибках в офис доставляет сам клиент. Ему передали готовый продукт, проект на боевой среде, а программисты переключились на другие задачи.
Заказчик находит мелкую ошибку на сайте, потом ему приходит отчет о сбоях на сервере, и, в конечном итоге, он становится тестировщиком на проекте, за который он сам и заплатил.
Стадия 2: QA-специалисты проверяют проекты только на этапе подготовки продукта к официальному выпуску
Протестировать весь веб-продукт еще только на предварительном этапе – банальный способ работы при модели Waterfall.
ПО делится на большие этапы (порой, один проект – это одна большая стадия). На каждой стадии первоначально реализуется ПО, а только потом его начинают тестировать. Процесс проверки уже присутствует, и это замечательно.
Но определенные проблемы есть, и их запросто можно конкретизировать.
Для начала надо сказать, что когда проект тестируется на конечной стадии разработки, критические ошибки на уровне системной архитектуры будут обнаружены крайне поздно.
Придется переделывать большую часть ПО, или даже весь продукт. Подобный сценарий никакой выгоды не несет.
Затем отмечаем тот факт, что при отсутствии правильной документации тестировщик может выполнить исключительно поверхностную проверку методом вольного поиска багов.
Подобная проверка автоматически исключает часть альтернативных и действенных сценариев тестирования ПО.Часто бывает так, что документация на проекте есть, но в процессе выполнения задачи структурная часть ПО существенным образом видоизменяется и конечный продукт отличается от того, что было обещано клиенту изначально.
Еще можно отметить, что практически 90% процентов от всего времени работы над проектом закладывается в процесс программирования, как наиболее важную ветвь работы с ПО.
На тесты выделяется не так много времени, а на устранение дефектов его вообще нет. В конечном итоге выходит так, что внушительные доработки существенно притормаживают проект и срывают изначальные сроки сдачи.
Во время проведения раздельного тестирования появляется другая проблема: между разными этапами тестировщик может забыть некоторые особенности проекта, и ему постоянно придется изучать происходящее, и, как результат, потратится большое количество рабочих часов.
Стадия 3: Тестирощики проверяют выполнение программистами изначально поставленных задач
Затем компании начинают понимать, что эффективнее всего находит дефекты по мере их систематического накопления. А значит, идет переключение с модели Waterfall на классический Agile. В это судьбоносное время тестирощик интенсивнее интегрируется с процессом создания программного обеспечения.
Все фиксированные задачи последовательно и многократно документируются: отдельно от процесса разработки, и в окружении реальной среды.
На данном этапе все задачи проверяются на соответствие «реальным» клиентским требованиям.
Методология Agile позволяет работать намного эффективнее, но не все тестирощики, и особенно их менеджеры, готовы «по-новому» смотреть на процесс тестирования.
Руководитель всегда ожидает от тестировщика максимально быстрого выполнения работы и высшего качества проверки, а понимания нужности использования тестовой документации и выполнения регрессионного тестирования пока не наблюдается.
Процесс проверки качества ПО проводится в большей степени интуитивно, нежели структурировано.
При любой итерации выполняются проверки и всегда в различной последовательности.
Как итог, ошибки можно не заметить как минимум на одном из этапов тестирования или вообще не рассмотреть их наличия. Все альтернативные сценарии и редактирование функционала тестировщик может упустить из своего поля зрения.
Также присутствует проблема с проведением регрессионных проверок, которые если и внедряются, то абсолютно бессистемно. По факту, тестирощик проверяет лишь то, что нужно, по его мнению, или ту часть функционала, на который обратил внимание его менеджер.
Стадия 4: Тестировщики занимаются только тест-дизайном
На данной стадии на авансцену выходит всем известный тест-дизайн. Тестировщики начинают более осознанно анализировать требования к продукту.
Весь функционал дробится на логические блоки, которые должны быть покрыты чек-листами и работающими тест-кейсами.
При таком раскладе, проекты имеют полноценную техническую документацию, по которой запросто можно отслеживать, как именно тестировался определенный функционал.
Характеристика каждого тестового шага сопровождается точным описанием того, как система должна себя вести в конечном счете. Все это и является тест-дизайном.
Можно дополнительно отметить, что именно на данной стадии начинается профессиональное и полностью осмысленное тестирование.
Теперь это уже не банальная гора задач, которые нужно протестировать. Это целостный, полностью структурированный процесс работы, направленный на анализ требований клиента, сформированных в тестовой документации, которые имеют прямое отношение к проводимым проверкам.
При таком раскладе полностью меняется подход к тестовой информации. Данные для проверок больше не придумываются спонтанно в результате мозгового штурма, а берутся из предварительно «заготовленных» наборов.
Больших минусов на этапе тест-дизайна нет. Это очень достойный уровень тестирования.
Стадия 5: Используется система управления проверками
Затем компании приходят к острой необходимости применения специализированных систем для качественного сохранения тест-кейсов и работы с тестовыми прогонами.
Подобная система позволяет:
- Хранить данные и тест-кейсы;
- Связывать тестовые шаги в группу;
- Анализировать текущее тестовое покрытие;
- Осуществлять тестовые прогоны;
- Вести документацию по тестированию;
- Постоянно мониторить рабочую нагрузку команды для удобного корректирования задач и ресурсов.
Любая система – это новая ступенька эволюции чего-то. В данном случае, в первую очередь, использование системы позволяет улучшить процесс контроля за выполнением тестирования ПО.
Тестировщик ловко руководит тестами, благодаря чему мы получаем более усовершенствованный уровень качества веб-продукта.
Стадия 6: Есть автоматизация процесса тестирования
Во время длительного развития проектов может возникнуть вопрос касательно автоматизации некоторых частей ПО.
Для подобных задач тестировщики и программисты создают специализированные автотесты. Разработчики всегда делают модульные тесты, а тестировщики – UI-тесты.
Все начинается с покрытия автоматизированными проверками позитивных сценариев: авторизация, регистрация, публикация новостей, поиск по страницам и т. д.
Итоги
Выше были рассмотрены все базовые стадии эволюции отдела тестирования в любой компании, которые должны быть на вооружении любого специалиста по тестированию ПО.
Осознанное и профессиональное тестирование начинается с тест-дизайна и в конечном итоге приводит к полной автоматизации проверок.Стоит отметить, что процесс развития отдела тестирования не всегда идет линейно. Можно запросто или упускать некоторые из стадий, или сразу смешивать использования нескольких подходов.
Не во всех ситуациях и не всем нужны системы управления проверками, автотесты, а иногда даже и тест-дизайнер.
Но если всегда оставаться на стадии инстинктивного тестирования и ограничиваться только финальными проверками, выполнять сложные задачи и расти профессионально вряд ли удастся.
Оставить комментарий