Создать отдел тестирования — просто

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

    Вопрос эффективности и рациональности я ставлю во главу угла, поэтому вопрос быть или не быть практике тестирования нужно обсуждать не в этом разделе. Кому не нужно тестирование и кто хочет сделать это самостоятельно силами разработчиков — могут не читать далее :) или все-же взвесить аргументы:
    1. Профессия тестировщика не нуждается в обосновании, жизнь доказала потребность :)
    2. Независимое тестирование позволяет выполнять работу для нескольких подразделений, продуктов или проектов.
    3. Сложные виды тестирования требуют организационной формы для закупки инструмента, который будет использован (и амортизирован) для нескольких подразделений, продуктов или проектов.
    4. Тестирование на этапе приемки в корпорациях выполняется для большого спектра продуктов или технологий.
    5. Тестирование длительных жизненных циклов требует взаимозаменяемости участников и групповой (не только персональной) компетенции, например, тесты сопровождаемых систем со стороны заказчика или организации внедрения или сопровождения.

    Disclimer: универсальных рецептов не бывает, автор исходит из опыта создания и развития практики тестирования в крупных ИТ-компаниях и не претендует на истину во всех инстанциях :)

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

    C чего начать? Существует много нюансов, но попробую выделить основные принципы и детализировать их.

    Для чего?
    Отдел создается для:
    1. Формирования и развития профессионального центра компетенции (по тестированию) для более широкого круга задач.
    2. Более гибкого управления группами тестировщиков по проектам или продуктам.
    3. Выделения юридической ответственности за действия в Процессе тестирования.
    4. Финансовой независимости от отдела разработки и др. подразделений.

    Необходимо и достаточно:
    1. Желание и возможность вашего руководства организовать и содержать отдел (выделенная группа) для тестирования внутренних или внешних разработок. Желание руководства должно базироваться на финансовых возможностях — это инвестиции на несколько лет. Зарплаты сотрудников — не самое тяжёлое. В оптимальном варианте предстоит закупка или интеграция инструментов автотестирования и, возможно, ещё и вспомогательных средств — task/bug-трекинг систем, систем управления требованиями; необходимы версионные хранилища, оборудование или системы виртуализации для организации тестовых стендов и др.
    2. Наличие тест-менеджера — начальника отдела. Он должен понимать цели и задачи построения отдела, согласовывать все стратегические изменения с руководством, и совершенствовать процесс тестирования день за днём.
    3. Обучаемость сотрудников.
    4. Мотивированность сотрудников.

    Необязательные (развиваемые) требования, улучшающие эффективность:
    1. Совершенствование корпоративной культуры.
    1.1. Внедрение методологий разработки (Agile/SCRUM, RUP, MSF) с учетом взаимодействия групп/отделов.
    1.2. Разработка инструкций для сотрудников (с малой или большей степенью формальности).
    1.3. Разработка регламентов взаимодействия подразделений/команд проектов.
    1.4. Создание практики совершенствования методов через комитеты или т.п. (SEPG, ИТ-комитеты и т.п.)
    1.5. Обучение сотрудников как постоянная функция hr и руководства через запросы сотрудниками актуальных курсов.
    1.6. Team-building.

    Необходимость иметь выделенную практику тестирования есть у:
    1. Аутсорсинговых компаний полного цикла для обеспечения тестов при заказной разработке.
    2. ИТ-интеграторов (in-house, сервисных компаний и др.) для приемочного тестирования.
    3. Компаний-разработчиков (как минимум для нагрузочных видов тестирования).

    Продолжение планируется…

    Комментарии приветствуются!
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      0
      Краткость?
      Касательно создания отдела — самое сложное объяснить зачем нужен именно «тестер». Почему «те кто пишут, и сидят рядом — не могут проверить продукт самостоятельно».

      Плюсом, думаю, в 90% случаев отдел тестирования будет состоять из 1 человека. Он будет себе и тестеровщиком, и менеджером и «нагоняя-получателем».

      Касательно затрат: на первых порах самое дорогое это зарплата. Ибо первое время можно будет пользоваться и free версиями багтрекеров и продуктов. Благо, что они есть.
        +1
        Кстати, да. Я вот, как программист, не могу объяснить начальнице, зачем нам нужны отдельные тестировщики. Просто не знаю, какие доводы приводить, так чтобы не поставить себя же самого под удар.
          0
          А почему это должен делать программист? Вы будете начальником группы/отдела тестирования, тест-менеджером или собственно тестировщиком? Или пока таких ролей/людей нет — на вас висят задачи по тестированию?
            0
            Ответ очевиден — отдел тестирования не нужен потому, что программист должен лдибо писать без ошибок, либо эти ошибки быстро находить и исправлять. Потому что задача программиста — выдавать качественный продукт.

            Конечно с таким подходом на мне висят задачи тестировщика.
              0
              С точки зрения программиста ни отдел тестирования, ни тестировщик не нужны для проверки его кода. Юнит-тестирование — не для тестировщиков, на это указывают все учебники. Программист отвечает за свой код сам. Вникнуть полностью в его код может только такой же программист. Используйте парное программирование (ХР). Конечно, есть тестировщики, которые смогут это сделать, но это вопрос более тонкий (если они полностью будут в курсе любого кода, то либо они уже разработчики тестов, либо автоматизаторы, либо гуру — это не вопрос организации).
                0
                Это я понимаю.
                Но с определенной точки зрения, никакие тестировщики не нужны, потому что программист должен выпускать законченнный продукт как с отчки зрения программных ошибок, так и с точки зрения бизнес-логики и тому подобных широких задач.
                –1
                Потребность в тестировании — это взросление процессов в компании. Тестирование должно потребоваться руководству:
                1. для проверки интеграции, для функционального (системного) тестирования, для проведения сложных видов тестирования — нагрузочных, безопасности, для приемки продуктов от внешних поставщиков…
                2. для экономии сил разработчиков.
                3. для экономии денег — тестировщики как правило дешевле разработчиков
                4. для экономии времени — тестирование достаточно хорошо (коенчно, не полностью) параллелится с длительной, модульной/компонентной/проектной разработкой.

                Есть хорошие переводы обоснований необходимости, например, Джоэл Спольски «Пять (неуважительных) причин не иметь тестеров»(http://russian.joelonsoftware.com/Articles/TopFiveReasonsYouDontHave.html)
                  0
                  см. Джоэл Спольски «Для чего нужны тестировщики» и многое другое здесь, и там.
          0
          маловато будет…
            –1
            Тезисность, а не краткость. Все не охватишь в топике. Как видно из первых откликов — у всех свои проблемы, не характерные для той среды, где 10 лет я занимаюсь автотестированием.
            +1
            Обычно отдел тестирования состоит из одного тестировщика.
            А необходимость в нем простая и очевидная — снять непрофильную нагрузку с разработки. Кстати, скорость баголовства тоже учеличится.
            Кстати, вот топик про аутсорс в тестировании, тоже вариант:
            http://habrahabr.ru/blogs/startup/116166/
              –1
              Все зависит от задач. Я также могу написать, что на одного разработчика должен приходиться один тестировщик — это справедливо для некоторых отраслей. Или 2 разработчика на 1 тестировщика — это также массовый случай в индустрии. Наша практика и хабровский расклад показывают иное. К сожалению, я не внедренец и не собираюсь агитировать за тестирование, я прихожу туда, где уже ясно, что НАДО строить тестирование, причем на индустриальных инструментах, достаточно мощное, часто дорогое, всегда — кастомизированное по процессам.
                –1
                Указанное вами скорее некий новорожденный краудсорс, это не вариант для корпораций вообще. Если для аутсорсинга до сих пор стоит вопрос SLA, NDA, финансовой ответственности и доверия, то для такого «колхоза» — эти слова вообще/пока неприменимы.
                  –1
                  Впрочем, колхозы в свое время много хорошего сделали :) И сейчас, при адаптации к условиям, например, в Израиле, кибуцы очень эффективны и доходны, там, говорят, самые лучшие зарплаты и социальные гарантии, лучшие школы и пр. Будем посмотреть на рост и взросление нашего «тест-кибуца» :)
                    0
                    Для корпораций есть uTest (http://utest.com/), возможно что-то еще. Но там скорее приемочное тестирование, взгляд незамыленных глаз и отзыв потенциальных потребителей перед релизом. Полноценного внутреннего тестирования ни в коем случае не заменяет.
                      0
                      Какие корпорации в здравом уме отдадут приемку на аутсорсинг? Максимум — аутстаффинг (боди-шоппинг), т.е. использование людей и инструментов на своей территории. И зависит от видов тестирования, в этом согласен с вами. Апробацию сайтов и тесты пользовательского интерфейса — да. Но бизнес-критические решения все тестируют сами, иначе — риск потери компетенции и бизнеса.
                        0
                        Я об этом и написал в последнем предложении, может быть несколько неудачно выразился насчет приемочного тестирования, я думал, из контекста будет понятно, что имелось в виду.
                  –1
                  Один тестировщик, нет тестировщиков, нет денег на инструменты — это кейсы не для той темы, которую я описываю. Если подходить со стороны работодателя, то надо описывать доходность направления, если со стороны разработки — эффективность выделения тестировщиков в отдел (не обязательно отделять от разработки!, очень важно сотрудничать и дружить).
                    0
                    Не очень поняла, зачем на самом деле создаётся отдел. Централизованное управление ресурсами и знаниями, юридическая ответственность, финансовая независимость — это всё критерии устройства отдела, которые никак не отражают его эффективность.

                    А зачем вообще в компании тестирование? ИМХО ответ на этот вопрос — 90% успеха, но я его пока не вижу :)
                      –1
                      Зачем — это не вопрос топика. Цель статьи — КАК. Цель выбрана, есть опыт как решить вопрос.
                      Зачем в вашей в компании тестирование — ваш вопрос, хотите, отвечайте. Я отсылаю к Джоэлю Спольски.
                        0
                        Я видела в крупных компаниях эпик фейлы при оргиназиции отдела тестирования именно потому, что организаторы акцентировали своё внимание на процессе, а не на цели.

                        Понятное дело, что тестирование врядли будет конечным процессом с финальной целью, но определить, зачем оно нужно — необходимо. Иначе все «КАК» полетят в тартарары.

                        Тестирование может и качество повышать, и сроки разработки снижать, и стоимость проекта уменьшать, и почти всё что угодно. Но — только если эти цели вам известны и если вы понимаете, как их оценить.

                        Естественно, ИМХО.
                          –1
                          Да, вы правы, все это видели. И что? Никто за вас вашу цель не выявит и не решит. Статья описывает опыт и этапы. Каждый вправе как наступать на свои грабли, так и учиться на чужих ошибках и на успешном опыте. Вы вправе на вашем авто ехать куда угодно, в том числе и в кювет, автошкола за вас не решит, куда вам ехать в текущем состоянии.
                        –1
                        Ответ на вопрос — не может быть успехом, т.к. тестирование — не ребус, а процесс. Процесс — это деньги, методы и люди. Не надо утрировать и на пальцах решать интегралы :)
                          –1
                          Любой желающий может написать ЗАЧЕМ создавать отдел тестирования. И любой может ему противоречить. У меня нет готового ответа на этот вопрос. Я, конечно, много чего могу сказать в связи с этим, но ответить — увольте. У меня есть опыт создания и развития — welcome или мимо :)

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

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