В любых начинаниях допускать ошибки не только нормально, но иногда даже полезно. При правильном отношении можно трансформировать ошибки в опыт и использовать его для развития своих навыков.
На наших курсах начинающие специалисты допускают одни и те же ошибки. Поэтому мы решили рассмотреть типичные ошибки начинающих тестировщиков и подготовить рекомендации, которые помогут упростить тестирование и избежать нежелательных последствий.
Ошибка №1. Неинформативные названия дефектов
Вы наверняка слышали о том, что нужно правильно писать заголовки дефектов (title). Как это сделать? Самый популярный совет – составьте заголовок так, чтобы он соответствовал формуле 3W - What? Where? When? Выглядит просто, не правда ли? Но тестировщики раз за разом неправильно пишут заголовки и усложняют себе работу. Давайте разберемся, как исправить это.
Главная функция заголовка дефекта – это описание проблемы. Title отвечает на вопрос: «Что не так?». Для этого нужно составить предложение, в котором будет вся исчерпывающая информация об ошибке. Чтобы написать такой заголовок нам и пригодится формула 3W:
- What? – ответ на этот вопрос описывает некорректное поведении программы. Другими словами – «симптом».
- Where? – здесь мы описываем в какой части системы найдена ошибка, то есть, ее «локация».
- When? – ответ на этот вопрос – описание действия/события, которое вызвало появление ошибки («триггера», от англ. «спусковой крючок»).
Рассмотрим на примере как не стоит и как нужно писать title.
«Incorrect Site Search». Неудачный заголовок. Единственный вопрос, на который он отвечает, это «Where?». Благодаря ему можно определить только то, что проблема связана с поиском на сайте. Но не понятно, в чем суть проблемы, что конкретно случилось и из-за чего возник баг. Все это осталось загадкой.
«The result of the action of the empty site search». Перед нами еще один title с ошибкой. Благодаря ему мы понимаем, с чем связан дефект и при каких условиях он возник. Но, что произошло, мы не знаем. К сожалению, просто «the result» не дает конкретики. Чтобы баг был найден и исправлен, в описание (description) нужно добавить: «After empty search request too, large image is shown in “category-view” div». Теперь мы понимаем, что на сайте есть картинка, которая нарушает UI, и где она расположена.
«Broken layout». Еще один неудачный заголовок. Здесь дан ответ на вопрос «What?», но где именно, при каких условиях и что служит причиной возникновения ошибки, мы не понимаем. Поэтому в description нужно будет добавить следующее: «On 150% zoom images at all pages are superimposed».
И последний пример неправильного заголовка – «Регистрация с невалидным адресом электронной почты». Мы понимаем, что ошибка связана с регистрацией, знаем причину (триггер) и что это связано с «невалидным эмэйлом». Но непонятно, при каких условиях появился баг. Здесь больше подходит заголовок «Возможна регистрация с невалидным адресом электронной почты» или «При регистрации не происходит валидация адреса электронной почты».
Советы для тех, кто хочет научиться правильно писать заголовки дефектов
1. Пишите сжато, но не переусердствуйте. Чаще всего будет достаточно 7–10 слов (без предлогов) для хорошего описания.
2. Убирайте бесполезные слова. Вот пример: «The opening of each new image when viewed on a new tab» – много «воды», но нет информации, которая помогла бы нам найти и исправить проблему.
3. Используйте description, если описание ошибки невозможно уместить в заголовок. Описание поможет вам максимально полно рассказать о проблеме, следовательно, разработчики быстрее смогут взяться за ее решение.
Ошибка №2. Отсутствие ожидаемых результатов
Когда тестировщик готовит баг-репорт, он понимает, как лучше исправить ошибку. Но разработчики не умеют читать мыслей. Поэтому возникают ситуации, когда ожидание не совпадает с реальностью. Существует риск, что разработчик сделал выводы о том, как ликвидировать баг и отправил готовый вариант на ревью. Здесь начинаются споры. Одна сторона утверждает, что все «исправлено в лучшем виде», а другая уверена, что нет. В итоге имеем потерянное время и нервы. Поэтому старайтесь четко прописывать ожидаемые результаты. Плюсом будет, если вы сможете подкрепить свое решение конкретным требованием.
Ошибка №3. Невнятные шаги воспроизведения
Простой совет, которому, к сожалению, следуют далеко не все – описывайте шаги поэтапно, нумеруйте их или используйте буллиты. Не нужно усложнять description и писать все одним большим абзацем. Разделите текст и расскажите о каждом аспекте отдельным предложением. Громоздкий текст затруднит воспроизведение дефекта, и вы можете запутать разработчика. Например, «When purchasing products, when you press a button to buy, pop-up window, which when pressed to continue shopping, throws on the orders page», можно описать гораздо проще: «"Continue shopping" button redirects to “Orders” page». Лишние детали первого предложения лучше перенести в description.
Ошибка №4. Скриншот вместо фактического результата
Помните, скриншот – это не замена текстового описания, а еще один источник информации. Иногда в баг-репорте можно увидеть это: «Фактический результат: "Запрос не прошел валидацию (см. скриншот)"». Но ситуаций, когда «фактический результат» нельзя описать словами практически нет. Если сделать это не получается, скорее всего вы не до конца понимаете баг.
Бывают случаи, когда скриншот нуждается в доработке, особенно если дефект найден в сложном интерфейсе. Чтобы разработчик не тратил время и не всматривался в скриншот по 15 минут, отметьте место, где находится дефект. Иногда можно убрать лишнюю часть скриншота и оставить только тот фрагмент, где хорошо видно ошибку.
Умение выражать свои мысли логично и понятно – особенность работы тестировщика. Найти дефект – это полдела, еще нужно правильно его описать.
Хотите узнать, как не допускать ошибок на всех этапах разработки ПО? Присоединяйтесь к нашим курсам!
#программирование #тестировщик #тестировщик по #баги