⚡️ Техники тестирования - не "техники тестирования".

Какое-то время назад (год или два) мимо меня пробежал пост на LinkedIn авторства, кажется, Джеймса Баха. Автор писал: техники тестирования - никакие не “техники” и не “тестирования”.

Я прочитала, пожала плечами и пошла дальше (идею, тем не менее, запомнила).

…Угадайте, до кого сегодня дошло, что хотел сказать автор.

Причем дошло в процессе объяснений другим людям. Видимо, потому, что я обычно не думаю о техниках тестирования. Я смотрю на контекст и придумаваю, что как тестировать, опираясь на этот контекст. То есть в моей голове это работает как “нужно сделать вот так, потому что… чтобы…”, а не “вот тут я применю state transition”.

Так вот. Я посмотрела на свои объяснения и увидела, что я сама же объясняю техники НЕ как способ что-то протестировать, а как что-то другое.

Например, decision table: способ декомпозировать требование на сценарии.

Или state transition: способ визуализировать логику системы с фокусом на какой-то объект, его состояния и переходы между этими состояниями.

То есть это организация знаний в структуру, чтобы на основе этой структуры уже можно было нагенерить идеи, касающиеся тестирования.
Это не “техники тестирования”, это способы посмотреть на систему и/или требование под разными углами, чтобы придумать, как тестировать систему (или делать что угодно другое, ради чего мы эти знания собирали).
Это точно такие же “техники тестирования”, как иерархические списки или таблички, где мы организуем информацию любым удобным для нас способом.

Полезно ли это?
Точно да.
Стоит ли называть это “техниками тестирования”?

Не уверена.

С каким-то приближением можно назвать техниками тестирования boundary value analysis / equivalence partitioning и pairwise testing, но...

BVA / EP это частный случай risk-based тестирования. То есть у нас существует 100500 разных рисков, и некоторые из можно покрыть с помощью BVA / EP, причем тут важно помнить, что эти техники основываются на предположениях. В процессе применения техник их еще надо основательно почелленджить.
Возникает, конечно, вопрос: почему один из вариантов risk-based тестирования так важен, что удостоился названия отдельной “техники тестирования”? Подозреваю, что только потому, что основную идею можно объяснить новичкам на пальцах:)

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

Не пора ли нам вместо "техник тестирования" придумать уже наконец что-то другое?

Exploratory testing тут является хорошей альтернативой (не знаю пока альтернативы лучше, если честно), но, кажется, под exploratory testing в широких массах часто понимают что-то совсем простое а ля "побродить по приложению без явной цели", а про разработку гипотез и постановку экспериментов для их проверки как-то забывают.

Возможно, нужно говорить про это чаще (и больше).