— тестирование – это процесс для демонстрации того, что в программе нет ошибок;
— цель тестирования в том, чтобы показать, что программа выполняет ожидаемые от нее действия корректным образом;
— тестирование – это процесс, направленный на создание уверенности, что программа делает то, что должна.
Эти определения неверны.
Вот вам дедуктивное умозаключение:
Вписываясь в тестирование, мы желаем добавить продукту значимость (ценность) –
Добавление ценности продукту происходит за счет увеличения качества и надежности продукта –
Добавление надежности продукта происходит путем поиска и удаления ошибок.
Поэтому не занимайтесь тестированием. Не занимайтесь тестированием для того, чтобы показать, что все работает; начните с аксиомы – программа содержит ошибки (кстати, это верно для большинства программ), и далее тестируйте так, чтобы найти их столько, сколько это вообще возможно, будто это Ваш последний день (в тестировании).
А вот определение получше:
Тестирование – процесс работы с программой со стойким намерением найти ошибки. И хотя это может звучать, как некая игра тонких семантический материй, здесь есть действительно важная составляющая. Понимание истинного (они правда сказали это слово? – прим. переводчика) определения процесса тестирования может глубоким образом повлиять на успех в Ваших усилиях.
Люди – существа, для которых важна ориентация на определенные цели, и установка таковых имеет важное психологическое значение. Если наша цель – показать, что продукт не имеет ошибок, мы будет неосознанно стремится к этой цели; отсюда, наши действия будут такими, которые будут снижать вероятность возникновения сбоев. На другой руке (я же правильно перевел? – прим. меня), если Ваша цель – продемонстрировать, что программа содержит ошибки, Ваши тесты будут более успешны в поиске последних. Такой подход добавит большей ценности продукту, нежели предыдущий.
Такое определение включает в себя множество аспектов. Например, оно подразумевает некую разрушительную, садистскую природу тестирования. Что может противоречить нашим жизненным взглядам: ведь большинство из нас любят больше создавать, нежели разрушать. Большинство людей склонны к созданию объектов, но не к их разрушению. Такое определение также включает в себя установку для тест-дизайна и установку на то, кому бы следовало заниматься тестированием, а кому — нет.
Другим способом ухватить определение тестирования должным образом выступает анализ использования слов «успешный» и «безуспешный» — в частности, их применение к результатам прохождения тестовый случаев. Большинство управленцев воспринимают тесты, которые не выявили ошибок, как «успешно пройденные», а те, которые обнаруживают ошибки обычно называются «безуспешными».
И снова это перевертыш. «Безуспешны» обозначает нечто нежеланное или разочаровывающее. Согласно нашему представлению, тест с хорошим дизайном, хорошо выполненный, является успешным, если он помог найти ошибку, которая может быть исправлена. Этот же тест мы также называем успешным, если в конечном итоге он сообщает, что ошибок, которые можно найти, ни осталось. Единственный случай, когда тест можно назвать безуспешным, — если он не может должным образом исследовать Систему. И в большинстве случаев, вероятно, так и происходит, поскольку концепция ПО без ошибок принципиально нереалистична.
Как можно назвать тест, который нашел новую ошибку, безуспешным? Ведь он предоставил инвестиции в ценность продукта. А вот тест, который выполняет программу с корректными результатами без найденных ошибок – можно назвать безуспешным.
Рассмотрим аналогию с визитом к врачу по причине общего недомогания. Если доктор начнет делать какие-либо лабораторные исследования, которые не обнаружат проблему, мы не назовем их успешными; они неудачны, поскольку кошелек пациента опустел, а он все еще болен. Возникают вопросы по поводу квалификации врача. И наоборот, тесты успешны, если они диагностировали язву, и врач может начать лечение. Похоже в медицинской профессии эти слова используются в правильном русле. Аналогия в том, что нам следует воспринимать программный продукт, как если бы он был больным пациентом.
Еще одна проблема с определение тестирования, как «процесса демонстрации того, что ошибок в программе нет» в том, что эта цель недостижима практически для всех, даже простеньких программ.
Повторим, результаты психологических исследований говорят, что человек малоэффективен, когда его установка на решение задачи содержит предусловия нецелесообразности или невозможности. К примеру, если у Вас есть задание решить сложную головоломку за 15 минут, Ваш успех через десять минут будет небольшим, поскольку Вы, если Вы похожи на большинство людей, уже скоро сделаете вывод, что выполнить поставленное задание невозможно. Если же решение нужно в течение четырех часов, мы можем ожидать, что успехов в первые десять минут будет больше. Если рассматривать процесс тестирования как процесс выявления наличествующих ошибок, это выполнимая задача, что позволяет справится с указанной психологической проблемой.
Проблема с определением тестирования как «процесса демонстрации того, что программа делает то, что должна» в том, что программа, выполняющая это условие, все еще содержит ошибки. Другими словами, ошибка есть в программе, которая не делает то, что должна – это очевидно. Но ошибки присутствуют и в программе, которая делает то, что не должна делать. Мы, вероятно, добьемся большего успеха, рассматривая процесс тестирования, как процесс поиска ошибок, нежели как процесс, целью которого является показ, что программа делает то, что должна.
Заключая, правильно рассматривать тестирование ПО как разрушительный процесс, состоящий из попыток найти ошибки, наличие которых предполагается. Удача в том, чтобы привести приложение к сбою, а «синий экран смерти» – высшая точка. Да, мы хотим добиться в процессе тестирования установки определенной степени доверия, что программа делает то, для чего она была создана и не делает ничего другого. Ошибки же могут стать отличным проводником к этой цели.
Представьте, что некто утверждает, что его программа идеальна, то есть не содержит ошибок. Самый лучший способ проверить правдивость этого утверждения – попытаться это опровергнуть. Другими словами, следует попытаться найти недостатки с большим желанием, нежели согласится, что программа работает корректно для определенного набора данных.
Комментарии (13)
Sh1k4r1
01.06.2017 10:39п.1 В коде всегда есть ошибки, а значит есть баги
п.2 Если багов и ошибок не найдено — смотреть п.1
icWasya
01.06.2017 11:551) Любой программист, посмотрев на чужой код, найдёт в нём, как минимум, три ошибки.
2) Ошибкам не всё равно, кто их ищет.
lxsmkv
02.06.2017 03:34Я никогда не ставлю себе прямую задачу найти ошибку. Иногда меня просят потестировать какой-то кусок программы, и я знаю какую последовательность действий выполнить чтобы увеличить вероятность выявления ошибки. Чтобы выявить ошибку, нужно понимать, как устроена программа внутренне, как взаимодействуют ее части. Это как тестировать спичечный домик. Можно его сжечь и сказать, что он не огнеустойчив, но это бесполезный тест, если он не является прямым требованием. Но то что спичечный домик можно сжечь ясно и без теста. А требовать от спичечного домика быть огнеустойчивым — безумие. С другой стороны, инженер, понимающий как он собран, будет искать места где неровно стоит спичка, так что зацепив ее можно развалить его полностью. Так вот в моем понимании, хороший тестировщик знает за какую ниточку стоит тянуть, а за какую не стоит. Ему не нужно рисовать матрицы эквивалентных классов, не нужно составлять комбинаторные таблицы. Они у него подвешены на интуиции, он проведет три теста, и скажет — все нормально или найдет проблему. И если он проблемы не выявит, это не значит что ее нет, это значит что за 20 % времени он проверил 80 % приложения. И такой тестировщик ценен. Он добивается приемлемого качества за короткий отрезок времени. Правильный тестировщик напишет очень много разных «тестов для карандаша», отличный тестировщик сделает два-три теста и скажет «окей» или нет. И в этом «окей» будет всё. Это будет уверенность в том, что оно действительно «окей». В свою оценку он вкладывает риск, обусловленный нецелесообразностью полного тестирования, и отвечает за этот риск. Мастер своего дела, не тот кто делает все по учебнику, а тот кто берет на себя обоснованные риски.
RockMachine
02.06.2017 11:40Кажется, я могу видеть такого сверхтест-инженера.
Несколько дополнений.
1. Вы переплетаете понятия «знания», «понимание», «интуиция» — на мой взгляд совершенно правильно. Эта смесь – важная составляющая тест-инженера. Хочу лишь призвать Вас не отбрасывать учебники. На каждую из этих тем есть достойная литература.
2. Таблицы и матрицы – не самоцель, а инструменты. Если они полезны, их можно использовать… даже если Вы чертовски хорош, чтобы выстраивать нечто подобное сразу у себя в голове.
3. Полного тестирования, говорят, не существует.
4. Надеюсь, что правильный и отличный не исключают друг друга, а второй идет за первым.lxsmkv
02.06.2017 18:39Спасибо за дополнение, а то мой комментарий прозвучал немного бескомпромиссно.
Мой «кумир» из-за которого я вообще пошел в профессию — James Bach. Послушав его лекции, сложилась картина, что можно стать «ниньзя-тестировщиком» (вот как-то так я себе его представляю). Это не значит конечно, что нужны только такие специалисты, это просто такой продвинутый уровень квалификации, который как мне кажется нарабатывается только опытом. И опытом в конкретном проекте. Но я точно знаю, что есть те кто стремятся стать такими высококлассными тестировщиками, а есть те кто предпочитают оставаться «обычными». А может быть опыт тоже такая штука что нарабатывается он всеми а усваивают его не все. Я пока не понял как это работает. Почему одни стремятся стать лучше а потом еще лучше, а другие остаются на своем уровне навыка и не страдают.
freshik
02.06.2017 11:18начните с аксиомы – программа содержит ошибки (кстати, это верно для большинства программ), и далее тестируйте так, чтобы найти их столько, сколько это вообще возможно, будто это Ваш последний день (в тестировании).
Лучше не найти как можно больше, а пропустить как можно меньше приоритетных для пользователя багов.
Очень хорошо про это написала NatalyaRukol в своей статье.RockMachine
02.06.2017 11:18Спасибо за комментарий.
Мне кажется, что здесь не совсем справедливо говорить о «лучше – хуже». Что касается психологического аспекта, установка «пропустить как можно меньше» уступает по своей силе установке «найти как можно больше». Похоже, что именно так считают авторы, и я с ними согласен. С формулировкой «найти как можно больше» все не просто. С формулировкой «пропустить как можно меньше» все еще сложнее. Как нам разобраться с этим? Автор указанной Вами статьи отвечает на этот вопрос (который, по существу, является вопросом эффективности). Чем меньше ошибок пропущено, тем эффективнее. А как мне разобраться с количеством? Откуда я могу узнать много пропущено ошибок или не много? То есть, я хочу сказать, что определение количества пропущенных ошибок требует дополнительной активности, оно не является само по себе. А второй ответ: чем меньше недовольства клиентом выражено, тем эффективнее. Но ведь этот показатель и является отличным способом (конечно же, одним из) разобраться, какое количество ошибок пропущено. Кто-нибудь направьте меня, если я запутался.
И снова, с точки зрения психологии (каким бы громким не было это слово) авторы, на мой взгляд, достаточно убедительны. Важно еще и то, что в переведенном мной отрывке не упоминается такой активности как погоня за отчетами об ошибках. Автор же указанной Вами статья такой параметр вводит.
Поэтому считаю, что темы двух текстов несколько отличаются.
В попытке найти лаконичный ответ на Ваш комментарий, снова сошлюсь на указанную Вами статью и скажу:
Существует поиск ошибок, который не имеет ничего общего с тестированием. Но здесь отсутствует утверждение, что не существует процесса поиска ошибок как важной части процесса тестирования. Нам нужны дополнительные детали.
Считаю, что автор указанной Вами статьи утрирует, неестественно разводя примеры по разным сторонам. Это отличная модель на первых порах обучения, но от нее следует двигаться далее туда, где все не так однозначно.
MarkNikitin
02.06.2017 13:04Я когда-то работал QA и вполне согласен, ошибки были и будут всегда, qa инженер должен найти их чтобы их количество стремилось к нулю. Иногда чтобы найти проблему достаточно просто посмотреть на код как бы сказать с другой стороны)
senpay
03.06.2017 11:34"На другой руке" (англ. Идиома on the other hand) переводится как "с другой стороны".
А так, спасибо за актуальный перевод полезного отрывка из книги!
sbnur
Вполне согласен — должен быть конфликт разработчика и тестера — типа спорта — чья возьмет
Всегда поражали тестеры, которые умудрялись находить весьма неочевидные баги — это надо чувствовать
RockMachine
Лишь одна маленькая просьба: употреблять тест-инженеры вместо тестеры) Если можно, конечно.