KR
И начать создавать тестовую документацию. Хз, это темный лес для меня тоже
Может сначала надо поговорить с руководством, чего они хотят видеть от тестирования. Пообщаться с представителями заказчика..
Если уж не то, что Вы сказали
Size: a a a
2020 October 29
AP
Заказчик хочет тестирования)
KR
Заказчик хочет тестирования)
В умных книгах просто читал, что у них можно узнавать критерии начала и окончания тестирования, и всякие другие..
АБ
Я могу только посоветовать записаться на курсы по тестированию от Шуу и всего за 59 990 вы научитесь (или нет) решать такие проблемы.
линк
AP
Я могу только посоветовать записаться на курсы по тестированию от Шуу и всего за 59 990 вы научитесь (или нет) решать такие проблемы.
Потом на собесе посоветовали яндекс практикум)) потому что 90% заказчиков не дают требования
NB
ну документацию могли и не оплатить ( ͡° ͜ʖ ͡°)
KR
Потом на собесе посоветовали яндекс практикум)) потому что 90% заказчиков не дают требования
А че не лернкуа
AG
линк
Ты забанен по айпи, извини.
AG
Потом на собесе посоветовали яндекс практикум)) потому что 90% заказчиков не дают требования
Ну, не знаю, чем поможет яндекс.практикум в данном контексте, но вообще да, большинству заказчиков не особенно интересно давать вам требования.
Они хотят дать денег и что б им хорошо сделали.
Они хотят дать денег и что б им хорошо сделали.
SO
даже больше скажу, у нас проект существует 25 лет, и от начала вообще не писали тест кейсы, сейчас иногда пишем, но чек-листы...так что вот так
SO
и-то эти чек-листы стали писать недавно)
AG
Ну, вообще, тут несколько моментов.
1. Понимание того, как работает приложение (и продукт) для того, что бы можно было нормально приоритизировать тестирование.
Тут помогает и общение с заказчиков (и "узнать, что важно для бинеса" не то, что бы тоже самое "запросить требования у заказчика").
2. Понимание того, что болит у команды и где сейчас больше всего проблем.
Здесь помогает анализ бэклога багов, общение с командой + базовая экспертиза.
3. Понимание того, какие действия сейчас дадут максимальный результат при минимальных усилиях.
Проще говоря, прежде чем делать, задаваться вопросами "а зачем?", "какую проблему это решит?" и "стоит ли решение этой проблемы тех сил, которые мы потратим?".
Помимо этого есть уже перечисленные выше "а зачем вообще ребята наняли тестировщика?" и т.д. и т.п.
Ну а дальше, по мере появления ответов на вопросы выше - предлагаешь решения, если всех устраивает - фигачишь, если нет - предлагаешь другое.
1. Понимание того, как работает приложение (и продукт) для того, что бы можно было нормально приоритизировать тестирование.
Тут помогает и общение с заказчиков (и "узнать, что важно для бинеса" не то, что бы тоже самое "запросить требования у заказчика").
2. Понимание того, что болит у команды и где сейчас больше всего проблем.
Здесь помогает анализ бэклога багов, общение с командой + базовая экспертиза.
3. Понимание того, какие действия сейчас дадут максимальный результат при минимальных усилиях.
Проще говоря, прежде чем делать, задаваться вопросами "а зачем?", "какую проблему это решит?" и "стоит ли решение этой проблемы тех сил, которые мы потратим?".
Помимо этого есть уже перечисленные выше "а зачем вообще ребята наняли тестировщика?" и т.д. и т.п.
Ну а дальше, по мере появления ответов на вопросы выше - предлагаешь решения, если всех устраивает - фигачишь, если нет - предлагаешь другое.
AP
Спасиб, а по вопросу сколько кейсов нужно делать на требование? Смотря, что нужно заказчику? Нужно, чтобы работало приложение
L
Спасиб, а по вопросу сколько кейсов нужно делать на требование? Смотря, что нужно заказчику? Нужно, чтобы работало приложение
Чтобы было нужное покрытие
L
Столько и кейсов
L
Это вам не 20 буханок хлеба испечь и не 200 строк кода написать
L
Покрытие и выход из тестирования прописываются в тест-плане
AP
Я просто не понял, какой именно ответ требуется в рамках собеседования на джуна
L
.