Управление дефектами

Как писать баг-репорты, которые помогут всей команде

2025-05-27T20:00:00Z

Автор: Михаил, специалист по тестированию в компании ITFB Group

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

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

Руководство по детализации багов: модернизация процесса

2025-03-31T20:00:00Z

Автор: Мэг МакКей (Meg MacKay)
Оригинал статьи
Перевод: Ольга Алифанова

Переход от «рассмотрения» к «уточнению» багов

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

Как новичок и тестировщик, я должна была поддержать команду в улучшении качества продукта. Но это было возможно только после решения вопроса, как нам работать в изменившихся командных условиях.

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

Что тестировщикам (и не только им) важно знать о базах данных. Шпаргалка по популярным ошибкам

2025-01-13T20:00:00Z

Нужно ли тестировщику разбираться в базах данных? Короткий ответ: да, как минимум на том уровне, чтобы можно было успешно выявлять и локализовывать ошибки в их работе. На практике же проблемы в базах данных зачастую фрустрируют даже опытных QA-инженеров. Что-то где-то пошло не так, но что именно и где?

Разумеется, БД — вовсе не черный ящик с магией внутри, а такой же набор взаимодействующих по определенным правилам компонентов, как и все остальное, с чем ежедневно приходится иметь дело QA-инженерам (и разработчикам, на самом деле, тоже, но они обычно больше погружены в контекст). Понимание того, что там под капотом, помогает эффективно проводить тест-дизайн, локализовывать баги, общаться с разработкой.

Под катом — наша шпаргалка по распространённым багам в работе баз данных. Разбили их по категориями, снабдили примерами и объяснили первопричины появления. Надеемся, будет полезно не только QA-специалистам, но и бэкенд-разработчикам начального уровня, а также всем, кто хочет углубить свои познания в области взаимодействия с БД.

Пишем хорошие баг репорты. Рекомендации

2024-12-10T20:00:00Z

Автор: Евгений Домнин

Представьте – вы разработчик, и тестировщик приносит баг, который найден в ходе регресса. Хочется поправить этот баг и вы просите оформить тикет. Уже представляете как возьмете его в работу, залинкуете к нему пулл реквесты и проставите эстимейты, чтобы не было вопросов у продакт менеджера.

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

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Спринт с багами, или как (не) создать себе проблем

2024-04-15T20:00:00Z

Автор: Султанов Илья, тимлид разработки, @sultanovis

В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.

Они чувствительны и сентиментальны. Даже исправлять жалко.

Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь делать разработку предсказуемой. Иногда даже получается.

Итак, к делу.

«Что? Где? Когда?» в названии багов

2024-01-24T20:00:00Z

Автор: Ольга Назина (Киселёва)

Хорошее название бага понятно любому:

менеджеру, плохо знающему техническую часть проекта;
джуниору, который только пришел в проект;
разработчику (зачем мне это чинить?)

Для этого оно должно отвечать на 3 главные вопроса: Что? Где? Когда?

И в этой статье я хочу разобрать каждый из них подробнее.

Bug policy. Что делать когда работа с дефектами — это хаос и ужас

2024-01-10T20:00:00Z

Автор: YouTravel.me

Сегодня хотим рассказать о том, как нам в YouTravel.me удалось снизить количество дефектов в 30 раз — с 400 до 13 — менее чем за полгода. Для наглядности — вот как выглядит это на графике:

Created - фиолетовая шкала
Resolved - салатовая шкала

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

Про приоритизацию багов

2023-06-21T20:00:00Z

Автор: Куликов Дмитрий

Как правило, все знают про severity и priority, но практически никто не говорит об urgency (срочности).

Значения приоритета и критичности

Например, если есть критичный баг S1 и его не нужно срочно исправлять, то у него может быть более низкий приоритет, к примеру - P2, а менее критичный баг S2, но который нужно исправить срочно — может иметь более высокий приоритет P1.

Уроки, извлеченные из поиска багов

2022-07-05T20:00:00Z

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

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

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

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

Новая функциональность без багов, на примере биллинга для мобильного оператора

2020-12-02T20:00:00Z

Привет, меня зовут Максим Плавченок, я работаю в компании Bercut, занимаюсь интеграционным тестированием. В сентябре мы с командой прошли важную веху: получили ноль ошибок по результатам интеграционного тестирования для релиза новой версии биллинга для мобильного оператора. Мы шли к этому два года; хочу сегодня рассказать, за счёт чего нам удалось добиться цели.

Создание хороших баг-репортов

2020-11-30T20:00:00Z

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Баги, баги, баги! Нельзя обсуждать разработку ПО, не затрагивая тему багов. Поначалу термин "баг" может казаться странным жаргоном для "дефекта". По коду и машинам что, бегают жучки и паучки? Как правило, нет, но иногда таки да! В 1947 году Грейс Хоппер нашла мертвого мотылька, застрявшего в реле гарвардского компьютера Mark II, и в отчете о "жучке" шутила, что нашла настоящего жука за компьютерным дефектом. Несмотря на то, что изобретатели вроде Томаса Эдисона использовали термин "баг" для описания технологических глюков задолго до 1947 года, именно этот мотылек зафиксировал терминологию для компьютеров и ПО.

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

Ожидаемый результат

2020-11-26T20:00:00Z

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

Клара Янова – ответственная тестировщица, которая изучает, практикует и пропагандирует Rapid Software Testing. Недавно она написала на LinkedIn:

"Я могу ОЖИДАТЬ, что что-то произойдет. Но это необязательно значит, что Я ХОЧУ, чтобы это произошло. Я даже могу хотеть, чтобы это произошло, но то, что оно не происходит, вовсе не означает автоматом, что тут есть какая-то проблема.

Смысл заметки: пожалуйста, давайте покончим с "ожидаемыми результатами" в баг-репортах!"

Чему меня научил один маленький баг

2020-11-15T20:00:00Z

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

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

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

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

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

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

Разбираемся с баг-репортом

2020-09-06T20:00:00Z

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

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

Измерение Production инцидентов, как цена качества

2020-03-09T21:00:00Z

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

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

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

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

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

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

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

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

2019-10-03T20:00:00Z

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

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

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

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

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

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

2019-08-21T20:00:00Z

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

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

О записи багов, или Найди кота

2019-08-20T20:00:00Z

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

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

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

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

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

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

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

Багов, еще не описанных..сколько..

2018-10-03T08:36:50Z

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

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

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

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

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

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

Знакомимся с российской системой управления тестированием Devprom ALM

2018-08-20T07:19:40Z

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

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

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

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

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

2018-01-19T08:45:56Z

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

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

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

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

Задание

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

2. Оформить найденные баги в гуглодоке

Функционал тестируем конкретный. Так проще (не надо тестировать все) и интереснее — кто больше багов найдет? =) Тестируем:

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

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

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

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

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

2016-10-25T07:56:02Z

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

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

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

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

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

Результаты опроса про популярность баг-трекеров

2016-08-30T14:34:12Z

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

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

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

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

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

Заступничество, Наблюдения, Будущее

2016-03-14T10:11:06Z

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

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

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

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

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

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

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

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

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

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

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

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

Природная лень, или "У меня все работает"

2015-10-20T06:57:01Z

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

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

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

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

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

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