Поиск и исправление ошибок – неотъемлемая часть процесса разработки программного обеспечения. Однако каждый тестировщик неизбежно сталкивается с такой ситуацией, когда обнаруженные им дефекты отклоняются. В такие моменты может возникать чувство разочарования и недоумения о том, из-за чего это произошло и как избежать подобных ситуаций в будущем.
В этой статье мы расскажем о наиболее вероятных причинах, по которым выявленные тестировщиком ошибки могут быть отклонены, а также разберем реальные примеры из жизни.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
- Непонимание требований
- Реализация требований
- Отсутствие четких требований
- Изменение требований
- Понимание целей
- Тестовая среда
- Некорректные тестовые данные
- Дублирование ошибки
- Неправильное описание ошибки
- Невоспроизводимые ошибки
- Заключение
1. Непонимание требований:
Причиной отклонения дефекта может быть неправильное или неполное понимание требований к ПО. В таком случае, вы будете ожидать от приложения функционал, который, на самом деле, не соответствует требованиям.
Таким образом, вы обнаружите в приложении множество ошибок, которые, в конечном итоге, будут отклонены.
Пример из реальной жизни:
Представьте, что вы готовите какое-то блюдо, и в процессе приготовления вы не добавили соль. По завершении приготовления и дегустации вы обнаруживаете, что блюдо получилось безвкусным.
Вы считаете это ошибкой, но причина этой ошибки в том, что вы не знали, что соль должна была быть добавлена во время подачи, а не в процессе приготовления.
2. Реализация требований:
В ходе последнего обсуждения вам было известно, что конкретное требование должно быть реализовано XYZ-способом. Но в процессе написания кода разработчик обнаружил, что невозможно следовать пути XYZ, и поэтому он пошел по пути ABC, о чем вам не сообщил.
В конечном итоге вы сообщите об ошибке, когда обнаружите, что требование было реализовано не так, как обсуждалось.
Пример из реальной жизни:
Вы попросили портного сшить рубашку, и когда вам предложили примерить ее, вы отказались, заметив, что на ней нет пуговиц. Портной объяснил, что если бы он пришил пуговицы на переднюю часть рубашки, это повлияло бы на дизайн рубашки, и поэтому он пришил их внутрь передней кромки рубашки. Вы, безусловно, были ошеломлены таким объяснением.
3. Отсутствие четких требований:
Когда нет четких требований, каждый волен понимать их по-своему, что приводит к личным предположениям. Когда результат не соответствует нашим ожиданиям или предположениям, мы отмечаем это как ошибку.
Пример из реальной жизни:
Представьте, что учитель дал вам задание нарисовать велосипед. Но он не уточнил, какой именно велосипед он хочет видеть.
После проверки работ учитель обнаружил, что рисунки совершенно разные: один нарисовал велосипед с тремя колесами, другой – детский велосипед, третий – велосипед с коляской, и так далее. Из-за того, что учитель не уточнил, что именно он хотел увидеть, каждый ученик по-своему понял и выполнил задание.
4. Изменение требований:
Когда тестировщикам не сообщают об изменениях в требованиях, это приводит к тому, что они находят много ошибок, которые в конечном итоге будут отклонены.
Пример из реальной жизни:
Вы обязательно откажетесь от сэндвича, когда обнаружите, что вместо заказанного бананового хлеба вам принесли хлеб с медом. Если бы вы знали, что ваш партнер поменял тип хлеба при заказе, пока вы разговаривали по телефону, и не счел нужным сообщить вам об этом.
5. Понимание целей:
Если вы начинаете тестировать что-то, что не должно быть включено в текущую фазу тестирования или вообще не относится к продукту, то вы можете столкнуться с отклонением найденных вами ошибок.
Пример из реальной жизни:
Вы должны подмести комнату, и это единственная задача, которую вам поручено сделать. Однако если вы начнете жаловаться на беспорядок в других помещениях, вас определенно проигнорируют.
6. Тестовая среда:
Приложение или продукт – это комбинация множества аппаратных и программных требований. Когда не используется правильная тестовая среда или что-то отсутствует в тестовой среде, приложение может крашнуться, что приведет к сообщению о критической ошибке.
Иногда тестировщики забывают предоставить все необходимые детали о тестовой среде, когда они сообщают об ошибке в приложении. Это создает проблему для разработчиков, потому что у них нет всей информации, чтобы понять проблему и исправить ее. Это похоже на попытку решить головоломку без всех кусочков.
Пример из реальной жизни:
Вы попробовали вкусные кексы у друга, и вам они очень понравились. Позже вы попытались приготовить такие же кексы дома, используя тот же рецепт, но они не получились такими вкусными, как у вашего друга. Почему это произошло?
Все дело в том, что вы не следовали точному рецепту. Вы использовали несвежее масло вместо свежего и приготовили кексы на сковороде, а не в духовке, потому что ваша духовка была сломана.
7. Некорректные тестовые данные:
Проверяя функционал приложения, тестировщики использованы неправильные и некорректные данные. Эти данные не соответствовали установленным требованиям к ПО.
Пример из реальной жизни:
Вы знаете, что калькулятор предназначен для числовых операций, но все равно пытаетесь ввести непонятные символы вместо чисел и математических знаков. Калькулятор ведет себя неожиданно, и вы думаете, что это неправильно. Действительно ли это так?
8. Дублирование ошибки:
Кто-то уже сообщал о такой же ошибке, а вы не позаботились о том, чтобы проверить ее наличие в отчетах, прежде чем сообщить о ней. Опять отказ.
Пример из реальной жизни:
Сотрудник службы поддержки клиентов не обрадуется, когда получит несколько звонков с жалобами на один и тот же продукт от каждого члена семьи. Разве одного звонка недостаточно, подумает он.
9. Неправильное описание ошибки:
Если разработчик не сможет понять, что вы пытались донести до него в своем отчете об ошибке, он обязательно отклонит ваш дефект, потому что у него есть много других тасков. У него нет времени самому выяснять детали этой ошибки, которые вы должны были предоставить в своем отчете.
Пример из реальной жизни:
Чтобы завести машину, вы должны открыть ее, сесть внутрь и повернуть ключ в замке по часовой стрелке. Но машина не завелась, и вы расстроены. А разве в инструкции к машине не говорилось проверить уровень топлива? Точно. Ошибка в инструкции. Они предполагали, что вы догадаетесь, что это нужно сделать по умолчанию.
10. Невоспроизводимые ошибки:
Сообщая об ошибке, вы никогда не осознавали важность того, можно ли повторно воспроизвести ошибку. Просто убедившись, происходит ли ошибка всегда или появляется случайно, вы можете сэкономить часы работы и избежать еще одной отклоненной ошибки.
Пример из реальной жизни:
Вы жалуетесь на сильную простуду, но врач, осмотрев вас, не находит никаких симптомов простуды. Когда пациент говорит, что просто крепко чихал, это может быть недостаточной информацией для врача, чтобы точно определить причину вашей проблемы.
Чихание может быть вызвано разными причинами, необязательно только простудой. Если пациент не предоставит дополнительную информацию о своем состоянии, врачу будет сложно определить точный диагноз.
Заключение
Когда разработчики отклоняют отчет об ошибке, это может вызвать у нас негативные чувства. Это естественная реакция, так как мы думаем, что наш вклад не был оценен или принят во внимание.
Не сосредотачивайтесь на количестве ошибок. Акцентируйте свое внимание на серьезных и существенных ошибках с подробными описаниями. В конечном итоге важно, как вы помогли улучшить качество продукта, а не сколько ошибок вы нашли.
Поделитесь своим мнением на эту тему в комментариях ниже.
Перевод статьи «10 Reasons Why Your Bugs are Getting Rejected and What You Can Do for it as a Tester!».