Мой путь тестировщика начался с любопытства. С самого детства я занимался сборкой компьютеров и установкой ПО, в ходе работы регулярно возникали вопросы: «Почему не устанавливается? Почему не работает?». В этот момент я подумал, что хочу стать тестировщиком, заниматься выпуском качественного ПО и узнать ответы на все эти вопросы.
Ниже я хочу рассказать будущим QA-специалистам о том, что их ожидает в начале карьеры, и дать несколько советов из своего опыта.
Собеседование
Junior-тестировщику не очень сложно пройти собеседование. От него не ждут глубокого знания теории и инструментов для тестирования. При собеседовании таких кандидатов мы обращаем внимание на скорость и живость мышления, свежий и нестандартный подход к решению задач.
Например, задаём необычные вопросы, чтобы посмотреть, как мыслит человек:
- Самолёт вылетает из точки А в 17:00, а прилетает в точку Б в 19:00. При этом находится в полёте три часа. Почему такое может быть?
- Как сделать так, чтобы, получив обновлённое приложение, конкуренты не смогли узнать его новые функции?
Будьте готовы и к самому обычному заданию — протестировать простой предмет: лист бумаги, карандаш, сетевой фильтр и тому подобное.
Также для собеседования будет полезно:
- Изучить виды тестирования: функциональное и исследовательское тестирование, автоматизированные тесты (включая инструменты для него), нагрузочное и стресс-тестирования, smoke-тестирование.
- Дополнительно почитать о приёмочном тестировании и его критериях.
- Если мы говорим о тестировании веб-приложений, то это браузерная консоль и её работа, количество и версии браузеров, разрешения мониторов, инструменты тестирования вёрстки (pixel perfect).
- Если мы говорим о мобильных приложениях, это виды платформ, эмуляторы, monkey testing. Не забудьте о планшетах.
- Изучить виды баг-трекеров. Самые популярные: Jira, BugZilla, RedMine, Mantis. Посмотрите, как они работают, в чём их особенность.
- В перспективе — инструменты Jmeter, Postman, Charles. Они не очень сложны в освоении на базовом уровне.
Первый рабочий день
Первый рабочий день проходит стандартно: выдают компьютер, который нужно настроить, установить рабочие программы. Системный администратор готовит доступы к почте и корпоративным внутренним программам.
Не стоит спрашивать, где установить Skype, использовать в нём ник со школьных времён gangsta_666 или забавную картинку. Используйте в нике сочетание имени и фамилии, например ivansmirnov или smirnovivan, поставьте свою обычную фотографию.
Важный шаг в подготовке к рабочему дню — знакомство с баг-трекром, который использует компания. Об этом стоит поинтересоваться заранее: изучите статьи, посмотрите обучающие видео. Вы сэкономите время коллег и сами будете чувствовать себя увереннее.
Первое задание
Вам будет предоставлен первый проект для погружения. Советую ознакомиться с историей баг-трекера и посмотреть, какие дефекты уже встречались или чаще всего встречаются. Сможете для себя сформулировать статистику и будете понимать, на какие моменты стоит обратить больше внимания.
Проявляйте инициативу. Если вам не дали чек-лист приложения, не ждите, а попросите его у ментора. Если в организации нет чек-листа, вы можете составить его сами. В нашей компании чаще чек-лист составляют в «Google Таблицах». Ниже мы привели пример такого чек-листа — вы сможете составлять свои по его примеру.
Коллеги будут удивлены, если составите чек-лист в виде карты мыслей, например в Xmind.net.
Чек-лист для тестирования Pokémon GO
Одним из первоочередных видов тестирования для начинающего QA-специалиста, возможно, станет прохождение по чек-листам, тест-кейсам более старших специалистов. Этот этап необходим для более быстрого погружения в проект. Для наращивания тестовой базы новичок может сам расширять этот чек-лист. Junior-тестировщики в рамках обучения написанию чек-листов подготовили лист для тестирования приложения Pokémon GO. Тут описаны только позитивные кейсы.
Первый баг в трекер
Описание багов в разных компаниях может различаться, но в целом есть принципы хорошего тона.
Тема
В ней описывают проблему несколькими словами. Лучше, если она будет начинаться с отрицания: «не работает», «не происходит», «неправильно» и прочее. Например: «Не происходит синхронизация с сервером на iPhone 6», «Не работает воспроизведение видео в Nexus 5».
Сценарий
Пошаговое описание воспроизведения бага. Обращайте внимание на предусловие и знаки, которые предшествуют багу (например, загорелась красная кнопка слева).
Дополнительно можно приложить скриншоты с указанием мест, на которые стоит обратить внимание (можно использовать приложения Joxi, LightShot и другие), для более сложновоспроизводимых багов — записать видео. Когда наберётесь опыта, можете снимать и прикладывать логи.
В конце сценария указывается среда, в которой проводилось тестирование: версия приложения, прошивка девайса (Android 6.0.1, iOS 9.3.2). Если это веб-приложение, дополнительно укажите версию браузера.
Назначение бага
Далее нужно назначить на кого-то баг. Узнайте у менеджера проекта или ментора, на кого вешать данный баг, кто из разработчиков за какую область проекта отвечает. Так вы познакомитесь с командой, чтобы в будущем самому назначать баги.
Проставление критичности
Виды критичности багов в большинстве трекеров представлены следующим списком:
Immediate (Blocker)
Блокирующая ошибка. Приводит приложение в нерабочее состояние, в результате которого дальнейшее взаимодействие с тестируемой системой или её ключевыми функциями становится невозможным.
Crit — Urgent
Критическая ошибка, нарушена ключевая бизнес-логика. Проблема приводит к временному падению сервера или приложения без возможности её решения. Устранение проблемы необходимо для тестирования.
High
Значительная ошибка, нарушена часть основной бизнес-логики. Ошибка не критична, есть возможность для работы с тестируемой функцией, используя другие входные точки.
Normal
Незначительная ошибка. Не нарушает бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса и локализации.
Low
Тривиальная ошибка, не касается бизнес-логики приложения. Проблема сторонних библиотек или сервисов, плохо воспроизводится, малозаметна ввиду пользовательского интерфейса.
Самообучение
О важности самообучения все прекрасно знают — мои наставления будут банальны. Так что сразу к делу.
Ниже — несколько книг, которые лично рекомендую своим стажёрам:
- «Тестирование DOT COM», Роман Савин — очень полезное пособие, практически настольная книга начинающего тестировщика. Содержит в себе львиную долю знаний для того, чтобы начать тестировать и успешно отвечать в ходе собеседования на вопросы, касающиеся технико-теоретической части.
- «Как тестируют в Google» — более глубокая книга, описывающая организацию процессов, различные стратегии и подходы к тестированию. Книга помогает понять, что такое качество, как и на каких этапах на него можно влиять.
- «A Practitioner’s Guide to Software Test Design», Lee Copeland — в книге расписаны виды тестирования как «белым», так и «чёрным» ящиком. Перечислены различные техники тестирования, а также то, как ими пользоваться и когда лучше применять. В книге можно найти интересную статью об исследовательском тестировании, которая очень полезна для начинающих тестировщиков.
Коллеги, напишите в комментариях названия интересных книг для тестировщиков. Уверен, всем будет полезно.
Заключение
В заключении хочется добавить,что выпуск качественного продукта — процесс нелёгкий и небыстрый. Нужно уметь отстаивать своё мнение в переговорах, убеждать разработчиков делать правильно, а не на «костылях», понимать, как сделать функциональность более удобной для пользователей.
Это лишь часть нужной информации для начинающего тестировщика. Всё остальное придётся в боевых условиях искать в интернете, потом спрашивать у коллег. Не надо стесняться задавать вопросы и часами гуглить, зачастую ответ на один вопрос сэкономит вам немало времени в будущем.
