Как тестировщик, видел много дефектов, воспроизведение которых вызывало у меня затруднение. Хочется поделиться некоторыми практиками оформления дефектов – надеюсь, что это поможет немного улучшить чью-то жизнь.
Участвуя в разработке программного обеспечения, видел, что при написании кода программисты обычно задают стандарт оформления кода (codestyle) — следование определённым практикам, призванным улучшить жизнь программистов. Моя роль в разработке программного обеспечения заключалась в тестировании. В качестве одной из своих обязанностей, как тестировщик, я видел производство информации о качестве программного обеспечения. В качестве одной из классификаций, эту информацию можно было поделить на позитивную и негативную. Позитивная информация обычно заключалась в том, что ожидаемое поведение совпадало с действительным, и результаты тестирования можно было предоставить в виде данных в отчете о тестировании (фича 1- работает, сценарий 2 – работает, и т.д.). А вот негативная информация чаще всего производилась и оформлялась в виде дефектов. (конечно же, бывали и другие рабочие элементы, такие, как риски, запросы на изменение, и др.)
Встречал внутри проектов ведение базы знаний (не только дефектов), ориентированное на то, чтоб его «раз-раз и в продакшн». Прямо как у дорожных рабочих – сдать объект, а потом будь что будет.
Хочется, чтоб процессы по обеспечению качества велись с расчетом на то, что после передачи продукта в релиз его можно было сопровождать, сохраняя о команде разработки хорошие воспоминания.
Обычно дефект включает в себя:
1. Название
2. Критичность
3. Описание: Информация о стенде, шагах воспроизведения, фактическом и ожидаемом результате.
В зависимости от багтрекиговой системы могут быть и другие поля.
О том, из чего состоит дефект и и базовых правилах оформления, таких, как задавать наименование дефекта, отвечающее на вопросы «Что, где, когда?» на просторах интернета и в том числе на самом хабре встречал много статей. Здесь хочу поделиться опытом, полученным собственноручно.
На дефекты могут смотреть не только программисты и тестировщики, но и другие люди, которые заинтересованы в выпуске и продаже продукта. Например: директор центра разработки, руководитель отдела продаж, проектировщик пользовательских интерфейсов, участники команды, разрабатывающей другой продукт, интегрированный с тестируемым. И у них нет времени изучать подробности и анализировать влияние дефекта на область их ответственности. Они вовсе не обязаны быть знакомы со всеми техническими деталями вашего продукта.
Стоит ориентироваться на то, чтоб по названию дефекта можно было понять к какому функционалу он относится, пользуясь поиском по документации или по базе знаний.
Следует учитывать, что при внесении изменений в продукт, техническое описание может измениться, но дефект обычно продолжает проявляться.
И чтоб не отвлекали вас от текущих дел. Отвлечение от текущих дел порой требует достаточно много усилий. И выгоднее затратить небольшое количество своего времени на предотвращение отвлечений, чем потом постоянно отвлекаться.
Когда проект маленький и вы являетесь единственным тестировщиком (возможно, сочетая и другие обязанности, например, программиста), дефекты можно оформлять как заблагорассудится. Но когда вы работаете в команде – требуется иной подход. Когда живете один в доме — можно не мыть посуду, не укладывать вещи на свои места и т.д. А когда живете в большой семье – стоит относиться с уважением к тому, что другие члены семьи захотят видеть чистоту и порядок.
Касаемо стенда:
Стоит учитывать, что изредка дефекты исправляются в условиях жесткого дедлайна, когда множество людей с нетерпением жаждет их исправления или перепроверки, каждая минута идет на счет золота — и стоит сделать так, чтоб время не утекало впустую из-за небрежного оформления.
Перед тем, как заводить дефект, желательно его воспроизвести, локализовать условия его воспроизведения и отбросить лишнее. Если есть предположение о том, что какой-то фактор не влияет на воспроизведение, то лучше прямо это прописать и не рассчитывать на то, что эта информация будет передана телепатически.
Подобно тому, как инструкция к любому прибору должна иметь достаточное количество информации с учетом того, чтобы им можно было воспользоваться кому-то помимо производителя этих приборов.
Следует учитывать, что члены команды в проекте периодически меняются. По моим наблюдениям люди работают над одним и тем же проектом, не меняя его и не переключаясь на другие, порядка 2-х лет. Следует учитывать эффект грузовичка. Еще бывает так, что в компании несколько тестировщиков, и стоит предусмотреть, чтоб при уходе в отпуск другие тестировщики могли перепроверить этот дефект.
В идеале описание дефекта можно делать ориентированным на тех, кто работает с продуктом в первый раз и имеет в распоряжении лишь документацию.
Стоит учитывать, что даже после закрытия дефекта он может кому-то понадобиться. Ориентировочная цифра перспективы– 2 года.(ориентировочный расчет).
Например, когда рабочие меняют окна в подъезде, бывает так, что они экономят время и усилия на выносе мусора. Вроде мусор проходу не препятствует, жители спокойно ходят. И ресурсы сэкономлены. НО: через некоторое время наступает момент, когда мусор начинает мешать. А если случится пожар (релиз или еще какое мероприятие), то начинаются неприятности.
Например, какой-то старый дефект всплывает у пользователей (или будет новый, симптомы которого будут совпадать со старым), из-за этого у компании возникает ущерб. Начинают выяснять детали. И если дефект был оформлен как попало, то владельцы явно не будут в восторге от работы тестировщика.
Много раз замечал, что тестировщики при описании дефекта ориентируются на то, что он будет исправлен командой в тот же день. Примерно с 80% дефектов так и происходит –они исправляются на ходу и становятся мало кому нужны. Но вот порядка 20% дефектов продолжают существовать, причем порядка половины оставшихся — в течение достаточно большого промежутка времени. За это время состав команды, работающей над продуктом, претерпевает изменения. И когда новые члены команды начинают работать, то разбор и воспроизведение существующих дефектов начинает занимать очень много времени. На актуализацию каждого дефекта без адекватного описания, даже зная продукт на уровне документации, может уходить уйма времени.
Приведу грубый расчет. Помню, что за 8-часовой рабочий день мне удавалось актуализировать около 5 дефектов без описания. Если бы тестировщики при заведении дефектов тратили дополнительно по 5 минут на каждый заведенный дефект, делая описание подробнее, то на заведение 100 дефектов ушло бы дополнительно 500 минут = порядка 1 рабочего дня. Из этих 100 дефектов порядка 20 останутся незакрытыми в течение достаточно большого количества времени. На их актуализацию при расчете 5 дефектов/день может уйти порядка 4 рабочих дней.
Когда над проектом работает 1-2 программиста, обычно каждый полностью знает весь функционал. Но когда над проектом работает, скажем, 10 программистов – то каждый хорошо знает лишь тот функционал, в который он вносил изменения. И не стоит заставлять программистов изучать поведение незнакомого для них функционала. У них с лихвой достаточно задач по реализации нового функционала.
Часто бывает, что важные детали дефекта выявляются уже после его оформления. Их добавляют где-то в комментариях к дефекту. Выгодно актуализировать информацию о шагах воспроизведения в описании дефекта. Особенно если дефект имеет отношение к нескольким командам. Не стоит заставлять всех перечитывать комментарии и вникать в них.
Например:
1 -скриншот окна входа в систему.jpg
2 — скриншот ошибки в консоли.jpg
3 — архив с загружаемыми файлами.zip
Впоследствии, при обсуждении, вложения могут добавляться, их количество может вырастать до десятков. Удобно оперировать указанием на вложения, например: на скриншоте 15… использовать скрипт из вложения 7… см. сообщение в логе архива 25.
Если в одном дефекте собрана информация о нескольких схожих ошибках, например, в описании присутствует:
Ошибка выводится в браузерах:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
После работы над дефектом выявляется, что дефект исправлен лишь частично, то выгодно актуализировать в нем информацию, не удаляя старое, а используя перечеркнутый шрифт:
Ошибка после исправления 0.1.01.2018 выводится в браузерах:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
«Что для русского хорошо, то немцу-смерть». Стоит задать единые критерии определения критичности дефектов для тестировщиков в компании. Может оказаться так, что каждый будет считать, что его дефекты должны быть исправлены в первую очередь и не осознавать, что при этом на исправление более критичных дефектов не будут выделены ресурсы.
Своевременность заведения дефектов – немаловажное дело. Чем быстрее они будут заведены – тем скорее и лучше будут исправлены. И тем меньше вероятность пропустить что-то критичное в продакшн. После просмотра заведенного дефекта другими участниками команды может выявиться, что критичность выше, чем кажется на первый взгляд.
Как один из вариантов – если дефект обнаружен во время совещания или иных работ, отвлечься от которых не представляется возможным – можно делать заметку о нем на бумажке, и завести его в конце дня.
Вы наверняка не игнорируете мелкий мусор при уборке дома, даже если он не сильно мешает. (Есть, конечно, те, кто не поддерживает в доме чистоту и порядок, но не стоит на них ориентироваться). Подобно этому, не стоит игнорировать мелкие дефекты. Если внутренние договоренности не позволяют заносить их в багтрекер, то можно их фиксировать как-то иначе, например, на какой-нибудь странице или в письмах по почте.
Когда продукт маленький – мелкие дефекты не очень сильно заметны. Но когда продукт становится большим — сценарии более емкими – наличие мелких дефектов начинает донимать.
Можно привести такую аналогию: представим небольшой населенный пункт, например, деревню из двух улиц, на перекрестке которых одна маленькая ямка с грязью. Вроде на каждом (единственном) перекрестке яма, но передвигаться по деревне легко, просто объезжая всякий раз эту яму. И она мало кому мешает. Проходит время. Населенный пункт увеличивается до города-милионника. На каждом перекрестке по ямке с грязью. Если ездить по такому городу на работу через часть-города – то передвигаться, объезжая по одной ямке на каждом перекрестке, станет уже далеко не так комфортно. И возникнет большое желание перебраться в другой город или переизбрать администрацию города. Аналогично с программными продуктами – следует способствовать тому, чтоб у пользователей было желание в них работать, вместо желания удалять.
Другие члены команды тоже заводят дефекты. И они вовсе не обязаны быть знакомы с деятельностью тестировщика, у них может быть дополна своих дел. База дефектов – одно из владений тестировщика, подобно тому, как система хранения кода – владения программистов.
Если вы, будучи тестировщиком, видите, что дефект на ваш продукт заведен не совсем корректно, то стоит подкорректировать его. Подобно тому, как стоит поддерживать порядок у себя в доме, складывая вещи на свои места, если гости поставили что-то не туда.
P.S. Недавно начал работать в компании «Модульбанк» и планирую добавить эти практики к имеющимся.
Предисловие
Участвуя в разработке программного обеспечения, видел, что при написании кода программисты обычно задают стандарт оформления кода (codestyle) — следование определённым практикам, призванным улучшить жизнь программистов. Моя роль в разработке программного обеспечения заключалась в тестировании. В качестве одной из своих обязанностей, как тестировщик, я видел производство информации о качестве программного обеспечения. В качестве одной из классификаций, эту информацию можно было поделить на позитивную и негативную. Позитивная информация обычно заключалась в том, что ожидаемое поведение совпадало с действительным, и результаты тестирования можно было предоставить в виде данных в отчете о тестировании (фича 1- работает, сценарий 2 – работает, и т.д.). А вот негативная информация чаще всего производилась и оформлялась в виде дефектов. (конечно же, бывали и другие рабочие элементы, такие, как риски, запросы на изменение, и др.)
Встречал внутри проектов ведение базы знаний (не только дефектов), ориентированное на то, чтоб его «раз-раз и в продакшн». Прямо как у дорожных рабочих – сдать объект, а потом будь что будет.
Хочется, чтоб процессы по обеспечению качества велись с расчетом на то, что после передачи продукта в релиз его можно было сопровождать, сохраняя о команде разработки хорошие воспоминания.
Обычно дефект включает в себя:
1. Название
2. Критичность
3. Описание: Информация о стенде, шагах воспроизведения, фактическом и ожидаемом результате.
В зависимости от багтрекиговой системы могут быть и другие поля.
О том, из чего состоит дефект и и базовых правилах оформления, таких, как задавать наименование дефекта, отвечающее на вопросы «Что, где, когда?» на просторах интернета и в том числе на самом хабре встречал много статей. Здесь хочу поделиться опытом, полученным собственноручно.
1. Название должно отражать суть проявления дефекта на прикладном уровне
На дефекты могут смотреть не только программисты и тестировщики, но и другие люди, которые заинтересованы в выпуске и продаже продукта. Например: директор центра разработки, руководитель отдела продаж, проектировщик пользовательских интерфейсов, участники команды, разрабатывающей другой продукт, интегрированный с тестируемым. И у них нет времени изучать подробности и анализировать влияние дефекта на область их ответственности. Они вовсе не обязаны быть знакомы со всеми техническими деталями вашего продукта.
Стоит ориентироваться на то, чтоб по названию дефекта можно было понять к какому функционалу он относится, пользуясь поиском по документации или по базе знаний.
Следует учитывать, что при внесении изменений в продукт, техническое описание может измениться, но дефект обычно продолжает проявляться.
2. Стоит ориентироваться на то, чтоб при воспроизведении дефекта коллеги не тратили впустую время, занимаясь додумыванием вместо своей работы
И чтоб не отвлекали вас от текущих дел. Отвлечение от текущих дел порой требует достаточно много усилий. И выгоднее затратить небольшое количество своего времени на предотвращение отвлечений, чем потом постоянно отвлекаться.
Когда проект маленький и вы являетесь единственным тестировщиком (возможно, сочетая и другие обязанности, например, программиста), дефекты можно оформлять как заблагорассудится. Но когда вы работаете в команде – требуется иной подход. Когда живете один в доме — можно не мыть посуду, не укладывать вещи на свои места и т.д. А когда живете в большой семье – стоит относиться с уважением к тому, что другие члены семьи захотят видеть чистоту и порядок.
Касаемо стенда:
| Не стоит так оформлять | Лучше оформить | Примечание |
|---|---|---|
| На компьютере у моего дедушки в деревне | Машина: CPU: AMD A4-6300, RAM: 2 GB DDR3, HDD: 500GB, экран 1024x768, ОС: Windows 7 x64 | Стоит поточнее указывать где именно проявился дефект. |
| На стенде тестирования Хамелеонова и Бабочкиной | Машина1: Windows 10, GCr 20.1 Машина2: Windows 10, FF 30.1 | На стендах часто что-то меняется, и стоит это учитывать. |
Стоит учитывать, что изредка дефекты исправляются в условиях жесткого дедлайна, когда множество людей с нетерпением жаждет их исправления или перепроверки, каждая минута идет на счет золота — и стоит сделать так, чтоб время не утекало впустую из-за небрежного оформления.
3. Описание дефекта не должно содержать не относящейся к нему информации
| Не стоит так оформлять | Лучше оформить | Примечание |
|---|---|---|
| 1. Попить кофе 2. Открыть страницу логона 3. Принять ванну 4. Попытаться залогиниться под пользователем user1 |
1. Открыть страницу логона 2. Попытаться залогиниться под пользователем user1 |
Все, что не относится к дефекту, не должно в нем упоминаться. |
Перед тем, как заводить дефект, желательно его воспроизвести, локализовать условия его воспроизведения и отбросить лишнее. Если есть предположение о том, что какой-то фактор не влияет на воспроизведение, то лучше прямо это прописать и не рассчитывать на то, что эта информация будет передана телепатически.
4. Описание дефекта должно содержать достаточное для воспроизведения количество информации
Подобно тому, как инструкция к любому прибору должна иметь достаточное количество информации с учетом того, чтобы им можно было воспользоваться кому-то помимо производителя этих приборов.
Следует учитывать, что члены команды в проекте периодически меняются. По моим наблюдениям люди работают над одним и тем же проектом, не меняя его и не переключаясь на другие, порядка 2-х лет. Следует учитывать эффект грузовичка. Еще бывает так, что в компании несколько тестировщиков, и стоит предусмотреть, чтоб при уходе в отпуск другие тестировщики могли перепроверить этот дефект.
5. Базу дефектов в багтрекере стоит вести с расчетом на перспективу
В идеале описание дефекта можно делать ориентированным на тех, кто работает с продуктом в первый раз и имеет в распоряжении лишь документацию.
Стоит учитывать, что даже после закрытия дефекта он может кому-то понадобиться. Ориентировочная цифра перспективы– 2 года.(ориентировочный расчет).
Например, когда рабочие меняют окна в подъезде, бывает так, что они экономят время и усилия на выносе мусора. Вроде мусор проходу не препятствует, жители спокойно ходят. И ресурсы сэкономлены. НО: через некоторое время наступает момент, когда мусор начинает мешать. А если случится пожар (релиз или еще какое мероприятие), то начинаются неприятности.
Например, какой-то старый дефект всплывает у пользователей (или будет новый, симптомы которого будут совпадать со старым), из-за этого у компании возникает ущерб. Начинают выяснять детали. И если дефект был оформлен как попало, то владельцы явно не будут в восторге от работы тестировщика.
Много раз замечал, что тестировщики при описании дефекта ориентируются на то, что он будет исправлен командой в тот же день. Примерно с 80% дефектов так и происходит –они исправляются на ходу и становятся мало кому нужны. Но вот порядка 20% дефектов продолжают существовать, причем порядка половины оставшихся — в течение достаточно большого промежутка времени. За это время состав команды, работающей над продуктом, претерпевает изменения. И когда новые члены команды начинают работать, то разбор и воспроизведение существующих дефектов начинает занимать очень много времени. На актуализацию каждого дефекта без адекватного описания, даже зная продукт на уровне документации, может уходить уйма времени.
Приведу грубый расчет. Помню, что за 8-часовой рабочий день мне удавалось актуализировать около 5 дефектов без описания. Если бы тестировщики при заведении дефектов тратили дополнительно по 5 минут на каждый заведенный дефект, делая описание подробнее, то на заведение 100 дефектов ушло бы дополнительно 500 минут = порядка 1 рабочего дня. Из этих 100 дефектов порядка 20 останутся незакрытыми в течение достаточно большого количества времени. На их актуализацию при расчете 5 дефектов/день может уйти порядка 4 рабочих дней.
6. Описание дефектов должно учитывать, что программисты, которым предстоит исправлять дефект, могут не быть знакомы с используемым при воспроизведении функционалом
Когда над проектом работает 1-2 программиста, обычно каждый полностью знает весь функционал. Но когда над проектом работает, скажем, 10 программистов – то каждый хорошо знает лишь тот функционал, в который он вносил изменения. И не стоит заставлять программистов изучать поведение незнакомого для них функционала. У них с лихвой достаточно задач по реализации нового функционала.
7. По мере получения информации о дефекте стоит актуализировать шаги воспроизведения
Часто бывает, что важные детали дефекта выявляются уже после его оформления. Их добавляют где-то в комментариях к дефекту. Выгодно актуализировать информацию о шагах воспроизведения в описании дефекта. Особенно если дефект имеет отношение к нескольким командам. Не стоит заставлять всех перечитывать комментарии и вникать в них.
8. Если к дефекту требуется прикрепить много файлов, то перед этим удобно задавать им имена, начинающиеся с цифр
Например:
1 -скриншот окна входа в систему.jpg
2 — скриншот ошибки в консоли.jpg
3 — архив с загружаемыми файлами.zip
Впоследствии, при обсуждении, вложения могут добавляться, их количество может вырастать до десятков. Удобно оперировать указанием на вложения, например: на скриншоте 15… использовать скрипт из вложения 7… см. сообщение в логе архива 25.
9. Стоит отмечать в описании дефекта информацию о частичных исправлениях
Если в одном дефекте собрана информация о нескольких схожих ошибках, например, в описании присутствует:
Ошибка выводится в браузерах:
1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari
После работы над дефектом выявляется, что дефект исправлен лишь частично, то выгодно актуализировать в нем информацию, не удаляя старое, а используя перечеркнутый шрифт:
Ошибка после исправления 0.1.01.2018 выводится в браузерах:
1. Firefox
3. Internet Explorer
10. В компании стоит определиться со стандартом критичности дефектов
«Что для русского хорошо, то немцу-смерть». Стоит задать единые критерии определения критичности дефектов для тестировщиков в компании. Может оказаться так, что каждый будет считать, что его дефекты должны быть исправлены в первую очередь и не осознавать, что при этом на исправление более критичных дефектов не будут выделены ресурсы.
11. Дефекты следует заводить как можно быстрее
Своевременность заведения дефектов – немаловажное дело. Чем быстрее они будут заведены – тем скорее и лучше будут исправлены. И тем меньше вероятность пропустить что-то критичное в продакшн. После просмотра заведенного дефекта другими участниками команды может выявиться, что критичность выше, чем кажется на первый взгляд.
Как один из вариантов – если дефект обнаружен во время совещания или иных работ, отвлечься от которых не представляется возможным – можно делать заметку о нем на бумажке, и завести его в конце дня.
12. Не следует игнорировать мелкие дефекты, стоит оформлять их в багтрекере
Вы наверняка не игнорируете мелкий мусор при уборке дома, даже если он не сильно мешает. (Есть, конечно, те, кто не поддерживает в доме чистоту и порядок, но не стоит на них ориентироваться). Подобно этому, не стоит игнорировать мелкие дефекты. Если внутренние договоренности не позволяют заносить их в багтрекер, то можно их фиксировать как-то иначе, например, на какой-нибудь странице или в письмах по почте.
Когда продукт маленький – мелкие дефекты не очень сильно заметны. Но когда продукт становится большим — сценарии более емкими – наличие мелких дефектов начинает донимать.
Можно привести такую аналогию: представим небольшой населенный пункт, например, деревню из двух улиц, на перекрестке которых одна маленькая ямка с грязью. Вроде на каждом (единственном) перекрестке яма, но передвигаться по деревне легко, просто объезжая всякий раз эту яму. И она мало кому мешает. Проходит время. Населенный пункт увеличивается до города-милионника. На каждом перекрестке по ямке с грязью. Если ездить по такому городу на работу через часть-города – то передвигаться, объезжая по одной ямке на каждом перекрестке, станет уже далеко не так комфортно. И возникнет большое желание перебраться в другой город или переизбрать администрацию города. Аналогично с программными продуктами – следует способствовать тому, чтоб у пользователей было желание в них работать, вместо желания удалять.
13. Если дефект был заведен кем-то помимо тестировщика, то при необходимости стоит его подкорректировать
Другие члены команды тоже заводят дефекты. И они вовсе не обязаны быть знакомы с деятельностью тестировщика, у них может быть дополна своих дел. База дефектов – одно из владений тестировщика, подобно тому, как система хранения кода – владения программистов.
Если вы, будучи тестировщиком, видите, что дефект на ваш продукт заведен не совсем корректно, то стоит подкорректировать его. Подобно тому, как стоит поддерживать порядок у себя в доме, складывая вещи на свои места, если гости поставили что-то не туда.
P.S. Недавно начал работать в компании «Модульбанк» и планирую добавить эти практики к имеющимся.
