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

Подписаться

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

Конференции

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

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

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

.
Управление дефектами
Как закрывать задачи в баг-трекере
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

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

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

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

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

Подробнее...
 
Результаты опроса про популярность баг-трекеров
30.08.2016 18:34

Десять дней назад мы запустили опрос про популярность баг-трекеров. Мы предложили ответить на два вопроса: “Какие системы для работы с ошибками вы используете в своей работе?” и “Почему?”

В опросе приняли участие 170 человек.

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

Чаще всего респонденты нашего опроса используют Jira, на втором месте по популярности - Redmine, а на третьем - MS TFS.

Теперь посмотрим на основные причины выбора той или иной системы.

Подробнее...
 
Заступничество, Наблюдения, Будущее
14.03.2016 14:11

Автор: Грег Готьер (Greg Gauthier)

Оригинал статьи: http://www.gmgauthier.com/advocacy-observation-and-the-future/

Перевод: Ольга Алифанова

Ученый, рассказчик, или официальный представитель?

Мне с трудом далась четвертая глава книги Джеймса Баха "Lessons Learned in Software Testing" ("В защиту багов"). Нет, она не была менее понятной или более интеллектуально насыщенной, чем первые три. Просто она полна противоречий.

Вопрос в моем подзаголовке очень волнует меня. В некотором роде тестировщик выполняет каждую из этих ролей. Ранее я уже говорил об этом. Однозначно ответить на этот вопрос невозможно. Крутой рассказчик может быть уважаемым ученым. А прекрасный ученый - интереснейшим рассказчиком.

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

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

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

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

"Любой баг-репорт - это адвокатская речь, призывающая к исправлению этого бага... это инструмент продаж, его цель - убедить людей... вы можете обнаружить сравнительно минорный баг и, исследуя его, узнать о серьезных последствиях... Чтобы баг исправили, вам нужно заставить всех ответственных за контроль изменений одобрить это исправление... Если убедить разработчиков сложно, но вы считаете, что баг надо исправить, подумайте, кому в компании еще выгодно исправление этого бага..."

Какой портрет более точный? Какую роль выбирать? Читая эту главу, определиться невозможно. На самом деле я вообще не уверен, что из этой главы можно извлечь некий универсальный принцип. Реальность такова, что иногда вы просто докладчик, а иногда - адвокат, и чтобы понять, какую роль сыграть, нужен опыт. Хотелось бы, конечно, чтобы Джеймс Бах и Кем Кейнер изложили чуть больше своих идей на этот счет.

Подробнее...
 
Природная лень, или "У меня все работает"
20.10.2015 10:57

Автор: Maaret Pyhäjärvi.

Оригинал статьи: http://visible-quality.blogspot.ru/2015/09/natural-laziness-and-it-works-on-my.html

Перевод: Ольга Алифанова.

Когда Ллевелин Фалько учит детей программировать, его "первое правило программирования" дети запоминают накрепко. Оно гласит, что программисты очень ленивые. Например, когда они хотят обратиться к некоторой функции, они не пишут её название полностью. Достаточно ввести две-три буквы, и пусть инструменты выполнят всю остальную работу за вас там, где это возможно.

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

Но иногда программисты действительно проявляют такую способность лениться, что это не укладывается у меня в голове. Лень заставляет их думать, что их компьютер – это практически центр вселенной, и подсказывает им знаменитый универсальный ответ «У меня все работает».

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



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