Важная причина плохого тестирования программных продуктов заключается в том, что большинство специалистов отталкивается от ложного определения этого термина. Они могут сказать:
— тестирование – это процесс для демонстрации того, что в программе нет ошибок;
— цель тестирования в том, чтобы показать, что программа выполняет ожидаемые от нее действия корректным образом;
— тестирование – это процесс, направленный на создание уверенности, что программа делает то, что должна.
Эти определения неверны.
Вот вам дедуктивное умозаключение:
Вписываясь в тестирование, мы желаем добавить продукту значимость (ценность) –
Добавление ценности продукту происходит за счет увеличения качества и надежности продукта –
Добавление надежности продукта происходит путем поиска и удаления ошибок.
Поэтому не занимайтесь тестированием. Не занимайтесь тестированием для того, чтобы показать, что все работает; начните с аксиомы – программа содержит ошибки (кстати, это верно для большинства программ), и далее тестируйте так, чтобы найти их столько, сколько это вообще возможно, будто это Ваш последний день (в тестировании).
А вот определение получше:
Тестирование – процесс работы с программой со стойким намерением найти ошибки.
И хотя это может звучать, как некая игра тонких семантический материй, здесь есть действительно важная составляющая. Понимание истинного (они правда сказали это слово? – прим. переводчика) определения процесса тестирования может глубоким образом повлиять на успех в Ваших усилиях.
Люди – существа, для которых важна ориентация на определенные цели, и установка таковых имеет важное психологическое значение. Если наша цель – показать, что продукт не имеет ошибок, мы будет неосознанно стремится к этой цели; отсюда, наши действия будут такими, которые будут снижать вероятность возникновения сбоев. На другой руке (я же правильно перевел? – прим. меня), если Ваша цель – продемонстрировать, что программа содержит ошибки, Ваши тесты будут более успешны в поиске последних. Такой подход добавит большей ценности продукту, нежели предыдущий.
Такое определение включает в себя множество аспектов. Например, оно подразумевает некую разрушительную, садистскую природу тестирования. Что может противоречить нашим жизненным взглядам: ведь большинство из нас любят больше создавать, нежели разрушать. Большинство людей склонны к созданию объектов, но не к их разрушению. Такое определение также включает в себя установку для тест-дизайна и установку на то, кому бы следовало заниматься тестированием, а кому — нет.
Другим способом ухватить определение тестирования должным образом выступает анализ использования слов «успешный» и «безуспешный» — в частности, их применение к результатам прохождения тестовый случаев. Большинство управленцев воспринимают тесты, которые не выявили ошибок, как «успешно пройденные», а те, которые обнаруживают ошибки обычно называются «безуспешными».
И снова это перевертыш. «Безуспешны» обозначает нечто нежеланное или разочаровывающее. Согласно нашему представлению, тест с хорошим дизайном, хорошо выполненный, является успешным, если он помог найти ошибку, которая может быть исправлена. Этот же тест мы также называем успешным, если в конечном итоге он сообщает, что ошибок, которые можно найти, ни осталось. Единственный случай, когда тест можно назвать безуспешным, — если он не может должным образом исследовать Систему. И в большинстве случаев, вероятно, так и происходит, поскольку концепция ПО без ошибок принципиально нереалистична.
Как можно назвать тест, который нашел новую ошибку, безуспешным? Ведь он предоставил инвестиции в ценность продукта. А вот тест, который выполняет программу с корректными результатами без найденных ошибок – можно назвать безуспешным.
Рассмотрим аналогию с визитом к врачу по причине общего недомогания. Если доктор начнет делать какие-либо лабораторные исследования, которые не обнаружат проблему, мы не назовем их успешными; они неудачны, поскольку кошелек пациента, а он все еще болен. Возникают вопросы по поводу квалификации врача. И наоборот, тесты успешны, если они диагностировали язву, и врач может начать лечение. Похоже в медицинской профессии эти слова используются в правильном русле. Аналогия в том, что нам следует воспринимать программный продукт, как если бы он был больным пациентом.
Еще одна проблема с определение тестирования, как «процесса демонстрации того, что ошибок в программе нет» в том, что эта цель недостижима практически для всех, даже простеньких программ.
Повторим, результаты психологических исследований говорят, что человек малоэффективен, когда его установка на решение задачи содержит предусловия нецелесообразности или невозможности. К примеру, если у Вас есть задание решить сложную головоломку за 15 минут, Ваш успех через десять минут будет небольшим, поскольку Вы, если Вы похожи на большинство людей, уже скоро сделаете вывод, что выполнить поставленное задание невозможно. Если же решение нужно в течение четырех часов, мы можем ожидать, что успехов в первые десять минут будет больше. Если рассматривать процесс тестирования как процесс выявления наличествующих ошибок, это выполнимая задача, что позволяет справится с указанной психологической проблемой.
Проблема с определением тестирования как «процесса демонстрации того, что программа делает то, что должна» в том, что программа, выполняющая это условие, все еще содержит ошибки. Другими словами, ошибка есть в программе, которая не делает то, что должна – это очевидно. Но ошибки присутствуют и в программе, которая делает то, что не должна делать. Мы, вероятно, добьемся большего успеха, рассматривая процесс тестирования, как процесс поиска ошибок, нежели как процесс, целью которого является показ, что программа делает то, что должна.
Заключая, правильно рассматривать тестирование ПО как разрушительный процесс, состоящий из попыток найти ошибки, наличие которых предполагается. Удача в том, чтобы привести приложение к сбою, а «синий экран смерти» – высшая точка. Да, мы хотим добиться в процессе тестирования установки определенной степени доверия, что программа делает то, для чего она была создана и не делает ничего другого. Ошибки же могут стать отличным проводником к этой цели.
Представьте, что некто утверждает, что его программа идеальна, то есть не содержит ошибок. Самый лучший способ проверить правдивость этого утверждения – попытаться это опровергнуть. Другими словами, следует попытаться найти недостатки с большим желанием, нежели согласится, что программа работает корректно для определенного набора данных.
Автор: RockMachine
