Автор: Алексей Баранцев,
главный редактор портала Software-Testing.Ru ©
Перевел: Алексей Лупан,
худший друг программистов, TestItQuickly.com ©

Иной раз и самые опытные, матёрые программисты затрудняются объяснить своим доверчивым мамам, что такое «файл».

Тестировщикам это тоже сложно объяснить.

Тестировщики вообще сложный народ. Они даже в среде самих себе подобных затрудняются определить правильное значение своего самого хлебоприносящего слова — «тестирование».

Поэтому в приличном обществе все разговоры о тестировании следует начинать с уточнений о том, что именно докладчик подразумевает под словом «тестирование».

Товарищи докладчики!

Перестаньте размахивать на нас руками!

Достаньте нам это ваше тестирование из своих карманов и положите его на стол, чтобы все видели.

Доставайте, чтобы всем было ясно — вот оно, тестирование!

Доставайте и рассматривайте!

Доставайте и щупайте вводный курс Алексея Баранцева по основам тестирования программного обеспечения!

«Уважаемые коллеги,

в этом курсе даны основные определения, которые используются во всех моих семинарах из серии «Тестирование ПО».

Я расскажу о том, каких воззрений на тестирование, и, в частности, на классификацию тестирования, я придерживаюсь; объясню, как я трактую те или иные понятия и термины, которые часто используются в среде тестирования, но в разных источниках определяются по-разному; но сначала я расскажу о том, что такое «тестирование» и что такое «тест» в моем понимании.

Что такое тестирование

Сначала попробуем понять, чем тестирование НЕ является.

Тестирование не разработка,

даже если тестировщики умеют программировать, в том числе и тесты (автоматизация тестирование = программирование), могут разрабатывать какие-то вспомогательные программы (для себя).

Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.

Тестирование не анализ,

и не деятельность по сбору и анализу требований.

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

Тестирование не управление,

несмотря на то, что во многих организациях есть такая роль, как «тест-менеджер». Конечно же, тестировщиками надо управлять. Но само по себе тестирование управлением не является.

Тестирование не техписательство,

однако тестировщикам приходится документировать свои тесты и свою работу.

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

Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?

Можно считать, что отчуждаемыми результатами работы тестировщиков являются дефекты, описания дефектов, или отчеты о тестировании.

Это наивно.

Хотя частично это правда.

Но это не вся правда.

Главная деятельность тестировщиков

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

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

Но эта вещь очень значимая, и, наверное, единственная наиболее значимая составляющая деятельности тестировщиков.

Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь»:

«Обратная связь» это некоторые данные, которые с выхода попадают обратно на вход, или какая-то часть данных, которые с выхода попадают обратно на вход. Эта обратная связь может быть положительной и отрицательной.

Считается, что положительная обратная связь прибавляется к входному сигналу, то есть, она усиливает входной сигнал. А отрицательная обратная связь входной сигнал ослабляет.

И та, и другая разновидности обратной связи равноценно важны.

Отрицательная обратная связь стабилизирует систему благодаря тому, что она ослабляет входной сигнал.

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

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

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

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

Отрицательная обратная связь тоже может поступать от конечных пользователей в виде каких-то негативных отзывов. Либо она может поступать от тестировщиков.

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

Синонимы термина «тестирование»

С точки зрения того, что тестирование — это предоставление отрицательной обратной связи, всемирно известная аббревиатура QA (англ. Quality Assurance — Обеспечение качества) синонимом термина «тестирование» уж совершенно точно НЕ является.

Нельзя считать обеспечением качества предоставление отрицательной обратной связи. Обеспечение — это некоторые позитивные меры. Подразумевается, что в этом случае мы именно обеспечиваем качество, своевременно предпринимаем какие-то меры для того, чтобы качество разработки ПО повысилось.

А вот «контроль качества» — Quality Control, можно считать в широком смысле синонимом для термина «тестирование», потому что контроль качества это и есть предоставление обратной связи в самых разных ее разновидностях, на самых разных этапах программного проекта.

Иногда тестирование подразумевается как некоторая отдельная форма контроля качества.

Путаница приходит из истории развития тестирования. В разное время под термином «тестирование» подразумевались различные действия.

1980
Процесс выполнения программы с намерением найти ошибки.
[Г.Майерс. Надежность программного обеспечения. М:Мир, 1980]

1987
Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов.
[ANSI/IEEE standard 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987]

1990
Это не действие. Это интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку.
[B. Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand Reinhold, 1990]

1999
Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц.
[С. Kaner, 1999]

2004
Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом.
[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

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

Но разгадка в другом. Процитированные определения можно разделить на 2 больших класса: внешние и внутренние.

Внешние определения

Определения, которые в разное время дали Майерс, Бейзер, Канер, описывают тестирование как раз с точки зрения его ВНЕШНЕЙ значимости. То есть, с их точки зрения, тестирование — это деятельность, которая предназначена ДЛЯ чего-то, а не состоит из чего-то. Все три этих определения можно обобщить как предоставление отрицательной обратной связи.

Внутренние определения

Это определения, которые приведены в стандарт терминологии, используемой в программной инженерии, например, в стандарт де-факто, который называется SWEBOK.

Такие определения конструктивно объясняют, ЧТО представляет из себя деятельность по тестированию, но не дают ни малейшего представления о том, ДЛЯ ЧЕГО нужно тестирование, для чего потом будут использоваться все полученные результаты проверки соответствия между реальным поведением программы и ее ожидаемым поведением.

Итак,

тестирование — это

• проверка соответствия программы требованиям,
• осуществляемая путем наблюдения за ее работой
• в специальных, искусственно созданных ситуациях, выбранных определенным образом.

Отсюда и далее будем считать это рабочим определением «тестирования».

Общая схема тестирования примерно следующая:

1. Тестировщик на входе получает программу и/или требования.
2. Он с ними что-то делает, наблюдает за работой программы в определенных, искуственно созданных им ситуациях.
3. На выходе он получает информацию о соответствиях и несоответствиях.
4. Далее эта информация используется для того, чтобы улучшить уже существующую программу. Либо для того, чтобы изменить требования к еще только разрабатываемой программе.

Это весьма близко к определению, данному в SWEBOK, хотя есть несколько отличий. Например, в нашем определении нет слова «тест».

Определение тестирования по SWEBOK

звучит следующим образом:

Тестирование – это проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранных определенных образом.

А мы с вами говорили о некоторых специальных искусственно созданныхситуациях, выбранных определенным образом. Вот эти специальные, искусственно созданные ситуации, и есть ТЕСТЫ. Чуть позже мы это сформулируем еще более точно в виде определения термина «тест», а пока пойдем дальше.

Определение по SWEBOK плохо по-следующей причине: оно говорит нам, что набор тестов должен быть КОНЕЧНЫМ. А он конечным будет всего лишь по определению. Он не может быть бесконечным, потому что у нас есть только ограниченное количество времени, ограниченные ресурсы, объем памяти компьютера конечен, поэтому это слово «конечный» ничего нам не дает осмысленного, правильно использовать термин «ограниченный», на ограниченный набор тестов. Мы его сами некоторым образом ограничиваем.

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

Что такое тест

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

Не нужно считать, что ситуация – это нечто одномоментное. Тест может быть достаточно длинным, например, при тестировании производительности вот эта искусственно созданная ситуация это может быть продолжающаяся в течение достаточно продолжительного времени нагрузка на систему. А наблюдения, которые нужно при этом делать, это набор различных графиков или метрик, которые мы измеряем в процессе выполнения этого теста.

Ну и таким образом мы можем заключить, что тестировщик делает в процессе тестирования две вещи.

1.Во-первых, он управляет выполнением программы и создает эти самые искусственные ситуации, в которых мы собираемся проверять поведение программы.

2.И, во-вторых, он наблюдает за поведением программы и сравнивает то, что он видит с тем, что ожидается.

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

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