Тестирование ПО (Тестировщик, QA инженер)

AlexMV:

Объясните мне, я наверное не понимаю
Есть вендинговая машина, нужно протестировать монетоприёмник, но в наличии есть только бумажная
Она же не примет бумажные деньги? И монет нет. Если бы были монеты, то вперед, но монет то нет?

Я бы обозвал это как-нибудь типа Подготовительные работы и добавил туда ваше

AlexMV:

До начала сходить разменять на монеты

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

DeathInfector, такие задания даются для проверки теоретической базы знаний. Решения у задачи нет. Можно изгаляться как угодно проверяя разные уровни и так далее. Это гораздо веселее чем карандаш или ручка, так как более вариативно.

Real-sasha:

алее расспросить про принцип его работы у заказчика (т.е. рекрута)

и в "плечи" прилетит вопрос: "А вот нет спецификации. Что будете делать?" =)

DeathInfector:

Если уже совсем ничего нет, то тестировать, основываясь на здравом смысле.

Так себе вариант. Тестирование как процесс в части разработки и взаимодействия с кастомерами-- штука весьма сложная и вариант вида "я художник, я так вижу" не всегда прокатывает. Имхо, если нет документации, описания, нет аналитиков, нет ПМов и т.п., то тестировщику открывается прямая дорога к кастомеру либо десижн мейкеру на стороне кастомера. Спрашивать нужно всегда.

Под словами

DeathInfector:

Искать описание фич

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

anisimau:

Так себе вариант.

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

anisimau:

DeathInfector:

из "не тестировать вообще" или "тестировать как-нибудь" я бы выбрал второй вариант.

и по каким критериям будете определять баг/не баг? =)

DeathInfector:

основываясь на здравом смысле.

Если новая пила не пилит, то скорее всего это баг.
Если новая пила пилит, но через 30 минут забивается опилками и перестает работать, то возможно, это не баг (и на самом деле не баг, когда делали пилу, то требовалось 15 минут непрерывной работы до очистки).

Если новая пила пилит, но не обрабатывает поверхность лаком, то возможно, это не баг (а на самом деле баг, так как это требовалось, когда делали пилу)

Но опять же, это все абсолютно вымышленная ситуация, и все зависит от тестируемого объекта/продукта и т.д.
Я сейчас могу выдумать миллион ситуаций, когда мой подход будет работать, а вы мне в ответ миллион одну, когда нет.

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

anisimau:

Спрашивать нужно всегда.

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

AlexMV:

Помогите пожалуйста с опытом работы

Могу помочь советом: тыц

Ivan Igorevich:

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

Я не совсем согласен

простой пример:
какой формат дат в филдах для вас, при тестировании на основе здравого смысла, будет наиболее приемлемым для вас:
1. mm/dd/yyyy
2. dd/mm/yyyy

anisimau:

Я не совсем согласен

простой пример:
какой формат дат в филдах для вас, при тестировании на основе здравого смысла, будет наиболее приемлемым для вас:
1. mm/dd/yyyy
2. dd/mm/yyyy

А если при этом сверху написано маленьким серым шрифтом (в формате mm/dd/yyyy)?
И при этом все даты в приложении в формате mm/dd/yyyy ?

DeathInfector:

anisimau:

Я не совсем согласен

простой пример:
какой формат дат в филдах для вас, при тестировании на основе здравого смысла, будет наиболее приемлемым для вас:
1. mm/dd/yyyy
2. dd/mm/yyyy

А если при этом сверху написано маленьким серым шрифтом (в формате mm/dd/yyyy)?
И при этом все даты в приложении в формате mm/dd/yyyy ?

3. dd/mmm/yyyy
да и если это нормальный дэв - он готовое решение возьмёт (протестированное 100К юзерами)
а не будет свои велосипеды городить

https://material.angularjs.org/latest/demo/datepicker