aid

Всем привет! Интересует ваше мнение касательно способа решения тестовой задачи.

 

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

•  Поля ввода "Введите время";
•  Поля вывода в виде циферблата аналоговых часов;
•  Кнопка "Показать"
•  Кнопка "Закрыть"

Принцип работы программы заключается во введении времени в 24-часовом формате и нажатии на кнопку "Показать".

Нужно:
Протестировать программу (имитировать работу пользователя) на работоспособность минимальным(!) количеством проверок. Результат предоставить в виде тест-кейсов.

 

Слово "минимальным" заставило меня задуматься - стоит ли описывать случаи негативного тестирования, или просто сформулировать все в одном позитивном тест кейсе? Например:

 

Имя тест-кейса: "Ввод данных в форму "Введите время"".
Шаги: Ввести поочередно значения времени в 24-часовом формате ЧЧ:ММ, где ЧЧ - значения от 00 до 24, где ММ - значения от 00 до 59. После каждого ввода пары значений нажимать на кнопку "Показать".
Ожидаемый результат: стрелки часов и минут должны занимать соответствующую своим значениям позицию на циферблате.

 

 

И вообще - можно ли как-то упростить этап ввода такого большого количества значений времени? Как выглядел бы ваш вариант?

Подсказка - классы эквивалентности.

"С теорией проблем особых не вижу" я вам посоветую, не обольщайтесь. Только на собеседовании реально увидите, что с теорией проблемы.

У вас немного не та шкала, тёплое с мягким. Вы смешали позицию менеджера и условное ранжирование по технической компетентности. А не все люди в силу разных причин подходят для роли организатора. 

Только не бейте:

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

 

 

В это случаи мне кажется, это должно решаться не на уровне тестировщика, а на уровне того кто нанял этого тестировщика.

 

Простите великодушно, а что решит уровень, который нанял тестировщика? И о каком в данном случае уровне речь? Директор? QA Lead? 

 

Решить в какой форме взаимодействовать с разработчиками; нужно ли их дрессировать и если нужно, то как это делать.

Решает, тот, у кого волшебная кнопка "оставить без денег".

 

Руководство видит проблему. А как её решать, это не совсем их уровень. Требования должны быть выполнены. А скупой баг-репорт это метод, благодаря которому, мы скрываем важную информацию, которая нам может навредить, так как мы не можем полагаться на порядочность чужих разработчиков.

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

Так вот, сделал вывод, что на кандидатов без техобразования на техпозиции - это в основном тратить время.

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