Как найти ошибки в программе тестировщик
Сегодня поговорим о тестировании у нас в Alente, а конкретно — о том, как трансформировалась роль тестировщика в проектах.
Пару лет назад мы работали как большинство студий: привлекали тестировщика только на этапе тестирования. Но сейчас он принимает деятельное участие в работе уже на этапе сбора требований к сайту. Почему так получилось и как это помогает улучшить продукт? Читайте — и вы всё узнаете.
Проекты приходили на тестировку перед запуском. И мы получали набор стандартных проблем данного этапа: непроработанные изначальные требования приводили к переделкам на этапе тестирования. При этом отметим, что непроработанные требования — это не только недостаточное описание работы функций, но и возникающие противоречия в их трактовке. Мы все люди, и бывают ситуации, когда команда разработки, начиная от проект-менеджера и дальше по цепочке верстальщик — программист — тестировщик, трактует требования по-своему. А в итоге получается проект-«франкенштейн».
Причиной чаще всего были ошибки коммуникации, потому что не все требования фиксировались текстом или выражались в виде прототипов и макетов. Что-то оставалось в переписках, в обсуждениях и даже просто в головах, терялось в потоке задач и выпадало из процесса.
Другой проблемой становились изменения требований по ходу разработки. Отсутствие чёткого механизма фиксации изменений приводило к ситуациям, когда что-то делалось по договорённости, а потом не было никакой возможности выяснить, кто, с кем и о чём конкретно договаривался. В случае кадровых ротаций в команде это приводило к очень серьёзным проблемам.
Получалось, что часть требований выяснялась только на этапе тестирования, когда тестировщик сталкивался с противоречиями и начинал задавать вопросы. То есть этап тестирования готового продукта, по сути, становился этапом выяснения исходных требований и попыткой доработать проект с их учётом.
К каким последствиям это приводило?
Во-первых, теряли в качестве проекты, которые не получали всех задуманных функций и страдали от багов. Во-вторых, даже при успешном выяснении всех требований не всегда была возможность их реализовать постфактум: клиент просто не согласовывал дополнительную смету. И, в общем-то, был прав: он платил деньги за готовый и работающий продукт и был совершенно не обязан финансировать внутренние трудности разработчика.
Отсюда вытекает «в-третьих»: эта проблема сказывалась на отношениях с клиентами даже спустя годы.
- Неверная трактовка требований в самом начале.
- Возникновение новых требований по ходу проекта.
- Всплывающие проблемы на этапе тестирования, отладки или запуска. Чинить такие проблемы может быть дорого, а иногда и невозможно. Это приводит к срывам сроков, бюджетов, и потере лояльности клиента.
- Потеря рабочего времени разработчиков и тестировщиков.
- Попытки вписать пропущенные требования в проект, часто приводящие к проблемам в его работе.
- Излишняя нагрузка на тестировщиков и, как следствие, снижение качества их работы.
Чтобы избежать вышеупомянутых проблем, мы стали подключать тестировщика и всю команду разработки с самого начала.
Сейчас команда разработки подключается начиная с этапа сбора требований. Каждый член проектной команды отвечает за то, чтобы требования не были противоречивыми, чтобы уточнения поступали вовремя и весь процесс был под контролем. Теперь клиент видит прототипы, макеты и ТЗ только после внутреннего согласования с командой разработки.
Раннее включение важно и в том смысле, что позволяет лучше погрузиться в среду, понять бизнес-процессы клиента и причины принятия различных решений (в дизайне, прототипах, проектировании, ТЗ). Оно гарантирует возможность получения наилучших проектных решений.
Тестировщик подключается на каждом этапе для того, чтобы:
- дать свою оценку, протестировать требования;
- зафиксировать важные моменты по проекту (чек-листы, тест-кейсы);
- выявить особые сценарии использования или user-stories, затрагивающие доступность, тестируемость, граничные случаи.
Здесь тестировщик определяет приоритеты и сценарии. важные для бизнеса. Он расставляет приоритеты на рисках (вещах, важных для клиента и его бизнеса), определяет, какие из заложенных функций своей некорректной работой могут повысить риски и в какой мере. Например: возможность оплаты заказа, оформление заказа, заявки, использование функций «личного кабинета».
Тестировщик составляет дневник проекта — его структуру с разделением на разделы и отдельные блоки с перечислением основных функций. По мере тестирования он заполняет этот документ информацией.
Здесь тестировщик определяет структуру проекта по блокам, перечень функций, пишет тест-кейсы под проект. Часть покрывается стандартными проверками, часть — стандартами компании. А под оставшуюся часть пишутся кейсы, которые в дальнейшем используются для тестирования и регресса.
Стандартные проверки представляют собой чек-листы под типовые ситуации, которые заготовлены заранее и повторяются от проекта к проекту. Главное их назначение — контроль над тестированием стандартных функций. Они могут быть представлены как в виде чек-листов, так и в виде таблиц принятия решений.
Стандарты зафиксированы для разработчиков в их типовых задачах и покрывают такие факторы, как:
- выполнение требований, необходимых для успешного продвижения сайта в поисковых системах;
- выполнение требований для сайтов определённых тематик, например медицинских учреждений или автосайтов;
- выполнение требований к доступности (более подробно о доступности можно прочитать здесь).
Также на этапе ТЗ тестировщику необходимо выяснить вопросы о работе функций, которые потенциально могут возникнуть на этапе тестирования. Свою оценку по данному вопросу дают и разработчики.
Кроме того, важно протестировать требования:
- Требования должны трактоваться всеми одинаково.
- Автор требований должен оперативно отвечать на вопросы и фиксировать изменения.
- Требования нужно поддерживать в актуальном состоянии на момент работы над продуктом.
- Все коммуникации и дополнительные договорённости по требованиям должны фиксироваться письменно.
- Согласование требований должно проходить со всей командой разработки.
- Не должно быть отсылок к неопределённой информации или незафиксированных требований.
На этом этапе происходит непосредственно тестирование проекта. Тестировщик выполняет свою задачу на всех требуемых конфигурациях, заложенных на этапе ТЗ, с помощью чек-листов, заготовленных кейсов, чек-листов по стандартам компании, таблиц принятия решений, дневника проекта.
Цель данного этапа — анализ внутренних процессов с целью их улучшения. Ретроспектива призвана совершенствовать взаимодействие внутри команды разработки, постановку задач, планирование релизов. Она помогает выявить узкие места в процессах и подумать, что можно улучшить, изменить или внедрить.
В компании существует два вида ретроспективы: одна из них — внутри рабочей группы, другая — только для тестировщика. На данном этапе тестировщик работает над выявлением пропущенных дефектов, причин их пропуска и возможностей улучшения процесса. Например: если дефект был пропущен из-за недостатка требований, то следует внести уточнение в конструктор технических заданий — какие требования необходимо прописать в следующий раз.
Ретроспектива помогает и самому специалисту — он может лучше понять свои качества тестировщика: что было легко, а что далось сложно и почему так вышло. Ему становится понятно, в каком направлении следует развиваться и улучшать навыки.
Менеджеру проектов:
- Увеличивается скорость разработки. Снимаются одинаковые вопросы и снижается количество доработок.
- Менеджер раньше получает информацию, важную для принятия решений.
- Растёт качество конечного продукта.
- Появляется дополнительная информация о рисках, возникающих в процессе разработки.
Разработчику:
- Качественные и понятные требования с однозначной трактовкой.
- Отсутствие изменений в требованиях, возникающих в процессе работы или после завершения разработки.
Тестировщику:
- Возможность влиять на проект в самом начале.
- Меньше багов на этапе тестирования продукта.
- Понятный конечный результат и алгоритм проверки. Лёгкое погружение в процесс, стандартизированный план тестирования и тестовая документация.
- Контроль над любыми изменениями в требованиях.
Результат проекта зависит не только от этапа тестирования, но и от всего процесса разработки. Качество закладывается в самом начале — чем лучше отрегулированы внутренние процессы в целом, тем легче тестировать готовый продукт и тем меньше в нём проблем. Мало того, большинства сложностей с поддержкой, внесением изменений и общением с клиентом можно избежать, правильно выстроив работу с самого начала.
Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
Что такое поиск ошибок?
Я тестирую продукт. Моя задача — завести как можно больше багов. Оно и логично! Заводить баги тестировщику всегда приятно, это видимый измеримый результат работы, И чем их больше, тем больше меня ценят как тестировщика.
Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.
Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?
Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.
Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати нет теста «проверить сложение» и другие базовые операции.
Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.
Что такое тестирование?
Я тестирую продукт. Моя задача — пропустить как можно меньше приоритетных для пользователя багов. Чем меньше багов пропущено, чем меньше недовольства клиентом выражено — тем выше я оцениваю эффективность своей работы.
Какие области я буду тестировать в этом случае? Естественно, я начну с самых приоритетных для пользователя. Даже если они стабильно и успешно работают, я всё равно буду проверять основные пользовательские сценарии, чтобы ни в коем случае не пропустить серьёзных проблем.
Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно». На заведение дефекта в итоге может уйти немало времени, и с точки зрения баг/время результат эффективности тестирования будет не очень высок, зато у меня появятся более глубокие знания о продукте, архитектуре, пользователях.
Какие тесты я буду проводить в первую очередь? Конечно, самые-самые стандартные. Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает. И только после этого я перейду к менее стандартным сценариям.
Результаты тестирования и поиска ошибок
В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.
- из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
- команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
- в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
- количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает
Как перейти от поиска ошибок к тестированию?
Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:
1. Анализ продукта и документирование тестов
Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.
- Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
- Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
- Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.
Залог успеха в ведении тестов — создание карты, по которой вы будете идти. Цель — покрыть весь продукт. Только пожалуйста, не надо отмазок об ужасной ресурсоёмкости — я покрывала проекты с миллионами строк кода меньше чем за месяц-полтора. И в процессе написания таких тестов поднимались неожиданные вопросы и всплывали критичные ошибки, которые несмотря на наличие горе-тестеров болтались в продукте годами.
2. Оценка тестирования
Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска. Покрытие функционала и кода тестами. Уровень удовлетворения пользователей, через анкеты и сбор обратной связи. Качество заведения ошибок, опрашивая разработчиков.
ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.
Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.
В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?
Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!
4. Понимание пользователей и их бизнес-процессов
- Как этот продукт используется?
- Зачем он вообще нужен, какие проблемы решает?
- Какая средняя квалификация у пользователей?
- В каких условиях работают пользователи? На каких окружениях, оборудовании?
5. Техническая квалификация и понимание архитектуры
Такие баги не просто бесполезны, они позорят тестировщиков и дискредетируют отрасль в целом! Чтобы заводить дефекты правильно, необходимо понимать платформу, на которой написан тестируемый продукт. Если мы говорим про веб-тестирование, то можно хотя бы указать в баг-репорте возвращаемый сервером код ошибки, посмотреть подробности файрбагом, предоставить подробную информацию и сэкономить разработке массу времени!
Выводы
Очень многие разработчики не любят тестировщиков. И правильно делают!
Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!
Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.
Что пишут в блогах
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Традиционно перед Новым годом принято подводить итоги прошедшего года и строить планы на следующий.
Чего вы хотите добиться в будущем году? Что хотели бы улучшить? Каких прошлых ошибок избежать? Какие цели вы ставите перед собой? Конечно, не забывайте о том, что цели должны быть SMART, то есть достижимые и измеримые. Пусть это будет "прочитать одну книгу на английском/немецком/испанском" или "занести в баг-трекер не меньше 300 баг-репортов". А может быть что-то более грандиозное?
Есть такая история: в штате Индиана (США) есть главное здание библиотеки университета этого самого штата. Каждый год библиотека уходит в землю примерно на дюйм. При проектировании библиотеки архитектор уделил внимание многим вещам и здание получилось действительно красивым. Но при этом он не учёл главного: веса книг.
Знакомо, не правда ли? Сколько раз мы составляли планы, включая в них множество вроде бы нужных дел, а потом оказывалось, что мы забыли о гораздо более важных вещах?
Пускай же в новом году всё действительно важное не потеряется для вас в гуще мелочей и второстепенных событий. Желаем вам ставить перед собой только самые правильные цели и достигать их, невзирая на мелкие препятствия и незначащие обстоятельства.
Пусть сбываются все ваши честолюбивые мечты и планы как на профессиональной ниве, так и в личной жизни!
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
На этой неделе я расскажу о трех вещах, которые нечасто ассоциируются с тестированием: это логирование, мониторинг и предупреждения. Возможно, вы пользуетесь логами, тестируя, однако мониторинг и предупреждения – проблемная область в IT и DevOps. Но ведь приложение без багов не стоит ничего, если ваши пользователи не могут до него добраться, потому что сервер упал! Поэтому очень важно разбираться в логировании, мониторинге и предупреждениях, чтобы мы, как тестировщики, могли участвовать в обеспечении качества наших приложений.
Представляем книгу Святослава Куликова «Тестирование программного обеспечения. Базовый курс.».
В основу книги положен десятилетний опыт проведения тренингов для тестировщиков, позволивший обобщить типичные для многих начинающих специалистов вопросы, проблемы и сложности. Эта книга будет полезна как тем, кто только начинает заниматься тестированием программного обеспечения, так и опытным специалистам — для систематизации уже имеющихся знаний и организации обучения в своей команде. Книга распространяется под лицензией Creative Commons.
В трансляцию блогов регулярно добавляются новые блоги. Их количество уже давно перевалило за отметку 100. Ну а мы продолжаем знакомить Вас с новыми блогами:
Немного о нас:
Performance Lab - это компания, которая вот уже 8 лет занимается тестированием программного обеспечения. За годы работы мы накопили огромный опыт теперь мы решили им поделиться!
Наши основные авторы статей:
Дмитрий Химион - эксперт в области автоматизации тестирования, докладчик на более чем 10 конференциях по тестированию и разработки ПО, Всегда придерживается понятия "Технология - "светлая сторона силы", с их помощью можно решить любую задачу"
Мешков Александр - эксперт в области функционального тестирования и тест-менеджмента. Участвовал более чем 15 различных проектах по тестированию ПО. Основные темы статей - тест-менеджмент и оптимизация процесса тестирования.
Макаров Александр - гуру нагрузочного тестирования. Может нагрузить любую систему, даже когда другие пассуют. В свободное время работает над созданием собственного инструмента нагрузочного тестирования приложений.
Осипов Антон - основной Agile идеолог к компании. Считает, что CI и DevOps - самые перспективные направления в ИТ. Всегда убежден, что качество кода играет ключевую роль в процессе обеспечения качества ПО.
А также другие ребята, активно принимающие участие в жизни нашей компании.
Вы успешно прошли собеседование и справились с тестовым заданием, работодатель готов предложить вашу первую работу начинающим тестировщиком. И вот, вы, воодушевленные своим успехом, рветесь в бой. Ведь перед этим вы прочли пару книг (а может и больше) по тестированию ПО, успешно окончили онлайн-курс, и даже почитали пару статей в интернете: “как же быть лучшим тестировщиком”. А теперь, уже три месяца, как внемлете рекомендациям и советам более опытных коллег, задерживаетесь, чтобы разобраться в сложном функционале, заводите миллионы багов и даже утомляете себя переработками.
Наконец, испытательный срок подходит к концу, и вы счастливо потираете ручки, уверенные в своем успехе. Но… Неожиданно руководитель мягко говорит, что продолжать сотрудничество он не намерен, а найдет другого тестировщика. Погодите-ка, но почему? Вы же вроде и книги читали по тестированию, и курсы проходили, да и советам коллег следовали. Я уж молчу про заведенные баги, коих миллионы, да и переработки никто не отменял. А тут такое…
Ну что же, давайте вместе разбираться: почему, несмотря на знания и старания, могут уволить начинающих тестировщиков, и как не оказаться в их числе?
Банальная невнимательность
Оказавшись в новом коллективе, каждый хочет понравиться, произвести хорошее впечатление, зарекомендовать себя. Именно по этой причине многие начинающие тестировщики задерживаются, перерабатывают и, порой, делают совершенно не ту работу, которую от них ожидают. А все потому, что были невнимательными.
Подобного рода ошибки для меня, как менеджера команд, являются очень показательными в профессиональном плане, ведь одно из самых важных качеств тестировщика – это его внимательность. А иначе, как я могу быть уверена в качестве его работы, если он и с заданием внимательно ознакомиться не в силах?
Для наглядности, приведу пару примеров из своего опыта.
Одна из моих команд занимается тестированием сайта, который предоставляет пользователям варианты разных кредитов. Сам сайт состоит всего из двух экранов: краткой формы и расширенной, где, задав определенные параметры и значения, можно получить информацию о кредите, срок, процентную ставку, сумму и другое.
Так вот, я дала своему тестировщику задание: построить таблицу решений по экрану с краткой формой. А тестировщик сделал по расширенной, потратил невообразимое количество драгоценного времени (на минуточку, в краткой форме – три поля и 9 значений, при этом, в расширенной – более 30-ти значений), и в итоге, сделал совершенно не то, что требовалось.
Другая же моя сотрудница проходила юзабилити чек-лист, одним из пунктов которого была проверка быстродействия поискового механизма на сайте.
Пункт чек-листа звучит примерно: “Как быстро работает поиск”. И ожидается довольно простой ответ: “работает быстро, отклик укладывается в 3 секунды” (что, по общепринятым нормам – хорошо), но, почему-то такая простота смутила мою сотрудницу и она привела мне определение быстродействия, способы его замера, а вот на вопрос: “быстро ли работает поиск?” – так и не ответила. Как вы думаете, обрадовалась ли я такой “самодеятельности”? И вы будете правы, ответив нет. Время снова потрачено, а результат нулевой.
Поэтому я всегда говорю, дорогие тестировщики, будьте, пожалуйста, внимательнее, ведь в постановке задачи (вопроса) очень часто содержится и часть ответа. Не изобретайте велосипеда там, где этого от вас не требуют!
“А как же улучшить свою внимательность?” – спросите вы, и это справедливо. Ниже я поделюсь несколькими советами, которые опробовала на себе и на тестировщиках из своей команды.
- Беритесь только за одно дело. Не хватайте сразу и побольше. Многозадачность – это круто, но очень трудозатратно. Наш бедный мозг не успевает обрабатывать несколько дел одновременно и какое-то точно пустит на самотек.
Получив задачу на тестирование, занимайтесь только ей, а не говорите по телефону с подругой и не серфите в соцсетях. - Сконцентрируйтесь! Внимательно (несколько раз!) прочитайте постановку задачи, в 90% случаях в ней уже содержится алгоритм выполнения или какая-то подсказка.
- Делайте необходимое, избегая лишнего. Тут все банально просто: попросили вас декомпозировать функционал – декомпозируйте, попросили предоставить список дефектов на версии – предоставьте, а не выдумывайте от себя.
- Записывайте задачи. Память может подвести, поэтому ведите список краткосрочных (на день) и среднесрочных (неделя, спринт) дел, и отмечайте их выполнение.
Принятие всего на веру
Пожалуй, одно из тех качеств, которых не должно быть у тестировщика, – это принятие всего на веру.
“Ну так в ТЗ было написано…” Да мало ли, что в ТЗ написано! На заборе тоже много чего написано, но это же не значит, что вы всему должны верить.
Включайте, пожалуйста, свое критическое мышление, размышляйте! А такой ли результат выполнения вы ожидали? А какой будет правильным? А может быть стоит сходить к аналитику или разработчику за уточнением? Ведь в ТЗ тоже могут быть ошибки, именно поэтому его также тестируют и находят баги.
Почему важно тестировать техническое задание? Потому что это первое, куда заглянет тестировщик при возникновении вопроса. И если вы понимаете, что ТЗ нелогично, противоречиво, содержит неточности – смело идите к аналитикам по продукту и выясняйте, как должно быть на самом деле, а не принимайте на веру все написанное.
Еще одно важное правило: не верьте разработчикам, которые просят: “Не заводи ошибку, я сейчас допью кофе и за 2 минуты все сделаю”. Как правило, этот дефект так и останется не исправленным, а вы будете виноваты, что не завели баг и доказать ничего не сможете.
Личный опыт – красноречивее любых слов. На одном из моих проектов команда проходила еженедельные регрессы по сложному функционалу. Регресс был довольно длинным и занимал много времени. Один из сотрудников прошел его невероятно быстро, чем вызвал у меня очень много вопросов. Я была уверена, что просто физически невозможно пройти регресс с такой скоростью. Тестировщик же уверял, что прошел все кейсы до единого. В итоге, после его проверок стали вылазить баги на тех шагах, где он поставил статусы “пройдено”.
Оказалось, мой сотрудник перед прохождением регресса общался с разработчиком, который уверял, что все шаги (условно, с 5 по 22) были “пофикшены в этой версии и можно смело ставить статусы “пройдено”.
Довольный тестировщик поверил разработчику на слово, а может просто поленился перепроверить. Своим поступком он вызвал во мне шквал эмоций и вовсе не приятных. Отличный кандидат на увольнение, не правда ли?
Итак, чтобы не прослыть самым доверчивым и наивным тестировщиком в команде, достаточно запомнить несколько простых правил:
- Документируйте все, даже минорные баги (если, конечно, у вас на уровне SLA не прописано обратное).
- Заставляйте свой мозг думать. Когда вы обнаружили неточность между технической документацией и реализацией функционала, смело идите к аналитику или разработчику за уточнениями.
- Не принимайте в работу незадокументированные задачи. Запомните, незадокументированной задачи в нашем информационном мире просто не существует. Просите, чтобы на вас ставили или переводили задачи в таск–трекере, ну или, на самый крайний случай, – отправляли на электронную почту.
- Всегда перепроверяйте задачи, а не слепо доверяйте словам разработчиков, потому что именно мы, тестировщики, предоставляем информацию о качестве тестируемого продукта. И отвечать за проделанную работу тоже нам. Помните об этом, и не подводите себя и руководителя команды.
Ошибки, связанные с баг-трекингом
Вы можете заводить миллионы багов, быть чемпионом в вашей команде, но если баги заведены плохо (неточно, некорректно), то нет никакого смысла в их количестве!
Самая свежая и нехорошая ошибка, за которую не то, что уволить, а сразу голову оторвать хочется – это 4 баг-репорта с одинаковым заголовком: “Ошибка в форме при ее открытии”.
Именно для того, чтобы заводить ошибки понятно и беречь к тому же нервные клетки тим-лидов и разработчиков, придумали прекрасную мнемонику: “Что? Где? Когда?”
- Что?
Что происходит, или же не происходит, согласно вашему представлению о нормальной работе тестируемой системы. - Где?
В каком месте интерфейса или архитектуры системы найдена ошибка. - Когда?
В какой момент работы системы, по наступлению какого события или при каких условиях, проблема проявляется.
Если ваш баг-репорт не отвечает на эти вопросы – то это плохой баг-репорт.
Еще одной, довольно частой (на удивление) ошибкой в баг-трекинге является указание в summary ожидаемого и фактического результатов для каждого шага.
По правилам, в баг-репорт записывается один фактический и один ожидаемый результат после всех шагов. Помните, пожалуйста, что вы пишите не тест-кейс, а баг-репорт, а он имеет свою строго обозначенную структуру:
- заголовок;
- предусловия;
- шаги воспроизведения;
- фактический результат;
- ожидаемый результат;
- приложения (скриншоты, видео, логи и пр.)
Следующая ошибка, связанная с баг-трекингом, – это отсутствие конкретики. Не информативно выглядят описания дефектов с абстрактными словами: несколько, множество, разные или подходящие (про значения). Разработчик ждет конкретных указаний для воспроизведения дефекта и, скорее всего, его “несколько” и ваше “несколько” – это разные вещи. Заводя дефекты без конкретных данных, на которых можно повторить ошибку, вы тратите не только время команды разработки, но и свое собственное. Потому что в 99% случаях такой баг вернется вам на доработку. А как вы знаете, время в тестировании – на вес золота.
Еще одна, довольно грубая ошибка, когда в одном баг-репорте содержится несколько найденных дефектов. Такие репорты скорее напоминают простыню текста, а не привычное описание ошибки.
Запомните, один баг = один репорт! Так они намного легче исправляются и, главное, отслеживаются и перепроверяются тестировщиками. Согласитесь, гораздо проще проверить одну описанную ситуацию, нежели 15.
Ваш менеджер, увидев такие баг-репорты, явно не захочет читать морали, а просто решит сменить вас на другого специалиста, потому что умение четко и понятно заводить баги – одна из главных задач тестировщика.
Вместо заключения
Все мы люди и все мы совершаем ошибки. Не нужно этого бояться (особенно, если вы новичок). Ошибки – это хорошо, ведь благодаря им можно учиться и приобретать полезный и ценный опыт. Но когда одна и та же ошибка повторяется из раза в раз – это дает пищу для размышления вашему менеджеру и порождает желание заменить вас на другого специалиста.
Именно сейчас самое время остановиться и немного подумать: а все ли правильно я делаю? Как часто допускаю ошибки? Выношу ли из них полезный урок? Эти вопросы очень важны, чтобы определить, в верном ли направлении вы движетесь. Помните, что испытательный срок – это не повод паниковать, это — всего лишь отправная точка вашего становления как тестировщика. И чтобы он прошел гладко, без лишнего волнения, я поделюсь с вами секретами на своем курсе. На нем вы познакомитесь с миром тестирования, узнаете о его техниках, видах, научитесь правильно и хорошо заводить баг-репорты, писать отчеты по тестированию, а также тестировать требования, и, что тоже немаловажно, научитесь деловому общению.
Читайте также: