Алексеи сегодня в ударе )

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

Алексей очень верно про диалектику подметил. Формализация таких определений описывает их слишком односторонне (

Ну это если я верно интерпретировал отсылку к Гегелю)))

Вы можете сразу и придумывать кейсы, и выполнять их, и записывать?

Конечно

Вот это и есть эксплоратори.

обычно сразу у опытных тестировщиков это не получается ВООБЩЕ. Или мы пишем тесты «чтобы их в будущем прогонять», или мы берем тесты, которые «были написаны ранее». Если взяться и за их придумывание/записывание, и за их выполнение, то будет ступор.

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

основная причина этого ступора — не получается писать тест-кейсы быстро.

Там должны быть три колонки, там должны быть предусловия, там леший бродит…

есть решение — перестать писать тесты в классическом их представлении. Можно записывать тесты быстро, оставляя от них одни только заголовки.

если с этим решением поэкспериментировать, то всё будет нормально. Оказывается, можно одновременно и придумывать, и записывать, и выполнять, и если баги есть — записывать их.

если спасовать и решить, что нее, это разные вещи, давайте их не смешивать, то на этом всё.

Куда-то мы не в ту степь ушли)) я тут со всем согласный. Изначально речь шла о том, что сценарное тестирование - это когда уже есть документ, по которому тестишь. Эскплоратори - когда тесты придумываешь в процессе. Записываешь ты их в это время, или нет, вопрос уже третий

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

Об этом я и говорил.

а если меня не остановить, то я могу ещё доказать, что и Ad hoc testing тоже не подразумевает отсутствие требований и тест-кейсов, как это обычно преподносится, и очень даже в них нуждается. Но для этого будет нужна лекция минут на 30-40, поэтому меня уже надо остановить.

Коллеги вопрос: а кто-нибудь реально этим пользуется в работе, вот этими книжными выкладками? Обычно ведь как - вот тебе описание фичи, проверил как понял, написал ТК по необходимости. Залез в код проекта - глянул что делали, оценил что может быть задето. Провел регресс в зависимости от этого. Всё, и так в 95% случаев

Хорошо, аргумент. Мне всегда приходится так работать в силу постоянной нехватки ресурсов, гигантского количества взаимодействий внутри системы и стремящемуся к бесконечности количеству возможных пользовательских сценариев. У нас сломано буквально всё, что мы не успели проверить в билде и это не преувеличение))

Чем лучше вы понимаете эти «книжные выкладки», тем лучше вы тестируете. Все просто

в юности — да, всё так, минимум вопросов, максимум рвения. Потом переделывать. Или объяснять, почему программист понял одно, мы протестировали что-то другое, а заказчик хотел третье.

Чем старше, тем — нет. Сразу много вопросов. Сразу "А вы уверены в том, что это надо именно так?" Это одна из причин того, почему со взрослыми тестировщиками  сложно работать и их молодым коллегам, и менеджерам, и вообще в условиях "У нас тут аджайл, заткнись и работай".

Ну лично я иду от кода. Например, если релиз состоит из коммитов вроде 'поменяли текстовку в мобильном приложении' и 'добавили на бэке такой-то эндпойнт', при этом я в состоянии понять что ничего при этом сломаться не могло