Случалось ли в вашей практике такое, что инцидент, который ещё совсем недавно казался незначительным, приводил к тому, что пригорюнивался весь прод? Или баг, который поначалу казался катастрофой, в итоге, почти ни на что не влиял? Как понять фактическое влияние и распознать мину замедленного действия среди потока багов и сбоев?
В приоритизации и работе со сбоями необходимо четко понимать:
первопричины сбоя,
триггер, который стал толчком для сбоя,
масштаб проблемы и влияния на бизнес.
Об этих и других характеристиках рассказал в своём докладе Дмитрий Химион. Также речь шла о практике рассмотрения Production сбоев, которую в Авито используют для понимания характера проблемы и принятия решений.
А мы ждем вас и в этом году на четвертом выпуске конференции TestCon Moscow 2020.
Всем читателям портала традиционно предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10
Аналогичную статью я написала в рабочем конфлюенсе в 2013 году. И на момент написания этой статьи (2019 год) она все еще была актуальна.
Исходно чек-лист записала как напоминание, в том числе и себе. Потому что к задачам приходится возвращаться, в том числе людям, которые их НЕ проверяли. Например, во время регрессии надо хотя бы базово проверить функционал.
И вот ты открываешь задачу, листаешь до последнего комментария посмотреть, какая документация, что как работает, а там… Пусто. Или скромное «Все проверено, все ок». А документация где? Я же не в теме задачи, я хочу прочитать побольше!
Или если заказчик пишет, что у него что-то не работает, а ты хочешь проверить, покрыта ли ситуация автотестами. Идешь в задачу, а там нет ссылки на автотесты. Их вообще не писали? Или просто ссылку не дали? Приходится выяснять…
Автор: Аннелиз Хербоза (Anneliese Herbosa) Оригинал статьи Перевод: Ольга Алифанова
Тестировщики – это рассказчики. До тестирования я работала в коммуникациях, и одна из поразительных параллелей обеспечения качества и тестирования с моей бывшей профессией – это то, что важная часть работы тестировщика заключается в рассказе коротких историй через мгновенную обратную связь о продукте. Один из мощных повествовательных инструментов в их арсенале – это баг-репорт. Я постоянно стремлюсь улучшить свои повествовательные навыки, дабы повысить эффективность своих баг-репортов, и вот какие сходства я выявила:
Эта статья родилась из поста на внутреннем форуме нашей конторы, немножко пообсуждалась, слегка дополнилась, а потом я решил выложить её в итоговом виде тут, чтобы ссылаться было удобнее.
Да, пост капитанский, это ожидаемое поведение :) я просто хочу это иметь собранным, упорядоченным и общедоступным.
Введение: найди кота
В продуктах, которые мы разрабатываем, есть баги.
Мы их иногда находим. Иногда даже записываем.
Для того, чтобы помочь нашим коллегам, сделать их продукт лучше.
И очень обижаемся, когда коллеги нам пишут – "я нихрена не понял", "у меня не воспроизводится", "приди покажи".
Иногда так говорю я.
Потому что достаточно часто баги выглядят как картинка "найди кота".
Тот, кто записал баг, точно знает, где кот. Он его уже нашёл. Он уже не может его развидеть.
А я должен сидеть, пыриться в монитор и искать грёбаного кота.
Из-за ускорения разработки, задачи обеспечения качества на проектах становятся более разноплановыми и сложными. Ручное функциональное тестирование, автоматизированное интеграционное тестирование, нагрузочное тестирование и проверка на регресс - все эти виды тестирования обязательны и требуют особенных навыков, а главное - инструментальной поддержки.
Традиционные баг-трекеры не решают всех этих задач, поэтому для любой команды стоит вопрос об использовании дополнительного инструментария. Например, такого который позволит создавать и обсуждать тестовую документацию, фиксировать результаты тестирования, объединять отчеты ручного и автоматизированного тестирования на одном дашборде, распределять работу между тестировщиками и сообщать разработчикам всю необходимую информацию - контекст для воспроизведения дефектов.
Исторически сложилось, что тестировщики используют бесплатные решения типа TestLink или платные Zephyr, TestRail. В случае с бесплатными, основной сложностью является установка, администрирование и низкое качество интерфейса. Желающих создавать и развивать продукты бесплатно в долгосрочной перспективе - почти нет. Поэтому часто такие продукты реализуют совсем минимум не очень удобной функциональности и годятся лишь для решения простых задач. Платные продукты не обладают этими слабостями, поскольку над ними работают продуктовые команды, работают ради пользователей. Однако, здесь наблюдается проблема другого рода. Например, Zephyr и TestRail рассчитаны на простые задачи и являются лишь дополнениями к баг-трекеру, причем интеграция требует настройки. Функциональность подобных продуктов представляется как полумеры, и не позволяют организовать эффективный тестировочный процесс.
Тестирование неразрывно связано с системными требованиями, с процессом выпуска релизов и сборок продукта. Требования постоянно меняются, поэтому нужно обновлять и тестовую документацию, поддерживать их в целостном состоянии. Эффективно эти задачи решаются только системами класса Application Lifecycle Management (ALM), которые традиционно производят только западные компании и продают очень дорого.
Российская разработка Devprom ALM уникальным образом объединяет лучшие стороны бесплатных продуктов и платных профессиональных инструментов уровня ALM. Базовая функциональность по управлению задачами команды по Scrum или Kanban предоставляется бесплатно и без ограничений, реализуя полноценный баг-трекер, совмещенный с базой знаний проекта. Дополнительный модуль тестирования органично развивает базовую функциональность и предоставляет возможности по тестированию уровня ALM-систем, по аналогии с такими продуктами как HP ALM, HP QC, IBM Rational, Microsoft TFS. При этом стоимость лицензии на одного тестировщика не велика и окупается многократно уже за несколько дней использования продукта.
Devprom ALM - это веб-приложение, в котором удобно и быстро создаются дефекты в результаты заполнения тестовых отчетов. Тестировщику не нужно в описании дефекта перечислять все шаги того, как он пришел к ошибке, поскольку все эти шаги уже описаны в тестовой документации, по которой выполняется тестирование. Дефект связан с конкретным тестовым отчетом и разработчик одним кликом сразу переходит в тот контекст тестирования, в котором тестировщиком была обнаружена ошибка в ПО. Весь процесс тестирования органично вписан в процесс разработки ПО, соответствующий стадии продукта или тонко настроенный под особенности вашей работы, будь то заказное тестирование, контроль качества при выпуске сложного продукта или работа в кроссфункциональной команде.
В отличие от продуктов, производимых партнерами Atlassian (таких как Zephyr), вы не оплачиваете лишних лицензий. Например, в вашей команде два тестировщика и 10 разработчиков. Функциональность управления задачами в проектах достается всем бесплатно, а купить нужно только 2 лицензии на модуль управления тестированием и не платить при этом за разработчиков, аналитиков или представителей заказчика - это очень выгодно!
Познакомиться подробнее с описанием возможностей Devprom ALM вы можете на сайте продукта: http://myalm.ru. Создайте свой экземпляр в нашем облаке и получите бесплатный 30-дневный оценочный период, чтобы лучше познакомиться с возможностями Devprom ALM. Наша команда бесплатно проводит демонстрацию возможностей системы - напишите нам запрос по адресу
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
и мы согласуем удобные дату и время проведения демо нашей платформы.
Общение на форуме. Создание новых тем не тестируем, только переписка внутри этой. Создать свое сообщение, процитировать чужое итд. Да, тут придется зарегистрироваться =)
Баг-трекер Багзиллу — http://bugzilla.testbase.ru/. Да да, мы тестируем реальный баг-трекер! Заведение дефектов, редактирование, прикладывание аттачей... Зайти в багзиллу можно с данными логин —
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
пароль — 12345678
Во время конференции Ольга показывала заведенные баги (все анонимно!) и разбирала выявленные ошибки.
Просмотр записи мастер-класса имеет смысл, если Вы так же как участники сначала попробуете выполнить задание, а уже потом будете смотреть видео.
Выступление Сергея Атрощенкова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA
Тестирование без такого артефакта, как отчет об ошибке, станет ненужной активностью разработки ПО. Странно было бы тестировать, находить ошибки, но не сообщать о них. Тестировщики выглядели бы такими кибер Мальчишами-Кибальчишами, обладающими Главной Военной Тайной, про которую они не скажут никому.
Баг-репорт – важнейший документ. Тестировщикам нечего делать в профессии без умения четко и внятно донести необходимую и актуальную информацию до лиц, ответственных за принятие решений.
Непрофессиональные отчеты об ошибках могут являться причинами срыва сроков и задержек в поставке ПО.
Так почему бы нам не пойти по пути постоянного совершенствования в написании баг-репортов вместе? Какими путями я шел и иду к «просветленному» отчету, на что я обращал и обращаю внимание, что исправлял и исправляю в отчетах и почему — об этом и пойдет речь в моем докладе. Не стоит бояться наступать на грабли, совершенствуясь в работе. И даже когда всё кажется превосходным — посмотрите, можно ли улучшить баг-репорты?
Десять дней назад мы запустили опрос про популярность баг-трекеров. Мы предложили ответить на два вопроса: “Какие системы для работы с ошибками вы используете в своей работе?” и “Почему?”
В опросе приняли участие 170 человек.
Ниже представлена диаграмма частоты использования инструментов по результатам этого опроса. На диаграмме представлены только те инструменты, который получили больше одного голоса (все инструменты в порядке убывания голосов представлены в конце статьи).
Чаще всего респонденты нашего опроса используют Jira, на втором месте по популярности - Redmine, а на третьем - MS TFS.
Теперь посмотрим на основные причины выбора той или иной системы.
Ученый, рассказчик, или официальный представитель?
Мне с трудом далась четвертая глава книги Джеймса Баха "Lessons Learned in Software Testing" ("В защиту багов"). Нет, она не была менее понятной или более интеллектуально насыщенной, чем первые три. Просто она полна противоречий.
Вопрос в моем подзаголовке очень волнует меня. В некотором роде тестировщик выполняет каждую из этих ролей. Ранее я уже говорил об этом. Однозначно ответить на этот вопрос невозможно. Крутой рассказчик может быть уважаемым ученым. А прекрасный ученый - интереснейшим рассказчиком.
Но тут всплывает более интересный вопрос - а как мы должны воспринимать сами себя, когда мы создаем и курируем свои баг-репорты? Бах, Кейнер и Петтикорд дают на это очень расплывчатый ответ.
Судя по главе в книге Баха, авторы рисуют два крайне различных - и очень противоречивых - портрета тестировщика. С одной стороны, это дисциплинированный, объективный, дотошный автор отчетов, который борется с желанием все преувеличить и выдает только голые факты, необходимые для принятия рациональных решений насчет реакции на баг-репорт.
"Вы информ-бюро... Ваша задача - сообщать о багах точно и внятно, чтобы читатель понял весь объем проблемы... Если вы преувеличиваете серьезность бага, вы утратите доверие... Ваша работа - сообщать о багах, а не выяснять, почему они произошли... старайтесь быть нейтральным... Не настаивайте на фиксе каждого бага, расставляйте приоритеты..."
С другой стороны, тестировщик отстаивает баги, вкладывается в них эмоционально, и мотивирован бороться за них из политических соображений. Он готов использовать свое влияние в офисе через головы коллег, чтобы вопросы исправления багов решались так, как нужно ему.
"Любой баг-репорт - это адвокатская речь, призывающая к исправлению этого бага... это инструмент продаж, его цель - убедить людей... вы можете обнаружить сравнительно минорный баг и, исследуя его, узнать о серьезных последствиях... Чтобы баг исправили, вам нужно заставить всех ответственных за контроль изменений одобрить это исправление... Если убедить разработчиков сложно, но вы считаете, что баг надо исправить, подумайте, кому в компании еще выгодно исправление этого бага..."
Какой портрет более точный? Какую роль выбирать? Читая эту главу, определиться невозможно. На самом деле я вообще не уверен, что из этой главы можно извлечь некий универсальный принцип. Реальность такова, что иногда вы просто докладчик, а иногда - адвокат, и чтобы понять, какую роль сыграть, нужен опыт. Хотелось бы, конечно, чтобы Джеймс Бах и Кем Кейнер изложили чуть больше своих идей на этот счет.
Из-за ускорения разработки, задачи обеспечения качества на проектах становятся более разноплановыми и сложными. Ручное функциональное тестирование, автоматизированное интеграционное тестирование, нагрузочное тестирование и проверка на регресс - все эти виды тестирования обязательны и требуют особенных навыков, а главное - инструментальной поддержки.