Я не силён в этих ваших тестировщицких терминах и в моей голове нету особой разницы между ad-hoc, свободным поиском, исследовательским тестированием и прочими штуками.
Поэтому давать определение я бы, наверное, не стал, это лучше сертифицированным тест-джедаям делать.

Касательно пользы:
При должном багаже знаний и понимании продукта (а так же принципов его работы, как с бизнесовой, так и с технической точки зрения) это хорошая история.
Просто потому, что тестовые наборы никогда не будут исчерпывающими, а некоторые вещи проще оставить на исследовательское тестирование, нежели пытаться формализовать в тест-кейсы.
Обратная сторона - субъективность и непрозрачность таких проверок.

спасибо за ответы

Почитайте статью, которую привел выше. Мсье Фаулер довольно подробно рассказывает про чудесную пирамиду тестирования, что как и зачем.

да да, уже в процессе, благодарю)

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

В итоге вместо пирамиды тестирования - две бетонные плиты лежат на кирпиче

Ну, это уж в ваших руках. :)

Это прекрасно

Ты чо, это IceCreamCone паттерн.

@arsbatyrov а тебе есть что об этом сказать?)

Мне интересно конкретно практикуется ли у вас на проектах такое, если да - то когда и с какой целью?

Ну и приоритеты.

У нас практикуется, когда пришел новичок и ему нужно вникнуть что вообще за проект и что он делает

Ребята, привет!

Тут есть такие кто пришел на проект единственным тестировщиком и выстраивал процесс тестирования с нуля?

оч громко

лучше сразу с вопроса начинать, тут всякие сидят

лучше сразу вопрос конкретный писать

Да.

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

уши заложило?)))