Сообщений в теме: 26

[ddimoxa]

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

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

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

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

[Freiman]

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

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

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

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

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

1.5 Да, ....

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

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

[Spock]

возможные ответы, которых "ждёт" интервьюер

 

1. да, должен, ведь ошибка может заново появиться в регрессии, да и авто-тестами чтобы потом покрыть

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

3. чаще всего так и бывает. принимаем и согласовываем недостающие детали с заказчиком

[KraT_by]

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

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

[Spock]

 

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

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

 

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

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

[Zuga]

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

 

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

[Shuga]

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

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

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

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

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

 

[Freiman]

1. Допустим, да. А если бы вопрос звучал "выполнил ли он свою работу полностью" - то нет.
2. Расхождение в чем?
3. А как поставлен процесс разработки?
4. Тестирование требований? Переформулируйте свой вопрос.

[Vasiliy]

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

[Spock]

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

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

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

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

[Vasiliy]

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

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

ИМХО.

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

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

[Shuga]

1. Допустим, да. А если бы вопрос звучал "выполнил ли он свою работу полностью" - то нет.
2. Расхождение в чем?
3. А как поставлен процесс разработки?
4. Тестирование требований? Переформулируйте свой вопрос.

По первому пункту. Можете разъяснить, какова будет его работа полностью?

По второму, третьему и четвертому. Вопросы заданы - так как заданы, уточнить возможности нет.

[Shuga]

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

Не совсем понял, но ответить попробую, на предварительном собеседовании.

[Freiman]

Последний вопрос явно из ISTQB и Блэка :) Они относят это к статическому тестированию черного ящика. Почему так - хз. Так что вопрос не на логику даже, а на знание конкретных фактов.

[Freiman]

По второму, третьему и четвертому. Вопросы заданы - так как заданы, уточнить возможности нет.

Точно ли нет такой возможности? Или вы просто не хотите беспокоить рекрутера?

[Shuga]

 

По второму, третьему и четвертому. Вопросы заданы - так как заданы, уточнить возможности нет.

Точно ли нет такой возможности? Или вы просто не хотите беспокоить рекрутера?

 

К сожалению -точно

[Vasiliy]

 

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

Не совсем понял, но ответить попробую, на предварительном собеседовании.

 

Позиция какая? Старший тестировщик, начинающий? Нач. отдела?

[Shuga]

 

 

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

Не совсем понял, но ответить попробую, на предварительном собеседовании.

 

Позиция какая? Старший тестировщик, начинающий? Нач. отдела?

 

Начинающий.

[Freiman]

По первому пункту. Можете разъяснить, какова будет его работа полностью?

Могу, но не хочу. Просто поразмышляйте, и ответ найдется.

[Spock]

 

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

ИМХО.

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

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

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

 

http://istqbexamcert...ting-technique/

 

 

 

 

 

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

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

 

 

 

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

требования и есть часть документации