Недавно прочитал пару статей про “правильное” описание дефекта и решил в очередной раз потормошить тему управления дефектами на проекте. Я уже писал на тему того, какие типы дефектов существуют и как с ними быть в адекватной команде.
Давайте задумаемся, сколько усилий тратится на самом деле при работе с дефектом:
В результате, один и тот же сценарий запускается не менее 7 раз. А в большей части случаев гораздо больше… И все это делается руками! А теперь добавьте сюда проблемы разряда “это не повторяется на моей машине” и “у меня нет времени смотреть на новые баги”.
Оно и понятно – усилия со стороны разработчика на ручной прогон сценариев очень велики, а разработчики ленятся делать что-то руками. Получая информацию о дефекте, разработчик заранее понимает, сколько усилий ему нужно будет сделать и относится к этому негативно.
Тут притаилась и еще одна проблема – интерпретация информации. Тестировщик пишет сценарий для воспроизведения, вкладывая в него имеющуюся у него информацию. Потом разработчик ее пытается “декодировать” при чтении сценария. И этот процесс далеко не безошибочный. Из-за этого так часто и возникают проблемы взаимопонимания.
Ну и последняя проблема – мы все знаем, что дефект может проявиться снова. Поэтому сценарий должен быть добавлен к регрессионному тестированию. А это значит, что его будут запускать каждый раз при тестировании продукта, что требует еще больше времени.
Так может стоит сразу вкладываться в автоматизацию для дефектов? Ведь вопросов об объеме ручной работы тут не стоит. Мало этого, это будет ручная работа не только тестировщиков, а и разработчиков. Важно отметить, что на коротком интервале можно даже не заботиться о поддерживаемости сценария – ведь всегда можно будет запустить ту же версию кода и на ней прогнать сценарий. А это очень сильно облегчает автоматизацию. Возможно, если у вас и так уже имеется автоматизация, то сценарий будет всего лишь использованием уже реализованных шагов со специфическими данными и новыми проверками.
Если тестировщики вместо написания очередной “истории дефекта” будут предоставлять автоматизированный скрипт, то многих перечисленных выше проблем можно будет избежать. Вдобавок, можно будет сразу же добавить написанный сценарий в имеющийся тестовый набор или как раз и положить начало автоматизации тестирования. Задумайтесь об этом на досуге! 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
На моем проекте мы пробовали ваш подход с багами и все равно через некоторое время пришли к необходимости включать в дефект словесные: Steps to reproduce, Expected и Actual.
Также мы включали все тесты на дефекты в регрессию пока не оказалось, что слишком много времени тратится на поддержку, запуск и анализ результатов тестов на дефекты, вероятность повтора которых близка нулю.
Тут даже не знаю с чего начать. Начну пожалуй с конца – про Selenium IDE. Речь шла о сценарии для воспроизведении, который НЕ добавляется в общие тесты или же добавляется с переводом на язык программирования, если команда посчитала нужным.
Теперь по поводу готового фреймворка – обычно дефекты возникают в случае использования специфических данных в давно известных сценариях, в случае “неожиданных” действий на каком-то этапе и гораздо реже при совершенно новом действии (если автоматизация у нас есть и развивается). Поэтому через некоторое время большая часть шагов у вас уже будет.
Профи-автоматизаторы – это понятие чуть не из той области. Я повторял и буду повторять, что роль автоматизатора размазывается по всей команде, включая разработчиков и тестировщиков. Поэтому это обычные тестировщики, которые не регрессию делают руками, а исследовательское тестирование.
Теперь по поводу плюсов ручного заведения дефектов:
> + выигрыш во времени сообщения о проблеме
Сообщить о проблеме вы можете и до заведения дефекта названием и кратким описанием сути дефекта. Разницы никакой.
> + понятен каждому от тестировщика до бизнеса и техподдержки
Ага, особенно сценарий из 20 шагов, написанный без подсветки данных в простом текстовом редакторе. Шикарнейшее чтиво. 🙂
> + может быть воспроизведен с разными предусловиями, в зависимости от того, где было открыто приложение на момент начала проверки бага тестировщиком, что увеличивает вероятность нахождения новых багов при проверке исправленных
А также повышает риск пропуска дефекта из-за человеческого фактора – ведь реально не каждый вчитывается по все детали каждого шага, описанного другим, и часто действует по наитию.
> + является доументацией к поведению системы
Документацией, которая устаревает как только происходит изменение в продукте, влияющее хоть на один шаг. Или вы занимаетесь поддержкой всех закрытых дефектов?
> + может быть сразу прописан воркэраунд для понятия серьезности проблемы
Не понимаю, почему он не может быть прописан к автоматизированному сценарию. При желании, может быть даже продемонстрирован.
> + позволяет проверить исправление бага другим тестировщиком, который сможет понять, где надо посмотреть вокруг
Я же уже писал про посмотреть вокруг – при автоматизированном вы тоже можете это делать, только можно автоматом долетать до определенного этапа, а потом смотреть сколько влезет. Так же проще.
Самый главный вопрос – вы пробовали данный подход? Обсуждали его с разработчиками? С заказчиками? Я лично по нему работал и в несколько других команд внедрил. А вы разводите теоретические дебаты…
> В результате, один и тот же сценарий запускается не менее 7 раз. А в большей части случаев гораздо больше…
У меня не сходятся расчеты с вашими.
Вот я нашел баг и воспровожу его несколько раз, чтобы понять, в чем именно он состоит, придумать самый короткий путь для воспроизведения, учесть предусловия и т.д. Эти попытки мы не считаем, ибо они в любом случае будут сделаны, чтобы получить сценарий воспроизведения бага. Далее, чтобы описать баг надо затратить несколько минут (ибо последняя попытка, являющаяся проверкой для сценария, также позволила снять скриншот, нужные логи и т.д.).
Чтобы написать тест, мне нужно в несколько раз больше времени: чтобы написать код, несколько раз его запустить для отладки, вставить коментарии (фактически те же самые, что я напишу в баге), добавить в тестовый набор
Теперь смотрим дальнейшее развитие событий.
Вариант 1. Программист смог воспроизвести сценарий. У него 2 прогона (понял в чем баг + проверил после фикса). Поскольку подразумевается, что программисты хорошие, то они прежде чем править код, пишут юнит-тест для проблемы и смотрят уже по нему, исправилась ошиба или нет. Таким образом получаем всего 1 прогон нашего сценария программистом. Но и это еще не все. При наличии хороших логов и сценария программист может понять, где ошибка и пофиксить ее, не воспроизводя сценарий вообще. Таким образом, получаем от 0 до 2 прогонов у программиста.
Баг возвращается тестировщику, и он воспроизводит свой сценарий 1 раз.
Итого: сценарий воспроизводится от 1 до 3 раз. В этом случае получаем следующую картину:
Ручной сценарий:
+ выигрыш во времени сообщения о проблеме
+ понятен каждому от тестировщика до бизнеса и техподдержки
+ может быть воспроизведен с разными предусловиями, в зависимости от того, где было открыто приложение на момент начала проверки бага тестировщиком, что увеличивает вероятность нахождения новых багов при проверке исправленных
+ является доументацией к поведению системы
+ может быть сразу прописан воркэраунд для понятия серьезности проблемы
+ позволяет проверить исправление бага другим тестировщиком, который сможет понять, где надо посмотреть вокруг
Автоматический сценарий:
+ остается в наследство
– требует больше времени на заведение
– не смотрит вокруг
– обычно требует приведения системы в определенное исходное положение (то есть проверяет один путь, по которому проблема нашлась)
– требует квалифицированных автоматизаторов
требует ресурсов на поддержку в будущем
– прохождение теста не является гарантией исправления ошибки
– игнорирует, каким образом была исправлена ошибка (может после фикса программой стало дико неудобно пользоваться?)
– возможен далеко не во всех случаях
Дальше – хуже.
Возьмем вариант 2, когда сценарий не воспроизводится у программиста и поэтому его приходится прогонять больше раз, чем в варианте 1. Спасет ли нас здесь автоматизация?
Если исходить из того, что программисты у нас профессионалы и верен принцип Дорофеева о наименьшем количестве 3,14**расов, то причины, по которым программист не может воспроизвести сценарий, описанный текстом, – это:
1) разное окружение на тестовом стенде и машине программиста
2) тестировщик учел не все факторы при описании сценария и не указал полностью состояние системы, в котором она находилась на момент бага (а привести ее в это состояние он мог сильно раньше, нежели баг произошел, поэтому оно и не попало в сценарий)
3) разное состояние системы на момент заведения бага и его воспроизведения программистом (время, данные в базе, и т.д.)
Теперь смотрим, поможет ли нам автоматизация сценария в вышеперечисленных случаях?
Ответ – нет! Более того, при наличии автоматизированного сценария у нас появляются дополнительные факторы риска, что сценарий не воспроизведется программистом, ибо тестировщик, пишущий сценарий мог не учесть:
разные браузеры, настройки этих браузеров, динамичесие локаторы, конфликты инструмента автоматизации с окружением, баги в инструменте автоматизации.
Итого, ситуация с тем, что программист не сможет воспроизвести дефет и у него не будет времени смотреть на новые дефекты рискует стать сильно хуже, чем до введения автоматизации.
Теперь, что касается самих автотестов и их последующей поддержки.
Отвечая Дмитрию, вы пишите:
>Selenium IDE легко поможет решить проблему, если автоматизации нет в проекте совсем. Если есть, то надо просто использовать уже написанное.
Вот в этом случае вы получите гору говнотестов, время на поддержку которых будет расти очень быстро. И совершенно не окупится, учитывая причины, озвученные выше.
Так что рекорд-энд-плей автоматизация сценариев людьми, далекими от автоматизации, – это верная дорога к проблемам.
Но допустим, что у нас профи автоматизаторы и готовый фреймворк для UI тестирования. Все ли баги мы сможем заавтоматизировать в этом случае?
Внезапно: нет!
Ибо, если мы их нашли руками, то скорее всего в той области, до которой автоматизация еще не добралась, а раз так, то нет и готовых функций взаимодействия с UI для этой области приложения. А может и не планируется их делать вообще, ибо сильно затратно, сложно и неэффективно.
Более того, встает вопрос: почему профи-автоматизаторы вместо автоматизации занимаются ручной регрессией: эффективно ли мы тратим наши ресурсы?
Считаю, что описанный в статье способ автоматизации сильно вреден для большинства проектов.
Но он реально подходит для тестирования API, когда мы весь функционал тестируем все равно
автоматизированно и тест в этом случае написать проще и эффективнее, нежели описывать ошибку словами.
Мы опять вернулись к началу. Я веду разговор не о названии или кратком описании дефекта, а о шагах для его повторения. Название и краткое описание нужны людям из бизнеса, а шаги – разработчикам и тестировщикам.
>Важность дефекта должны определять люди со стороны бизнеса
что приводит нас к необходимости держать все дефекты в одном месте (багтрекере) и писать словесные дескрипшены багов, потому что бизнес люди обычно не смотрят вики и не читают автотесты.
Важность дефекта должны определять люди со стороны бизнеса (за редким исключением сильно технического дефекта). Если они доступны между командами только на пару часов, то у вас уже и без того хватает проблем. Достаточно задуматься “а что если у меня вопрос возникнет по бизнес-логике?”.
Проблема в том, что понятие о том важный это дефект или не очень у разных людей разное. И если команды охватывают три часовых пояса, то таймслот в который можно договориться очень небольшой. 🙁 Баг трекер позволяет часть проблем решить без личного контакта.
Если он важный, то надо исправлять. А если с ним живут и не согласны на исправление, то зачем копить мусор? У нас команда в одной локации, но принципиальной разницы не вижу.
А нет ли риска, что какие-то важные проблемы будут навсегда спрятаны от заказчика на Wiki? Все-таки в багтрекере значительно легче следить за судьбой дефекта. А что если бага найдена в коде, который поддерживает другая команда, в другой локации?
У нас несколько другой подход к дефектам. Они скорее не норма, а исключение. Если дефект находится, что бывает очень нечасто, то сразу создается автотест и дефект чинится с наивысшим приоритетом. Если он “минорный”, то максимум это помечается на Wiki страничке в разделе “известные мелочи”, но репорт не добавляется в баг-трекер. В итоге баг-трекер всегда пуст, отношение к коду более внимательное и заказчики/конечные пользователи довольны.
Я против включения тестов на дефекты в регрессию вообще, совершенно не важно мануальную или автомейшен.
Про 100% зеленых тестов: а если у вас остается незакрытый минорный баг – релиз отменяют?
Да, требования меняются. Да, архитектура меняется. И тесты вместе с ними меняются. Вот только не могу понять в чем разница между изменениями в обычных тестовых сценариях. Там еще сложнее – тяжело отловить, что тест уже неактуален и требует изменений.
Все дело в магическом проценте, который у вас установлен в 80%. У нас статус “все хорошо” означает 100% тестов зеленые, а до этого фича не готова к релизу. И тогда сколько вы тестов ни добавите ситуация не исказится.
По поводу поддержки: Архитектура тестируемого приложения меняется, спецификации переписываются, требования к тестам меняются. Все это вынуждает переписывать тесты снова и снова. И в какой-то момент это занимает все время на тестировщика.
По поводу искажений. Например, есть набор регрессионных тестов – 100 штук 30 из них Fail (Pass- 70%), добавляем еще 50 тестов на уже пофикшеные баги – итого 150 тестов 30 по-прежнему Fail (Pass – 80%). Заветный процент достигнут и фича становиться готовой к релизу. Потому я против включения тестов на дефекты в регрессию. Я за запуск тестов на дефекты отдельными сьютами и поддержку их ровно до того момента пока они актуальны.
По поводу поддержки – тут все зависит от правильности архитектуры и правил написания тестов, а также от выбора инструментов. В некоторых случаях поддержка почти ничего не стоит.
А вот по поводу искажения картины тестирования не понял. Было бы интересно послушать. Мне казалось, что добавление теста на дефект и помечание его специальным маркером наподобие @Defect(“1456”) дает нам разделение тестов от проверок дефектов и еще большую гибкость в плане запуска – можно только тесты, только дефекты или все вместе.
Я не отрицаю полезность линковать автотесты к дефекту, сама так почти всегда поступаю, но из личного опыта знаю, что даже прокоментированый тест, написаный на юзерфрендовом фреймворке с “говорящими” названиями методов не исключает необходимости дескрипшена “словами” в багтрекинговой системе.
Больше тестов на регрессии не значит что покрытие стало лучше. Нужно подходить тщательно к выбору тестов на регрессию и добавлять все тесты для проверки фиксов всех багов явно не самая обдуманная стратегия. Автомейшен дает иллюзию что раздувание регрессии ничего не стоит, ведь тесты уже написаны, но на самом деле растет время на поддержку, искажаются результаты тестирования, хотя бы за счет того что в тестовой выборке становиться больше негативных тестов и заковыристых сценариев.
Все, что вы описали в качестве недостающих частей, можно описывать в комментариях (в случае Selenium IDE и ему подобных) или правильно названными/применяемыми методами в коде.
Интересно, а как вы справляетесь с растущей регрессией вручную? Больше тестировщиков нанимаете или тестируете только “самое важное”? И то и другое не дает вам гарантий отсутствия регрессии.
Сомнительная экономия времени для тестировщика. Потому что вот аттачу я к дефекту линку на падающий тест. И сразу возникает много серых пятен, которые все равно приходится прояснять в описании:
1)Почему я вообще считаю, что это бага?
2)Зачем нужно это фиксить ?
3)Где в моем тесте приведение в тестовую ситуацию (пред условие) и где собственно само воспроизведение бага.
Кроме того все равно надо словами, чаще по телефону, объяснять проблему и шаги ее воспроизведения широкому кругу заинтересованных лиц, которые не разбираются в тестовом фреймворке, не имеют времени запускать скрипт и вообще подключились на митинг из машины по дороге на работу.
Мысль добавлять все сценарии для дефектов в регрессию пугающая: Больше тестов на регрессии -> больше времени на поддержку регрессии -> меньше времени на тестирование нового функционала ->больше дефектов -> больше тестов для дефектов в регрессии
Хотя начать стоит вообще с вопроса нафига нам такой хитрый кэш, который иначе никак не проверить. А если можно проверить, то зачем мы так корячимся?
> В случае API – это скорее не симтоматика.
Зависит от API и того что там за ним стоит. У меня за API стоят алгоритмы с нечеткой логикой и небольшая пачка различных компонент, работа которых может зависеть от постоянно меняющихся данных и их структуры (которая тоже меняется). Там одного совершенно внешнего симптома недостаточно.
> Если проблема больше не воспроизводится, то разве это не значит что она исправлена?
Она не воспроизводится на сравнительно небольшом отрезке времени, который мы можем себе позволить отвести под наблюдения. Как правило в этом случае было бы отлично принять меры по мониторингу ситуации на приложении и перестраховать его от известного риска слета кэша и все это проверить. Это как минимум. И дело даже не в “Mission critical” – подобные вещи стоит делать в любом мало-мальски серьезном production-окружении, чтобы меру энтропии в и так не очень простой инфраструктуре не увеличивать. Это очень стремно, когда у тебя сервер случайно падает. Да и обычному приложению тоже не стоит.
>> А когда тест завалится – мне достаточно будет указать какой тест нужно запустить и в контексте какой базы. Так разработчики смогут вопроизвести баг.
Сергей Высоцкий :
> Еще раз – это симптоматика. И после фикса оно покажет только то, что данный симптом исчез.
В случае API – это скорее не симтоматика. Вызывая конкретную функцию – я получаю конкретный результат. И у меня есть исходный код, который я могу просмотреть. Я не отрицаю, что в результате фикса может быть исправлен всего лишь симптом, но скорее всего будет исправлена именно конкретная проблема.
В случае с вышибающим мозги кешем? Если проблема больше не воспроизводится, то разве это не значит что она исправлена? Я понимаю, что где-то внутри может жить еще куча гипотетических багов, но стоит ли тратить время на их поиск, если в принципе проблем с функционалом нет?
В разных ситуациях ответ на этот вопрос может быть разным. В медицинском софте, с уверенностью можно сказать – да. В финансовом “Mission critical” – да. В любом другом – может быть и нет.
> А когда тест завалится – мне достаточно будет указать какой тест нужно запустить и в контексте какой базы. Так разработчики смогут вопроизвести баг.
Еще раз – это симптоматика. И после фикса оно покажет только то, что данный симптом исчез.
Вот, скажем, у меня есть проблема рассинхронизации кэша. Не закапываясь особо в код я пишу скрипт, который примерно за полтора часа своей работы показывает что да, нашему приложению время от времени вышибает мозги к чертям (+ собирает всякую попутную телеметрию с приложения для фиксации других возможных проблем). Назовем его автоматическим тестом.
Я отдаю это счастье разработчику. Он смотрит – правда раз в полтора часа вышибает мозг. Что-то чинит, проверяет. Я смотрю что вроде за полтора часа не вышибает. За день тоже. За неделю вроде тоже ок. Мы молодцы? Нет, нам обоим за такое по рукам надавать надо и от монитора на месяц отлучить.
> Удивлю вас, если скажу, что описанным методом мы действуем и вовсе без тестировщиков, а в некоторых проектах лишь с одним тестировщиком?
Нет. Я всегда считал что лучше никакого тестирования, чем плохое.
> Задача регрессионных тестов – не искать баги, а не допускать их.
Нет. Тут сложнее. Скорее сигнализировать об изменениях. Это, как лампочка в экспериментах Павлова, может помочь выработать полезные рефлексы у разработчика. Он будет стараться писать более стабильный и качественный код, чего для решения регрессионных рисков, как правило, более чем достаточно.
> Поэтому расчеты процентов из головы бессмыссленны.
Они не из головы. Это исследования авторов Agile Manifesto. Довольно старые.
> И проблемы с отвратным кодом регрессия конечно же не исправит. Их вообще тестировщики никак не исправят.
А тестировщики вообще не исправляют ничего. Мы чисто информационный сервис – ищем проблемы и сообщаем о них. Помогаем, так сказать, управлять рисками. И если вы о каких-то проблемах не знаете, то это еще не значит, что их у вас нет. А если вы понятия не имеете как искать неизвестные вам проблемы и доступные вам тестировщики не могут вам помочь решить эту задачу – скорее всего эти тестировщики вам и не нужны.
> И тогда все будет так же как с REST.
Не, не будет. Уровень абстракции у UI выше и потому возникают всякие неприятности, вроде race conditions на асинхронных действиях, которые в UI в любом случае ловить сложнее, чем на REST. И вопросы кроссплатформенности для REST-интерфейсов не так остро стоят, как реализация JavaScript для разных браузеров. Да, большую часть проблем можно минимизировать нормальным Testability и хорошим дизайном тестов, но так же как REST все равно не будет.
Вот! То есть получается, что разница с UI только в сложности интерфейса по сравнению с REST. Выходов несколько:
Писать лучше UI, чтобы его было легко автоматизировать
Выбирать правильный подходящий инструмент
Научиться им пользоваться умело и использовать предыдущие наработки
И тогда все будет так же как с REST.
Время на поддержку тестов не будет расти в случае если вы:
Добавляете их в CI
Вводите правило “кто поломал тест, тот его и чинит”
Тогда поддержка распространяется на всю команду и все пытаются улучшить тесты, чтобы они были стабильнее. Но если уж проект такой говнокодный и работают одни раздолбаи и студенты, то можно использовать автоскрипты только для описания дефекта и не добавлять их в общую автоматизацию. Тогда вопросы поддержки отпадают сами по себе.
В поддержку идеи, скажу что сейчас занимаюсь тест-дривен тестингом. А точнее, покрываю интеграционными тестами (в интеграции с базой Oracle и SQLServer одновременно) Rest-API нашего приложения.
В данном случае, единственный способ протестировать необходимые мне функции – это написать авто-тест, в котором дергается одна или несколько функций API. А когда тест завалится – мне достаточно будет указать какой тест нужно запустить и в контексте какой базы. Так разработчики смогут вопроизвести баг.
Задача регрессионных тестов – не искать баги, а не допускать их. Поэтому расчеты процентов из головы бессмыссленны. И проблемы с отвратным кодом регрессия конечно же не исправит. Их вообще тестировщики никак не исправят. Не платить за поддержку автотестов можно двумя способами: писать качественные автотесты и писать качественные автотесты. 🙂
Удивлю вас, если скажу, что описанным методом мы действуем и вовсе без тестировщиков, а в некоторых проектах лишь с одним тестировщиком? 🙂
> Чем больше будет автоматизированной регрессии, тем меньше проблем будет у тестировщиков и команды.
Правило “чем больше тем лучше” для регрессии не работает. Эффективность нахождения дефектов у регресионных тестов низкая (от силы 20%). У автоматических регрессионных тестов еще ниже. Единственное для чего регрессионные тесты более или менее нормально работают – обнаружение изменений. Поэтому их не надо много – их надо достаточно. Иначе вы убиваете 95% усилий на обнаружение ~5-20% дефектов.
Проблемы с техническим долгом, плохой архитектурой и отвратным дизайном кода регрессионными тестами обнаружить крайне сложно. А головняков от этих проблем сильно больше.
Так что еще раз повторяю – то что тут предлагается это оптимизация починки регрессионной симптоматики. Круто, конечно, но затраченных усилий как правило не стоит.
Но это проблема современной автоматизации в принципе – кроме автоматизации регрессии никто ничего не знает (или не умеет?). Ну иногда нагрузки, но и там у людей пробелы с матстатистикой чудовищные. При этом всех все устраивает до поры до времени.
Метод описанный в статье – это прекрасный способ раздуть команду тестирования в несколько раз. Прекрасная цель с точки зрения [псевдо]карьеры, вы не находите? Одно дело “у меня было 5 тестировщиков” и совсем другое: “у меня было 25 автоматизаторов”.
>Чем больше будет автоматизированной регрессии, тем меньше проблем будет у тестировщиков и команды
До поры до времени так и будет. Дело в том , что это все хозяйство требует поддержки и попутно разрастается. Все очень сильно зависит от фреймворка автотестов. Если он сам изменяется и развивается, то часто старые тесты необходимо актуализировать только поэтому. Меняется также и тестируемый код, интерфейсы (GUI, API..).. Некоторыые тесты становятся неактуальными. Может так случиться , что со временем путь воспроизведения бага, который проверяет регрессионный тест, может просто перестать сущестовать. То есть по мере роста числа тестов будет рости и время на их поддержку. Выход – либо нанимать еще людей, либо отключать какие-то тесты.
Практика показывает, что с наймом часто бывают проблемы. А второй путь – путь отключения тестов будет противоречить принципу “тотальной автоматизации регрессии” )
Автоматизировать нужно конечно же, но с очень большой оглядкой . Вопросы при этом: КАК автоматизировать?, КТО автоматизирует? и ЧТО ИМЕННО автоматизирует.
Смотреть по сторонам обязаны и тестировщик и разработчик. Я считаю, что это очень важно. Но речь скорее об оформлении дефекта и попытке оптимизировать контроль его повторяемости.
Очень даже рационально, особенно в быстрорастущем проекте. Чем больше будет автоматизированной регрессии, тем меньше проблем будет у тестировщиков и команды. А без модульных тестов тоже никуда, тут я полностью поддерживаю.
Видео – это уже шаг навстречу эффективности. В этом случае ты можешь экономить на описании дефекта, а разработчик – на интерпретации шагов.
> Точно так же и с тестировщиком – он должен дать надежный и быстрый способ проверить, что дефект повторяется или же исправлен.
Проблема в том, что большая часть багов это просто описание симптомов реальной проблемы. И если старый симптом исчез это еще не значит, что все стало хорошо. Ведь если у вас прошел кашель, то еще не факт что вы выздоровели – возможно болезнь перешла в терминальную стадию и вам скоро умирать. А то, что тут предлагается в статье это отличный способ быстро глушить симптомы не углубляясь в саму проблему. Нужна обратная связь. Тесты это отличный способ коммуникаций между разработчиками и разработчик-тестировщик, но они должны быть в обе стороны, иначе в этом нет смысла. И тут будет итеративный процесс, т.к. это будет диалог. И не стоит в нем форсировать скорость – это опасно. Задача же не быстро накостылить, а избавиться от проблемы раз и навсегда.
Если у вас проблемы с регрессией – фикса и сценария недостаточно. В идеале нужно смотреть гулбже – дизайн, код, архитектура и т.д.. Ведь недостаток сценариев сам по себе проблемой не является – проблема в дефекте и том, что этот дефект породило.
Нерационально тестировщикам заниматься регрессией каждого найденного ими ранее бага. Дорого.
Тут, как мне кажется уместно следующее разделение: тестировщики занимаются регрессией тех багов , автоматизация проверки которых ну уж очень трудоемка… например какой-нибудь гипотетический race-condition в распределенной системе )
Разработчики же пишут дешевые, быстрые unit-ы там где они могут быть дешевыми и быстрыми….
А в общем, ну никуда вы не денетесь, от описанных вами пяти или “семи раз”… поэтому вкладываться лучше не в огульную автоматизацию воспроизведения/проверки каждого бага , а в комплекс мер, направленных на снижение количетсва багов в целом… В общем , опять банальная мысль : “лучше лечить причину , а не следствие”.
Я пользуюсь записью видео в тех случаях, когда текстовое описание может быть непонятным.
Для разработчиков воспроизвести видео-баг не составляет большого труда, с учетом того, что они могут использовать мою тестовую базу со всеми данными.
А чтобы проверить фикс, возможно разработчику не следует кликать на все кнопки, а достаточно написать юнит-тест, который бы вызвал одну единственную функцию.
TDD я привел для примера мышления – прежде чем начинать работу над исправлением дефекта надо позаботиться о простом способе проверить свою работу. Точно так же и с тестировщиком – он должен дать надежный и быстрый способ проверить, что дефект повторяется или же исправлен.
Ну а вакансия конечно – полнейший бред.
Разработчик хороший и напишет тест перед исправлением, только на уровне кода. А на уровне UI это может сделать тестировщик.
Видел одну вакансию тестировщика-автоматизатора, не разработчика, со знанием TDD. Долго смеялся. Ведь TDD это тогда, когда сам разработчик пишет тесты для того, чтобы реализовать необходимую ему функциональность. В противном случае – это не TDD – а набор модульных тестов, написанных другим человеком. Разница тут большая.
Ну, а BDD – это лишь набор лучших практик TDD + связь тестов с хотелками бизнеса.
Возвращаясь к вопросу: да, у разработчика должен быть способ проверить то, что проблема исправлена. И TDD в таком случае будет эффективным. Но, и тесты должны быть написаны сами разработчиком, но не тестировщиком.
1. Важна не скорость предоставления отчетов, а эффективность их исправления. Если хотите ускорить отчеты, то оформляйте дефекты после отчета.
2. Не мешайте теплое с мягким – речь в статье именно об оформлении дефекта, а не о тестировании. Любое оформление дефекта отвлекает от сессии тестирования.
3. Мне казалось, что аналитикам и прочим нужен рабочий продукт, а не дефекты. 😉 В случае Selenium IDE аналитики получат возможность запускать дефект, да и к коду можно их не допускать – главное дать возможность запуска.
4. Причина в том, что сценарии надо писать в ручную и потом много раз запускать вручную, а это долго и зависит от человеческого фактора.
5. Как он может содержать баги? Вы же прогоняете его и убеждаетесь, что ошибка повторилась. В этом его миссия – он может быть плохого качества, ненадежным при изменениях на страницах. Главное повторить дефект.
А вы слыхали о TDD и BDD? Или их тоже вы считаете порочными практиками? Так вот, по принципу TDD, прежде чем начинать работу над исправлением дефекта надо позаботиться о простом способе проверить свою работу.
Если тестировщики вместо написания очередной «истории дефекта» будут предоставлять автоматизированный скрипт, то многих перечисленных выше проблем можно будет избежать.
Отличная идея! Посетила меня три года назад! Попробовал! Неделю! Потом забил по причинам, которые Дима указал.
Конечно, я делал не так, как надо.
1. очень большое кол-во отчетов о багах необходимо предоставлять быстро, чем быстрее, тем лучше. Написание кода вместо сценария отлично увеличит время предоставления фидбека о продукте на дни или недели, конечно потом это время окупится, когда продукт будет в проде, а тестировщик будет дописывать скрипты 🙂
2. самое опасное, когда тестировщик тестирует – он тестирует (сорри кэп), врядли он сможет продолжить тестирование с тем же настроем и мыслями, после того как ему прийдется переключится на создание скрипта.
3. баги нужны не только девелоперам, интересно как обрадуются аналитики и прочие, при получении вместо сценария интересного кусочка кода 🙂
4. если причина плохих сценариев в дефектах (так, что эти сценарии надо много раз перепрогонять) кроется в самом тестировщике, то не стоит ждать от него хороших скриптов, скрипты придется отлаживать еще дольше (узнавая у того же тестировщика сценарий 🙂 )
5. код скрипта тоже будет содержать баги:).
ну а так вообще идея хорошая, надеюсь никогда не встретить ее в реальной жизни:)
Не согласен, что подход будет неуместен. Selenium IDE легко поможет решить проблему, если автоматизации нет в проекте совсем. Если есть, то надо просто использовать уже написанное.
Да, это можно легко протестировать. И как было замечено, можно добавить задачу на написание теста на все страницы.
Никого не надо поддерживать. Надо просто указать на какой версии сценарий работал. Если багу сразу не поправят (что уже плохо, потому что усилий надо тратить гораздо меньше), то потом можно вернуться на ту версию кода и найти проблему. Если на новом коде она уже не повторяется, то закрыть. Тут как и с обычным баг репортом.
Все правильно. Можно и нужно смотреть по сторонам, но не придется повторять все шаги вручную. Дошел до 12-ого шага с помощью скрипта, а дальше руками. Потом до 15-ого и опять руками. Это почти бесплатно и не тратит времени. Поэтому можно прогонять много раз.
Эта хорошая мысль, но только лишь в контексте определенных проектов.
Например, для библиотеки или любом другом сервисе без UI – очень хорошее решение.
Известно то, что раньше разработчики MySQL (до Оракловский период) писали тест на каждую багу для того, чтобы другие разработчики могли понять пофиксана ли та бага или нет, просто прогоняя тест.
Но, что делать в том случае, если в приложении есть динамический HTML интерфейс всякими AJAX запросами и кучей JavaScript? Тут такой подход будет просто неуместным. Потому что стоить будет дорого.
Ну, вот пример.
На странице была найдена JavaScript-овая ошибка. Каков будет тест на багу?
Зайти на страницу и проверить что там нет JavaScript ошибки?
Почему бы вместо этого не написать сценарий, который способен находить такие ошибки динамически для любой страницы?
С другой стороны, а сколько времени потратит тестировщик, программируя новый сценарий для минорной баги? Или может быть в таком случае Selenium IDE лучше использовать? А ведь это все потом еще и поддерживать нужно.
Ну, и напоследок по пунктам:
«Проблема найдена и исправлена, после чего разработчик запускает сценарий еще раз для проверки.
Тестировщик также запускает сценарий для проверки пару раз для уверенности.»
Да, все верно. Один раз я запускаю сценарий, чтобы проверить фикс, и еще раз, чтобы посмотреть не сломалось ли чего рядом. И таки ломается и очень часто. Но, авто-скрипт не будет смотреть по сторонам.
А то, что тот же самый баг может воспроизвестись два раза – да такая вероятность есть. Но, она мизерная. Скорее всего может быть другая регрессионная поломка в той же функциональности, и ту поломку такой тест-на-баг может и не найти.