Создаем отдел тестирования

    Разработка программного обеспечения невозможна без контроля качества, а в этом ключевую роль играет процесс тестирования. Надо заметить, что тестирование ‒ это не единственная и тем более не достаточная мера для создания качественного ПО, но совершенно необходимая.



    Что такое тестирование? Упрощенно, это процесс проверки того, что программа соответствует всем поставленным требованиям. Еще более упрощенно ‒ тестирование есть поиск ошибок. При этом обычно программа рассматривается как “черный ящик”, и проверка производится многократным запуском с разными исходными данными и в разных условиях.
    Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования. Перекладывание функций тестировщиков на разработчиков, бизнес-аналитиков или даже менеджеров ‒ путь неэффективный. В этой статье мы расскажем, как можно построить отдел тестирования.

    Глоссарий


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

    Люди


    Самое важное ‒ найти правильных людей. Первое, с чем вы столкнетесь ‒ на тестировщиков у нас не учат, и найти человека не так уж просто. У вас два пути: “сделать тестировщиком” кого-то из ваших сотрудников или нанять со стороны человека в опытом работы.
    Определенно, человек из компании уже знает особенности вашего продукта, требования клиентов и коллектив (это тоже важно). Вероятно (если вы уж занимаетесь разработкой), что кто-то из программистов свой код все же тестировал и кто-то это делал лучше и более тщательно, чем другие?
    Однако, хотя переход из программистов в тестировщики возможен, никак нельзя быть уверенным, что ваши сотрудники, которым нравится своя работа, согласятся полностью посвятить себя тестированию. Я бы предположил, что они вообще не будут в восторге от такого предложения — слишком разные это профессии. Поэтому, найм со стороны также рассматривайте.
    Хороший тестировщик — это не просто “выполнятель тестов”, это тот человек, который будет каждый день использовать ваш продукт и быть самым преданным его пользователем. А иметь такого человека в команде — многого стоит.

    Планирование времени


    Тестирование ‒ это трудоемкий и затратный по времени процесс. Один прогон регресс-тестов чего стоит! Поэтому при тестировании крайне важно планирование времени. Например, проектов у вас много, а отдел тестирования ‒ только один. Возникает много проблем при одновременных релизах.
    Для решения очень удобно использовать google-календарь (про использование сервисов google я как-то уже писал), то есть создать календарь, в который можно вносить планируемые релизы, и расшарить его менеджерам и тестировщикам. Можно просматривать даты релизов и в системе управления проектами, например, Redmine, но наиболее наглядно использовать единый календарь для планирования.

    Тестирование ‒ это учет и контроль


    Чем иметь очень “злой” тест-кейс, намного важнее его “прогонять” регулярно и фиксировать результаты. Можно, конечно, все держать в голове или заносить результаты выполнения тестов в блокнот, но это не эффективно. Пользуйтесь TMS (Test Management System). Они позволяют использовать системный подход при тестировании ‒ когда мы изначально садимся и описываем план своих тестов, чтобы не получилось так: потестировали тут, там и, в результате, не можем сказать, каково же состояние проекта/продукта.
    Самое важное при использовании TMS ‒ это анализ полученных результатов и выявление динамики развития проектов. Мы начинаем видеть от релиза к релизу, что, например:
    • Увеличивается количество багов, и следует разобраться, в чем же проблема.
    • Один из тестировщиков находит больше багов, чем остальные. Как поднять скиллы тестировщиков?
    • Время на прогон регресс-тестов неуклонно растет с развитием проекта, но мы это наглядно видим и можем планировать.
    • …… в общем, информации для анализа вполне достаточно.

    Мы используем TMS Testlink. Вы можете выбрать и другие системы. Свой опыт и советы один из моих коллег рассказал в статье. Возьмите на заметку ‒ поможет в трудный момент. В TMS мы вносим все наши тесты, а потом просматриваем отчеты.

    Ручное тестирование


    Ручное тестирование — это то, с чего все начинается. Тесты выполняются вручную, без использования особых средств автоматизации (за исключением TMS). Тестировщик обычно просто следует заранее написанному плану действий, фиксируя результат — было ли поведение ожидаемым, или нет (в этом случае записывается, что пошло не так).
    В большинстве случаев, ручное тестирование — это функциональное тестирование, а также тестирование на программную и аппаратную совместимость. Ручное тестирование наиболее распространено для проверки пользовательских интерфейсов — здесь автоматизация иногда экономически неэффективна или вообще невозможна.
    Сотрудника на ручное тестирование следует искать кропотливого, пытливого и терпеливого, который “на ты” с объектами тестирования — сайтами, мобильными устройствами, SmartTV и т.п.

    Автоматизированное тестирование


    Потребность в автоматизированном тестировании возникает, когда проект уже большой и ведется его активное развитие. Чтобы не тратить время на ручной прогон тестов, которые приходится выполнять очень часто, можно использовать автоматизированное тестирование.
    Часто под автотестами понимают только юнит-тесты, хотя автоматизировать можно практически любой вид тестирования. Мы считаем, что любое тестирование кода по принципу “белого” или “серого ящика” — это задача разработчика, а не тестировщика, поэтому здесь организацию юнит-тестирования рассматривать не будем.
    Инструментарий для автоматизации ручного функционального тестирования достаточно широк. Мы сами используем Selenium для тестирования веба.

    Часто бывает так, что затраты на поддержание автотестов значительно превышают затраты на ручное тестирование. Поэтому надо действовать без фанатизма.
    Требования к сотруднику практически такие же, как к программисту-администратору. Почему администратору? Потому что автотестирование тесно связано с релиз-инжинирингом.
    То есть мы, как правило, либо собираем пакеты для тестирования, либо выкатываем релиз в тестовое окружение (staging environment или “карантин” в нашей терминологии). В определенный момент мы приходим к тому, что надо минимизировать время тестирования перед релизом.

    Нагрузочное тестирование


    О нагрузочном тестировании зайдет речь после первого пика пользователей. Если все затормозило и упало, то как только перестанут искры сыпаться из глаз, поднимая проект, разработчики сами начнут произносить эту мантру, и вам повезет, если в ТЗ к проекту вы найдете цифры нагрузок, которые ваш проект/продукт должен выдерживать. Как ни странно, и сам заказчик зачастую не знает, чего можно ожидать от пользователей. Обычно эти цифры из менеджера будут выбивать разработчики, а менеджер ‒ у потустороннего менеджера, то есть со стороны заказчика.
    Каким инструментом проводить тестирование? Мы используем yandex-tank.
    Требования к сотруднику, проводящему тестирование:
    • знание технической структуры проекта,
    • неплохой уровень администрирования в linux (я говорю про крупные проекты),
    • навыки программирования.


    Тестирование отказоустойчивости


    Вам понадобится этот вид тестирования, как только вы начнете строить отказоустойчивые системы (например, с резервированием элементов или с graceful degradation). Печальный опыт показывает, что при отказе одно элемента в таких системах падает вообще все поведение других элементов труднопредсказуемо.
    Как мы проводим тест отказоустойчивости? Анализируем техническую структуру проекта, тщательно планируем действия и в часы наименьшей загрузки выводим некоторые элементы системы из работы, изучаем последствия, вносим улучшения и корректировки. Потом повторяем.

    Заключение


    Подведу итоги, что же надо сделать, чтобы создать отдел тестирования:
    • Выбрать правильных людей — из компании или извне;
    • Завести инструмент планирования времени на тестирование релизов;
    • Организовать работу с TMS для формирование тест-кейсов и учета результатов тестирования;
    • Собственно, регулярно проводить тесты и анализировать результаты;
    • Начать с ручного тестирования и по необходимости внедрять автоматизацию; по мере развития проектов добавлять нагрузочное тестирование и тестирование отказоустойчивости.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 27

      +3
      Смотря какие проекты и о каких продуктах идет речь, конечно, но есть еще полно других видов полезного тестирования, упущенных в статье, хотя бы тестирование безопасности. Статья достаточно поверхностная и капитаноочевидностная, на мой взгляд.
        +1
        inventos.ru/produkty/#top
        Когда начал заниматься организацией, как раз «очевидностных» статей мне не хватало. С остальным согласен, будет продолжение.
          +2
          Судя по вакансиям тестировщиков вы уже набрали :)
          Возможно мне это кажется очевидным, потому что я тестировщик, а менеджеры, особенно не айти-менеджеры или менеджеры не имеющие большого опыта, к тестированию относятся как к некой деятельности, которой если и нужно заниматься, то в одну из последних очередей. Кроме того в СНГ до сих пор есть некоторое предвзятое отношение к тестировщикам — как к людям если не второго сорта (с айти точки зрения), но уж точно как к менее ценным людям, нежели программисты. Впрочем, потихоньку ситуация исправляется.
          Впрочем, это лирика. В общем-же случае, таким менеджерам, которые «не в теме», мне кажется, имеет смысл прочитать какую-либо литературу о тестировании (да хотя бы «тестирование dot ком»), прежде чем строить планы и узнать, что же собственно это такое — тестирование.
        –5
        Уважаемые коллеги-айтишники!

        Пожалуйста не читайте это. Автор все напутал про тестирование.
          +2
          Просьба обосновывать подобные комментарии.
          +2
          Уважаемый автор. Статья действительно весьма специфична. И подходит для узкого круга проектов и команд.
          Вот если вы добавите в какой команде, на проекте какого типа это работает и какая задача у вашего тестирования, она заиграет новыми красками.

            +1
            и да. причем тут отдел тестирования? отдел-это люди, регламенты, оценка, инфраструктуре на тыщитыщ багов, инстансов и тд.
            вы говорите о каком-то минимально достаточном тестировании в условиях отсутсвия людей. правильно же понимаю?
              +1
              О начальном этапе, с чего начать, чтобы процесс начал развиваться.
                +1
                вот тут опять без постановки задачи непонятно. бывают проекты и команды, которые наоборот сводят тестирование к вот такому минимуму. Бывают проекты, на которых важно заколупываться в каждую деталь — ваша схема тут точно не пойдет)))
                Конкретизируйте в общем ;)
              +1
              Веб-проекты, часть из которых высоконагруженные системы. Команда состоит из тестировщиков, автоматизаторов и «нагрузочников», работают во всех проектах, планируя ресурсы. Задачи как и везде — тестирование для исправления и оптимизации, но в единой не хаотичной информационной среде с фиксацией реального состояния проекта.
              0
              Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования.
              Работал в аналогичной структуре руководителем проектов. Отдел тестирования был один, и из него выделялись сотрудники на проекты или отдельные работы. Естественно постоянно шла грызня между РП, кому достанется свободный ресурс тестирования. Для этого была предусмотрена система долгосрочного резервирования ресурсов, но она лишь частично снимала проблему. Как у вас это решается?

              И второй вопрос, подчиняются ли тестировщики в рамках проекта руководителю проектов? У нас было так, но здесь возникает проблема: РП обычно замотивирован на сроки релиза, при приближении которых начинает давить на тестировщиков. В результате качество тестирования может снижаться. Как вы с этим боретесь?
                0
                А что толку давить?

                Отдел рабработки ставит себе due date, а отдел тестирования ставит себе due date и все это на этапе планирования достаточно просто считается.
                В стиле команда делает неделю, функционал тестируется день-два. И никто ни на кого не давит. Невовремя отдали в тестирование сами виноваты. Давить тут нет никакого смысла.
                  0
                  Естественно все это планируется, но ведь тестирование (особенно финальное) иногда находит баги, иногда очень серьезные, и иногда прямо перед релизом. И тут-то все и начинается
                  0
                  Сделали общий календарь в google, доступный менеджерам (РП) и руководителям групп тестировщиков. Менеджеры заранее проставляют свои релизы, хотя бы приблизительно. Таким образом, все смотрят как бы на общую доску. Но и в этом случае бывают проблемы, но редко, решаются переговорами )
                    0
                    Ясно. Мы дошли до того, что планируется не более 3/4 времени тестировщиков. Остальное на срочные неожиданные задачи.
                      0
                      Самая большая проблема в таких ситуациях — решение через свой авторитет. Т.е. есть какой-нибудь СТО, который «круче» всех в компании и ему нужно, чтобы тестировщик сделал то и то. И он, не пойдя к менеджерам, не пойдя к руководителям, сразу идет к тестировщику и просит его сделать то и то.
                      Ну и тестировщик же тоже не скажет ему — идите дядя, к моему боссу, очевидно. Для этого нужен некий уровень осознанности и зрелости общей работы в компании. И получается в итоге неудовольствие всеми всех. Менеджеры не видят отчета, который не сделал тестировщик, потому что он был занят на другой задаче, о которой менеджер даже и не в курсе.
                        0
                        Ну и тестировщик же тоже не скажет ему — идите дядя, к моему боссу, очевидно.
                        Это почему не скажет? Именно так и должен говорить всем, вплоть до учередителей, включительно. Мы в свое время именно так эту проблему и побороли. Выбили и согласовали приказ по компании, что никаких задач исполнителям в обход регламентов. Все задачи строго фиксируются.
                        Были конечно желающие обойти, но руководство прекрасно понимало для чего это сделано, и таких желающих строго наказывало.

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

                        Правда есть как всегда и обратная сторона — ни один исполнитель больше не принимает устных заданий. Все через систему учета. Но это меньшее зло.

                        PS: здесь кстати помогает рассадка тестеровщиков и их руководителя в одном кабинете. Руководитель должен отслеживать несанкционированные «заходы», и разговаривать самостоятельно с таким ходоком.
                          +1
                          А ну, так вот именно. У вас это как раз
                          Для этого нужен некий уровень осознанности и зрелости общей работы в компании.
                          — т.е. выдали решение, указ компании и строго его придерживались, молодцы. До такого решения еще дорасти надо.

                          Правда есть как всегда и обратная сторона — ни один исполнитель больше не принимает устных заданий. Все через систему учета. Но это меньшее зло.


                          Возможно это слишком крутое решение. Решение, когда исполнитель принимает задачи от одного непосредственного начальника — вполне разумный вариант.
                          Хотя, с другой стороны, ваш подход позволяет легко автоматизировать всякую статистику — типа кто как работал, сколько сделал и т.д. было бы любопытно такую статистику увидеть даже самому — узнать, что ты этот месяц собственно делал :) Ну и начальникам очевидно проще мониторинг осуществлять.
                            0
                            Хотя, с другой стороны, ваш подход позволяет легко автоматизировать всякую статистику
                            Конечно. На эту статистику еще и KPI завязаны.

                            Решение, когда исполнитель принимает задачи от одного непосредственного начальника — вполне разумный вариант.
                            Да, но это только в иерархической системе управления возможно. Тестировщики были расшаренным ресурсом — в матричном подчинении у руководителей проектов. Если пускать весь поток задач через их линейного руководителя, он быстро становится узким местом.
                            Программисты чаще сидели на одном проекте, но некоторые тоже были расшарены.
                  0
                  При нагрузочном тестировании танк куда направляете и чем стреляете?

                  При тестировании отказоустойчивости прям продакшн роняете?)

                    0
                    Говорю про крупную кластерную систему:
                    При нагрузочном тестировании танк куда направляете и чем стреляете?

                    При предрелизном тестировании на тестовую машину с выкаченными последними правками, чтобы сравнить изменение производительности от релиза к релизу.
                    После выкатки проверяем в космосе (продакшен), но стреляем на отдельные компоненты и при необходимости выводим машины из балансировки.

                    При тестировании отказоустойчивости прям продакшн роняете?)

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

                    А приведите пример такой ситуации? Автотесты как раз и придуманы, чтобы уменьшать затраты и улучшать качество
                      +1
                      Автотесты, конечно, придуманы именно для этого, но в большинстве случаев этого не достигают. Во-первых, автотесты на системе с активным девелопментом — практически нереализуемое занятие. Только ты написал подробный хороший цикл автотестов на тестирование регистрации пользователей, как тут, переместили поля, добавили новое поле, сделали прочтение лицензии дополнительным шагом, добавили картинок и т.д. все тесты нужно переписывать. Не с нуля, конечно, но сам факт.
                      Так что автотесты имеет смысл писать на том, что не подразумевает меняться довольно продолжительное время. Да и то. Вот у меня есть конкретный пример на моей работе.

                      Работа связана с программным обеспечением для спутниковых ТВ-ресиверов. Так что, автоматическое тестирование подразумевает анализ видео-потока. И так, прямо скажем, не самая тривиальная задача, так еще нюанс в том, что весь бэкенд с нашей стороны черный ящик, да еще и находящийся на другой стороне земного шара. Так что периодически случаются сбои, дефекты, и т.д. и т.п. Это значит, что потратив кучу времени на создание фреймворка, который позволяет это сделать (времени реально много было потрачено), потратив энное количество времени, чтобы загнать туда тесты (тоже далеко не один месяц дело заняло), мы получили систему, которая может прогнать тесты примерно в десять раз быстрее, чем при ручном тестировании. Но. В том случае если случилась какая-то проблема — нужно просмотреть логи, дампы, что вызывает массу затруднений и отнимает кучу времени и в общем-то временной выигрыш практически нулевой. Так что теперь еще и систему разбора и анализа логов к этому нужно прикручивать.

                      С моей точки зрения, такая автоматизация вообще бесперспективное дело. Руководство правда считает иначе.
                        0
                        А приведите пример такой ситуации?
                        Тестирование интерфейсов, например. Пока напишите скрипт, который тыкает мышкой по кнопкам можно сто раз вручную прокликать. Но если интерфейс не меняется — можно один раз и потратиться.
                          +1
                          А выполняться потом этот скрипт будет тысячу раз. И выйгрыш во времени будет в 10 раз минимум в течении от силы первого года.
                          Решение надо принимать исходя из долгосрочности проекта и рисков что что-то отвалится критичное.

                          Помню работал в одной компании, которая писала софт для банков. Протестировать всю систему вручную стоило 2 человеко месяца (разработка велась всего лишь год). Команда разработки регулярно раз в месяц делала капитальные изменения в кодовой базе (чисто инфраструктурные изменения). Руководство бледнело, когда надо было фиксы выкатывать на продакшн раз в тот же месяц. Что делали? Выкатывали раз в месяц без тестирования и естественно факапились. Не знаю даже какая репутация потом была у нашей компании…

                          И я не понимаю, какие проблемы в правке тестов следом за правкой интерфейса — в том же коммите?
                            0
                            А выполняться потом этот скрипт будет тысячу раз. И выйгрыш во времени будет в 10 раз минимум в течении от силы первого года.

                            Иногда бывает достаточно одного раза, или 10 раз. А дальше проект не меняется.
                            И я не понимаю, какие проблемы в правке тестов следом за правкой интерфейса — в том же коммите?
                            Если тестирование интерфейса делается по принципу эмуляции мыши, то такой тест как правило требует длительной отладки, чисто по опыту сужу. Надо же не только прокликать в нужные места в нужном порядке с нужными таймаутами, но и обработать результат. Зато такой тест максимально приближен к действиям пользователя.
                            Решение надо принимать исходя из долгосрочности проекта и рисков что что-то отвалится критичное.
                            Безусловно! Тут масса факторов влияет, даже перечислять не буду. В первом приближении это актуально для долгосрочных тиражируемых продуктов (или веб-интерфейсов), где UI не слишком часто и не слишком сильно меняется.
                        0
                        Поспорю с глоссарием.
                        Тест-кейс ‒ шаги по достижению ожидаемого результата.

                        Часто у тест-кейса нет шагов. В том же TMS Testlink, много версий подряд было только поле «Описание» без шагов и ожидаемых результатов. И даже тест-кейсы без описания были тест-кейсами.

                        Тест-кейс (он же тестовый сценарий или test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнение определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]

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

                        Выделяют сценарии высокого уровня (90% для ручных тестов), и низкого уровня (90% для автоматических тестов). Низкого уровня те, что указывают на конкретные значения входных данных и ожидаемых результатов. Примечание про 90% — сугубо личная оценка, в конкретных случаях может быть не так.

                        Прогон ‒ выполнение тест-плана.

                        Не уточнено прогон чего, и оказывается, что это про весь план тестирования. Закрепилось в голове, что прогон, это прогон теста.

                        Прогон теста (test run) — выполнение теста на определенной версии объекта тестирования. [ISTQB]

                        «Тестирование» — наиболее подходящее общее слово, которое можно раскрыть как выполнение плана тестирования. У понятия тестирование есть и более развернутые определения, не затрагивающие другие определения.

                        Only users with full accounts can post comments. Log in, please.