как правильно...
TRANSCRIPT
Кирилл Загоруйко, Инновационные Трейдинговые Системы
Дефекты программного обеспечения:
Немного теории и практические советы по описанию дефектов программного обеспечения
от тех, кто «был там, делал это», тем, кому это предстоит постичь
и полюбить всей душой
Практическое занятие для студентов КГТУ
План занятия
I. Введение
II. Преодолеваем барьеры
III. Основные составляющие вменяемого описания дефекта
IV. ЖБЖ
V. Суммируем
VI. Шпаргалка
VII.Вопросы / ответы
I. Введение
Нахождение дефектов и их правильное описание – это основное, зачем мы нужны клиенту. Удачные описания дефектов имеют большее значение для качестваконечного продукта, чем большинство остальных вещей, которые мы делаем в процессе тестирования и предоставляем клиенту.
Удачные описания дефектов:
1. Сокращают количество отвергнутых разрабтчиками ПО проблем, о которых мы им рассказываем;
2. Сокращают время на исправление дефектов;3. Повышают достоверность результатов тестирования, о которых
мы рассказываем клиенту;4. Улучшают взаимодействие тестировщиков и разработчиков.
(Based on “Writing Effective Defect Reports” by Kelly Whitmill, IBM Printing Systems Division)
II. Преодолеваем барьеры
Описания дефектов как часть проектных коммуникаций:
Удачные описания дефектов снимают эти барьеры и экономят время
III. Основные составляющие вменяемого описания дефекта
К ним относятся:
1. Заголовок (Summary): коротко - в чем суть проблемы.2. Краткое описание (Brief description): коротко - что, где, как, и как
должно быть. 3. Детальное описание (Detailed description): иногда совместимо с 2.
выше – о том же, но более развернуто; если дефект простой как 5 коп., этого пункта может и не быть.
4. Шаги по воспроизведению (Steps to reproduce): по пунктам и коротко - делаю то-то там-то; вижу то-то там-то вместо того-то.
5. Приложения (Attachments): сюда прикрепляется все, что может и должно помочь делу (если дефект простой как 5 коп., можно не прикреплять ничего).
6. Примечания (Notes): сюда обычно пишут комментарии при рассмотрении дефекта (разработчики, тестировщики, бизнес, менеджеры и т.д.)
III. 1) Поле Summary
Дефект (допустим просто для примера, что это дефект, а не какая-то конфигурационная проблема, например) состоит в том, что инструменты для какого-то рынка недоступны в принципе, а должны быть доступны. При попытке выбрать инструмент (любой) появляется сообщение: "Cannot find instrument [название инструмента]"
Не так: АБВ не работает (ABC doesn't work)Это неконкретно и по сути неверно. Не надо народ в заблуждение вводить.
Так: Инструменты АБВ в данный момент недоступны для использования (Сообщение
об ошибке: “Cannot find instrument…”)
Вопросы на засыпку:
1. Что из этого можно выкинуть, если по количеству знаков в поле Summary это всё не влезает?
2. Зачем вообще нужно это поле?
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. Зачем вообще нужно это поле?
III. 3) Поле Detailed Description
Вот так, например:
Всё в мире, в конечном итоге, объяснимо. Вот и объясните.
Т.е. именно тут самое место, где можно (и очень часто нужно) ответить на вопрос: почему этот дефект имеет место быть?
Или на такой вопрос: почему, с нашей точки зрения, этот дефект имеет место быть?
Почувствуйте разницу.
Вопросы на засыпку:
1. Почему данный дефект имеет место быть? И дефект ли это?
2. Зачем вообще нужно это поле?
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. Зачем вообще нужно это поле?
III. 5) Поле Attachments
Source: http://www.chillicothepubliclibrary.org/library-humor/how-to-annoy-your-friendly-public-librarian.html
Дайте мне материал, с которым можно работать! Черт побери! То есть... пожалуйста и спасибо.
Give me some material to work with! Dammit!Errr… Please and thank you.
Вопросы на засыпку:
1. Зачем вообще нужно это поле?
2. Что бы такое можно было бы «им туда» приложить?
Варианты ответа:
– Свою фотографию;
– Новогоднюю открытку;
– Приглашение на конференцию EXTENT;
– Файл, дающий исчерпывающую дополнительную информацию о другом дефекте;
– Что-то иное
III. 6) Поле Notes
При рассмотрении дефекта разработчики, тестировщики, бизнес, менеджеры и т.д. обычно вносят в это поле свои комментарии.
Вопрос на засыпку:
Что значит «при рассмотрении дефекта»?
Ответ: см. следующий слайд.
IV. Жил был жук
– Круговорот жуков в природе происходит примерно так:
Source: http://dic.academic.ru/dic.nsf/enc_colier/4011/%D0%96%D0%A3%D0%9A%D0%98
V. Суммируем
Золотые правила при описании дефектов ПО:
1. Краткость – сестра таланта: Говорим и пишем понятно и покороче.
2. «Давайте не будем нервничать и неспеша во всем разберемся»: Это правда дефект или неверно интерпретированное нами требование из документа, или «просто» сами забыли что-то подключить, и т.д.?
3. Смех без причины – признак известно чего: Только факты. Не надо сарказма, юмора и эмоций.
4. Берём быка за рога: Без ненужных предисловий – в чем именно проблема?
5. За деревьями леса не увидели: Что сделали, чтобы понять масштаб проблемы? 6. Спрятал концы в воду: Что необходимо сделать, чтобы вызвать проблему и
воспроизвести её (среда, шаги, условия)?
7. Гроша ломаного не стоит: Почему плохо от этого будет конечному пользователю? Как это сказывается на тестировании? «Продайте» найденный вами дефект.
8. Лучше один раз увидеть, чем сто раз услышать: Что разработчику нужно, чтобы понять причину проблемы (логи, картинки, видео-файл, доступ, и т.д.)
9. Доверяй, но проверяй: Документация есть, где написано, как должно работать? Процитируйте её и дайте на неё ссылку.
VI. Шпаргалка
Ещё раз на всякий пожарный:
1. Четко формулируем, в чем именно проблема. А не просто: «оно у вас там не работает».
2. Используем ключевые слова в описании. 3. Указываем название тестовой среды (test environment) и то, чему
описываемая нами проблема мешает.4. Кто, что, когда, где, почему и как?5. Почему конечному пользователю от этого плохо?6. Использовать сокращения можно, но не переусердствуем в этом.7. Грамматика в данном случае – второстепенна (в разумных пределах);
главное – смысл донести.
Вопрос на засыпку:
То, что написано в поле Заголовок, – это важно или нет?
Спасибо!
VII. Вопросы и ответы
Сайт Костромского сообщества тестировщиков:
http://clubqa.ru/site/lectures
• Презентации всех лекций• Материалы к лабораторным работам• Вопросы к зачету• Полезные ссылки и документы