Roman Klochkov

Так вот, оптимизация тестов (ужимание, выкидывание ненужных, рефакторинг) — это характерные признаки наличия элементов exporatory.

Исходя из моего опыта не обязательно так.

Вот у нас есть строго обратный пример - есть несколько комплектов тестов, проверяющих соблюдение требований платформы (playstation). Любой проект должен соответствовать, так что выполняем мы их регулярно. За несколько лет использования и апдейтов эти тесты стали оптимальны с точки зрения "ужимание, выкидывание ненужных, рефакторинг". Но врядли стали близки к exploratory ;-)

Мне статья понравилась, посыл верный. Обилие воды (комментариев, деталей, уточнений) может сильно испортить тест и затруднить работу.

Предположения, что

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

конечно хорошие, и опытный тестировщик обязан так делать...

но идея, что признак хорошего тестировщика -

он не станет выполнять инструкцию шаг за шагом

меня пугает )

да, обладая экспертизой в продукте и среде я могу "скипнуть" часть теста или проверить утверждение чуть отличным образом, чем предписывает тест. Но даже обладая обоими экспертизами (продукта и среды) я рискну сделать это ТОЛЬКО со своим тестом. Сколько бы времени я не потратил на

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

без общения с автором теста я не рискну что-либо менять (исключение - я уверен низком качестве теста)

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

сначала история )
скинул сегодня с утра в студийную qa-рассылку -

рекомендую к прочтению статьб Баранцева "Меньше слов — больше смысла" о "кошерных" тестах.
Общий посыл  - "Вычистив всю «вату», вы получите то, что я называю «направляющими тестами», то есть нечто вроде чек-листа, который направляет 
действия тестировщика, а не руководящий документ, который управляет его действиями."

Это сильно расходится с принятой у нас  точкой зрения -" тест должен быть полным, детальным и гарантировать обнаружение ошибок"

Буду рад услышать аргументы в защиту вариантов
- он абсолютно прав, а мы тупили
- он не шарит
- и мы, и он правы

первое место занял ответ -

А я вот не вижу никакого расхождения.
Мы уже давно применяем подход "кртк сстр тлт" в части своих тестов.

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

Есть тесты схематичные (пример - общепроектный тест на чужой/поврежденный сейв). Дадим мы такой тест новому неопытному человеку? Нет. 
Есть смысл дорабатывать его до состояния "любой взял, понял и сделал"? Я не вижу такого смысла, это слишком затратно. 
Мы даем этот тест опытному тестировщику, он делает все как надо и попутно обнаруживает баги, 
обращая внимание на что-то не описанное прямо в тесте (но любой натасканный боец это просто обязан заметить).

Весь вопрос в целевой аудитории каждого конкретного теста.

А, да. Было в комментариях (слава богу, это не автор поста додумался до светлой мысли) вопиющее: "Я предпочёл бы написать просто: 
«проверить сохранение в файл там-то». Хороший думающий тестировщик проверит при этом: 
как ведёт себя программа при отмене диалога, при записи файла с тем же именем, при записи на защищённый от записи или заполненный диск,
 и т.д. и т.п." Вот ТАКОЙ подход нам не нужен. Надеюсь, не докатимся.

Юля

Теперь сижу и горжусь отделом ))