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

Добрый день. Готовлюсь к своему собеседованию. Собственно работодатель дал вот такие вот ситуационные вопросы. Сюда выкладываю лишь малую часть, ибо на остальные ответил как смог. Эти вызвали затруднения. Как ответили бы Вы?

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

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

3. Задача на тестирование из-за дедлайна была передана с недостаточным описанием требований к изменяемому продукту. На каких условиях мы можем взять данную задачу в тестирование?

#2 Freiman

ФИО: Андрей Адеркин
Город: Йошкар-Ола

Ну вот, например, возможные, но совершенно неправильные ответы:

1.1 Да, должен, исправление ошибки может повлиять на регрессию

1.2 Нет, не должен, это только излишняя трата времени в условиях ограниченных временных ресурсов

1.3 Да, должен, это повлияет на общие метрики производительности в позитивную сторону для тестировщика и программиста

1.4 Нет, не должен, это повлияет на метрики продукта в негативную сторону

2. А что такое "полноценное тестирование"? А какое тестирование можно назвать "неполноценным"?

3. На условиях, что мы ни за что ответственности не несем. Требования не актуальны, из-за дедлайна все равно будет выпущено "то, что есть", а не такой качественный продукт, как нам хотелось бы. Сколько-то критичных багов будет найдено и поправлено, на остальное пока пофиг.

#3 Spock

ФИО: Роман

#4 KraT_by

Ещё в пункте 1 надо узнать, были ли баги найдены на продакшене или на тестовой среде.

И баг всегда должен быть задокументирован, обычно я это делал с фразой: "Давай я забью багу, а ты сразу закоммитишь и закроешь, пусть для истории будет"

#5 Spock

ФИО: Роман

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

ещё тут зависит от вида тестирования при котором были найдены ошибки

когда девелопер делал юнит-тестирование и сам нашёл ошибки и сразу исправил, такие никто никогда никуда не заносит

когда девелопер делал интеграционное тестирование и сам нашёл ошибки и сразу исправил, такие обычно никуда не заносят, если баг не в продакшене

#6 Zuga

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

#7 Shuga

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

1. Заказчик сформулировал свои требования к программному продукту. Допустим, что тестировщик проверил соответствие реализации всем таким требованиям.

Выполнил ли он свою работу?

2. В рамках требований изменяется часть информационной системы. При тестировании было найдено расхождение в той части, которая не изменялась. Является ли это ошибкой, что тестировщик должен сделать в такой ситуации?

3. При тестировании задачи были найдены ошибки, разработчик их исправил и передал обратно в тестирование. В каких случаях это можно считать новой итерацией тестирования? 4. Есть заказчик, разработчик, аналитик и тестировщик. Существует процесс согласования ими требований к ПО до реализации. К какому виду тестирования можно отнести данный процесс в части согласования тестировщиком? Прокомментируйте свой ответ.

#8 Freiman

ФИО: Андрей Адеркин
Город: Йошкар-Ола

#9 Vasiliy

ФИО: Касимов Василий
Город: Москва

Андрей вам уже ответил, а у меня свой вопрос - на какой позиции задают такие вопросы?

#10 Spock

ФИО: Роман

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

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

3 - вообще наверное да, новая итерация. Это ведь цикл - разработчик чинит, тестировщик тестирует, и так по новой

4 - к статическому наверное. так как есть только документация, которая тестируется в какой-то мере всеми участниками, кем-то меньше, кем-то больше

#11 Vasiliy

ФИО: Касимов Василий
Город: Москва

Это требования, а не документация)

Статическое тестирование относится к коду. Когда у вас есть выбор выполнять его (динамическое тестирование) или не выполнять (статическое).

Документация тестируется в рамках тестирования документации:) Потому что вы можете только прочесть ее и ничего более.

📎📎📎📎📎📎📎📎📎📎