7 этапов эволюции тестирования в компании

    image

    Я выделил 7 ключевых стадий эволюции тестирования, чтобы проиллюстрировать, как меняются подходы к обеспечению качества в компаниях. В ходе чтения статьи вы сможете проследить эволюцию тестирования, определить свой текущий этап и узнать, что стоит предпринять для улучшения процесса и качества тестирования.

    Статья изначально писалась для журнала CIS, но думаю будет интересна и пользователям Хабра.

    Итак, стадии.

    1. Нет тестировщика. Его функции выполняет сам разработчик или менеджер.
    2. Тестировщики появляются, но тестируют проекты только на стадии завершения.
    3. Тестировщики проверяют все задачи разработчиков на предмет соответствия результата изначальной постановке задачи.
    4. Тестировщики занимаются тест-дизайном.
    5. Внедряется система управления тестированием.
    6. Появляется автоматизация тестирования.
    7. Усложняется иерархия, появляются новые роли в команде тестирования.

    Теперь о каждой стадии подробнее.

    Стадия 1. Тестирование выполняет разработчик и\или менеджер


    «Сделал — проверь за собой» — самый простой, «инстинктивный» подход к тестированию. Обычное дело в небольших компаниях. Когда нет возможности нанять профессионального тестировщика или нет понимания необходимости тестирования, этот фронт работ выполняется своими силами. Тестировать самому — самый нерациональный и проблемный подход. Вот почему.

    • Сам разработчик тестирует только те сценарии, которые реализовал и с теми данными, которые использовал в процессе разработки. При таком тестировании «в вакууме» альтернативные сценарии опускаются. В итоге жизнь вносит коррективы и у конечных пользователей как правило всплывают ошибки.
    • Если тестирует менеджер, то он делает это в качестве дополнительной нагрузки, не владея экспертизой и не имея времени и моральных сил плотно заниматься тестированием. Так можно обнаружить грубые ошибки, но многие нюансы упускаются из виду.
    • Субъективное отношение к проекту, желание побыстрее его сдать ведут к соблазну закрыть глаза на ряд казалось бы «несущественных» проблем.

    Крайний случай, когда тестированием в компании вообще не занимаются, а репорт об ошибках приносит… заказчик. Он получил релиз, все уже на боевой среде, разработчик отчитался о запуске. Клиент открывает проект и видит какую-то банальную ошибку базы данных или ошибку сервера. Потом еще и еще ошибки. Клиент становится тестировщиком за свои же деньги.

    Стадия 2. Тестировщик проверяет проект в самом конце


    Проверить весь проект на предрелизной стадии — классический метод при работе по модели Waterfall. Проект разделяется на глобальные этапы (иногда весь проект это один этап). На каждом этапе сначала делается софт, а уже потом тестируется. Тестирование уже есть, и это хорошо. Но проблемы тоже есть, и совершенно конкретные.

    Во-первых, когда мы тестируем в самом конце, серьезные ошибки на уровне архитектуры будут найдены слишком поздно. Потребуется переделывать большую часть, а то и весь проект. Это никому не выгодно.

    Во-вторых, при отсутствии документации мы можем провести только поверхностное тестирование методом свободного поиска. Это сразу выключает часть альтернативных сценариев. Бывает, что документация есть, но в процессе задачи видоизменяются и готовый продукт отличается от картинки на бумаге. Опять же возникают сложности в тестировании и в разборе баг-репортов.

    В третьих, практически все время проекта обычно закладывается на разработку как приоритетную задачу. Оставляют немного времени на проверку. А вот на исправление ошибок времени-то и нет, в результате порой внушительные доработки тормозят проект и срывают сроки.

    При раздельном тестировании этапов возникает другая проблема. Между этапами тестировщик забывает детали проекта, и ему приходится каждый раз вникать в происходящее. Это тоже трата рабочих часов.

    В общем, проверять проект в самом конце логично и вроде бы правильно, но этот метод не учитывает риск обнаружения глобальных ошибок. Поэтому тестирование эволюционирует дальше.

    Стадия 3. Все задачи проверяются на соответствие результата изначальной задаче


    Далее компания понимает, что лучше отлавливать ошибки по мере их накопления. Стало быть, переключаемся с Waterfall модели на методологию Agile. В этот момент тестировщиков более тесно интегрируют в процесс разработки. Все задачи начинают последовательно многократно тестироваться: отдельно, в составе релиза, на боевой среде.

    На этой стадии задачи проверяются на соответствие заявленным требованиям. Agile помогает работать лучше, но далеко не все тестировщики, и особенно их руководители готовы по-новому относиться к тестированию.

    Руководитель ждет от тестировщиков скорости и качества, а понимания необходимости тестовой документации и проведения регрессионного тестирования еще нет. Отсюда типичные проблемы этой ступени эволюции.

    Тестирование проводится больше интуитивно, чем структурированно. Главенствует принцип «что вижу — то и тестирую». При каждой итерации делаются разные проверки и в разной последовательности. В результате ошибку можно как минимум пропустить на одном из этапов тестирования или вообще не увидеть. Альтернативные сценарии и изменения в связанном функционале тоже могут выпасть из поля зрения.

    Плюс проблема с регресс-тестированием, которое если и проводится, то бессистемно. По факту тестировщик проверяет то, что сам считает нужным или то, что ему посоветовал проверить разработчик/менеджер.

    Стадия 4. Тестировщики занимаются тест-дизайном


    На этой стадии на сцену выходит тест-дизайн. Тестировщики начинают осознанно уделять внимание анализу требований. Функционал разбивается на логические блоки, которые покрываются чек-листами или тест-кейсами.

    Чек-лист — список проверок, необходимых для тестирования функционала. Чек-листы более распространены, так как их проще поддерживать в актуальном состоянии, особенно в рамках большого динамичного проекта.

    Тест-кейс — последовательность шагов, которые необходимо пройти для проверки функционала. Описание каждого шага сопровождается указанием на ожидаемое поведение системы.

    Появляется полноценная тестовая документация, по которой можно отследить, как проверяется тот или иной функционал. Тестовая документация полезна не только при первичном тестировании, но и в регрессионных тестах.

    Всё это и называется тест-дизайном. Можно сказать, что на этой стадии начинается осмысленное профессиональное тестирование. Больше это не просто гора задач, которые нужно проверить, а структурированный процесс по анализу требований, формированию тестовой документации и непосредственному тестированию. В том числе меняется подход к тестовым данным. Данные уже не придумываются спонтанно в процессе, а берутся из заранее подготовленных наборов.

    Явных минусов на стадии тест-дизайна нет. В целом это уже достойный уровень тестирования. Для потокового производства сайтов или подобных проектов тест-дизайна более чем достаточно. Главное правильно подходить к процессу тестирования: проанализировать продукт, составить документацию и по ней провести тесты.

    Стадия 5. Внедряется система управления тестированием


    Далее компания дорастает до необходимости использования специализированных систем для хранения тест-кейсов (чек-листов) и выполнения тестовых прогонов.

    Такая система позволяет:

    • хранить требования и тест-кейсы;
    • связывать требования с тест-кейсами;
    • анализировать тестовое покрытие;
    • хранить разные версии тест-кейсов;
    • выполнять тестовые прогоны;
    • проводить сравнительный анализ по тестовым прогонам;
    • вести отчетность по тестированию;
    • отслеживать рабочую нагрузку команды для корректировки задач и ресурсов.

    Система — это всегда новая ступень эволюции. В нашем случае прежде всего улучшается контроль за процессом тестирования. Мы лучше управляем тестами и получаем новый уровень качества продукта.

    На поздних стадиях развития проекта такая система помогает всем участникам помнить, как вообще что-то должно работать и как это проверять. Система ускоряет ввод в проект новых участников.

    Стадия 6. Автоматизируются регулярные проверки


    В процессе длительного развития проектов возникает потребность автоматизировать отдельные проверки. Для этого разработчики и тестировщики пишут автотесты. Разработчики обычно делают unit-тесты, тестировщики — ui-тесты. Начинают с покрытия автотестами позитивных сценариев использования ключевого функционала: авторизации, регистрации, публикации записей и тому подобное.

    Разработанные автотесты включаются в процесс непрерывной интеграции (CI/CD), что позволяет команде узнавать об ошибках непосредственно в момент коммита.

    Автотесты значительно сокращают расходы на регрессионное тестирование и повышают качество конечного продукта. Но, чтобы их делать, нужен определенный уровень тестировщика. Также стоит знать, что автотесты не имеет смысла делать на ранних стадиях проекта. Система быстро меняется, поэтому во избежание фантомных ошибок нужно менять и автотесты, что занимает время.

    Стадия 7. Усложняется иерархия, появляются новые роли


    Мы подошли к высшей стадии эволюции, когда в отделе тестирования значительно усложняется иерархия и появляются узкие специалисты: тест-менеджер, тест-лид, тест-аналитик, тест-дизайнер и так далее.

    Команда растет, задачи усложняются. Например, тест-менеджер больше всех знает о продукте и занимается организацией тестирования на более высоком уровне. Он чаще и более тесно коммуницирует с заказчиками и разработкой, нежели с командой тестирования.

    Тест-лид организует тестирование на проекте и распределяет задачи внутри команды. Тест-аналитик занимается аналитикой требований, их декомпозицией и приоритезацией, готовит материал для тест-дизайна и последующего тестирования. А тест-дизайнер трансформирует требования в чек-листы и тест-кейсы.

    Новые роли нужны на больших проектах, где работает целая команда тестировщиков. Появление подобных ролей ведет к еще большей структуризации процесса тестирования, без чего невозможна работа над большими и сложными ИТ-проектами.

    Выводы


    Мы рассмотрели ключевые стадии эволюции тестирования в компании. Осознанное профессиональное тестирование начинается со стадии тест-дизайна. Тест-дизайн дает устойчивое повышение качества продукта.

    Процесс развития тестирования не всегда линейный. Вы можете пропускать, объединять, смешивать определенные этапы или сразу выходить на более высокий уровень. Например, у нас в Qualitica есть система управления тестирования, то есть мы на стадии 5. Сейчас практически одновременно у нас появляются узкие специалисты (новые роли, стадия 7) и автоматизация (стадия 6).

    Далеко не всем и не всегда нужны система управления тестированием, автотесты и тем более тест-дизайнер. Но, оставаясь на этапе инстинктивного тестирования или ограничиваясь финальными проверками, делать сложные длительные проекты вряд ли получится. Поэтому желаю вам найти нужную точку в процессе развития тестирования и прийти к ней, чтобы повысить качество тестирования и давать заказчикам продукт высокого качества.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 19

      0
      К сожалению, тут плохо примерно всё, и к современной реальности имеет очень мало отношения.
      Например, «Тестировщики занимаются тест-дизайном». Тест-дизайн — это проектирование тестов. Даже если тестировщик не пишет тест-кейсы, а занимается исследовательским тестированием продукта на финальной стадии — он занимается тест-дизайном, он продумывает, что и как он будет тестировать. И новичок, и суперопытный тестировщик этим занимаются — различие лишь в качестве и эффективности этого процесса.

      Стадия 2, Waterfall… да закопайте уже waterfall! :(
      В том понимании, в каком это указано здесь, его никто не применял последние лет дцать. А более ранней информацией я не владею.

      Руководитель ждет от тестировщиков скорости и качества, а понимания необходимости тестовой документации и проведения регрессионного тестирования еще нет. Отсюда типичные проблемы этой ступени эволюции.

      Пруфы! У кого нет понимания необходимости? Почему это необходимо?

      Тестирование проводится больше интуитивно, чем структурированно. Главенствует принцип «что вижу — то и тестирую».

      Это еще почему?

      Для потокового производства сайтов или подобных проектов тест-дизайна более чем достаточно.

      Окей :(

      Мы лучше управляем тестами и получаем новый уровень качества продукта.

      По умолчанию не получаем. А если находится больше важных проблем, мы их находим быстрее, быстрее потом фиксим и не добавляем новых — то да, уровень качества повышается.

      Автотесты значительно сокращают расходы на регрессионное тестирование и повышают качество конечного продукта.

      Абсолютно не факт. Скорее, наоборот, автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.

      Также стоит знать, что автотесты не имеет смысла делать на ранних стадиях проекта. Система быстро меняется, поэтому во избежание фантомных ошибок нужно менять и автотесты, что занимает время.

      А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(

      Например, тест-менеджер больше всех знает о продукте и занимается организацией тестирования на более высоком уровне. Он чаще и более тесно коммуницирует с заказчиками и разработкой, нежели с командой тестирования.

      Это не очень хороший тест-менеджер.

      итд…
        0
        Я написал о своем опыте. В моей практике до сих пор делаются проекты по waterfall в том виде, который я здесь описал. До сих пор многие менеджеры не в курсе, что такое тестовая документация, что нужно проетировать кейсы и т.д. Повторюсь, это мой опыт. Основан он на сотрудничестве с несколькими сотнями компаний за последние лет 10. Возможно в вашем случае, в вашей компании ситуация другая )

        Я различал и буду различать тестировщиков, которые при тестировании отталкиваются от требований, проектируют кейсы… и тех, кто просто проверяет то, что видит. Вы можете считать, что и те и другие занимаются тест-дизайном — окей, ваше право. Лично я так не считаю )
          0
          В моей практике до сих пор делаются проекты по waterfall в том виде, который я здесь описал.

          Ну и ура. Вам дали тонну готовой документации, вы по ним написали тест-кейсы, прогнали, предоставили отчет. Красота! (Или в реальности все не так?)

          До сих пор многие менеджеры не в курсе, что такое тестовая документация, что нужно проектировать кейсы и т.д.

          Вы имеете в виду тест-менеджера или менеджера продукта? Я думаю, что менеджеру продукта совершенно не обязательно знать, какую именно тестовую документацию вы используете. Но если он знает про это всё — то, конечно, ему плюс.
          «Тест-кейсы, чек-листы, майндмапы? Что это? Вы мне лучше скажите, можно ли показывать продукт заказчику?»
            0
            Дали документацию, прогнали кейсы, дали отчет. Тут все хорошо. Проблема же в другом там, если вы конечно читали текст статьи) В частности при таком подходе срываются сроки из-за того, что все баги находятся в самом конце работы.

            Тест-менеджер явно появляется позже, чем компания осознает необходимость проектировать кейсы. Я писал про руководителей (всего бизнеса или отдельного продукта\проекта), которые принимают решение о судьбе тестирования в тот момент. Есть много небольших компаний, где руководство набирает тестировщиков по объявлению, ждет чудес и абсолютно не понимает зачем нужно выделять время и вообще делать какую-то там документацию для тестирования)
              0
              Тест-менеджер явно появляется позже, чем компания осознает необходимость проектировать кейсы.

              Компания в принципе может не проектировать тест-кейсы (ибо незачем).
              И руководителю бизнеса или продукта, повторюсь, вообще неинтересно, есть тест-кейсы или нет. Они оперируют на другом уровне. Писать ли тест-кейсы — это уровень тест-лида/тест-менеджера максимум.
                0
                Компания в целом может не тестировать, может не нанимать тестировщиков и тем более может не разбираться в тестировании… но зачем вы про эти компании? Или может быть вы считаете, что руководители компаний при найме первого тестировщика в штат интуитивно понимают какой из 100 кандидатов хороший и сразу разрешают ему делать что угодно? О чем вы вообще? Что вы пытаетесь мне доказать?
                0
                В частности при таком подходе срываются сроки из-за того, что все баги находятся в самом конце работы.

                При нормальном эстимировании и выставлении сроков сроки не срываются, потому что они учитывают вероятность появления багов. Другими словами, если вы планируете тестить в самом конце, то и баги получать вы планируете в самом конце, соответственно баги фиксы ретесты закладываются или должны закладываться в сроки.
            0
            вы пишете:
            автотесты для регрессии не сокращают расходы и не повышают качество, а просто тратят время и деньги.
            и
            Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы


            Вам не кажется, что это немного противоречивые заключения?
            Регресс может содержать в себе и автоматизированные тесты и ручные, а основная цель автоматизации — ускорить выполнение кейсов и минимизировать риски человеческого фактора (усталость, рассеяность, изматывающая монотонность выполнения). Кроме того автоматизация отлично заходит в ci/cd и в мониторинг какой — нибудь, что действительно означает «пишут автотесты раньше -> они приносят больше пользы»
              0
              Нет, они не противоречивые.
              Я имел в виду, что не надо писать автотесты специально для регресса. Надо писать тесты для нового функционала, и со временем эти тесты автоматически станут регрессионными :)

              Кроме того автоматизация отлично заходит в ci/cd и в мониторинг какой — нибудь, что действительно означает «пишут автотесты раньше -> они приносят больше пользы»

              Именно так.
              0
              А как же TDD, Test-First, Shift-left? Все сейчас стараются писать автотесты как можно раньше, чтобы они принесли как можно больше пользы, а вы говорите, пишите в конце, автоматизируйте регрессию… :(

              Ну оно то конечно да, но первые 2-3 месяца UI-тесты действительно нет смысла писать, потому что проект часто изменяется и получится что будешь постоянно занят восстановлением работоспособности только что написанных тестов.А вот спустя месяца 3 — там да, уже имеет смысл — к этому времени проект обычно устаканивается и правки, ломающие GUI тесты случаются значительно реже.
                0
                А для проектов какой длительности это применимо?
                  0
                  Ну как можно увидеть из моего комментария — для проектов длительностью меньше 2-3 месяцев автотесты писать вообще особо смысла нет(ну кроме каких-то исключительных случаев). Я бы сказал что автотестами стоит заниматься если проект от полгода и дольше по длительности. Ну а до полугода — внимательно рассматривать каждый конкретный случай. Потому что иногда бывают нужны автотесты и на 3-г=недельный проект, но все же это не часто случается)
                    0
                    Ок.

                    Просто хочу сказать, что при нормальной организации процесса для наибольшей эффективности тесты необходимо писать как минимум параллельно с разработкой, а еще лучше — до того, как код улетает на dev-стенд :)
                    Правда, это требует такой культуры разработки, которая пока мало у кого есть :(
                      0
                      Ну в идеале — да. Но вот для юнит тестов к примеру гораздо проще быть написанными параллельно с разработкой, или даже до, потому что им не нужен GUI, с другой стороны GUI тесты очевидно чувствительны к изменениям в GUI и потому часто пишутся уже после разработки. С другой стороны когда проект достаточно длинный, интерфейс уже стандартизированный и кардинально меняется скорее логика, чем интерфейс — то в этом случае и GUI тесты могут быть написаны до разработки.
                        0
                        Если мы говорим про Selenium и прочий веб, то имхо там достаточно ввести требования к верстке с обязательным указанием id-шников всех интерактивных элементов. И это прям значительно повышает тестируемость.
                        В каком-то идеальном мире это, наверно, есть :)
                          0
                          В каком-то идеальном мире это, наверно, есть :)

                          Вот в том то и дело, что и в идеальном) Насколько бы упрощало жизнь, если бы на всех проектах было возможно такого добиться)
              +1
              Самый первый этап — «Нет тестировщика. Его функции выполняет сам разработчик» — то, к чему в последние годы все и идет. Shift-left, shift-right, вот это все. Отдельные команды тестировщиков, автоматизаторов, наличие тест менеджеров — как раз говорит, что все идет в наименее эффективном направлении.

              На первых же страницах книги «Как тестируют в Google» есть ответ на вопрос как им удалось выстроить эффективные процессы тестирования в компании — у них был большой недостаток в отдельных специалистах тестировщиках, в итоге тестированием «пришлось» заниматься разработчикам.
                0
                Отдельные команды тестировщиков, автоматизаторов

                Есть случаи, когда отдельная команда нужна, но как дополнение к тестировщикам внутри команд. Только отдельная команда тестировщиков — ну, так себе решение.

                наличие тест менеджеров — как раз говорит, что все идет в наименее эффективном направлении.

                А что не так с тест-менеджерами? :)
                0
                Ну вот, профессиональные тестировщики налетели тестировать статью. Сейчас оформят багрепорты и переведут в reopen, как несоответствующую их представлениям об идеальном мире ;)

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое