Баг-репорт, тест-кейс и чек-лист. Лайфхаки для начинающих тестировщиков от бывшего преподавателя в Арктике!

Hola, Amigos! Меня зовут Алина Кузьмина, я middle тестировщик в агентстве продуктовой разработки Amiga. В этой статье я расскажу про свой опыт прихода в профессию и основы, которые советую изучить каждому тестировщику в начале пути. С ними вы будете увереннее расти дальше и не бояться браться за первую работу.

Изначально я вовсе никакой не тестировщик (QA). Я закончила филологический факультет МГУ и целых 13 лет своей жизни отдала преподаванию иностранных языков. Так, вероятно, могло быть и дальше, но в один прекрасный миг я поняла, что развиваться мне больше некуда: я успела поработать и в школе, и в детском саду, и в ведущих вузах страны, и стать соавтором учебника для НИУ ВШЭ, и даже побывала директором школы в Арктике!

В общем, набрала весьма богатый бэкграунд и поняла, что топтаться на месте не хочется. У меня был неофициальный опыт работы тестировщиком и этот опыт мне нравился. Меня завораживало то, что я могу делать продукт лучше и понятней для пользователей, и что в этой профессии можно развиваться бесконечно много, а ещё эта сфера никак не связана с преподаванием.

Я решила пройти полную переквалификацию и с головой ушла в новую для меня сферу. Обучалась я на всем известных курсах на платформах Skillbox, Stepik, смотрела различные обучающие видео в youtube, читала статьи, общалась со знакомыми из IT, самостоятельно тестировала всё подряд и много чего еще. В итоге пришло время начинать поиски новой работы.

Когда я пришла на своё первое в жизни собеседование на тестировщика, мне дали огромное тестовое задание: надо было протестировать функционал сайта (по распечаткам, сам сайт посмотреть не дали!), составить баг-репорты, написать SQL-запросы и тест-кейсы. На всё про всё мне дали не больше часа. Тут хочется добавить, что будучи преподавателем я не провалила ни одного собеседования. Везде, куда я хотела, меня всегда брали с руками и ногами, поэтому и в новой профессии я не ожидала другого исхода.

Глядя на задание, я поняла, что на этот раз легко мне не будет. Дрожа и бледнея, я решила начать с более для меня трудного, а потом перейти к легкому. Лёгким я считала написание тест-кейсов. В итоге, перенервничав, вместо тест-кейсов я выдала довольно несуразные чек-листы. Была опозорена и выдворена вон. Таким был мой старт.

Сейчас я работаю в крутой IT-компании и занимаю должность middle QA. И думаю, что именно тот опыт стал для меня показательным. Он научил меня внимательно относиться к документации.

Этой статьёй я хочу раз и навсегда разложить по полочкам три кита документации тестировщика: баг-репорт, тест-кейс и чек-лист, потому что именно они являются базой. И любому начинающему тестировщику будет полезно хорошо разобраться в этой теме.

Баг-репорт — это полноценное описание найденного бага или дефекта. То, с чем тестировщик сталкивается каждый день на абсолютно любом проекте.

Немного отвлекусь: на моей первой официальной работе в качестве QA, разработчики вообще предложили мне кратко формулировать проблему и не описывать никаких шагов воспроизведения. «Они проект знают и всё поймут», но так это не работает.

Я отвергла эту мысль, хотя это сэкономило бы кучу моего времени. А почему? Часто недостаточно просто краткой формулировки проблемы. Не всегда достаточно написать: «Такая-то кнопка не работает». Есть несколько причин «почему».

Во-первых, часто баг воспроизводится только в каких-то специфических условиях, поэтому нужны точные шаги воспроизведения, окружение, может какая-то дополнительная информация, а иначе баг просто невозможно будет воспроизвести и разработчик вернёт его на тестировщика с пометкой «Не смог воспроизвести».

Во-вторых, в команду может прийти новый человек. Вы только представьте, как не информативные баг-репорты усложнят ему жизнь! Проекта он не знает, баг-репорт не отвечает ни на один вопрос. Разработчик будет вынужден каждый раз спрашивать у вас нужные ему детали. Ужас, какая трата времени!

Ну и в-третьих, никогда не надейтесь на свою память. Уверяю вас, когда количество найденных вами ошибок перевалит за пару десятков, запомнить всё будет невозможно. Поэтому, записывайте всё и всегда.

Заголовок. Краткий, чёткий, ёмкий. Идеально, если отвечает на вопросы «Что, где, когда».

Например: «Нет перехода на страницу оформления заказа при нажатии на кнопку “Купить”». Так разработчику сразу станет ясно, в чём проблема. Ну и плохой пример для сравнения: «В корзине не работает кнопка». Какая кнопка? А как она должна работать? Непонятно.

Описание. Тут пишем дополнительные детали, которые не поместились в заголовок.

Например: «Кнопка “Купить” не работает, когда пользователь хочет приобрести какие-то конкретные товары».

Предусловие. Этот пункт не всегда актуален, но иногда бывает очень полезен. Сюда вписываем определённые условия, при которых воспроизводится баг или что должен сделать пользователь, чтобы его воспроизвести.

Например: «В случае с кнопкой “Купить” у пользователя должен лежать товар в корзине».

Окружение. Этот пункт тоже используется не во всех баг-репортах. Сюда пишем номер версии, на которой воспроизводится баг или на каком устройстве можем его повторить.

Шаги воспроизведения. Этот пункт нельзя выкинуть и отнестись к нему нужно очень аккуратно, потому что это «инструкция, как воспроизвести баг». Пишем по шагам.

Например: «1. Перейти в корзину 2.Нажать кнопку “Купить”».

Важным моментом является то, что шаги необходимо писать в нейтральном, обезличенном варианте, используя инфинитивы «нажать», «купить», «открыть», «перейти» и так далее. Если писать “Нажми”, “Перейдите” и так далее, это может выглядеть не совсем вежливо и, используя нейтральную форму, можно легко избежать потенциальных неудобств.

Ожидаемый результат. Тут обязательно пишем, что, согласно ТЗ и здравому смыслу, должно получиться после того, как пользователь повторил все шаги воспроизведения.

Например: «Осуществляется переход на страницу оформления заказа».

Фактический результат. Тут пишем то, что получилось по факту.

Например: «После нажатия на кнопку “Купить” не осуществляется переход на страницу заказа».

Скрин или запись экрана. Всегда, всегда прикладывайте либо скрин бага, либо запись экрана! Во-первых, так наглядно будет видно, как именно он выглядит. Во-вторых, снимет с вас, как с тестировщика, некоторую ответственность: баг был, доказательство приложено.

Тест-кейсы — это подробное описание проверок, которые необходимо выполнить.

Представьте, что вы пришли на новый проект, например, интернет-магазин, где часть функционала уже реализована. Вас просят протестировать все способы регистрации и авторизации, которые имеются на проекте. Может возникнуть вопрос: а что, может быть несколько способов зарегистрироваться и авторизоваться?

Вот тут вам на помощь и придут тест-кейсы. В них будет подробно расписано, что конкретно надо проверить, как осуществлять проверку и что должно в итоге получится. Например, вы посмотрите на тест-кейсы и поймёте, что можно зарегистрироваться самостоятельно, а можно с помощью менеджера, можно быть авторизованным как клиент, как менеджер, а может быть вообще мультиаккаунт.

Работа тестировщика бывает непредсказуемая. Вас могут переводить с проекта на проект, вы можете тестировать только определённый функционал у продукта, а не весь полностью, и держать в голове всё невозможно.

Более того, каждый тестировщик может по-своему смотреть на необходимые проверки. Тест-кейсы помогают максимально беспристрастно подойти к процессу тестирования, учесть все его стороны и ничего не забыть.

Заголовок. Тут стоит написать, что конкретно проверяется.

Например: «Проверка увеличения количества товаров в корзине».

Шаги воспроизведения. Подробно по шагам описываем, как надо воспроизвести проверку.

Например: «1) Положить в корзину товар 2) Перейти в корзину 3) Увеличить количество товара» и т.д.

Ожидаемый результат. Что должно случится в результате проверки?

Например: В случае, который мы рассматриваем, количество товаров должно увеличиться.

Чек-листы — это тоже список проверок, но тут не надо подробно описывать шаги воспроизведения.

Чек-лист должен быть кратким, ёмким и лаконичным. Он должен отразить проверяемый функционал. Например: «Проверка получения пуш-уведомления при оплате заказа».

Из сказанного выше может возникнуть вопрос: какая разница между тест-кейсом и чек-листом и в каких случаях что надо использовать?

По своему опыту могу сказать, что, когда тестировщик приходит на новый проект нет ничего лучше, чем тест-кейсы. А почему?

Например, однажды я подключилась на проект, когда до релиза оставалась всего неделя. Ситуация была критической: мне надо было очень быстро включиться в новый для проект, который к тому же был довольно сложным. Что я начала сразу делать? Проходить тест-кейсы и это здорово помогло мне вникнуть в суть проекта буквально за пару дней.

С другой стороны, бывает, что проекты радикально меняются. Например, заказчик решил внести новый функционал или полностью переделать старый. Получается, что часть тест-кейсов и чек-листов становится неактуальной. Приходится обновлять. Конечно, в таком случае поддерживать чек-листы гораздо проще и менее трудозатратно, чем тест-кейсы.

Подводя итоги, в первую очередь, хочется пожелать вам, чтобы вы не боялись искать себя и своё дело жизни! Я много лет была преподавателем, но в какой-то момент почувствовала, что мне пора что-то менять. Решилась и не жалею! Не бойтесь идти в IT, это самая волшебная сфера, для обучения в которой в наше время есть множество способов.

Я писала статью для начинающих тестировщиков, но думаю, что она будет полезна и тем, кто хочет познакомиться с этой профессией. Запомните, что баг-репорт, текст-кейс и чек-лист это важнейшая документация для любого QA-инженера.

Усвоив эти основы, вам будет гораздо проще найти работу мечты и стать действительно хорошим специалистом. Надеюсь, что лайфхаки, которыми я поделилась, окажутся полезными и выручат вас на первом месте работы.

Успехов!

Контакты Amiga:

Наш тг-канал для мобильных разработчиков: @flutter_amiga

Сайт: amiga.agency

Почта: hello@amiga.agency