Какие вопросы тестировщику могут задать на собеседовании: Подробный разбор для соискателей

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

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

Как правило, собеседование на позицию тестировщика проходит в 2 этапа:

• Собеседование с HR — знакомство с кандидатом как с потенциальным сотрудником.

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

• Собеседование с техническим специалистом — знакомство с базовыми скиллами кандидата.

На втором этапе присутствует уже не только HR, но и один технический специалист, цель которого – оценить теоретические знания и умение соискателя применять их на практике.

Вопросы общего характера

Вопросы общего характера HR задаёт на первом этапе собеседования. Ниже представлен их примерный список:

1. Какое у вас образование?

2. Работали ли вы по этой специальности раньше?

3. Как долго вы проработали на прошлом месте и почему приняли решение уйти?

4. Что вы слышали о нашей компании?

5. Каковы ваши зарплатные ожидания?

6. В каком направлении вам хотелось бы развиваться?

7. Почему вы выбрали именно Тестирование?

Универсальных ответов на типовые вопросы, подходящие для любого соискателя, нет. Однако есть ряд рекомендаций, которых следует придерживаться:

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

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

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

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

Изучение основных терминов и понятий

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

Вопросы о тестировании

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

QA, QC и тестирование

• Что такое QA?

QA (обеспечение качества) гарантирует, что все необходимые методы, процедуры, стандарты и методологии были соблюдены, чтобы гарантировать бездефектный продукт.

• Что такое QC?

QC (контроль качества) это процесс проверки, который гарантирует, что тестируемый продукт соответствует требованиям, ранее к нему предъявленным. Это процесс, который обеспечивает ожидаемое качество продукта.

• Что такое Тестирование?

Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта прямым и косвенным требованиям, к нему предъявляемым.

• В чем разница между этими тремя понятиями?

QA – это упреждающий процесс, направленный на предотвращение возникновения возможных дефектов. Он выполняется во время разработки продукта.

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

Цель QA – улучшить процессы разработки и тестирования и таким образом избежать появления дефектов.

Цель QC – выявить дефекты продукта после его разработки и до его выпуска.

Фокус QA всегда именно на процессе, в то же время фокус QC – на продукте.

Теория тестирования

• В чём цель тестирования?

Цель тестирования – предоставление актуальной информации о соответствии продукта выдвигаемым к нему требованиям.

• Что такое ошибка?

Ошибка – это несоответствие производимого продукта прямым или косвенным выдвигаемым к нему требованиям.

Жизненный цикл бага

1. Открыт (Open) – баг выявлен. Создан баг-репорт.

2. В работе (In Progress) – Баг-репорт назначили разработчику, который занялся его исправлением.

3. Исправлен (Ready) – Разработчик устранил проблему с его точки зрения и перевёл баг-репорт обратно на перепроверку.

4. Закрыт (Closed) – баг больше не воспроизводится. В комментарии под баг-репортом пишут дату, когда произведена проверка и комментарий с замечаниями.

5. Отклонен (Rejected) – из-за неточности или недостаточного количества предоставленной информации для воспроизведения баг починить не удалось.

Виды багов

• Функциональные.

Пример: не работает кнопка или весь функционал, за которую она отвечает.

• Визуальные.

Пример: съехал текст, кнопка визуально не отображается, но при этом «если нажать на место кнопки», функционал будет работать.

• Логические.

Пример: возможность указать дату рождения из будущего.

• Дефекты UX. Баги удобства использования.

Пример: плохо виден текст на фоне, страница притормаживает при скроллинге.

• Дефекты безопасности.

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

Из каких этапов состоит процесс тестирования

• Инициация.

Команду извещают о необходимости проведения тестирования.

• Выявление требований.

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

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

• Генерация тестовых случаев.

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

• Отбор показательных, значимых тестовых случаев.

От данного этапа зависит, насколько сессия тестирования будет полезной, эффективной и анализируемой.

Пример: есть «голубая кнопка». Можно придумать много тестовых случаев на основании косвенных требований, но проверять их все – то, что как раз-таки делать не стоит, однако, подобные тест-кейсы должны быть «накиданы» хотя бы в голове того, кто будет проверять эту кнопку. Но если нужно проверить, что «голубая кнопка» именно голубая, то осуществляются проверки, направленные именно на это.

• Проведение проверок.

Либо согласно документации, либо интуитивно, в свободном поиске, но эти проверки проводят согласно ранее утверждённому списку проверок.

• Фиксация результатов.

Создание тестовой документации (например, баг-репортов).

• Анализ результатов.

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

• Передача всей информации, всех выводов заинтересованным сторонам.

Как понять, когда стоит закончить тестирование

Логически тестирование необходимо завершить в тот момент, когда дополнительные тесты существенно не изменят качество программного обеспечения. Однако, стоит выделить несколько причин возможного завершения тестирования:

• Команда достаточно хорошо исследовала продукт.

Ответы на поставленные вопросы были найдены, данные предоставлены клиенту, и он удовлетворён итогами.

• Истекло отведённое время.

В любом проекте на тестирование отводятся определенные сроки. Если в отведённое время весь спектр задач не был решён, процесс, тем не менее, может быть остановлен.

• ПО оказалось слишком «сырым».

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

• Клиент попросил прекратить тестирование.

Команда вышла за рамки бюджета, либо проект был отменен клиентом.

Виды тестирования с примерами

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

Классификация по позитивности сценария

• Позитивное тестирование.

В тест кейсе используются только корректные, «ожидаемые» входные данные.

• Негативное тестирование.

В тест кейсе тестировщик использует как корректные, так и «ожидаемые» входные данные для имитации ситуаций, когда пользователь начинает «чудить» и делать не то, что от него ожидает ПО.

Классификация по знанию системы

• Тестирование белого ящика.

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

• Тестирование чёрного ящика.

Подход к тестированию, который предполагает, что тот, кто выполняет тестирование, не знает о внутреннем устройстве системы. Всё, что ему известно, это входные и выходные данные.

• Тестирование серого ящика.

Это подход к тестированию, сочетающий в себе подходы белого и черного ящика.

Классификация по уровню тестирования

• Модульное (Компонентное, Юнит) тестирование.

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

• Интеграционное тестирование.

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

• Системное тестирование.

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

• Операционное тестирование.

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

Классификация по хронологии выполнения

• Дымовое тестирование.

Это короткий цикл тестов, который проводится после сборки билда, выполняемый для подтверждения того, что билд стартует и выполняет основные функции.

• Повторное тестирование.

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

• Регрессионное тестирование.

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

• Приёмочное тестирование.

Это совокупность процедур, направленных на проверку соответствия системы требованиям к ней, предъявленным по отношению к бизнес-процессам пользователей.

• Тестирование безопасности.

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

Когда следует и когда не следует начинать автоматизацию

Какие тесты имеет смысл автоматизировать:

• базовые часто повторяющиеся тесты, которые от прогона к прогону либо не меняются вообще, либо изменяются минимально.

Это может пригодиться при дымовом тестировании или регрессионном тестировании.

• проверки с большим массивом данных, тестирование форм, тесты, которые предполагают многократный ручной ввод данных;

• тесты с различными конфигурациями, где используется множество ОС и различных браузеров;

• тесты производительности, когда проводятся проверки с помощью тысяч условных «пользователей», и проверяют, как реагирует на данную нагрузку приложение;

• сложные, трудоёмкие сценарии, которые не подходят для ручной проверки.

Какие тесты и при каких условиях нет смысла автоматизировать:

• При динамическом UI.

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

• При ограниченном бюджете проекта.

Если соответствующие затраты не были предусмотрены, прибегать к автоматизации не стоит.

• В планах присутствуют регулярные кардинальные изменения тестов.

Вы будете больше тратить времени на поддержку автоматизированных тестов, чем если бы тестировали ПО вручную.

Зачем нужны техники тест-дизайна

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

• Эквивалентное разделение.

Техника, при которой значения разделяются на эквивалентные группы. Например, при диапазоне допустимых значений от 2 до 20, выбирается одно значение внутри и одно вне диапазона (например, 9 и 1).

• Анализ граничных значений.

Техника, при которой значения для тестов выбираются на границах входных данных. Например, при диапазоне допустимых значений от 2 до 20, выбирается несколько значений по границам диапазона (например, 1,2 и 20, 21).

• Предугадывание ошибки.

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

• Причина / Следствие.

Техника, которая подразумевает наличие ряда условий (причина) для получения ответа от системы (следствие).

• Исчерпывающее тестирование.

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

• Попарное тестирование.

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

• Тестирование на основе состояний и переходов.

Техника необходима для описания дизайна и фиксирования требований.

• Таблица принятия решений.

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

Виды тестовой документации

Требования – это описание того, что должно быть реализовано, без детализации технической стороны решения.

Основные атрибуты требований:

• Полнота.

В требованиях содержится вся необходимая информация для реализации функциональности.

• Непротиворечивость.

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

• Недвусмысленность.

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

• Проверяемость.

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

• Приоритетность.

Каждое требование должно иметь оценку степени значимости.

Какие бывают требования?

Требования бывают прямыми и косвенными.

Пример прямых требований: техническая документация, спецификация, юзер-стори и другие тестовые артефакты.

Пример косвенных требований: было бы очень неожиданно увидеть кнопку закрытия окна «X» в Windows внизу слева, а не вверху справа, где она сейчас и располагается.

Требования также делятся на функциональные (описание функционала продукта) и нефункциональные (требования к окружению, поддерживаемости, надёжности и прочим характеристикам продукта).

Прямые требования всегда приоритетнее косвенных.

Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, выдвигаемым к нему, – ошибки или её проявления. Он обязательно должен содержать следующие элементы:

1. Шапку: краткое, не подробное, но, при этом, однозначно понятное и отличимое от остального, описание бага.

2. Подробное описание состояния системы для выполнения кейса.

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

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

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

6. Входные данные, которые использовались во время воспроизведения кейса.

7. Прочую информацию, такую как, скриншот/видео, логи браузера, логи бэкэнда, то есть ту информацию, без которой воспроизвести баг не получится.

8. Критичность и приоритет.

9. Версию, ресурс и другие данные об окружении.

В чем разница между серьёзностью и приоритетом ошибок?

Серьёзность – характеристика, которая показывает влияние бага на работоспособность функционала.

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

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

3. Значительный баг – из-за которого функционал работает некорректно, но он не влияет на всю систему. Ошибка UI, которая сразу же бросается в глаза. Например, некорректно показывается логотип компании.

4. Минорный баг – это баг UI, который, как правило, не влияет на функциональность, но портит внешний вид и опыт пользования функционалом, либо незначительный функциональный баг, который особо не влияет на опыт пользования приложением, поскольку есть альтернативные пути без проблем воспользоваться функционалом.

5. Тривиальный баг – баг, который не оказывает какого-либо влияния на опыт пользования продуктом. Например, опечатки, несоответствие шрифтов, оттенка и подобное.

Приоритет – характеристика, которая указывает на важность выполнения поставленной задачи. 

Есть 4 основных уровня приоритета:

1. Немедленный (immediately).

2. Высокий (High).

3. Средний (Medium, Normal).

4. Низкий (Low).

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

Тестовый сценарий (тест-кейс) – описание одной показательной проверки на соответствие требованиям.

Чек-лист – перечень тест-кейсов для проведения проверок, без чрезмерных подробностей.

Тестовый комплект — набор тест-кейсов, объединённых между собой по общему логическому признаку. Он содержит в себе идеи проверок, наборы входных данных, ожидаемые результаты, отметку о прохождении/не прохождении тест-кейса, ссылку на баг-репорт.

Тест-план – документ, описывающий весь объем работ по тестированию:

1. Что нужно тестировать.

2. Как будет проходить сессия тестирования.

3. Когда будет проводиться сессия тестирования.

4. Критерии начала сессии тестирования.

5. Критерии окончания сессии тестирования.

Отчёт о тестировании (тест-репорт) – документ, в котором содержатся сведения о нынешнем качестве билда. Содержит подробный анализ, описание произведенных проверок, количество багов, отсортированных по приоритету и степени критичности. Обычно предоставляется после проведения регрессионного тестирования нового билда.

Модели и методологии разработки ПО

В моделях разработки ПО описывается, какие этапы проходит жизненный цикл ПО, и что происходит на каждом из них. К основным этапам жизненного цикла ПО относят:

1. Анализ и разработку требований.

2. Проектирование.

3. Написание кода (разработку).

4. Тестирование.

5. Внедрение и сопровождение.

В методологиях разработки ПО описываются методы по управлению разработкой: принципы, техники, которые делают разработку более эффективной.

Каскадная модель или Waterfall

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

Преимущества модели:

• простая схема процесса;

• просто просчитать затраты на реализацию;

• пишется подробная документация, это сильно упрощает как разработку, так и тестирование продукта.

Недостатки модели:

• тестирование стартует на последних этапах разработки, а это значит, что если была допущена ошибка при проектировании или планировании требований, то исправить её будет существенно дороже;

• клиенты смогут пощупать продукт и дать фидбек только в конце разработки. 

V-образная модель или разработка через тестирование

Это модель, в которой разработка проходит параллельно с тестированием. V-модель считается расширением каскадной модели.

Ключевым преимуществом модели является гибкость и масштабируемость.

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

Итеративная модель

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

Преимущества модели:

• тестирование начинается на ранних этапах, что позволяет снизить риски и стоимость проекта;

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

Недостатки модели:

• отсутствие фиксированного бюджета и сроков. Ни клиент, ни команда разработки и тестирования не знает, как будет выглядеть конечный продукт и когда закончится работа над ним;

• разработка может прекратиться после последней итерации, или же, наоборот, длиться значительно дольше, чем планировалось изначально.

Спиральная модель

Это комбинация итеративной модели и Waterfall. Каждый этап спиральной модели начинается с определения цели разработки и заканчивается оценкой достигнутого прогресса заказчиком.

Главное преимущество – возможность построения большого проекта при нечётких и сложных требованиях, которые могут часто меняться.

Недостатки:

• спиральная модель сложнее в реализации;

• не подходит для небольших проектов ввиду дороговизны;

• требует постоянного анализа рисков.

Agile-методология

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

Преимущества методологии:

1. Все плюсы итеративной модели.

2. «Тесное» взаимодействие команды.

Недостатки методологии:

1. Хорошо прописанная документация – большая редкость на проектах с данной методологией.

2. Нет чёткой дорожной карты выпуска продукта, сроки могут смещаться до бесконечности.

Существует большое количество подходов к разработке, которые относятся к Agile-подобным.

Скрам

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

Основными элементами подхода считаются:

1. Небольшие скрам-команды (менее десяти человек).

2. Регулярные обсуждения (митинги), на которых рассматривается продукт и его проблемы, пути их исправления и реализация новых фич.

3. Подробная тестовая документация.

4. Наличие строгих правил.

Особенности Скрам-подхода:

1. Наличие предварительного плана, который будет изменяться по мере реализации проекта.

2. Фиксированные по длительности спринты разработки и тестирования (от 1 до 4 недель), после чего происходит выдача промежуточного билда.

3. Постоянное взаимодействие со всеми заинтересованными сторонами, в том числе и с клиентом.

Канбан

Канбан — подход к реализации принципов Agile при разработке ПО, который предполагает прозрачность процессов и их обсуждение в режиме реального времени. Рабочие задачи размещаются на доске Канбан стикерами и пометками маркером, что позволяет участникам проекта видеть прогресс задач в любой момент. В рамках канбан-подхода можно взять срочные задачи сразу, не дожидаясь начала следующей итерации разработки.

Важные качества для тестировщика

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

Список качеств хорошего тестировщика также включает:

• энергичность;

• ответственность;

• дисциплинированность;

• здоровый перфекционизм;

• нестандартное мышление.

В совокупности перечисленные навыки и умения способствуют эффективной работе сотрудника в команде.

Коммуникативные навыки

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

Аналитические способности

Без аналитического мышления в работе тестировщика не обойтись. Необходимо разбивать анализ сложного функционала на составные части.  Аналитическое мышление можно и нужно тренировать и развивать. Для этого:

1. Решайте логические задачи, математические примеры и головоломки.

2. Играйте в шахматы и иные настольные игры разного уровня сложности.

3. Анализируйте различные ситуации из повседневной жизни.

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

Навыки работы с тестовыми инструментами

Инструменты тестирования – это отдельное ПО либо утилиты, фреймворки, которые используются при тестировании.

Тестировщики в своей работе пользуются большим количеством различного софта. Например, для тестирования веб-приложений часто используется Chrome DevTools (можно использовать аналогичные режимы разработчика в других браузерах). Для тестирования API – SOAP UI, Postman. Для ведения тестовой документации – Atlassian Jira, Redmine, TestIT.

Что нужно знать тестировщику дополнительно

1. Принципы тестирования API, его виды (REST, SOAP), что такое RESTFul.

2. Linux, Windows, уметь пользоваться командной строкой. Это нужно не всем, поскольку ваш проект может разрабатываться, допустим, под MacOS, но это добавит вам ценности. Пользоваться консольной строкой придется практически постоянно.

3. Знание протоколов HTTP, HTTPS, знание кодов ответа сервера. Принципы клиент-серверного взаимодействия.

4. JSON, XML — форматы обмена данных. 

Практическая подготовка

Только лишь уверенного знания теории недостаточно для получения хорошего оффера, важно уметь применять знания на практике. Чтобы развить необходимые навыки или «набить руку», следует:

1. Выбрать любой сайт и составить для него тестовую документацию: тест-план, чек-лист, тест-кейсы. Не обязательно в полном объёме, 10-20 тест-кейсов будет достаточно. Затем выполнить их и посмотреть результат.

2. Потренироваться в написании баг-репорта. Атрибуты, которые находятся внутри баг-репорта можно найти в отдельной статье.

3. Изучить язык SQL. Попрактиковаться можно на специальных ресурсах, например, на: www.sql-ex.ru

4. Не лишним будет разобраться и потестировать структуры XML и JSON. В этом поможет ресурс: https://www.w3schools.com/xml/xml_whatis.asp.

Заключение

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

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