Перейти к содержимому

Практикум по тест-дизайну 2.0
онлайн, начало 29 ноября
Тестирование REST API
онлайн, начало 18 ноября
Автоматизатор мобильных приложений
онлайн, начало 27 ноября
Selenium WebDriver: полное руководство
онлайн, начало 15 ноября

metodh9

Регистрация: 10 апр 2015
Offline Активность: 23 мар 2019 05:27
-----

Мои сообщения

В теме: Интересные вопросы на собеседовании.

22 Март 2019 - 23:46

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

1. Что такое минимальные изменения. То что изменения часто накатываются вовсе не гарант того, что они минимальны. За 30 минут рефакторинга разработчик может так переколбасить софт, что его потом надо будет тестировать несколько дней.
2. Импакт-анализ. https://habr.com/ru/post/144609/
3. Автоматизация, TDD, BDD - https://habr.com/ru/post/139674/
 

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

1. Нужно уточнить вопрос. Как дойти до страницы - через UI или можно ввести ее URL. Как тестировать - нажать и посмотреть, что будет :D

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

1. Были ли изменения? Если изменений в коде с последнего прогона не было - то можно сообщить заказчику, возможно продукт можно отдавать сразу. А может не нужно, если вы аутсорс и ваш руководитель (не заказчик) захочет заработать на прогоне :)
2. Исключить тесты которые гонялись при выпуске последней версии продукта.
3. Подходы к оценке есть разные, лучше использовать те которые приняты в компании и знакомы заказчику. Кто-то любит эксельки с графиками и тестовой стратегией на трех листах, а кому-то достаточно кол-во часов. 

Ситуация: Вы попали на новый проект и вы единственный тестировщик на нём. С чего вы начнёте в первую очередь?
1. Добавлю отдельный выделенный этап тестирования, если его нет, в процесс, чтобы все задачи проходили через меня. 
2. Начну ходить на регулярные встречи которые есть у участников проекта
3. Начну разбираться в продукте на верхнем уровне (ЦА продукта, проблемы решаемые продуктом, зависимости, компоненты)

Ситуация: У вас есть приложение, которое вычисляет среднее значение оценок студента. Какие входные параметры нам необходимо будет проверять?
1. Какой интерфейс? 
2. Какая система оценки? (пятибальная, десятибальная и т.п)
3. Будут ли вводиться +/-?
4. Какой минимальный шаг? Может ли быть 3.1 балла

Ситуация: Представте, что вы Менеджер, как вы будетете оценивать работу тестировщика на ревью? По каким критериям?
1. По вопросу не совсем понятно.
Если говорим про ревью работы тестировщика, т.е. он протестировал какую-то задачу, я просто буду задавать вопросы по различным кейсам из этой задачи. Если он на все вопросы ответит - то все ок. Если на эти вопросы он не ответит - то тут уже все зависит от вопросов и как он не ответил.   


В теме: Интересные вопросы на собеседовании.

22 Март 2019 - 23:07

По вопросам от ТСа.
 

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

 

2. Тестировщик получил задачу, в которой описаны только функциональные требования. Достаточно ли этого для проведения полноценного тестирования? Если нет, то какая еще информация может быть нужна?
Ответ: смотря какое тестирование является для этой задачи полноценным. Если для бизнеса важен лишь happy path и уверенность, что не сломалась старая функциональность - то этой информации может быть вполне достаточно. 

 

3. Задача на тестирование из-за дедлайна была передана с недостаточным описанием требований к изменяемому продукту. На каких условиях мы можем взять данную задачу в тестирование?
Ответ: Плохие требования, к сожалению это норма. Тестировщик может сам собрать требования и исследовав текущую реализацию обсудить ее с бизнесом(демо) для внедрения доработок до выпуска. 

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


Но мне кажется с такими ответами собеседование не пройти. 


Яндекс.Метрика
Реклама на портале