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

1. Практическое занятие для
студентов КГТУ
Дефекты
программного обеспечения:
Немного теории и практические советы
по описанию дефектов программного обеспечения
от тех, кто «был там, делал это»,
тем, кому это предстоит постичь
и полюбить всей душой
Кирилл Загоруйко,
Инновационные Трейдинговые Системы

2. План занятия
I. Введение
II. Преодолеваем барьеры
III. Основные составляющие вменяемого описания
дефекта
IV. ЖБЖ
V. Суммируем
VI. Шпаргалка
VII.Вопросы / ответы

3. I. Введение
Нахождение дефектов и их правильное описание –
это основное, зачем мы нужны клиенту.
Удачные описания дефектов имеют большее значение для качества
конечного продукта, чем большинство остальных вещей, которые
мы делаем в процессе тестирования и предоставляем клиенту.
Удачные описания дефектов:
1. Сокращают количество отвергнутых разрабтчиками ПО проблем, о
которых мы им рассказываем;
2. Сокращают время на исправление дефектов;
3. Повышают достоверность результатов тестирования, о которых
мы рассказываем клиенту;
4. Улучшают взаимодействие тестировщиков и разработчиков.
(Based on “Writing Effective Defect Reports” by Kelly Whitmill, IBM Printing Systems Division)

4. II. Преодолеваем барьеры
Описания дефектов как часть проектных коммуникаций:
Удачные описания дефектов снимают эти барьеры и экономят время

5. III. Основные составляющие
вменяемого описания дефекта
К ним относятся:
1. Заголовок (Summary): коротко - в чем суть проблемы.
2. Краткое описание (Brief description): коротко - что, где, как, и как
должно быть.
3. Детальное описание (Detailed description): иногда совместимо с 2.
выше – о том же, но более развернуто; если дефект простой как 5
коп., этого пункта может и не быть.
4. Шаги по воспроизведению (Steps to reproduce): по пунктам и
коротко - делаю то-то там-то; вижу то-то там-то вместо того-то.
5. Приложения (Attachments): сюда прикрепляется все, что может и
должно помочь делу (если дефект простой как 5 коп., можно не
прикреплять ничего).
6. Примечания (Notes): сюда обычно пишут комментарии при
рассмотрении дефекта (разработчики, тестировщики, бизнес,
менеджеры и т.д.)

6. III. 1) Поле Summary
Дефект
(допустим просто для примера, что это дефект, а не
какая-то конфигурационная проблема, например)
состоит в том, что инструменты для какого-то рынка недоступны
в принципе, а должны быть доступны. При попытке выбрать
инструмент (любой) появляется сообщение:
"Cannot find instrument [название инструмента]"
Не так:
АБВ не работает (ABC doesn't work)
Это неконкретно и по сути неверно. Не надо народ в заблуждение вводить.
Так:
Инструменты АБВ в данный момент недоступны для использования (Сообщение
об ошибке: “Cannot find instrument…”)
Вопросы на засыпку:
1. Что из этого можно выкинуть, если по количеству знаков в поле Summary это
всё не влезает?
2. Зачем вообще нужно это поле?

7. III. 2) Поле Brief Description
Вот так, например:
Инструменты АБВ в данный момент недоступны для использования. При
попытке выбрать любой из них, появляется сообщение об ошибке: «Инструмент
[название инструмента] не находится»
(ABC instruments are currently unavailable. When the user tries to select any such
instrument, he/she gets the following warning message: "Cannot find instrument [название
инструмента]”)
Вопросы на засыпку:
1. Чем это по сути отличается от Summary?
2. Зачем вообще нужно это поле?

8. III. 3) Поле Detailed Description
Вот так, например:
Всё в мире, в конечном итоге, объяснимо. Вот и объясните.
Т.е. именно тут самое место, где можно (и очень часто нужно) ответить на
вопрос: почему этот дефект имеет место быть?
Или на такой вопрос: почему, с нашей точки зрения, этот дефект имеет место
быть?
Почувствуйте разницу.
Вопросы на засыпку:
1. Почему данный дефект имеет место быть? И дефект ли это?
2. Зачем вообще нужно это поле?

9. III. 4) Поле Steps to Reproduce
Вот так, например:
1) Откройте XYXY и выберите любой ABC инcтрумент (например, ZZ_TOP.ABC).
Ожидаемый результат: интрумент и рыночные данные для него доступны для
использования.
Фактический результат: пользователь получает следующее сообщение об
ошибке: «Инструмент ZZ_TOP.ABC не находится»
(Open XYXY and select any ABC instrument (e.g. ZZ_ТОР.ABC).
Expected result: the instrument and market data are available.
Actual result: the user gets the following warning message: “Cannot find instrument
ZZ_ТОР.ABC”)
Вопросы на засыпку:
1. Как следовало бы улучшить 1) выше из чисто формальных соображений?
2. Зачем вообще нужно это поле?

10. III. 5) Поле Attachments
Source: http://www.chillicothepubliclibrary.org/library-humor/how-to-annoy-your-friendly-public-librarian.html
Вопросы на засыпку:
1. Зачем вообще нужно это поле?
2. Что бы такое можно было бы «им туда»
приложить?
Варианты ответа:
– Свою фотографию;
– Новогоднюю открытку;
– Приглашение на конференцию EXTENT;
– Файл, дающий исчерпывающую
дополнительную информацию о
другом дефекте;
Дайте мне материал, с которым можно
работать! Черт побери!
– Что-то иное
То есть... пожалуйста и спасибо.
Give me some material to work with! Dammit!
Errr… Please and thank you.

11. III. 6) Поле Notes
При рассмотрении дефекта разработчики, тестировщики, бизнес, менеджеры и
т.д. обычно вносят в это поле свои комментарии.
Вопрос на засыпку:
Что значит «при рассмотрении дефекта»?
Ответ: см. следующий слайд.

12. IV. Жил был жук
– Круговорот жуков в
природе происходит
примерно так:
Source: http://dic.academic.ru/dic.nsf/enc_colier/4011/%D0%96%D0%A3%D0%9A%D0%98

13. V. Суммируем
Золотые правила при описании дефектов ПО:
1. Краткость – сестра таланта: Говорим и пишем понятно и покороче.
2. «Давайте не будем нервничать и неспеша во всем разберемся»: Это
правда дефект или неверно интерпретированное нами требование из документа, или «просто»
сами забыли что-то подключить, и т.д.?
3. Смех без причины – признак известно чего: Только факты. Не надо сарказма,
юмора и эмоций.
4. Берём быка за рога: Без ненужных предисловий – в чем именно проблема?
5. За деревьями леса не увидели: Что сделали, чтобы понять масштаб проблемы?
6. Спрятал концы в воду: Что необходимо сделать, чтобы вызвать проблему и
воспроизвести её (среда, шаги, условия)?
7. Гроша ломаного не стоит: Почему плохо от этого будет конечному пользователю? Как
это сказывается на тестировании? «Продайте» найденный вами дефект.
8. Лучше один раз увидеть, чем сто раз услышать: Что разработчику нужно,
чтобы понять причину проблемы (логи, картинки, видео-файл, доступ, и т.д.)
9. Доверяй, но проверяй: Документация есть, где написано, как должно работать?
Процитируйте её и дайте на неё ссылку.

14. VI. Шпаргалка
Ещё раз на всякий пожарный:
1. Четко формулируем, в чем именно проблема. А не просто: «оно у вас
там не работает».
2. Используем ключевые слова в описании.
3. Указываем название тестовой среды (test environment) и то, чему
описываемая нами проблема мешает.
4. Кто, что, когда, где, почему и как?
5. Почему конечному пользователю от этого плохо?
6. Использовать сокращения можно, но не переусердствуем в этом.
7. Грамматика в данном случае – второстепенна (в разумных пределах);
главное – смысл донести.
Вопрос на засыпку:
То, что написано в поле Заголовок, – это важно или нет?

15. VII. Вопросы и ответы
Спасибо!
Сайт Костромского сообщества тестировщиков:
http://clubqa.ru/site/lectures
• Презентации всех лекций
• Материалы к лабораторным работам
• Вопросы к зачету
• Полезные ссылки и документы