Были вопросы на собеседовании...

1. Suppose that you find some scenarios that are not covered in the requirements( for example the new feature interacts with other existent components). Which are the steps that you take?
2. Suppose that we have the next scenario: in a program the actual result doesn't match the expected result, what should you do?
3. Suppose that you have to test a table on a web application and the last column contains two actions: edit and delete. How do you test it?

Собеседование я непрошол, но хочу разобраться
Со вторым понятно нужно рапортировать баг, а остальные что ? Кто умнее подскажите пожалуйста

Со вторым тоже не всё так просто :)
Во-первых, надо разобраться - может это Вы что-то не так сделали (может у вас просто закончилось место на диске и дальнейшие операции с диском невозможны)? Как минимум попробовать воспроизвести на другой машине и уже после этого - постить дефект :)
То есть дело в том, что бы действовать не просто, не совпало - постим.. а Вы должны показать, что пытаетесь разобраться, думаю именно это от Вас хотели услышать , как ответ на второй вопрос ;)

Со вторым тоже не всё так просто :)
Во-первых, надо разобраться - может это Вы что-то не так сделали (может у вас просто закончилось место на диске и дальнейшие операции с диском невозможны)? Как минимум попробовать воспроизвести на другой машине и уже после этого - постить дефект :)
То есть дело в том, что бы действовать не просто, не совпало - постим.. а Вы должны показать, что пытаетесь разобраться, думаю именно это от Вас хотели услышать , как ответ на второй вопрос ;)

А вдруг требования изменились, программу переписали, а поправить тестовую документацию не успели/забыли итп, и expected result уже не является верным результатом, а правилен как раз actual?

1. Итак, мы нашли место, не учтенное в требованиях. Что бы я стал делать? Я бы выяснил, какие проблемы может вызвать отсутствие этого требования, и рассказал об этом ответственному за требования человеку (старший тестировщик, менеджер проекта, ...)
3. ИМХО, тут информации маловато.
1) Кликнуть по кнопке EDIT, отредактировать поля, кликнуть SAVE, посмотреть, что данные обновились в соответствии с изменениями.
2) Кликнуть по кнопке EDIT, отредактировать, кликнуть Cancel (если кнопка есть), либо просто закрыть окно браузера, посмотреть, что данные в таблице не изменились
3) Кликнуть DELETE, посмотреть, что строка удалилась
4) Кликнуть EDIT, заполнить поля «негативными» значениями, посмотреть, будет ли система ругаться, или примет невалидные значения
5) Удалить все пункты в таблице
6) ???

Еще были как всегда вопросы о том как бы я тестировал кусок бумаги. Интересно мнение опытных людей или возможно самих рекрутеров- что в таких случаях будет правильным?
Я например спросил у интервюера есть ли у нас для теста какие нибудь requirement, ответ был отрицательным. Я сказал ей что начну с функцыонального тестирования, тоесть проверю можно ли на нем что то написать! Потом тестирую его usability тоесть например не скользит ли он на столе, удобно ли его держать. Вопрос в том есть ли какойнибудь шаблон набора тестов применимих в случаи вопросов насчет тестирование предметов, и как это разложить по полочкам чтобы протестировать в полном обэме и оставить довольным работника HR. Спасибо за предыдущие ответы

1. Итак, мы нашли место, не учтенное в требованиях. Что бы я стал делать? Я бы выяснил, какие проблемы может вызвать отсутствие этого требования, и рассказал об этом ответственному за требования человеку (старший тестировщик, менеджер проекта, ...)
3. ИМХО, тут информации маловато.
1) Кликнуть по кнопке EDIT, отредактировать поля, кликнуть SAVE, посмотреть, что данные обновились в соответствии с изменениями.
2) Кликнуть по кнопке EDIT, отредактировать, кликнуть Cancel (если кнопка есть), либо просто закрыть окно браузера, посмотреть, что данные в таблице не изменились
3) Кликнуть DELETE, посмотреть, что строка удалилась
4) Кликнуть EDIT, заполнить поля «негативными» значениями, посмотреть, будет ли система ругаться, или примет невалидные значения
5) Удалить все пункты в таблице
6) ???

Спасибо за ответ. Скажите пожалуйста в вопросе №3 как я понимаю здесь применимо лишь функциональное тестирование? или например можно ответь что проверить также сами кнопки на правильное правонаписание? В вашем примере ответа на 3ий вопрос в конце каждой строки мы должны просто поставить passed или fail?

Вопрос в том есть ли какойнибудь шаблон набора тестов применимих в случаи вопросов насчет тестирование предметов, и как это разложить по полочкам чтобы протестировать в полном обэме и оставить довольным работника HR. Спасибо за предыдущие ответы

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

Тестить следует начинать с positive testing)

Они больше обращают внимание на твою логику, умение мыслить!

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

Спасибо за ответ. Скажите пожалуйста в вопросе №3 как я понимаю здесь применимо лишь функциональное тестирование? или например можно ответь что проверить также сами кнопки на правильное правонаписание? В вашем примере ответа на 3ий вопрос в конце каждой строки мы должны просто поставить passed или fail?

Нет, можно открыть это все в разных браузерах и ОС, проверить правильность надписей, проверить, как будет вести себя система при удалении строки, в которой очень много данных?

нет, не просто поставить pass или fail — это ж не тест, а только мысли о том, что я бы стал тестировать.

Спасибо за ответ. Скажите пожалуйста в вопросе №3 как я понимаю здесь применимо лишь функциональное тестирование? или например можно ответь что проверить также сами кнопки на правильное правонаписание? В вашем примере ответа на 3ий вопрос в конце каждой строки мы должны просто поставить passed или fail?

Нет, можно открыть это все в разных браузерах и ОС, проверить правильность надписей, проверить, как будет вести себя система при удалении строки, в которой очень много данных?

нет, не просто поставить pass или fail — это ж не тест, а только мысли о том, что я бы стал тестировать.

Ну вот например вы начинаете с пункта 1 своего примера
1) Кликнуть по кнопке EDIT, отредактировать поля, кликнуть SAVE, посмотреть, что данные обновились в соответствии с изменениями.
Как это задокументировать или вапще ненужно этого делать! или та строка и являеться полноценным документом ( это стало быть тест кейс?) и куда записать результат? Может и тупой вопрос, извините))

Ааа...еще я затупил на вопросе - приведите пример бага с critical severity and low priority. Это должен быть один баг!
Даже не подозреваю ( Думал что если баг критичен то приоритет должен быть по крайней мере не лоу ?

http://www.aphids.co...s_priority.html - тут есть примеры.

http://www.aphids.com/agiletesting/2009/08/defect_severity_vs_priority.html - тут есть примеры.

спасибо, полезно

Еще были как всегда вопросы о том как бы я тестировал кусок бумаги. Интересно мнение опытных людей или возможно самих рекрутеров- что в таких случаях будет правильным?
Я например спросил у интервюера есть ли у нас для теста какие нибудь requirement, ответ был отрицательным. Я сказал ей что начну с функцыонального тестирования, тоесть проверю можно ли на нем что то написать! Потом тестирую его usability тоесть например не скользит ли он на столе, удобно ли его держать. Вопрос в том есть ли какойнибудь шаблон набора тестов применимих в случаи вопросов насчет тестирование предметов, и как это разложить по полочкам чтобы протестировать в полном обэме и оставить довольным работника HR.

Сразу возник вопрос - почему Вы решили, что речь идет о листе офисной бумаги? Бумага может быть подарочной - совсем необязательно на ней писать, даже затруднительно, я бы сказала, на некоторых видах.. Бумага может быть туалетной - там тоже другие критерии будут. :) Мне кажется, работнику HR бы понравился разносторонний взгляд на вещи. Мыслим шире! :)
Насчет функционального тестирования, мне кажется, это основа, и основа правильная. Вот только нужно было не останавливаться на том, что нет требований, - если нету четких requirements, стоит выяснить хотя бы цель тестируемого объекта, зачем его вообще делают, кто будет пользоваться, и т.д. "Протестируй то, не знаю, что" [если нету СОВСЕМ ничего] - это пустая трата времени, за которое платит заказчик. Не знаю, одобрил бы такой ответ HR, но PM понять должен. Иногда "дешевле" выведать инфо и потом уже нормально тестировать. Опять же - мыслим шире. :)

Вопрос в том есть ли какойнибудь шаблон набора тестов применимих в случаи вопросов насчет тестирование предметов, и как это разложить по полочкам чтобы протестировать в полном обэме

Новичкам наверное можно начать например с RUP-овского шаблона тест-плана. Но тесты и сценарии придется придумывать самому.

...оставить довольным работника HR...

техническое интервью проводит HR?

Еще были как всегда вопросы о том как бы я тестировал кусок бумаги. Интересно мнение опытных людей или возможно самих рекрутеров- что в таких случаях будет правильным?
Я например спросил у интервюера есть ли у нас для теста какие нибудь requirement, ответ был отрицательным. Я сказал ей что начну с функцыонального тестирования, тоесть проверю можно ли на нем что то написать! Потом тестирую его usability тоесть например не скользит ли он на столе, удобно ли его держать. Вопрос в том есть ли какойнибудь шаблон набора тестов применимих в случаи вопросов насчет тестирование предметов, и как это разложить по полочкам чтобы протестировать в полном обэме и оставить довольным работника HR. Спасибо за предыдущие ответы

Как вариант )

1. Suppose that you find some scenarios that are not covered in the requirements( for example the new feature interacts with other existent components). Which are the steps that you take?
2. Suppose that we have the next scenario: in a program the actual result doesn't match the expected result, what should you do?
3. Suppose that you have to test a table on a web application and the last column contains two actions: edit and delete. How do you test it?

Собеседование я непрошол, но хочу разобраться
Со вторым понятно нужно рапортировать баг, а остальные что ? Кто умнее подскажите пожалуйста

У нас в проекте постоянно такие ситуации случаются, поэтому вброшу свои 5 копеек ;-)
1. Спросить у девелопера\менеджера.
2. Спросить у девелопера\менеджера.
3. В первую очередь, надо подготовить то, что потом будете редактировать и удалять, то есть, тестовые данные. То есть, надо забить таблицу строчками.

Такого рода краткие ответы устраивали потенциального работодателя или ему нужно было развернуто?