Тестировщик: от самоопределения до первого бага

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

Как определиться?

Профессию QA-специалиста (Quality Assurance) можно рассматривать как стартовый этап, можно как самодостаточную специальность. Если общих фраз и требований на hh.ru вам недостаточно для того, чтобы понять, увлечет вас тестирование или пройдет мимо — мы вас понимаем. Пообщайтесь с потенциальными коллегами, посмотрите видео на Youtube, можете сходить на митап QA-специалистов. В конце статьи для вас есть пункт, где мы рекомендуем дополнительные материалы — они будут полезны, если вам интересны теоретические основы тестирования (а без них, по факту, тяжеловато).

Собеседование. Чего ждать?

Все зависит от компании, в которую вы планируете собеседоваться. Где-то ручаются всему научить самостоятельно, но в большинстве случаев существует перечень требований к потенциальному QA: с него и начните. А пока что вот вам чек-лист основных понятий, с которых стоит начать:

Чем отличаются друг от друга виды тестирования
Какая бывает документация и как с ней работать
Методы тест-дизайна
Принципы написания тест-кейсов

В качестве тренировки попробуйте протестировать первый попавшийся под руку предмет. Из личных качеств вам пригодятся усидчивость, внимательность к деталям, придирчивость, стремление развиваться — все по канону.

Первый рабочий день

Как к начинающему, скорее всего, в курс дела вас будет вводить кто-то из числа опытных коллег, в больших компаниях этим занимается QA-lead. Покажут весь софт, объяснят, как работать с документацией, расскажут парочку кейсов, познакомят со всеми QA и разработчиками, расскажут о компании. Есть организации, в которых новеньким заботливо организовали целый портал, чтобы они познакомились с системой. Не упустите возможность спросить все, что непонятно, интересно и т.д. В Infoshell рабочий день начинается с созвонов с Product Owner’ами. Обсуждаем, что успели вчера, чем будем заняты сегодня, распределяем задачи, обсуждаем то, что непонятно. Также в течение дня всегда можем связаться в Skype или Slack.

Первые кейсы

Пришло время взяться за практику. Сейчас вы протестируете своё первое приложение. Как это проходит?
До того, как тестировать приложение, попробуйте составить чек-лист (список функций, которые нужно проверить). Потом это станет у вас постоянной практикой. Вам расскажут о приложении и выдадут документацию, в которой подробно описан функционал. Уделите время тому, чтобы продумать возможные баги и записать их. Попросите чек-лист у более опытных тестеров, чтобы дополнить свой.

Например, часть общего чек-листа для мобильного приложения:

Дальше приступаем к тестированию приложения. Как правило, оно проходит в несколько этапов:

Дымовое тестирование
Или Smoke-тестирование — проверка основных функций приложения: если в приложении “Велопрокат” некорректно работает функция заказа одного из товаров — приложение не выполняет основные функции. Такие баги проверяют в первую очередь. Идея в том, чтобы на первых шагах выявить очевидно важные баги и не копаться в заведомо нерабочем приложении.

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

Полное функциональное тестирование и тестирование пользовательских интерфейсов
Полностью проверяем приложение на соблюдение всех требований, указанных в спецификации.

Кратко рассказали об этапах тестирования, а теперь о том, как описывать найденные баги.

Первым делом стоит разобраться с типом найденной ошибки. В основном их делят на баги, улучшения и дополнения к функционалу. Баги — нарушения в функционале; улучшения — в целом работает, но можно сделать лучше; дополнения к функционалу — возможности, которые нужно добавить к функционалу. Такая классификация помогает разработчикам расставлять приоритетность выполнения задач.

Далее приступайте к позитивному тестированию — когда вводите заведомо корректные значения, после — к негативному. При негативном тестировании проверяем, что программа не работает там, где не должна.

Итак, разберем составление тест-кейса для бага (описание найденного бага):

Порядковый номер
Название
Оно должно быть понятным, отражающим суть, но кратким.
Лайфхак: название можно строить по принципу чгк (что случилось? на какой странице приложения? после чего это случилось?). Например: на странице “Корзина” после нажатия кнопки “Отправить” появляется сообщение об ошибке.

Предварительные шаги
Сценарий того, как вы пришли к багу. Какие действия выполнили, куда кликали, что вводили и т.д. Все подкрепляется скриншотами.

Ожидаемый результат
Расписываем, что должно было произойти исходя из документации.

Полученный результат
Что произошло по факту. Снова прилагаем скриншот.

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

О серьезности:
S1(Блокирующая) — одна или несколько функций не работают, приводя систему в нерабочее состояние.
S2(Критическая) — когда не работает важный функционал, затрагивающий основную бизнес-логику.
S3(Значительная) — когда не работает не самый важный функционал, бизнес-логика не нарушена или есть возможность осуществить тестируемую функцию корректно, но через другой набор действий.
S4(Незначительная) — дефект, не относящийся к основному функционалу, возможно, не влияющий на работу приложения: ошибка в интерфейсе, сместившееся поле, проблема сторонних сервисов.

Среда
Указываем, на какой платформе тестировался сервис (браузер, модель телефона, версия Android и т.д.).

Как правило, на тестирование одной версии уходит 3-5 часов.

Часть записи тест-кейса в TFS:

Наш пример — один из самых популярных подходов к описанию багов. Он не универсален для каждой компании, но более-менее общий.

Не первый рабочий день

Немного набравшись опыта, вы сможете “умнее” подходить к тестированию приложения: не просто тыкать на кнопочки и искать то, что не работает — вы будете знать, какие баги искать в первую и последнюю очередь, где они могут быть, начнете учитывать бизнес-логику продукт, будете учиться. Опытных тестировщиков ценят за то, что они повышают качество продукта, а не ищут как можно больше багов.

Приятно, когда тестировщик старается дойти до “корня” проблемы. Пробуйте находить закономерности. Например, при поиске по названию программа при вводе названия пиццы “Пепперони” производит поиск по категории продуктов “Выпечка”. Так происходит со всеми пиццами? Что происходит при поиске выпечки? В каких случаях поиск работает верно? Так вы облегчите работу программистам.

Несколько ресурсов для тех, кому нужно больше информации

1. Для начала, можете посмотреть вот этот плейлист на Youtube. Теоретические основы рассказывают в меру подробно, но этого хватит, чтобы понять, хочется ли двигаться дальше.
2. Рекомендуем книгу Романа Савина “Тестирование dot COM”. Эта книга дает общее понятие о тестировании, рассказывает основы, дает представление о том, чем занимаются тестировщики.
3. “Тестирование программного обеспечения. Базовый курс” Святослава Куликова — полезно начинающим и продолжающим.
4. Полезная статья о том, почему тестирование — не забег на скорость по количеству найденных багов.
5. Здесь разобраны примеры тест-кейсов.
6. Хороший портал, который вам ещё не раз пригодится.

Успехов!