Комментарии 60
Мне показалось, или в тексте проскакивает какое-то неодобрение результатов работы ваших тестировщиков?
В тексте должно читаться неодобрение моей оценки результатов с точки зрения управления (моего управления). Надо было сначала сделать 100% ручное тестирование, а уже потом автоматизировать. Я об этом в последних абзацах писал.
Не-не. Я про:
Соответственно, архитектура тестов должна
совершенствоваться аналогично и «успевать» за совершенствованием архитектуры
кода, чего сделано не было из-за недостаточной квалификации тестировщика.
и еще вот про:
Руководитель отдела тестирования на тот момент делала доклад на тему Приемочные тесты на огурце
Соответственно, архитектура тестов должна
совершенствоваться аналогично и «успевать» за совершенствованием архитектуры
кода, чего сделано не было из-за недостаточной квалификации тестировщика.
и еще вот про:
Руководитель отдела тестирования на тот момент делала доклад на тему Приемочные тесты на огурце
Первая часть была написана самим руководителем отдела тестирования. Он делал ревью этой статьи и добавил как раз этот текст :) На самом деле тестировщикам было тяжело автоматизировать свою работу, очень часто переключали на эти задачи программиста.
Про вторую часть, использование SpecFlow стало почти прорывом для нас. Расскажу как мы на него перешли. Сначала код тестов был написан на C# и в определенный момент его стало очень тяжело читать. Мы решили записать сценарии в Excel-файле. После записи нескольких сценариев нас осенило, ведь тоже самое можно по-русски написать в SpecFlow и запускать в виде тестов. Выступление Алены содержит реальные преимущества от перехода на SpecFlow, там даже пример из проекта был. Правда в конечном итоге значительных результатов для нас это не принесло.
Про вторую часть, использование SpecFlow стало почти прорывом для нас. Расскажу как мы на него перешли. Сначала код тестов был написан на C# и в определенный момент его стало очень тяжело читать. Мы решили записать сценарии в Excel-файле. После записи нескольких сценариев нас осенило, ведь тоже самое можно по-русски написать в SpecFlow и запускать в виде тестов. Выступление Алены содержит реальные преимущества от перехода на SpecFlow, там даже пример из проекта был. Правда в конечном итоге значительных результатов для нас это не принесло.
Работал на 3 проектах с похожими входными данными и наличием автоматизации гуй-тетирования.
На первых двух в той или иной степени проявились перечисленные выше ошибки.
Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.
Вторая заключается в непонимании факта, что автоматизация является разработкой ПО, к ней нужно писать требования, ставить цели, считать рентабельность и прочее.
На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия. К тестирующей системе предъявлены требования по времени прохождения тестов, частоте ложных срабатываний, возможностям адаптации к изменениям GUI, типу ошибок, которые могут обнаружить тесты.
И сейчас есть масса проблем, по большей части в функциональности, связанной со временем: фичи работающие асинхронно, срабатывающие по событиям, обрабатываемые в очереди с недетерминированным временем прохождения.
На первых двух в той или иной степени проявились перечисленные выше ошибки.
Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.
Вторая заключается в непонимании факта, что автоматизация является разработкой ПО, к ней нужно писать требования, ставить цели, считать рентабельность и прочее.
На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия. К тестирующей системе предъявлены требования по времени прохождения тестов, частоте ложных срабатываний, возможностям адаптации к изменениям GUI, типу ошибок, которые могут обнаружить тесты.
И сейчас есть масса проблем, по большей части в функциональности, связанной со временем: фичи работающие асинхронно, срабатывающие по событиям, обрабатываемые в очереди с недетерминированным временем прохождения.
> Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.
Точно, про это у меня вывод в последних абзацах, согласен с вами.
>… автоматизация является разработкой ПО
В точку.
> На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия.
Поделитесь, у вас отдел тестирования интегрирован в команду по проекту или отдел тестирования занимается всеми проектами, которые проходят в компании? Кто составляет регламент? Кто и как несет за выполнение регламента ответственность?
Мне, да и не только мне, ответы помогут сориентироваться с организацией в своей компании.
Точно, про это у меня вывод в последних абзацах, согласен с вами.
>… автоматизация является разработкой ПО
В точку.
> На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия.
Поделитесь, у вас отдел тестирования интегрирован в команду по проекту или отдел тестирования занимается всеми проектами, которые проходят в компании? Кто составляет регламент? Кто и как несет за выполнение регламента ответственность?
Мне, да и не только мне, ответы помогут сориентироваться с организацией в своей компании.
В команду разработки интегрировано ручное тестирование, «персональный программист тестировщика» (или наоборот) с оговорками. Автоматизация тестирования — отдельно, на несколько проектов.
Внутренний регламент работы тестировщиков — авто и не авто — составляют они же.
Регламент, касающийся работы других участников — согласовываем с ПМом и разработчиками.
Требования нам сильно помог создать руководитель разработки, у него богатый опыт.
Ответственность за тесты несет тимлид автотестеров перед заказчиками — ПМами проектов.
В моих целях — создание микрокоманды аналитик+(авто)тестер+разработчик для каждой фичи. Это обеспечит скорость и глубину.
В противовес этой модели — отдельная группа автотестирования, хоть и немного оторвана от текущего контекста, но имеет большой плюс — отношения «заказчик-клиент». Это позволяет избежать написания тестов ради тестов, позволяет покрывать тестами актуальные фичи.
Внутренний регламент работы тестировщиков — авто и не авто — составляют они же.
Регламент, касающийся работы других участников — согласовываем с ПМом и разработчиками.
Требования нам сильно помог создать руководитель разработки, у него богатый опыт.
Ответственность за тесты несет тимлид автотестеров перед заказчиками — ПМами проектов.
В моих целях — создание микрокоманды аналитик+(авто)тестер+разработчик для каждой фичи. Это обеспечит скорость и глубину.
В противовес этой модели — отдельная группа автотестирования, хоть и немного оторвана от текущего контекста, но имеет большой плюс — отношения «заказчик-клиент». Это позволяет избежать написания тестов ради тестов, позволяет покрывать тестами актуальные фичи.
ну нельзя же из одной крайности в другую кидаться. Полезно иметь набор автоматизированных тестов, которые покрывают хотя бы основные более-менее стабильные части продукта, либо писать по тесту на каждый найденный баг, чтобы перед выпуском в production делать регрессионные тесты. Регрессионные тесты — это самая нудная часть, поэтому всем хочется на них забить, а как раз тут-то баги и вылазят, когда чинили что-нибудь одно — поломали в другом месте.
У меня до сих пор есть мечта автоматизировать тесты, чтобы каждый раз не протыкивать всё с начала.
notacat взгляните дальше первого релиза. У вас есть набор тестов, которые были актуальны для первой версии. Кто и что будет делать с этим набором во второй версии? В 3й? В 20ой? Их надо поддерживать, актуализировать, рефакторить. Вот тут начинаются проблемы.
notacat взгляните дальше первого релиза. У вас есть набор тестов, которые были актуальны для первой версии. Кто и что будет делать с этим набором во второй версии? В 3й? В 20ой? Их надо поддерживать, актуализировать, рефакторить. Вот тут начинаются проблемы.
Ответ есть тут. В кратце: тесты — это часть продукта. Кто сломал — тот и чинит (желательно сразу).
Версии не с нуля пишутся; обычно между версиями нет революционных изменений. Продукт до них эволюционирует. Так же и тесты — как часть функционала (который чем меньше — тем лучше) — тоже должны эволюционировать вместе(!) с генерирующими бизнес-ценности частами, являться их неотъемлемой частью.
Версии не с нуля пишутся; обычно между версиями нет революционных изменений. Продукт до них эволюционирует. Так же и тесты — как часть функционала (который чем меньше — тем лучше) — тоже должны эволюционировать вместе(!) с генерирующими бизнес-ценности частами, являться их неотъемлемой частью.
тут все от специфики продукта зависит. Вот мы пишем контролы, и если релиз состоялся, то скорей всего публичный интерфейс не будет ломаться (только расширяться) до тех пор, пока это не уйдет в легаси, некоторые вещи живут больше 10 лет, а очередные версии выпускаются несколько раз в год. Поэтому и тесты живут долго. Но конечно, и тесты надо поддерживать, рефакторить и т.д…
> тут все от специфики продукта зависит
Согласен. Я рассказывал про заказную разработку с частыми релизами. Вы поделились опытом разработки продукта с релизами раз в год.
Предлагаю здесь добавить описание ваших проектом и специфику их тестирования.
Согласен. Я рассказывал про заказную разработку с частыми релизами. Вы поделились опытом разработки продукта с релизами раз в год.
Предлагаю здесь добавить описание ваших проектом и специфику их тестирования.
сейчас у нас 3 раза в год, плюс куча промежуточных билдов с хотфиксами, которые мы публикуем.
описание наших проектов на www.componentone.com. Тиражируемый софт, контролы и компоненты для .Net.
У нас QA полностью отдельный, т.е. отдельные люди, со своим отдельным начальством. Мы с ними синхронизируемся на уровне квартальных планов. Т.е. они делают и ручное, и автоматизированное тестирование, но это не интегрировано в наш рабочий процесс. Если есть критичные места, которые надо покрывать юнит-тестами — то это полностью на разработчиках.
Что интегрировано в разработку — это автоматические билды на сервере после коммитов. Если очередной билд сломался, то автоматически создается баг и присваивается на того разработчика, который делал последний коммит. Тут никаких дискуссий по поводу «кто должен чинить» не возникает, потому что если билд на сервере не проходит, то нечего отдавать в QA и это может помешать другим разработчикам работать над своим кодом.
QA получает готовый билд, сэмплы, документацию и уже со всем этим работает. Они знают, кто из разработчиков за какой продукт отвечает, и сами расписывают баги по разработчикам. Они же определяют критичность багов и какие баги должны быть обязательно исправлены до релиза. Уже разработчики между собой могут этот баг передать, если видят, что на самом деле проблема где-то в чужой области ответственности. Пофиксенный баг опять автоматом присваивается тестеру, который его нашел, и при следующем билде все начинается сначала. Закрыть баг окончательно может только QA.
Кроме QA баги может постить тех.саппорт (если они смогли их у себя воспроизвести), такие баги всегда имеют более высокий приоритет. Ну и еще у нас есть публичные форумы, где каждый разработчик обязан отвечать на вопросы в пределах своей компетенции как минимум раз в неделю. Кстати, очень много багов приходит именно с этой стороны, никакой QA не может вообразить себе, куда люди засунут наши контролы и что с ними сделают.
У нас QA полностью отдельный, т.е. отдельные люди, со своим отдельным начальством. Мы с ними синхронизируемся на уровне квартальных планов. Т.е. они делают и ручное, и автоматизированное тестирование, но это не интегрировано в наш рабочий процесс. Если есть критичные места, которые надо покрывать юнит-тестами — то это полностью на разработчиках.
Что интегрировано в разработку — это автоматические билды на сервере после коммитов. Если очередной билд сломался, то автоматически создается баг и присваивается на того разработчика, который делал последний коммит. Тут никаких дискуссий по поводу «кто должен чинить» не возникает, потому что если билд на сервере не проходит, то нечего отдавать в QA и это может помешать другим разработчикам работать над своим кодом.
QA получает готовый билд, сэмплы, документацию и уже со всем этим работает. Они знают, кто из разработчиков за какой продукт отвечает, и сами расписывают баги по разработчикам. Они же определяют критичность багов и какие баги должны быть обязательно исправлены до релиза. Уже разработчики между собой могут этот баг передать, если видят, что на самом деле проблема где-то в чужой области ответственности. Пофиксенный баг опять автоматом присваивается тестеру, который его нашел, и при следующем билде все начинается сначала. Закрыть баг окончательно может только QA.
Кроме QA баги может постить тех.саппорт (если они смогли их у себя воспроизвести), такие баги всегда имеют более высокий приоритет. Ну и еще у нас есть публичные форумы, где каждый разработчик обязан отвечать на вопросы в пределах своей компетенции как минимум раз в неделю. Кстати, очень много багов приходит именно с этой стороны, никакой QA не может вообразить себе, куда люди засунут наши контролы и что с ними сделают.
Про «автозаведение бага по последнему коммитившему» — поподробнее пожалуйста! :)
У вас 1 коммит на 1 билд? Сколько идет билд по времени? Если соотношение не 1 к 1 соотношение — почему на последнего коммитившего?
У вас 1 коммит на 1 билд? Сколько идет билд по времени? Если соотношение не 1 к 1 соотношение — почему на последнего коммитившего?
сначала делали 1 билд на 1 коммит, в какой-то момент стало сильно не хватать билд серверов, сделали раз в сколько-то времени. Автоматически определить, чей именно коммит сломал билд — невозможно. Поэтому на последнего, кто коммит делал, баг присваивается. Но в билдлоге пишется список всех последних коммитов, поэтому тот, кому этот баг упал, имеет возможность откреститься и отправить его по адресу. Это проще, чем заставить кого-то одного следить за билдами и назначать ответственных.
А вот как это технически делается, не знаю, у нас TFS, по всей видимости где-то на сервере скрипт написан, который баги раскладывает. И кроме багов еще e-mail приходит о сломанном билде. Мы не мгновенно к этому пришли, где-то с год устаканивались с тех пор, как на TFS переехали.
А вот как это технически делается, не знаю, у нас TFS, по всей видимости где-то на сервере скрипт написан, который баги раскладывает. И кроме багов еще e-mail приходит о сломанном билде. Мы не мгновенно к этому пришли, где-то с год устаканивались с тех пор, как на TFS переехали.
Очень дельная мысль!
У нас сейчас от TeamCity приходят письма всем авторам коммитов, попавшим в билд. Кто первый на кого ответственность переложил — тот и молодец. Если никто долго не берет ответственность (почту не смотрел никто, разбираться лень) — разобраться должен ответственный за компонент QA… в теории. :)
Надо у нас попробовать такие баги писать.
У нас сейчас от TeamCity приходят письма всем авторам коммитов, попавшим в билд. Кто первый на кого ответственность переложил — тот и молодец. Если никто долго не берет ответственность (почту не смотрел никто, разбираться лень) — разобраться должен ответственный за компонент QA… в теории. :)
Надо у нас попробовать такие баги писать.
наверное, в общем случае менедмент должен оценить соотношение цикла жизни продукта, затрат на разработку/тестирование, потерь от багов ушедших в релиз и т.д., и т.п…
Но если вы планируете, что версий продукта будет больше 3х, и вы не будете каждую версию делать с нуля, то поддержка актуальных тестов должна окупаться. Можно обсуждать объем тестов, покрытие, но совсем отказываться я бы не стала.
Но если вы планируете, что версий продукта будет больше 3х, и вы не будете каждую версию делать с нуля, то поддержка актуальных тестов должна окупаться. Можно обсуждать объем тестов, покрытие, но совсем отказываться я бы не стала.
Я тут напишу свое мнение с точки зрения автотестера :)
Не-а, неверный посыл. Вы заставили тестировщика догонять команду. Тестировщик-автоматизатор в принципе не может успеть за всей командой, если команда не слоу-поки. Он один — их много, и они в тельняшках.
Правильнее было бы:
Задачами, собственно, тестировщика-автоматизатора становятся контроль за покрытием функциональности тестами, написание сложных сценариев. Если квалификация тестировщика позволяет — доверяем поддержку инфраструктуры тестирования: фреймворки, обвязки, помощники и т. д.
Собственно желательно, чтоб в интеграционных сценарных тестах использовались настолько высокоуровневые команды, чтоб это напоминало DSL.
Автоматизированное тестирование — не панацея. Как минимум эксплорационное тестирование нетривиально автоматизируется.
Одним предложением: «не одни тестеры, но вся команда в полном составе ответственна за качество».
Соответственно, архитектура тестов должна
совершенствоваться аналогично и «успевать» за совершенствованием архитектуры
кода, чего сделано не было из-за недостаточной квалификации тестировщика.
Не-а, неверный посыл. Вы заставили тестировщика догонять команду. Тестировщик-автоматизатор в принципе не может успеть за всей командой, если команда не слоу-поки. Он один — их много, и они в тельняшках.
Правильнее было бы:
- обязать разработчиков самим писать юнит-тесты на свою новую функциональность, простейшие интеграционные тесты;
- считать минимальный набор тестов одним из критериев завершенности фичи;
- добиться прохождения юнит-тестов и базового набора интеграционных (обзовем его Smoke) в один-два часа максимум (если Selenium — постараться использовать Selenium 2.0 и HtmlUnit);
- ввести принцип «кто сломал — тот чинит». Тестировщик следит за состоянием билдера и цветом тестов. Как только имеем сломанный тест, отыскиваем (с помощью того же TeamCity) коммит-источник проблемы и пинаем разработчика-ломатора или чиним сами — если умеем :);
- по приоритетам программистов: починку тестов считаем блокером или как минимум мажором;
Задачами, собственно, тестировщика-автоматизатора становятся контроль за покрытием функциональности тестами, написание сложных сценариев. Если квалификация тестировщика позволяет — доверяем поддержку инфраструктуры тестирования: фреймворки, обвязки, помощники и т. д.
Собственно желательно, чтоб в интеграционных сценарных тестах использовались настолько высокоуровневые команды, чтоб это напоминало DSL.
Автоматизированное тестирование — не панацея. Как минимум эксплорационное тестирование нетривиально автоматизируется.
Одним предложением: «не одни тестеры, но вся команда в полном составе ответственна за качество».
Правильный, хороший, но сложно реализуемый подход.
При робких намках на что-то подобное сталкивался с:
1. «Эти Ваши тесты опять сломались»
2. Программистам нужно писать фичи, скоро релиз править баги, стоять на скрам митинге, тесты чинить некогда.
3. А вас зачем наняли?
Если изначально строить процесс разработки то получится, переучить людей много сложнее да и необходимо понимание проблемы руководителем проекта, а это, что характерно, не всегда бывщий разработчик или тестировщик.
При робких намках на что-то подобное сталкивался с:
1. «Эти Ваши тесты опять сломались»
2. Программистам нужно писать фичи, скоро релиз править баги, стоять на скрам митинге, тесты чинить некогда.
3. А вас зачем наняли?
Если изначально строить процесс разработки то получится, переучить людей много сложнее да и необходимо понимание проблемы руководителем проекта, а это, что характерно, не всегда бывщий разработчик или тестировщик.
Если пункт 1) говорит тестировщик — он должен указать кто и когда сломал (вплоть до строк с поломкой, на diff-е коммита видно :) ).
Если говорит менеджер — тестировщик выполняет команду «Найти негодяя».
Если часто так говорит менеджер — тестировщика оставляем без премии или баним менеджера по IP на билдере (нечего людям работать мешать).
Если программист так говорит — пусть сам разбирается.
Ситуация 2) сложнее и, опять же, смотря кто ее поднимает. Если менеджер:
Если говорит менеджер — тестировщик выполняет команду «Найти негодяя».
Если часто так говорит менеджер — тестировщика оставляем без премии или баним менеджера по IP на билдере (нечего людям работать мешать).
Если программист так говорит — пусть сам разбирается.
Ситуация 2) сложнее и, опять же, смотря кто ее поднимает. Если менеджер:
- надо выяснить северити — импакт по функциональности конечного продукта;
баги в баг трекере (расписать импакт, в терминах бизнес-процессов описать проблему и путь воспроизведения);
довести до руководителя баг, дать ссылку на трекер
следовать обычным процессам QA
Если даже после этого не подействует — ни о каком вменяемом руководстве и вообще качестве продукта речи быть не может.
Пункт 3) не самый интересный. Разработчик автотестов (он же SDT/SET: software developer in test, software engineer in test) — это, фактически одновременно QA и разработчик в одном лице. Ни один тестировщик (даже «ручной») не сможет в одиночку (или командой QA) обеспечить «качество».
Качество дают программисты и тестировщики, и аналитики, и художники-дизайнеры. Это всё — разработчики продукта. Они все до единого ответственны за конечный продукт, за свою работу.
Вот как это объяснить руководитству (и надо ли объяснять, если сразу не понятно) — вопрос. Потому что если руководитель проекта не понимает, что качество обеспечивает вся команда — это как минимум некомпетентный руководтель проекта.
Спасибо, я думаю, что стоит попробовать ваш подход, в нем есть логичная структура.
Обратите внимание, что наши разработчики писали модульные тесты и даже тесты на JavaScript, которые гонял TeamCity.
Тем не менее я увидел в комментарии Wolonter habrahabr.ru/post/145974/#comment_4910764 то, с чем сам сталкивался.
Wolonter не зря написал «Эти Ваши тесты опять сломались». Разработчики не хотят заниматься тестами, это факт. Можно придать разработчикам мотивации, можно сделать, чтобы их хотя бы не тошнило после дня парного программирования с тестировщиком, но это будет временно. Всё-таки тесты — это работа тестировщика.
Обратите внимание, что наши разработчики писали модульные тесты и даже тесты на JavaScript, которые гонял TeamCity.
Тем не менее я увидел в комментарии Wolonter habrahabr.ru/post/145974/#comment_4910764 то, с чем сам сталкивался.
Wolonter не зря написал «Эти Ваши тесты опять сломались». Разработчики не хотят заниматься тестами, это факт. Можно придать разработчикам мотивации, можно сделать, чтобы их хотя бы не тошнило после дня парного программирования с тестировщиком, но это будет временно. Всё-таки тесты — это работа тестировщика.
Да, такое есть. Но! Когда разработчик будет писать тесты сам — он не будет говорить, что это «ваши» тесты — он будет их чинить. Потому что это его правка поломала его же тесты.
Программист — такой же наемный рабочий, получают ЗП за результат — работающий проект. О каком «не хотят заниматься» может вообще идти речь? :) И если ручные тестировщики не успевают писать баги, если серверное ПО падает от каждого чиха — это надо решать, вплоть до кадрового вопроса.
(но, таки да, есть такая проблема: у нас программисты зачастую воротят нос от тестов, часто пишут один-два самых базовых)
Что есть «парное программирование с тестировщиком»? Тестировщик читает код, который пишет программист? Без квалификации — бесполезно в принципе. Парное программирование — вообще не панацея. Очень сильно зависит от контингента и воспитания.
Работа тестера — озвучить проблемы, с которыми столкнется конечный пользователь если получит текущий продукт.
Задачей же всей команды (и в первую очередь ПМа) — сделать так, чтоб в любой момент разработки продуктом можно было нормально пользоваться: а это всего лишь значит, что пользователя не должно тошнить от пары недель работы с корпоративной системой учета времени, которая падает каждый три минуты (уже приоритет — мажор), да еще и данные теряет (а вот сейчас приоритет подымается до блокера и виновата в этом вся команда).
Про модульные тесты. Надо контролировать, что покрывают тесты, надо знать наиболее частые сценарии использования продукта. Надо знать, какие сценарии блокированы баглом. И надо отдавать себе отчет, что автотесты — никогда не отловят все ошибки. Так же как и ручные тестировщики не смогут этого сделать.
Программист — такой же наемный рабочий, получают ЗП за результат — работающий проект. О каком «не хотят заниматься» может вообще идти речь? :) И если ручные тестировщики не успевают писать баги, если серверное ПО падает от каждого чиха — это надо решать, вплоть до кадрового вопроса.
(но, таки да, есть такая проблема: у нас программисты зачастую воротят нос от тестов, часто пишут один-два самых базовых)
Что есть «парное программирование с тестировщиком»? Тестировщик читает код, который пишет программист? Без квалификации — бесполезно в принципе. Парное программирование — вообще не панацея. Очень сильно зависит от контингента и воспитания.
Работа тестера — озвучить проблемы, с которыми столкнется конечный пользователь если получит текущий продукт.
Задачей же всей команды (и в первую очередь ПМа) — сделать так, чтоб в любой момент разработки продуктом можно было нормально пользоваться: а это всего лишь значит, что пользователя не должно тошнить от пары недель работы с корпоративной системой учета времени, которая падает каждый три минуты (уже приоритет — мажор), да еще и данные теряет (а вот сейчас приоритет подымается до блокера и виновата в этом вся команда).
Про модульные тесты. Надо контролировать, что покрывают тесты, надо знать наиболее частые сценарии использования продукта. Надо знать, какие сценарии блокированы баглом. И надо отдавать себе отчет, что автотесты — никогда не отловят все ошибки. Так же как и ручные тестировщики не смогут этого сделать.
(я сейчас очень плохо скажу, потому что иначе пока не дорос.)
И, кстати, проблема «надо писать фичи, а не баги чинить» — совсем не проблема автоматизации.
Это проблема менеджмента, планирования буфферов времени, оценки рисков.
Думаю, фимоз головного мозга — это самая большая проблема менеджмента вообще, а в IT она цветёт очень ярко.
Особенно это заметно в гос-секторе, в котором вбухиваются немереные средства в посредственные работы, с кучей фееричнейших блокеров в основых сценариях использования.
И, кстати, проблема «надо писать фичи, а не баги чинить» — совсем не проблема автоматизации.
Это проблема менеджмента, планирования буфферов времени, оценки рисков.
Думаю, фимоз головного мозга — это самая большая проблема менеджмента вообще, а в IT она цветёт очень ярко.
Особенно это заметно в гос-секторе, в котором вбухиваются немереные средства в посредственные работы, с кучей фееричнейших блокеров в основых сценариях использования.
Зачетный набор советов.
У нас на проекте больше тысячи функциональных тестов. Используем Selenium(WebDriver). Запускается все это чудо на Jenkins, где подготовлено около 30 виртуальных машин. В сумме от от нажатия кнопки «build» до получения готового к релизу билда (на котором все юнит и функциольные тесты зеленые) проходит минут 40-50.
Пока тесты писали только тестировщики, у нас всегда была проблема с нестабильностью, которую и описывает автор статьи. По началу проглядывали красные тесты и запускали их руками на своих машинах. Было грустно. Код тестов был тоже грустный. Все-таки писать автоматические тесты на .NET это уже полноценное программирование, а люди занимающиеся автоматическим тестированием как правило не имеют достаточной квалификации.
Как-то собрались все вместе и решили, что функциональность-то наша, и будем сами покрывать ее этим самым минимальным набором тестов, при этом постепенно приведем тестовый фреймворк в порядок. Стало полегче.
При этом осталась проблема нестабильных тестов. Договорились что каждый день один из программистов будет «ответсвенный» за билд. Если тест упал, и упал по нестабильности, разработчик его чинит. В команде 7 человек, так что это было не так напряжно. Сначала тесты было чинить непросто, т.к. проблемы выявлялись повсюду (то в Selenium, то сам тест был очень хитер). По немногу выделили многие паттерны нестабильности, сейчас без причины падает каждый 5-ый а то и 10-ый билд. Кстати в красный билд комитить нельзя:-)
Выводы думаю понятны. А вот от себя могу добавить важный итог — когда я делаю довольно серьезные изменения в коде, я без страха смотрю в будущее, т.к. цвет билда буквально через часок подмигнет мне о том, что же такого я накодил. Стало действительно легче и быстрее делать серьзеные изменения.
P.S. Релизы выпускаем где-то раз в месяц. Стоит признать что продукт уже довольно устоявшийся, мы скорее добавляем новые области, чем серьезно меняем существующие.
У нас на проекте больше тысячи функциональных тестов. Используем Selenium(WebDriver). Запускается все это чудо на Jenkins, где подготовлено около 30 виртуальных машин. В сумме от от нажатия кнопки «build» до получения готового к релизу билда (на котором все юнит и функциольные тесты зеленые) проходит минут 40-50.
Пока тесты писали только тестировщики, у нас всегда была проблема с нестабильностью, которую и описывает автор статьи. По началу проглядывали красные тесты и запускали их руками на своих машинах. Было грустно. Код тестов был тоже грустный. Все-таки писать автоматические тесты на .NET это уже полноценное программирование, а люди занимающиеся автоматическим тестированием как правило не имеют достаточной квалификации.
Как-то собрались все вместе и решили, что функциональность-то наша, и будем сами покрывать ее этим самым минимальным набором тестов, при этом постепенно приведем тестовый фреймворк в порядок. Стало полегче.
При этом осталась проблема нестабильных тестов. Договорились что каждый день один из программистов будет «ответсвенный» за билд. Если тест упал, и упал по нестабильности, разработчик его чинит. В команде 7 человек, так что это было не так напряжно. Сначала тесты было чинить непросто, т.к. проблемы выявлялись повсюду (то в Selenium, то сам тест был очень хитер). По немногу выделили многие паттерны нестабильности, сейчас без причины падает каждый 5-ый а то и 10-ый билд. Кстати в красный билд комитить нельзя:-)
Выводы думаю понятны. А вот от себя могу добавить важный итог — когда я делаю довольно серьезные изменения в коде, я без страха смотрю в будущее, т.к. цвет билда буквально через часок подмигнет мне о том, что же такого я накодил. Стало действительно легче и быстрее делать серьзеные изменения.
P.S. Релизы выпускаем где-то раз в месяц. Стоит признать что продукт уже довольно устоявшийся, мы скорее добавляем новые области, чем серьезно меняем существующие.
>>написание тестовых сценариев в Google Docs
Можете привести пример подобного? Интересует как именно у Вас это выглядит.
Можете привести пример подобного? Интересует как именно у Вас это выглядит.
Сейчас сценарии сгруппированы на листах Excel по функциональности и на каждом листе есть колонки:
- Название — «Отображение списка задач в деталях заказа»
- Сценарий — пошаговая инструкция
- Ожидаем — несколько пунктов про ожидания после сценария
- Ссылка на UserStory — в нашем случае AgileZen
Вопросы:
1)
У Вас нет уровня важности? Каким образом Вы понимаете что тот или иной сценарий нужно выполнять раньше чем другой?
2)
Я правильно понимаю, что под «пошаговая инструкция» понимает алгоритм действий с продуктом как это во втором варианте комментарий ниже?
1)
У Вас нет уровня важности? Каким образом Вы понимаете что тот или иной сценарий нужно выполнять раньше чем другой?
2)
Я правильно понимаю, что под «пошаговая инструкция» понимает алгоритм действий с продуктом как это во втором варианте комментарий ниже?
1) Уровня вложенности нет. Сценарий тестирует User Story, она сама по себе может быть, без следования за другой User Story.
2) Да, очень похоже
2) Да, очень похоже
Еще вопросы, если не сложно:
1)
А как у вас коллекционируются тест-сценарии? Интересует как вы их организовываете чтобы не заблудиться в них.
2)
Есть ли у Вас какая-либо «бюрократия»?
1)
А как у вас коллекционируются тест-сценарии? Интересует как вы их организовываете чтобы не заблудиться в них.
2)
Есть ли у Вас какая-либо «бюрократия»?
1) В основном на каждую группу делается отдельный лист в Excel (точнее в таблице в Google Docs). Группа делается по функциональности, например, Вход на сайт. Работа с Проектами, работа со Счетами т.п.
2) После проверки сценария надо отметить кто и когда его проверял. Это делается в строке со сценарием. Если произошел баг, то надо добавить ссылку на описание этого бага.
2) После проверки сценария надо отметить кто и когда его проверял. Это делается в строке со сценарием. Если произошел баг, то надо добавить ссылку на описание этого бага.
Также интересует как у Вас организован «распил бюджета человеко-времени», т.е. учет человеко-времени выделяемое на тестирование. Волнуют следующие случаи:
1)
Фича только что реализована, никто еще не знает сколько по факту в часах может занять ее тестирование. Что делаете? Собираете 2-3 эксперта и даете предварительную оценку или не паритесь и ждете окончания работ и записываете полученный опыт. Возможно у Вас как-то по-другому интересно как?
2)
Отличается ли у вас человеко-время отводимое на тестирование релиза и обновления, если да, то почему и чем?
1)
Фича только что реализована, никто еще не знает сколько по факту в часах может занять ее тестирование. Что делаете? Собираете 2-3 эксперта и даете предварительную оценку или не паритесь и ждете окончания работ и записываете полученный опыт. Возможно у Вас как-то по-другому интересно как?
2)
Отличается ли у вас человеко-время отводимое на тестирование релиза и обновления, если да, то почему и чем?
Александр, а как вы, кстати, SpecFlow использовали, что-то типа такого:
Или
И что такое для вас сложный сценарий?
Дано пользователя «Ваня» нет в системе
Когда я создаю нового пользователя «Ваня»
Тогда я могу залогиниться под пользователем «Ваня» Или
Дано зайти под пользователем ‘admin’/’admin’
И Кликнуть на ссылку «Администрирование»
И Кликнуть на ссылку «Пользователи»
И Удалить пользователя «Ваня»
Когда я на Главной странице
И я кликнул на ссылку «Регистрация»
И я заполнил поле Имя: Ваня
И я заполнил поле Фамилия: Иванов
И я заполнил поле Пароль: kjHKJKJhjkhU*IKL:”1
И я заполнил поле Подтвердите Пароль: kjHKJKJhjkhU*IKL:”1
И я нажал на кнопку «Регистрация»
И я ввел в поле Логин: Ваня
И я ввел в поле Пароль: kjHKJKJhjkhU*IKL:”1
И я нажал на кнопку «Вход»
Тогда я должен увидеть надпись «Привет, Ваня!»И что такое для вас сложный сценарий?
Дмитрий, мы использовали второй вариант с множеством шагов.
Под сложным я понимал кол-во шагов больше 5-6.
Под сложным я понимал кол-во шагов больше 5-6.
Александр, я бы еще хотел порекомендовать вам посмотреть на bddify или StoryQ. Я ничего плохого не могу сказать про SpecFlow, сам пользуюсь этим фреймворком, но только в случае высокоуровневых сценариев. Для меня правило – что любой сценарий на SpecFlow должен состоять из трех строк максимум: один Given один When и один Then, который бы в общих чертах объясняли что делает сценарий. Вся сложная логика и детали у меня зашита в слое автоматизации на C#.
Вторым фреймворком я использую bddify, который позволяет разделять тест на блоки Given When Then и генерировать красивый отчет после прогона.
Вся бизнес логика работы приложения у меня находится в слое автоматизации, который я называю Тестовой Моделью. Там все логические страницы приложения задекларированы с использованием Page Object и DSL, вот например, следующий тест пересоздает пользователя и пробует залогинится:
В общем, в первую очередь, я старался добиться чтобы чтобы и на C# тесты смотрелись не плохо. Только потом я начал прикручивать SpecFlow и Bddify, с мыслью о том, что скорее всего в будущем я могу перейти на дргие тестовые фреймворки, но сам слой автоматизации останется не тронутым.
У меня есть длинные многострочные сценарии, из 10 – 15 шагов. Для их создания я использую Bddify, потому что в основном, написать на C# такой сценарий легче – и переменные можно использовать и контроля над кодом больше.
В SpecfLow я тоже изобрел свои велосипедо-переменные, но получилось не так эффективно как на 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#.
Спасибо за ссылки.
В вашей команде программисты участвуют в автоматизации тестирования?
В вашей команде программисты участвуют в автоматизации тестирования?
Нет, наши программисты тестов не пишут. Раньше писали юнит-тесты время от времени, но сейчас нет.
Автоматизированы у нас основные CRUD операции и инсталляция/конфигурация приложения. Перед началом моего рабочего дня тестировщика: скачан, проинсталлирован и сконфигурирован новый билд – и прогнаны основные тесты. Этого пока достаточно и поддержки требует минимум.
На моем текущем проекте эффективны средства полу-автоматизации: вот например, скрипты для отслеживания изменений в таблицах БД или xml файлов, слежка за HTTP запросами при помощи Fiddler’а, скрипты сигнализации об ошибках в логах приложения.
И сейчас осваиваю mdbg
И основная проблема пока что не в том, чтобы готовый код выполнялся корректно, а в том, чтобы правильно понять чего же хотят пользователи нашего продукта. Это уже процессная проблема. В таких условиях хорошо работают простые тесты и полу-автоматизированные инструменты, которые позволяют исследовать продукт быстрее.
Кроме того, пользователи нашего продукта модифицируют свои базы данных, расширяя размеры полей таблиц, добавляя триггеры и даже используя некоторые баги как фичи (например XSS уязвимости для вставки ссылок на свои файлы). В таких условиях, конечно же, более эффективно работает мануальное и исследовательское тестирование с использованием полу-автоматических инструментов.
Автоматизированы у нас основные CRUD операции и инсталляция/конфигурация приложения. Перед началом моего рабочего дня тестировщика: скачан, проинсталлирован и сконфигурирован новый билд – и прогнаны основные тесты. Этого пока достаточно и поддержки требует минимум.
На моем текущем проекте эффективны средства полу-автоматизации: вот например, скрипты для отслеживания изменений в таблицах БД или xml файлов, слежка за HTTP запросами при помощи Fiddler’а, скрипты сигнализации об ошибках в логах приложения.
И сейчас осваиваю mdbg
И основная проблема пока что не в том, чтобы готовый код выполнялся корректно, а в том, чтобы правильно понять чего же хотят пользователи нашего продукта. Это уже процессная проблема. В таких условиях хорошо работают простые тесты и полу-автоматизированные инструменты, которые позволяют исследовать продукт быстрее.
Кроме того, пользователи нашего продукта модифицируют свои базы данных, расширяя размеры полей таблиц, добавляя триггеры и даже используя некоторые баги как фичи (например XSS уязвимости для вставки ссылок на свои файлы). В таких условиях, конечно же, более эффективно работает мануальное и исследовательское тестирование с использованием полу-автоматических инструментов.
О! Поддерживаю все что сказано в статье. Частенько тут высказывался в этом свете, но меня любили за это минусовать, и высказывать, что-то типа «просто не умеешь готовить автоматические тесты». В итоге, я уже подумывал — а может стоит попробовать… ан, нет — теперь вижу, что и смысла нет начинать. Итак, мы на верном пути :)
Я уже писал вышел, всё еще не отказался от этой идеи. Просто автоматизировать надо самое нужное и делать это так, чтобы не приходилось поддерживать. Возможно скоро выйдет новое поколение инструментов для тестирования и тогда всё изменится.
Бред. Тесты — часть продукта. Не бывает «чтобы не приходилось поддерживать»! Продукт меняется — меняются тесты. Если функционал не поменялся — не меняются тесты. Какие бы то не было изменения в поведении продукта будут всегда за собой тянуть изменения тестов.
Речь о рентабельности поддержки тестов (речь про интеграционные тесты). Если дешевле и эффективнее тыкать руками, то нет смысла автоматизировать тесты.
Рентабельность поддержки — совершенно другой вопрос. Из каких слов следует ваш этот коментарий?
Вы пишете, что с выходом новых инструментов не придется переделывать тесты, когда меняется продукт. Так вот: это — неправда.
Если уж говорить о рентабельности, выбор писать автотесты-не писать автотесты (что юниты, чтоб интеграционные) надо делать осознанно. Например, попробовать применить известную формулу возврата инвестиций, учесть частоту запусков автотестов, учесть покрытие, работу по поддержанию автотестов. И аналогичные работы для всего этого объема, производимые вручную.
Вот тогда можно говорить о рентабельности.
И да, вы б почитали свою ссылку на Джоэля Спольски. Там все очень хорошо написано, зачем и почему нужны автотесты и почему их стоит использовать совместно с ручными тестировщиками.
Вы пишете, что с выходом новых инструментов не придется переделывать тесты, когда меняется продукт. Так вот: это — неправда.
Если уж говорить о рентабельности, выбор писать автотесты-не писать автотесты (что юниты, чтоб интеграционные) надо делать осознанно. Например, попробовать применить известную формулу возврата инвестиций, учесть частоту запусков автотестов, учесть покрытие, работу по поддержанию автотестов. И аналогичные работы для всего этого объема, производимые вручную.
Вот тогда можно говорить о рентабельности.
И да, вы б почитали свою ссылку на Джоэля Спольски. Там все очень хорошо написано, зачем и почему нужны автотесты и почему их стоит использовать совместно с ручными тестировщиками.
> Вы пишете, что с выходом новых инструментов не придется переделывать тесты, когда меняется продукт. Так вот: это — неправда.
Трудно оценивать инструменты, которых еще не существует :)
> И аналогичные работы для всего этого объема, производимые вручную.
Да, именно так ручное тестирование побеждает. Для заказной разработки с частыми релизами, пока автоматизация тестов не очень подходит.
> И да, вы б почитали…
Как не странно я ее почитал.
linuxoid я бы предложил вам быть менее ортодоксальным в суждениях, вы ведь не знаете специфики потока в заказной разработке, где я работаю.
Трудно оценивать инструменты, которых еще не существует :)
> И аналогичные работы для всего этого объема, производимые вручную.
Да, именно так ручное тестирование побеждает. Для заказной разработки с частыми релизами, пока автоматизация тестов не очень подходит.
> И да, вы б почитали…
Как не странно я ее почитал.
linuxoid я бы предложил вам быть менее ортодоксальным в суждениях, вы ведь не знаете специфики потока в заказной разработке, где я работаю.
Хочется еще раз задать вопрос по поводу:
Может ли кто-нибудь привести примеры подобных инструментов? Что используется/как это интегрируется, например, с билд-сервером?
Например, если вы пишите жука, который отлавливает ошибки 404 и 500 на живом сервере
Может ли кто-нибудь привести примеры подобных инструментов? Что используется/как это интегрируется, например, с билд-сервером?
С билд-сервером жука наверное нет смысла интегрировать, он должен в текущем режиме проверять работоспособность системы.
Я писал 2 вида этих жуков:
В обоих случаях, когда есть 404 или 500, то шлет письмо/смс ответственному.
Я думаю, что подобные жуки для Ruby, Python и других языков есть уже готовые.
Я писал 2 вида этих жуков:
- По метаданным IIS берет данные про сайт, ходит по всем сайтам, которые есть на сервере, чтобы убедится, что сайты работают
- Жук делается по данным ASP.NET MVC, это на много проще. Формирует возможные URL для Get-запросов и пытается на них перейти
В обоих случаях, когда есть 404 или 500, то шлет письмо/смс ответственному.
Я думаю, что подобные жуки для Ruby, Python и других языков есть уже готовые.
и для начала мы решили, что тестирование должно быть автоматизированным, как запуск модульных тестов. Автоматизация должна была избавить тестировщика, от постоянного повторения одних и тех же сценариев.
OMFG! Когда уже до менеджеров проектов дойдет простая мысль, что 100% автоматизация тестирования — это миф? И 50% тоже. Хорошо, если 10% получится.
OMFG! Когда уже до менеджеров проектов дойдет простая мысль, что 100% автоматизация тестирования — это миф? И 50% тоже. Хорошо, если 10% получится.
Steve McConnell в книге «совершенный код» посветил главу про тестирование, там в основном говорится о том, что более эффективны инспекции кода и code review, что тесты обычно более дорогие и менее эффективные. Что думайте по этому поводу?
Здесь же речь про интеграционное тестирование, а не модульное и не про качество кода.
Какие бы ни были инспекции или code review, а за место пользователя надо систему «протыкать».
Тут встает вопрос, как это делать? Руками или написать интеграционные тесты.
Какие бы ни были инспекции или code review, а за место пользователя надо систему «протыкать».
Тут встает вопрос, как это делать? Руками или написать интеграционные тесты.
Цель тестирования, интеграционного, модульного или любого другого — выявить максимальное количество ошибок. Речь про то, что инспекции и ревью более эффективны, они позволяют выявить большее количество ошибок.
Как во время code review можно выявить, что кнопка в браузере наехала на таблицу?
вот кстати, для подобных случаев у нас в авто-тесты встроена фича сохранять скриншот после каждого теста. Ну чтобы запустить все на автомате, а в конце посмотреть на цвет галочек и просмотреть картинки. Это быстрее, чем руками все протыкивать
Да, данные ошибки с помощью обзора кода будет сложно выявить), а селениум нормально работает со всеми браузерами? opera, IE, chrome
ну если речь идет о чем-то очень небольшом, то может быть. А на большом проекте, пока кто-то будет делать code review по всем закоулкам, там уже можно десяток новых версий выпустить
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование: Ручное или Автоматизированное?