Что пишут в блогах

Подписаться

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Управление дефектами
Чему меня научил один маленький баг
16.11.2020 00:00

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Почти десять лет назад я написал серию статей об оценке проекта и черных лебедях.

И почти что спустя десять лет Крис НеДжейм сообщил о своем наблюдении об абзаце ближе к концу четвертой части:

Как часто говорил Джерри (Вайнберг), множество компаний становятся жертвами неужач, но в основном всему виной не неудачи, а то, как они реагируют на неудачи.

Заметили проблему? Крис заметил. Он вежливо сообщил – "возможно, что в части 4 опечатка: "неужач"?" После чего я исправил баг.

Какие уроки можно из этого извлечь?

Подробнее...
 
Разбираемся с баг-репортом
07.09.2020 00:00

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Хорошо тестировать – значит находить значимые баги, с учетом предположения, что эти баги существуют (а мы всегда, всегда начинаем с этого предположения). Эти баги зарождаются в темноте, и мы выводим их на свет, оперируя продуктом всеми правильными способами. Я иногда чувствую, что баги застряли в коробке, а я трясу эту коробку, стучу по ней, как человек, у которого застряла монетка в автомате. Заметьте, я сказал, что я это чувствую. Я абсолютно точно так не думаю, и я редко так говорю, потому что это придает тестированию вид грубого усилия, а не вдумчивого процесса проектирования, достойного умных людей вроде нас (но да, я могу чувствовать себя гориллой из этого знаменитого рекламного ролика. Баг, выходи, подлый трус!)

Подробнее...
 
Измерение Production инцидентов, как цена качества
10.03.2020 01:00

Случалось ли в вашей практике такое, что инцидент, который ещё совсем недавно казался незначительным, приводил к тому, что пригорюнивался весь прод? Или баг, который поначалу казался катастрофой, в итоге, почти ни на что не влиял? Как понять фактическое влияние и распознать мину замедленного действия среди потока багов и сбоев?

В приоритизации и работе со сбоями необходимо четко понимать:

  • первопричины сбоя,
  • триггер, который стал толчком для сбоя,
  • масштаб проблемы и влияния на бизнес.

Об этих и других характеристиках рассказал в своём докладе Дмитрий Химион. Также речь шла о практике рассмотрения Production сбоев, которую в Авито используют для понимания характера проблемы и принятия решений.

 

А мы ждем вас и в этом году на четвертом выпуске конференции TestCon Moscow 2020.

Всем читателям портала традиционно предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10

Обсудить в форуме

 
Как закрывать задачи в баг-трекере
04.10.2019 00:00

Автор: Назина (Киселева) Ольга (автор тренинга Школа для начинающих тестировщиков)

Аналогичную статью я написала в рабочем конфлюенсе в 2013 году. И на момент написания этой статьи (2019 год) она все еще была актуальна.

Исходно чек-лист записала как напоминание, в том числе и себе. Потому что к задачам приходится возвращаться, в том числе людям, которые их НЕ проверяли. Например, во время регрессии надо хотя бы базово проверить функционал.

И вот ты открываешь задачу, листаешь до последнего комментария посмотреть, какая документация, что как работает, а там… Пусто. Или скромное «Все проверено, все ок». А документация где? Я же не в теме задачи, я хочу прочитать побольше!

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

image


Подробнее...
 
Искусство баг-репорта: основные принципы оформления дефектов
22.08.2019 00:00

Автор: Аннелиз Хербоза (Anneliese Herbosa)
Оригинал статьи
Перевод: Ольга Алифанова

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

Подробнее...
 
О записи багов, или Найди кота
21.08.2019 00:00

Автор: Андрей Кулешов, Developer Soft
Оригинальная публикация

Эта статья родилась из поста на внутреннем форуме нашей конторы, немножко пообсуждалась, слегка дополнилась, а потом я решил выложить её в итоговом виде тут, чтобы ссылаться было удобнее.
Да, пост капитанский, это ожидаемое поведение :) я просто хочу это иметь собранным, упорядоченным и общедоступным.

Введение: найди кота

В продуктах, которые мы разрабатываем, есть баги.

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

Найди кота

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

А я должен сидеть, пыриться в монитор и искать грёбаного кота.

Подробнее...
 
Багов, еще не описанных..сколько..
03.10.2018 12:36

Автор: Алена Балакина, тренер Первого Онлайн Института Тестировщиков, http://pointschool.ru/

Здравствуйте, дорогие друзья!

Бесспорно, постановка задач - одна из крупнейших составляющих работы практически любого тестировщика.

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

А как описать дефект качественно и составить грамотный баг-репорт?

Читайте дальше - в этой статье мы поделимся некоторыми полезностями по составлению самых важных частей баг-репорта!

Подробнее...
 
Знакомимся с российской системой управления тестированием Devprom ALM
20.08.2018 11:19

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

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

Исторически сложилось, что тестировщики используют бесплатные решения типа 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. Наша команда бесплатно проводит демонстрацию возможностей системы - напишите нам запрос по адресу info@devprom.ru и мы согласуем удобные дату и время проведения демо нашей платформы.

Обсудить в форуме

 
Мастер-класс по заведению дефектов от Ольги Назиной
19.01.2018 12:45

В рамках прошедшей онлайн-конференции для тестировщиков КоТэ было проведено несколько мастер-классов.

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

Ольга Назина - автор многочисленных статей и курсов по тестированию, таких как Школа начинающих тестировщиков, Интенсив для начинающих тестировщиков.

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

Задание

1. Провести тестирование указанного функционала

2. Оформить найденные баги в гуглодоке
Функционал тестируем конкретный. Так проще (не надо тестировать все) и интереснее — кто больше багов найдет? =) Тестируем:
  1. Поиск товара — https://www.wildberries.ru/ (регистрироваться не надо, исследуем только поиск)
  2. Поиск аптеки — http://papteki.ru/apteki/
  3. Общение на форуме. Создание новых тем не тестируем, только переписка внутри этой. Создать свое сообщение, процитировать чужое итд. Да, тут придется зарегистрироваться =)
  4. Баг-трекер Багзиллу — http://bugzilla.testbase.ru/. Да да, мы тестируем реальный баг-трекер! Заведение дефектов, редактирование, прикладывание аттачей... 
    Зайти в багзиллу можно с данными
    логин — mail.for.testbase@yandex.ru
    пароль — 12345678

Во время конференции Ольга показывала заведенные баги (все анонимно!) и разбирала выявленные ошибки.

Просмотр записи мастер-класса имеет смысл, если Вы так же как участники сначала попробуете выполнить задание, а уже потом будете смотреть видео.

Обсудить в форуме

 
Отчеты об ошибках, или как просто встать на путь постоянного совершенствования
25.10.2016 11:56

Выступление Сергея Атрощенкова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA

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

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

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

Так почему бы нам не пойти по пути постоянного совершенствования в написании баг-репортов вместе? Какими путями я шел и иду к «просветленному» отчету, на что я обращал и обращаю внимание, что исправлял и исправляю в отчетах и почему — об этом и пойдет речь в моем докладе. Не стоит бояться наступать на грабли, совершенствуясь в работе. И даже когда всё кажется превосходным — посмотрите, можно ли улучшить баг-репорты?

Подробнее...
 



Страница 1 из 3