0,0
рейтинг
17 июня 2012 в 19:01

Разработка → Тестирование: Ручное или Автоматизированное?

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:
  • Модульные тесты с покрытием около 50%
  • Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
  • Пересечение из гибких методологий под общим названием ScrumbanXP


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



Шаг 1. Тестировщиков нет



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

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

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

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

Судя по опросу, который я проводил Как у вас устроен процесс тестирования? большинство может позволить себе именно такой подход к тестированию.

Шаг 2. Начало автоматизации тестирования



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

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

Идея была проста и для всех казалась решением проблем. Мы хотели, чтобы CI запускала ночью набор интеграционных тестов. Утром мы приходим, если тесты все зеленые, то значит можно делать релиз. Если есть красные тесты, значит исправляем, снова запускаем весь набор тестов и т.д. пока все тесты не станут зелеными.

Для записи тестов попробовали разные варианты, остановились на Selenium. Сначала тесты писали на API самого Selenium. Со временем начала создаваться обертка над низкоуровневым API и эта обертка превращалась в некий DSL для тестирования.

Пока тестировщик разбирался с продуктами для тестирования и налаживал процесс автоматизации тестов разработка не останавливалась. Мы должны были выпускать новые версии после каждой 1-2 итераций. Тестировщик постоянно находился в стадии погони за программистами. Его цель была 100% покрытием сценариев, чтобы мы могли спокойно выпускать новые версии не боясь багов.

Шаг 3. Борьба за зеленые тесты



Проблемы с автоматизацией тестирования оказались для нас неожиданными. Фактически мы не были к ним готовы.

Долгая обратная связь


Чем больше была система, тем больше мы писали тестов. Тесты начали работать реально медленно. Если они проходили за 14 часов — это была невероятная удача. Со временем тесты перестали укладываться в промежуток между 18.00 прошлого дня и 9.00 текущего дня. Мы не получали от тестов обратную связь, возникали простои в работе. Бывало еще, что свет выключат или сервер перезагрузится, тогда потери времени были слишком большие.

Зеленые тесты? Нет, не видел


Зелеными тесты не были никогда. Правда один раз были, 30 декабря они запустились и выдали результат как 100% зеленые. Наверное это был их подарок нам на Новый год. Больше такого за всё время не было.

Почему они не были зелеными? Для этого было несколько причин:

  • Хрупкие тесты — интерфейс постоянно менялся и тесты не успевали за этими изменениями.
  • Негибкие тесты — архитектура системы постоянно совершенствуется, находятся обобщающие решения для гибкости кода. Код тестов (описание) тоже надо рефакторить и обобщать, чтобы их было легче поддерживать. Например, у нас должно появиться много типовых workflow с незначительными изменениями. Разработчики
    придумывают архитектуру, которая будет достаточно гибкой, чтобы позволять
    быстро реализовывать эти workflow. Соответственно, архитектура тестов должна
    совершенствоваться аналогично и «успевать» за совершенствованием архитектуры
    кода, чего сделано не было из-за недостаточной квалификации тестировщика. Из-
    за того, что архитектура тестов «не успевает» за архитектурой кода, программисты
    реализуют фичи всё быстрее и отставание тестировщика накапливается
  • Минорные баги — тесты не всегда находили критические баги, иногда они падали из-за незначительных багов-недочетов, о которых мы знали, но исправлять их было не приоритетно. Для этого даже специально сделали плагин для TeamCity и можно было смотреть должен тест упасть или нет. Набор падающих тестов с минорными багами не давал тестам быть зелеными.
  • Нечитаемые тесты – например, у нас есть сложный сценарий с большим
    количеством действий, результат которого нужно протестировать. Соответственно,
    тест нельзя разбить на несколько мелких (проверяется не промежуточный результат,
    а конечный, который достигается в результате нескольких действий). Код такого теста
    нужно оптимизировать так, чтобы он оставался понятным и читаемым, чего также не
    удалось добиться.
  • Длинные сценарии — чтобы реализовать длинные сценарии нам надо сделать, например, 10-20 шагов. Промежуточный результат не важен, важен только конечный. С длинными сценариями возникает ряд проблем:
    • Если на 2-м шаге произошла ошибка, то ошибочным считается весь сценарий. В этом случае красный тест говорит не об ошибке в том, что он тестировал, а в ошибке шага, который был где-то в начале (могли поменять интерфейс Входа в систему).
    • В длинных сценариях шаги часто повторяются, возникает дублирование.
    • Длинный сценарий нельзя начать с середины, потому что для этого придется готовить специальное состояние системы, в котором она должна быть к N-му шагу. Это вносит дополнительную хрупкость в структуру тестов.



Из-за нестабильности тестов и того, что мы не успевали актуализировать их, нам пришлось:

  • Переключить разработчика, чтобы он помог тестировщикам перейти на SpecFlow, иначе тестировщики не удерживали объем тестов на C# коде. Руководитель отдела тестирования на тот момент делала доклад на тему Приемочные тесты на огурце
  • 70% времени тестировщики переписывали автоматические тесты, чтобы они соответствовали текущему набору функций системы. Т.е. это была работа ради самих тестов.
  • Как следствие из вышесказанного — мы наняли еще тестировщиков.


Достигнута ли цель?


У нас была цель — увидеть зеленые интеграционные тесты и, не боясь багов, залить на боевой сервер. Фактически мы этой цели так и не достигли.

Как итог, первый же запуск системы в реальных условиях показал, что автотесты пропускают множество багов. Эти баги мы нашли, когда вручную потыкали систему. За 10 минут ручного тестирования были обнаружены самые критичные баги.

Я волевым решение отменил работу по всем интеграционным тестам и ввел ручное тестирование с написание тестовых сценариев в Google Docs. После этого мы добили основные баги и тестирование отлично встроилось в Kanban поток.

Текущее состояние



В данный момент в моей компании мы с командой тестировщиков придерживаемся подхода: ручное тестирование + написание тестовых сценариев в Google Docs. Тестировщики вручную протыкивают все сценарии перед заливкой.

Тестовые сценарии считаются частью артефактов проекта и отдаются заказчику вместе с исходным кодом.

По факту это дает отличные результаты. В релизах у нас только минорные баги, либо баги, которые на самом деле фичи.

Против автоматизации тестирования?



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

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

Если вы хотите заменить ручное тестирование автоматическим на 100%, то подумайте, как избежать проблем описанных выше. Возможно нам надо было сначала использовать ручное тестирование, а потом, автоматизировать те части, автоматизация которых даст максимальный эффект без необходимости поддерживать эти тесты.

Буду рад услышать, как развивалось тестирование в вашей компании.




Ссылки

Top Five (Wrong) Reasons You Don't Have Testers, Joel Spolsky
The Joel Test: 12 Steps to Better Code, Joel Spolsky
Обезьянки против роботов. Часть I (TestLabs09), Максим Дорофеев
Обезьянки против роботов. Часть II (TestLabs09), Максим Дорофеев
Обезьянки против роботов. Часть III (TestLabs09), Максим Дорофеев
Организация работы команды в Agile: разработка + тестирование
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (60)

  • +4
    Мне показалось, или в тексте проскакивает какое-то неодобрение результатов работы ваших тестировщиков?
    • +6
      В тексте должно читаться неодобрение моей оценки результатов с точки зрения управления (моего управления). Надо было сначала сделать 100% ручное тестирование, а уже потом автоматизировать. Я об этом в последних абзацах писал.
      • +1
        Не-не. Я про:
        Соответственно, архитектура тестов должна
        совершенствоваться аналогично и «успевать» за совершенствованием архитектуры
        кода, чего сделано не было из-за недостаточной квалификации тестировщика.

        и еще вот про:
        Руководитель отдела тестирования на тот момент делала доклад на тему Приемочные тесты на огурце
        • +2
          Первая часть была написана самим руководителем отдела тестирования. Он делал ревью этой статьи и добавил как раз этот текст :) На самом деле тестировщикам было тяжело автоматизировать свою работу, очень часто переключали на эти задачи программиста.

          Про вторую часть, использование SpecFlow стало почти прорывом для нас. Расскажу как мы на него перешли. Сначала код тестов был написан на C# и в определенный момент его стало очень тяжело читать. Мы решили записать сценарии в Excel-файле. После записи нескольких сценариев нас осенило, ведь тоже самое можно по-русски написать в SpecFlow и запускать в виде тестов. Выступление Алены содержит реальные преимущества от перехода на SpecFlow, там даже пример из проекта был. Правда в конечном итоге значительных результатов для нас это не принесло.
  • +5
    Работал на 3 проектах с похожими входными данными и наличием автоматизации гуй-тетирования.
    На первых двух в той или иной степени проявились перечисленные выше ошибки.

    Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.
    Вторая заключается в непонимании факта, что автоматизация является разработкой ПО, к ней нужно писать требования, ставить цели, считать рентабельность и прочее.

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

    И сейчас есть масса проблем, по большей части в функциональности, связанной со временем: фичи работающие асинхронно, срабатывающие по событиям, обрабатываемые в очереди с недетерминированным временем прохождения.
    • +1
      > Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.

      Точно, про это у меня вывод в последних абзацах, согласен с вами.

      >… автоматизация является разработкой ПО

      В точку.

      > На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия.

      Поделитесь, у вас отдел тестирования интегрирован в команду по проекту или отдел тестирования занимается всеми проектами, которые проходят в компании? Кто составляет регламент? Кто и как несет за выполнение регламента ответственность?

      Мне, да и не только мне, ответы помогут сориентироваться с организацией в своей компании.
      • +3
        В команду разработки интегрировано ручное тестирование, «персональный программист тестировщика» (или наоборот) с оговорками. Автоматизация тестирования — отдельно, на несколько проектов.

        Внутренний регламент работы тестировщиков — авто и не авто — составляют они же.
        Регламент, касающийся работы других участников — согласовываем с ПМом и разработчиками.
        Требования нам сильно помог создать руководитель разработки, у него богатый опыт.
        Ответственность за тесты несет тимлид автотестеров перед заказчиками — ПМами проектов.

        В моих целях — создание микрокоманды аналитик+(авто)тестер+разработчик для каждой фичи. Это обеспечит скорость и глубину.
        В противовес этой модели — отдельная группа автотестирования, хоть и немного оторвана от текущего контекста, но имеет большой плюс — отношения «заказчик-клиент». Это позволяет избежать написания тестов ради тестов, позволяет покрывать тестами актуальные фичи.
  • +1
    ну нельзя же из одной крайности в другую кидаться. Полезно иметь набор автоматизированных тестов, которые покрывают хотя бы основные более-менее стабильные части продукта, либо писать по тесту на каждый найденный баг, чтобы перед выпуском в production делать регрессионные тесты. Регрессионные тесты — это самая нудная часть, поэтому всем хочется на них забить, а как раз тут-то баги и вылазят, когда чинили что-нибудь одно — поломали в другом месте.
    • +2
      У меня до сих пор есть мечта автоматизировать тесты, чтобы каждый раз не протыкивать всё с начала.

      notacat взгляните дальше первого релиза. У вас есть набор тестов, которые были актуальны для первой версии. Кто и что будет делать с этим набором во второй версии? В 3й? В 20ой? Их надо поддерживать, актуализировать, рефакторить. Вот тут начинаются проблемы.
      • +2
        Ответ есть тут. В кратце: тесты — это часть продукта. Кто сломал — тот и чинит (желательно сразу).

        Версии не с нуля пишутся; обычно между версиями нет революционных изменений. Продукт до них эволюционирует. Так же и тесты — как часть функционала (который чем меньше — тем лучше) — тоже должны эволюционировать вместе(!) с генерирующими бизнес-ценности частами, являться их неотъемлемой частью.
      • +3
        тут все от специфики продукта зависит. Вот мы пишем контролы, и если релиз состоялся, то скорей всего публичный интерфейс не будет ломаться (только расширяться) до тех пор, пока это не уйдет в легаси, некоторые вещи живут больше 10 лет, а очередные версии выпускаются несколько раз в год. Поэтому и тесты живут долго. Но конечно, и тесты надо поддерживать, рефакторить и т.д…
        • +1
          > тут все от специфики продукта зависит

          Согласен. Я рассказывал про заказную разработку с частыми релизами. Вы поделились опытом разработки продукта с релизами раз в год.

          Предлагаю здесь добавить описание ваших проектом и специфику их тестирования.
          • +1
            сейчас у нас 3 раза в год, плюс куча промежуточных билдов с хотфиксами, которые мы публикуем.
          • +4
            описание наших проектов на www.componentone.com. Тиражируемый софт, контролы и компоненты для .Net.
            У нас QA полностью отдельный, т.е. отдельные люди, со своим отдельным начальством. Мы с ними синхронизируемся на уровне квартальных планов. Т.е. они делают и ручное, и автоматизированное тестирование, но это не интегрировано в наш рабочий процесс. Если есть критичные места, которые надо покрывать юнит-тестами — то это полностью на разработчиках.
            Что интегрировано в разработку — это автоматические билды на сервере после коммитов. Если очередной билд сломался, то автоматически создается баг и присваивается на того разработчика, который делал последний коммит. Тут никаких дискуссий по поводу «кто должен чинить» не возникает, потому что если билд на сервере не проходит, то нечего отдавать в QA и это может помешать другим разработчикам работать над своим кодом.
            QA получает готовый билд, сэмплы, документацию и уже со всем этим работает. Они знают, кто из разработчиков за какой продукт отвечает, и сами расписывают баги по разработчикам. Они же определяют критичность багов и какие баги должны быть обязательно исправлены до релиза. Уже разработчики между собой могут этот баг передать, если видят, что на самом деле проблема где-то в чужой области ответственности. Пофиксенный баг опять автоматом присваивается тестеру, который его нашел, и при следующем билде все начинается сначала. Закрыть баг окончательно может только QA.
            Кроме QA баги может постить тех.саппорт (если они смогли их у себя воспроизвести), такие баги всегда имеют более высокий приоритет. Ну и еще у нас есть публичные форумы, где каждый разработчик обязан отвечать на вопросы в пределах своей компетенции как минимум раз в неделю. Кстати, очень много багов приходит именно с этой стороны, никакой QA не может вообразить себе, куда люди засунут наши контролы и что с ними сделают.
            • +1
              Про «автозаведение бага по последнему коммитившему» — поподробнее пожалуйста! :)
              У вас 1 коммит на 1 билд? Сколько идет билд по времени? Если соотношение не 1 к 1 соотношение — почему на последнего коммитившего?
              • +3
                сначала делали 1 билд на 1 коммит, в какой-то момент стало сильно не хватать билд серверов, сделали раз в сколько-то времени. Автоматически определить, чей именно коммит сломал билд — невозможно. Поэтому на последнего, кто коммит делал, баг присваивается. Но в билдлоге пишется список всех последних коммитов, поэтому тот, кому этот баг упал, имеет возможность откреститься и отправить его по адресу. Это проще, чем заставить кого-то одного следить за билдами и назначать ответственных.
                А вот как это технически делается, не знаю, у нас TFS, по всей видимости где-то на сервере скрипт написан, который баги раскладывает. И кроме багов еще e-mail приходит о сломанном билде. Мы не мгновенно к этому пришли, где-то с год устаканивались с тех пор, как на TFS переехали.
                • +1
                  Очень дельная мысль!

                  У нас сейчас от TeamCity приходят письма всем авторам коммитов, попавшим в билд. Кто первый на кого ответственность переложил — тот и молодец. Если никто долго не берет ответственность (почту не смотрел никто, разбираться лень) — разобраться должен ответственный за компонент QA… в теории. :)

                  Надо у нас попробовать такие баги писать.
      • +1
        наверное, в общем случае менедмент должен оценить соотношение цикла жизни продукта, затрат на разработку/тестирование, потерь от багов ушедших в релиз и т.д., и т.п…
        Но если вы планируете, что версий продукта будет больше 3х, и вы не будете каждую версию делать с нуля, то поддержка актуальных тестов должна окупаться. Можно обсуждать объем тестов, покрытие, но совсем отказываться я бы не стала.
  • +5
    Я тут напишу свое мнение с точки зрения автотестера :)

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

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

    Правильнее было бы:
    • обязать разработчиков самим писать юнит-тесты на свою новую функциональность, простейшие интеграционные тесты;
    • считать минимальный набор тестов одним из критериев завершенности фичи;
    • добиться прохождения юнит-тестов и базового набора интеграционных (обзовем его Smoke) в один-два часа максимум (если Selenium — постараться использовать Selenium 2.0 и HtmlUnit);
    • ввести принцип «кто сломал — тот чинит». Тестировщик следит за состоянием билдера и цветом тестов. Как только имеем сломанный тест, отыскиваем (с помощью того же TeamCity) коммит-источник проблемы и пинаем разработчика-ломатора или чиним сами — если умеем :);
    • по приоритетам программистов: починку тестов считаем блокером или как минимум мажором;


    Задачами, собственно, тестировщика-автоматизатора становятся контроль за покрытием функциональности тестами, написание сложных сценариев. Если квалификация тестировщика позволяет — доверяем поддержку инфраструктуры тестирования: фреймворки, обвязки, помощники и т. д.

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

    Автоматизированное тестирование — не панацея. Как минимум эксплорационное тестирование нетривиально автоматизируется.

    Одним предложением: «не одни тестеры, но вся команда в полном составе ответственна за качество».
    • +1
      Правильный, хороший, но сложно реализуемый подход.
      При робких намках на что-то подобное сталкивался с:
      1. «Эти Ваши тесты опять сломались»
      2. Программистам нужно писать фичи, скоро релиз править баги, стоять на скрам митинге, тесты чинить некогда.
      3. А вас зачем наняли?

      Если изначально строить процесс разработки то получится, переучить людей много сложнее да и необходимо понимание проблемы руководителем проекта, а это, что характерно, не всегда бывщий разработчик или тестировщик.
      • +3
        Если пункт 1) говорит тестировщик — он должен указать кто и когда сломал (вплоть до строк с поломкой, на diff-е коммита видно :) ).
        Если говорит менеджер — тестировщик выполняет команду «Найти негодяя».
        Если часто так говорит менеджер — тестировщика оставляем без премии или баним менеджера по IP на билдере (нечего людям работать мешать).
        Если программист так говорит — пусть сам разбирается.

        Ситуация 2) сложнее и, опять же, смотря кто ее поднимает. Если менеджер:
        • надо выяснить северити — импакт по функциональности конечного продукта;
          баги в баг трекере (расписать импакт, в терминах бизнес-процессов описать проблему и путь воспроизведения);
          довести до руководителя баг, дать ссылку на трекер
          следовать обычным процессам QA

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

          Пункт 3) не самый интересный. Разработчик автотестов (он же SDT/SET: software developer in test, software engineer in test) — это, фактически одновременно QA и разработчик в одном лице. Ни один тестировщик (даже «ручной») не сможет в одиночку (или командой QA) обеспечить «качество».

          Качество дают программисты и тестировщики, и аналитики, и художники-дизайнеры. Это всё — разработчики продукта. Они все до единого ответственны за конечный продукт, за свою работу.

          Вот как это объяснить руководитству (и надо ли объяснять, если сразу не понятно) — вопрос. Потому что если руководитель проекта не понимает, что качество обеспечивает вся команда — это как минимум некомпетентный руководтель проекта.
        • +1
          Ах, забыл закрыть какой-то тэг… Ну почему ж я предпросмотр-то не нажал?
    • –1
      Спасибо, я думаю, что стоит попробовать ваш подход, в нем есть логичная структура.

      Обратите внимание, что наши разработчики писали модульные тесты и даже тесты на JavaScript, которые гонял TeamCity.

      Тем не менее я увидел в комментарии Wolonter habrahabr.ru/post/145974/#comment_4910764 то, с чем сам сталкивался.

      Wolonter не зря написал «Эти Ваши тесты опять сломались». Разработчики не хотят заниматься тестами, это факт. Можно придать разработчикам мотивации, можно сделать, чтобы их хотя бы не тошнило после дня парного программирования с тестировщиком, но это будет временно. Всё-таки тесты — это работа тестировщика.
      • +2
        Да, такое есть. Но! Когда разработчик будет писать тесты сам — он не будет говорить, что это «ваши» тесты — он будет их чинить. Потому что это его правка поломала его же тесты.

        Программист — такой же наемный рабочий, получают ЗП за результат — работающий проект. О каком «не хотят заниматься» может вообще идти речь? :) И если ручные тестировщики не успевают писать баги, если серверное ПО падает от каждого чиха — это надо решать, вплоть до кадрового вопроса.

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

        Что есть «парное программирование с тестировщиком»? Тестировщик читает код, который пишет программист? Без квалификации — бесполезно в принципе. Парное программирование — вообще не панацея. Очень сильно зависит от контингента и воспитания.

        Работа тестера — озвучить проблемы, с которыми столкнется конечный пользователь если получит текущий продукт.

        Задачей же всей команды (и в первую очередь ПМа) — сделать так, чтоб в любой момент разработки продуктом можно было нормально пользоваться: а это всего лишь значит, что пользователя не должно тошнить от пары недель работы с корпоративной системой учета времени, которая падает каждый три минуты (уже приоритет — мажор), да еще и данные теряет (а вот сейчас приоритет подымается до блокера и виновата в этом вся команда).

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

        И, кстати, проблема «надо писать фичи, а не баги чинить» — совсем не проблема автоматизации.
        Это проблема менеджмента, планирования буфферов времени, оценки рисков.

        Думаю, фимоз головного мозга — это самая большая проблема менеджмента вообще, а в IT она цветёт очень ярко.

        Особенно это заметно в гос-секторе, в котором вбухиваются немереные средства в посредственные работы, с кучей фееричнейших блокеров в основых сценариях использования.
        • 0
          Кстати, в источниках статьи у Спольски есть пункт «5. Do you fix bugs before writing new code?» — это оно и есть :)
    • +2
      Зачетный набор советов.
      У нас на проекте больше тысячи функциональных тестов. Используем Selenium(WebDriver). Запускается все это чудо на Jenkins, где подготовлено около 30 виртуальных машин. В сумме от от нажатия кнопки «build» до получения готового к релизу билда (на котором все юнит и функциольные тесты зеленые) проходит минут 40-50.

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

      Как-то собрались все вместе и решили, что функциональность-то наша, и будем сами покрывать ее этим самым минимальным набором тестов, при этом постепенно приведем тестовый фреймворк в порядок. Стало полегче.
      При этом осталась проблема нестабильных тестов. Договорились что каждый день один из программистов будет «ответсвенный» за билд. Если тест упал, и упал по нестабильности, разработчик его чинит. В команде 7 человек, так что это было не так напряжно. Сначала тесты было чинить непросто, т.к. проблемы выявлялись повсюду (то в Selenium, то сам тест был очень хитер). По немногу выделили многие паттерны нестабильности, сейчас без причины падает каждый 5-ый а то и 10-ый билд. Кстати в красный билд комитить нельзя:-)

      Выводы думаю понятны. А вот от себя могу добавить важный итог — когда я делаю довольно серьезные изменения в коде, я без страха смотрю в будущее, т.к. цвет билда буквально через часок подмигнет мне о том, что же такого я накодил. Стало действительно легче и быстрее делать серьзеные изменения.

      P.S. Релизы выпускаем где-то раз в месяц. Стоит признать что продукт уже довольно устоявшийся, мы скорее добавляем новые области, чем серьезно меняем существующие.

  • +1
    >>написание тестовых сценариев в Google Docs
    Можете привести пример подобного? Интересует как именно у Вас это выглядит.
    • +1
      Сейчас сценарии сгруппированы на листах Excel по функциональности и на каждом листе есть колонки:
      1. Название — «Отображение списка задач в деталях заказа»
      2. Сценарий — пошаговая инструкция
      3. Ожидаем — несколько пунктов про ожидания после сценария
      4. Ссылка на UserStory — в нашем случае AgileZen
      • 0
        Вопросы:
        1)
        У Вас нет уровня важности? Каким образом Вы понимаете что тот или иной сценарий нужно выполнять раньше чем другой?
        2)
        Я правильно понимаю, что под «пошаговая инструкция» понимает алгоритм действий с продуктом как это во втором варианте комментарий ниже?
        • +1
          1) Уровня вложенности нет. Сценарий тестирует User Story, она сама по себе может быть, без следования за другой User Story.

          2) Да, очень похоже
          • 0
            Еще вопросы, если не сложно:
            1)
            А как у вас коллекционируются тест-сценарии? Интересует как вы их организовываете чтобы не заблудиться в них.
            2)
            Есть ли у Вас какая-либо «бюрократия»?
            • +1
              1) В основном на каждую группу делается отдельный лист в Excel (точнее в таблице в Google Docs). Группа делается по функциональности, например, Вход на сайт. Работа с Проектами, работа со Счетами т.п.
              2) После проверки сценария надо отметить кто и когда его проверял. Это делается в строке со сценарием. Если произошел баг, то надо добавить ссылку на описание этого бага.
              • 0
                Также интересует как у Вас организован «распил бюджета человеко-времени», т.е. учет человеко-времени выделяемое на тестирование. Волнуют следующие случаи:
                1)
                Фича только что реализована, никто еще не знает сколько по факту в часах может занять ее тестирование. Что делаете? Собираете 2-3 эксперта и даете предварительную оценку или не паритесь и ждете окончания работ и записываете полученный опыт. Возможно у Вас как-то по-другому интересно как?
                2)
                Отличается ли у вас человеко-время отводимое на тестирование релиза и обновления, если да, то почему и чем?
                • 0
                  1) На проектах, где оплата почасовая, время тестировщика включается в счет. Где оплата фиксированная, мы делаем оценку проекта, которое включается работу тестировщика.

                  2) У нас не отличается. Опять же может зависеть от типа обновления, возможно оно совсем маленькое.
  • +3
    Александр, а как вы, кстати, SpecFlow использовали, что-то типа такого:

    Дано пользователя «Ваня» нет в системе
    Когда я создаю нового пользователя «Ваня»
    Тогда я могу залогиниться под пользователем «Ваня»


    Или
    Дано зайти под пользователем ‘admin’/’admin’
    И Кликнуть на ссылку «Администрирование»
    И Кликнуть на ссылку «Пользователи»
    И Удалить пользователя «Ваня»
    Когда я на Главной странице
    И я кликнул на ссылку «Регистрация»
    И я заполнил поле Имя: Ваня
    И я заполнил поле Фамилия: Иванов
    И я заполнил поле Пароль: kjHKJKJhjkhU*IKL:”1
    И я заполнил поле Подтвердите Пароль: kjHKJKJhjkhU*IKL:”1
    И я нажал на кнопку «Регистрация»
    И я ввел в поле Логин: Ваня
    И я ввел в поле Пароль: kjHKJKJhjkhU*IKL:”1
    И я нажал на кнопку «Вход»
    Тогда я должен увидеть надпись «Привет, Ваня!»


    И что такое для вас сложный сценарий?
    • +1
      Дмитрий, мы использовали второй вариант с множеством шагов.

      Под сложным я понимал кол-во шагов больше 5-6.
      • +2
        Александр, я бы еще хотел порекомендовать вам посмотреть на bddify или StoryQ. Я ничего плохого не могу сказать про SpecFlow, сам пользуюсь этим фреймворком, но только в случае высокоуровневых сценариев. Для меня правило – что любой сценарий на SpecFlow должен состоять из трех строк максимум: один Given один When и один Then, который бы в общих чертах объясняли что делает сценарий. Вся сложная логика и детали у меня зашита в слое автоматизации на C#.

        Вторым фреймворком я использую bddify, который позволяет разделять тест на блоки Given When Then и генерировать красивый отчет после прогона.

        Вся бизнес логика работы приложения у меня находится в слое автоматизации, который я называю Тестовой Моделью. Там все логические страницы приложения задекларированы с использованием Page Object и DSL, вот например, следующий тест пересоздает пользователя и пробует залогинится:

        string username = “Admin”;
        string pass     = “Admin”;
        User.ReCreate(new UserParams() { Name = username, IsAdmin = true, Password=pass} ); // DSL
        
        var loginPage = new LoginPage(); // Page Object
        MainPage mainPage = loginPage.Login(username, pass);
        
        Assert.IsTrue(mainPage.Exists);
        


        В общем, в первую очередь, я старался добиться чтобы чтобы и на C# тесты смотрелись не плохо. Только потом я начал прикручивать SpecFlow и Bddify, с мыслью о том, что скорее всего в будущем я могу перейти на дргие тестовые фреймворки, но сам слой автоматизации останется не тронутым.

        У меня есть длинные многострочные сценарии, из 10 – 15 шагов. Для их создания я использую Bddify, потому что в основном, написать на C# такой сценарий легче – и переменные можно использовать и контроля над кодом больше.
        В SpecfLow я тоже изобрел свои велосипедо-переменные, но получилось не так эффективно как на C#.

        • 0
          Спасибо за ссылки.

          В вашей команде программисты участвуют в автоматизации тестирования?
          • 0
            Нет, наши программисты тестов не пишут. Раньше писали юнит-тесты время от времени, но сейчас нет.
            Автоматизированы у нас основные CRUD операции и инсталляция/конфигурация приложения. Перед началом моего рабочего дня тестировщика: скачан, проинсталлирован и сконфигурирован новый билд – и прогнаны основные тесты. Этого пока достаточно и поддержки требует минимум.

            На моем текущем проекте эффективны средства полу-автоматизации: вот например, скрипты для отслеживания изменений в таблицах БД или xml файлов, слежка за HTTP запросами при помощи Fiddler’а, скрипты сигнализации об ошибках в логах приложения.
            И сейчас осваиваю mdbg
            И основная проблема пока что не в том, чтобы готовый код выполнялся корректно, а в том, чтобы правильно понять чего же хотят пользователи нашего продукта. Это уже процессная проблема. В таких условиях хорошо работают простые тесты и полу-автоматизированные инструменты, которые позволяют исследовать продукт быстрее.

            Кроме того, пользователи нашего продукта модифицируют свои базы данных, расширяя размеры полей таблиц, добавляя триггеры и даже используя некоторые баги как фичи (например XSS уязвимости для вставки ссылок на свои файлы). В таких условиях, конечно же, более эффективно работает мануальное и исследовательское тестирование с использованием полу-автоматических инструментов.
  • –2
    О! Поддерживаю все что сказано в статье. Частенько тут высказывался в этом свете, но меня любили за это минусовать, и высказывать, что-то типа «просто не умеешь готовить автоматические тесты». В итоге, я уже подумывал — а может стоит попробовать… ан, нет — теперь вижу, что и смысла нет начинать. Итак, мы на верном пути :)
    • 0
      Я уже писал вышел, всё еще не отказался от этой идеи. Просто автоматизировать надо самое нужное и делать это так, чтобы не приходилось поддерживать. Возможно скоро выйдет новое поколение инструментов для тестирования и тогда всё изменится.
      • +1
        Бред. Тесты — часть продукта. Не бывает «чтобы не приходилось поддерживать»! Продукт меняется — меняются тесты. Если функционал не поменялся — не меняются тесты. Какие бы то не было изменения в поведении продукта будут всегда за собой тянуть изменения тестов.
        • 0
          Речь о рентабельности поддержки тестов (речь про интеграционные тесты). Если дешевле и эффективнее тыкать руками, то нет смысла автоматизировать тесты.
          • 0
            Рентабельность поддержки — совершенно другой вопрос. Из каких слов следует ваш этот коментарий?

            Вы пишете, что с выходом новых инструментов не придется переделывать тесты, когда меняется продукт. Так вот: это — неправда.

            Если уж говорить о рентабельности, выбор писать автотесты-не писать автотесты (что юниты, чтоб интеграционные) надо делать осознанно. Например, попробовать применить известную формулу возврата инвестиций, учесть частоту запусков автотестов, учесть покрытие, работу по поддержанию автотестов. И аналогичные работы для всего этого объема, производимые вручную.

            Вот тогда можно говорить о рентабельности.

            И да, вы б почитали свою ссылку на Джоэля Спольски. Там все очень хорошо написано, зачем и почему нужны автотесты и почему их стоит использовать совместно с ручными тестировщиками.
            • –2
              > Вы пишете, что с выходом новых инструментов не придется переделывать тесты, когда меняется продукт. Так вот: это — неправда.

              Трудно оценивать инструменты, которых еще не существует :)

              > И аналогичные работы для всего этого объема, производимые вручную.

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

              > И да, вы б почитали…

              Как не странно я ее почитал.

              linuxoid я бы предложил вам быть менее ортодоксальным в суждениях, вы ведь не знаете специфики потока в заказной разработке, где я работаю.
  • 0
    Хочется еще раз задать вопрос по поводу:
    Например, если вы пишите жука, который отлавливает ошибки 404 и 500 на живом сервере

    Может ли кто-нибудь привести примеры подобных инструментов? Что используется/как это интегрируется, например, с билд-сервером?
    • 0
      С билд-сервером жука наверное нет смысла интегрировать, он должен в текущем режиме проверять работоспособность системы.

      Я писал 2 вида этих жуков:
      1. По метаданным IIS берет данные про сайт, ходит по всем сайтам, которые есть на сервере, чтобы убедится, что сайты работают
      2. Жук делается по данным ASP.NET MVC, это на много проще. Формирует возможные URL для Get-запросов и пытается на них перейти


      В обоих случаях, когда есть 404 или 500, то шлет письмо/смс ответственному.

      Я думаю, что подобные жуки для Ruby, Python и других языков есть уже готовые.
      • 0
        Спасибо, идея по asp.net mvc очень любопытна
  • –2
    и для начала мы решили, что тестирование должно быть автоматизированным, как запуск модульных тестов. Автоматизация должна была избавить тестировщика, от постоянного повторения одних и тех же сценариев.

    OMFG! Когда уже до менеджеров проектов дойдет простая мысль, что 100% автоматизация тестирования — это миф? И 50% тоже. Хорошо, если 10% получится.
  • 0
    Steve McConnell в книге «совершенный код» посветил главу про тестирование, там в основном говорится о том, что более эффективны инспекции кода и code review, что тесты обычно более дорогие и менее эффективные. Что думайте по этому поводу?
    • 0
      Здесь же речь про интеграционное тестирование, а не модульное и не про качество кода.

      Какие бы ни были инспекции или code review, а за место пользователя надо систему «протыкать».

      Тут встает вопрос, как это делать? Руками или написать интеграционные тесты.
      • 0
        Цель тестирования, интеграционного, модульного или любого другого — выявить максимальное количество ошибок. Речь про то, что инспекции и ревью более эффективны, они позволяют выявить большее количество ошибок.
        • 0
          Как во время code review можно выявить, что кнопка в браузере наехала на таблицу?
          • 0
            вот кстати, для подобных случаев у нас в авто-тесты встроена фича сохранять скриншот после каждого теста. Ну чтобы запустить все на автомате, а в конце посмотреть на цвет галочек и просмотреть картинки. Это быстрее, чем руками все протыкивать
          • 0
            Да, данные ошибки с помощью обзора кода будет сложно выявить), а селениум нормально работает со всеми браузерами? opera, IE, chrome
            • 0
              Да, со всеми отлично работает. Тестировщик тоже со всеми работает ;)
    • +1
      ну если речь идет о чем-то очень небольшом, то может быть. А на большом проекте, пока кто-то будет делать code review по всем закоулкам, там уже можно десяток новых версий выпустить
      • 0
        Ну и тесты это тоже не панацея, в них самих тоже могут быть ошибки, да и сделать большой процент покрытия тестами сложно.
  • НЛО прилетело и опубликовало эту надпись здесь

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