5 уровней невежества.

Совсем недавно наткнулся в сети на замечательную писанину гражданина Phillip G. Armour - The Five Orders of Ignorance
В pdf'ке гражданин предлагает нам рассмотреть разработку софта не как процесс производства продукта, а как процесс получения знания. Рассуждения почему это так я пропущу и сразу перейду к мякотке.

Kinda перевод (довольно вольный, так что на эту тему предлагаю не холиворить):

Основываясь на том что мы знаем и том что мы не знаем, мы можем разбить наше невежество на несколько слоев. Их я называю "Пять Уровней Невежества". Они могут серьезно помочь нам понять что же нужно чтобы уменьшить наше невежество и построить систему которая работает. Также они помогают объяснить некоторые артефакты среды разработки и наше поведение в процессе работы в ней.


0-й Уровень Невежества (0OI) - Отсутствие Невежества.
0OI это когда я знаю что-то и могу продемонстрировать отсутствие невежества в какой-нибудь осязаемой форме, например написав систему которая устраивает пользователя. Например если я уже много лет занимаюсь парусным спортом, то у меня 0OI о всякой деятельности связанной с ним и это можно легко проверить предоставив мне, скажем, судно и озеро.



1-й Уровень Невежества (1OI) - Отсутствие Знания.
1OI это когда я не знаю чего-то и могу легко определить этот факт. 1OI это самое простое невежество. Например я не умею говорить по-Русски, но при этом я могу легко устранить этот недостаток начав посещать уроки языка, читать книги, слушать правильные аудиокассеты и/или просто переехав в Россию на длительное время.



2-й Уровень Невежества (2OI) - Отсутствие Осведомленности.
2OI это когда я не знаю что я не знаю что-то. То есть это не только когда я не знаю что-то (например 1OI), но ко всему еще и совершенно не имею понятия об этом факте. Мне не достает знаний чтобы понять что мне не достает каких-то знаний. Например я не знаю хорошего примера 2OI (конечно же).



3-й Уровень Невежества (3OI) - Отсутствие Процесса.
3OI это когда я не знаю достаточно хорошего способа понять что я не знаю что я чего-то не знаю. Это отсутствие процесса и это представляется мне довольно серьезной проблемой: если у меня 3OI, то я не знаю как обнаружить вещи про которые я даже не знаю что я о них не знаю. Следовательно я не могу сделать так чтобы эти вещи о которых я не знаю что я о них не знаю стали вещами о которых я знаю или стали вещами о которых я не знаю, так как знание о том что я не знаю о какой-то вещи можно превратить в знание об этой вещи. Для разработки систем стоит еще добавить слова "достаточно эффективный", поскольку тут всегда есть 3OI процесс: взять и построить систему. И с этого момента пользователь уже может сообщить мне что есть какие-то вещи о которых я не знаю.



4-й Уровень Невежества (4OI) - Мета-Невежество.
4OI это когда я не знаю о Пяти Уровнях Невежества. У меня теперь нет этого невежества так же как и у тебя, читатель.




Дальше автор пускается в рассуждения о том как теперь с этим жить и что наиболее серьезными проблемами являются 3OI и 2OI и что они и жрут большую часть времени в процессе разработки.

Тут мы остановимся и переключимся на тестирование.

Тестирование во многих своих ипостасях так же является процессом устранения невежества. Точнее обретения знания. При этом практически всегда мы знаем о своем неведении ("в софте всегда есть баги" (с)). Это мета-знание об абстракциях. Другими словами практически изначально удаленный (еще до чтения вышеприведенной) статьи 4OI. При этом в отличии от разработки софта нет по умолчанию даже неэффективного процесса для 3OI. Другими словами даже обсуждая сферических коней в вакууме согласно уже устоявшейся теории в области тестирования нет процесса способного побороть все наше невежество. Нет, это совсем не значит что не стоит даже и пытаться. Есть в конце-концов уже готовые процессы поиска потенциально проблемных мест и так далее. Но не стоит зацикливаться уже на существующих процессах, поскольку в данном случае мы хоть и устраним наше невежество хотя бы частично, но еще и откажем себе в шансе устранить его в куда больших объемах. И если следовать положениям "software testing as service", то мы вместо того чтобы сделать работу очень хорошо, сделаем ее в лучшем случае просто хорошо.

Кто-нибудь конечно может вспомнить про exploratory testing и заявить что этот весьма аморфный процесс необходим и достаточен, но так ли это? Достаточно ли он эффективен? Нет ли способов лучше? И не вырождается ли у вас идея exploratory testing так же как люди порой способны делать монстров канонов из разных процессов порожденных как отклик на agile manifesto?