Собеседование на тестировщика

Собеседование на тестировщика

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

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

Собеседование

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

Например, задаём необычные вопросы, чтобы посмотреть, как мыслит человек:

  • Самолёт вылетает из точки А в 17:00, а прилетает в точку Б в 19:00. При этом находится в полёте три часа. Почему такое может быть?
  • Как сделать так, чтобы, получив обновлённое приложение, конкуренты не смогли узнать его новые функции?

Будьте готовы и к самому обычному заданию — протестировать простой предмет: лист бумаги, карандаш, сетевой фильтр и тому подобное.

Также для собеседования будет полезно:

  1. Изучить виды тестирования: функциональное и исследовательское тестирование, автоматизированные тесты (включая инструменты для него), нагрузочное и стресс-тестирования, smoke-тестирование.
  2. Дополнительно почитать о приёмочном тестировании и его критериях.
  3. Если мы говорим о тестировании веб-приложений, то это браузерная консоль и её работа, количество и версии браузеров, разрешения мониторов, инструменты тестирования вёрстки (pixel perfect).
  4. Если мы говорим о мобильных приложениях, это виды платформ, эмуляторы, monkey testing. Не забудьте о планшетах.
  5. Изучить виды баг-трекеров. Самые популярные: Jira, BugZilla, RedMine, Mantis. Посмотрите, как они работают, в чём их особенность.
  6. В перспективе — инструменты 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 — в книге расписаны виды тестирования как «белым», так и «чёрным» ящиком. Перечислены различные техники тестирования, а также то, как ими пользоваться и когда лучше применять. В книге можно найти интересную статью об исследовательском тестировании, которая очень полезна для начинающих тестировщиков.

Коллеги, напишите в комментариях названия интересных книг для тестировщиков. Уверен, всем будет полезно.

Заключение

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

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

lifehacker.ru


Делаю репост своей статьи из LinkedIn https://goo.gl/EAFQy1
Надеюсь, что будет полезным при проведении собеседований.

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

Вопросы на сообразительность

  • Сколько необходимо произвести кукол, чтобы удовлетворить спрос в куклах 1 млн города?
  • Сколько теннисных мячей влезет в автобус?
  • Как будете тестировать эскалатор/верёвку/будильник?
  • Подсчитайте примерную площадь застройки г. N в % от площади РФ
  • Как объясните свою работу человеку, не знакомого с тестированием?
  • Напишите формулу вычисления угла между часовой и минутной стрелками на часлах?
  • Как вы готовились для интервью?
  • Сколько ступенек на лестнице, по которой вы поднимались к нам?

Ситуационные вопросы

Ситуация: вам необходимо производить тестирование приложения, которое очень часто обновляется с минимальными изменениями (примерно раз в 2 дня или чаще). Как бы вы тестировали данное приложение, чтобы минимизировать свои трудозатраты?


Ситуация: вам необходимо протестировать кнопку “старт” в веб-приложении, кнопка находиться на 3-ей по счёту странице, начиная со стартовой? Как вы будете тестировать этот функционал?

Ситуация: Есть проект, для которого написано 500 тестов. Приходит заказчик и говорит, что хочет продать продукт и должен быть уверенным, что он рабочий. И хочет, чтобы вы прогнали все эти тесты. Как вы оцените трудозатраты (кол-во дней/часов) и как будет общаться с заказчиком по этому поводу?

Ситуация: Вы попали на новый проект и вы единственный тестировщик на нём. С чего вы начнёте в первую очередь?

Ситуация: У вас есть приложение, которое вычисляет среднее значение оценок студента. Какие входные параметры нам необходимо будет проверять?

Ситуация: Представте, что вы Менеджер, как вы будетете оценивать работу тестировщика на ревью? По каким критериям?

Собеседование на тестировщика

Общие вопросы на темы

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

  • Дизайн тест кейсов, планов и прочих артефактов. Приходилось ли их разрабатывать?Что такое тестирование сверху вниз и снизу вверх ?
  • Анализ требований, тест кейсов, результатов тестирования, отчётов об ошибках. Как вообще определяете, что необходимо тестировать?
  • Знаете ли что-нибудь о классах эквивалентности?
  • Как определить, что тестирование закончено?
  • Типы тестов (exploration/script, ручное/автоматизир, функц/нагруз/безопасности). Какие из них применяли? В чём они выражались?
  • Жизненый цикл дефектов (ошибок). Что включаете в ошибку при её описании?
  • Как будете тестировать приложение, если для продукта нет документации?
  • Как вы определяете эталонные результаты?
  • Что такое тестовое окружение?
  • Расскажите о методологиях тестирования
  • Опишите любой дефект, который вы помните. Вспомнитие ваш самый “лучший” баг.
  • Каков смысл тестирования в процессе разработки?
  • В чём разница между валидацией и верификацией?
  • Что по вашему является хорошим требованием?
  • В чём смысл автоматизации тестирования? Когда она необходима и что необходимо тестировать? Каковы на неё трудозатраты? Нужна ли автоматизация вообще?
  • Каковы минусы полной автоматизации тестирования ?
  • Что вам нравиться/не нравиться в вашей работе?
  • Как вы организуете свой процесс работы?
  • В чём различие тестирования методом чёрного/белого/серого ящика? Какой из методов лучше?

  • Необходимо ли нам тестировать все возможные комбинации/сценарии для программы?
  • В чём смысл unit тестов?
  • Знаете ли вы какие-либо техники/методологии разработки приложения, которые основываются на тестировании(BDD, TDD)?
  • Необходим ли тестировщику общаться с разработчиками? Зачем?
  • Есть ли смысл в баг-трекинг системах?
  • Как вы производите приоритезацию дефектов?
  • Что такое тестирование граничных значений?
  • Использует ли ваша команда CI? Если да, то зачем?
  • Где вы черпаете новые знания о методологиях тестирования и о самом тестировании?
  • Что вы будете делать, когда устанете делать монотонную работу (тестировать к примеру один модуль несколько месяцев подряд) ?
    P.S.: Это всего лишь вершина айсберга, для собеседования более серьёзных кандидатов необходимо влкючать логические задачи, алгоритмы, знание языков программирования и пр. и т.д.

Do different tests instead of repeating the same tests

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Adblock
detector