13 Слайд:
Основные вещи, которые спрашивают:
виды тестирования;
типы тестирования;
техники тест дизайна;
структура тест плана\тест кейса\баг репорта;
разница приорити и северити;
Спрашивают также, понимает или не понимает человек вопрос в общем. В идеале, чтобы он что-то на собеседовании написал (просто на листке) или рассказал, как будет тестировать. На собеседовании важно показать то, КАК вы думаете.
14 Слайд:
По техническим навыкам выигрыш дает владение прикладными инструментами. Часто спрашивают на собеседовании об этом. По словам Евгения, чаще всего люди зависают после Jira.
Включает в список технического минимума: Postman, скриншотилку, приложение для записи видео, Selenium на элементарном уровне.
Желательно понимать чем отличаются браузеры, если тестирование под вэб. Знать клиент-серверную архитектуру на концептуальном уровне. Понимать статус-коды
15 Слайд:
Практика показывает, что очень многие специалисты на собеседовании забывают о продуктовом тестировании, когда фокус идёт на сценарии, с которыми сталкивается реальный пользователь.
Например, Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение. Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. Я регулярно сталкиваюсь с тем, что забываю пароль от очередного сервиса, и надо его восстанавливать. По старому тебя не должно пускать, а по новому — должно
16 Слайд:
50-60% кандидатов фейлится на вопросе про свой самый большой провал. Очень многие комплексуют признаваться в неудачах. Ощущение, что они начитались книг про успешный успех и думают, будто все истории построены на череде исключительно успешных кейсов. Это не так: не ошибается только тот, кто ничего не делает.
Лучше прямо рассказывать о собственных неудачах. Не пытаться увиливать, спихивать ответственность на коллег, обстоятельства, фазы луны. Если человек хорошо рассказывает про собственные фейлы, например, как проанализировал их с помощью техники «Пять почему» или Диаграммы Исикавы, разобрался в причинах ошибок и устранил их, что сделал для того, чтобы проблема не повторялась — это очень подкупает. Если вам задают такой вопрос — будьте искренними, это ключ к успеху.
17 Слайд:
Если спросить у слушателей курсов Евения «Почему вы решили пойти в тестирование, а не в разработку?» Только 2-3 человека из 15 ответят, что им нравится что-то ломать или у них так голова устроена. Остальные обычно отвечают, что знакомый или родственник посоветовал им этот путь как самый простой вход в IT. «Иди в тестировщики, там ничего делать не надо. Будешь сидеть ровно и много зарабатывать».
Часто кандидат на собеседовании отвечает «иду в тестировщики, чтобы потом стать разработчиком». Нанимающий менеджер сразу думает: «Предположим этот человек проработает у меня год. Это примерно 2000 часов. И мне надо вложить 300-400 часов в его обучение. А что если он уйдет раньше?» Получается, что нанимать его невыгодно.