Различают тестирование по типам:

• черный ящик (без просмотра исходного текста);
• белый ящик (с изучением исходного текста);

и по объему:

• маленький тест, типа печати "hello, world", чтобы понять, есть ли вообще о чем говорить;
• получаcовое тестирование (американцы говорят "Тест на одну сигарету"), обычно проверяют по одному тесту на каждую функцию программы перед серьезным тестированием;
• модульное тестирование;
• комплексное тестирование.

Особого упоминания заслуживают тестирование граничных значений входных данных, тесты на максимальный объем счета, проверка предположений об ошибках ("Я бы сделал ошибку здесь").

Иногда применяется перекрестное чтение особо ответственных участков программы, когда одна группа разработчиков читает программы другой группы (insрection peer review). В США очень популярны Bugs festivals, когда незадолго перед выпуском системы фирма платит определенную сумму за каждую найденную ошибку. Список таких приемов можно расширить, но вряд ли их можно считать общеупотребительными.

В зрелых программистских компаниях для каждого проекта ведется своя база данных ошибок, в которую вносится:

• кто нашел ошибку, дата;
• описание ошибки;
• модуль, в котором ошибка обнаружилась (возможно, это наведенная ошибка, может быть, она вызвана ошибкой в совсем другом модуле);
• версия продукта;
• статус ошибки:
  • open: найдена
  • fixed: исправлена
  • can't reproduce: невозможно воспроизвести
  • by design: ошибка проектировщиков
  • wont fix: это не ошибка (тестеру показалось)
  • postponed: сейчас исправить трудно, исправим в следующей версии
  • regression: исправленная ошибка появилась вновь
• Важность (severity) ошибки:
  • сrash: все падает, полная потеря данных
  • major problem: падает частично, частичная потеря данных
  • minor problem: что-то не то, но данные не теряются
  • trivial: сейчас не стоит исправлять
• Приоритет ошибки:
  • highest: невозможно поставить продукт с такой ошибкой, не можем перейти к следующей версии
  • high: поставить не можем, но можем перейти к следующей версии
  • medium: можем и исправим
  • low: косметические улучшения – оставим на следующую версию.

Особенно заметна ценность базы данных ошибок для больших и длительных проектов. Если идентификатор одной ошибки встречается десятки раз в различных письмах, недельных отчетах – это верный признак того, что требуется вмешательство руководства. Все руководители разных рангов знают на память записи из этой базы данных о текущих ошибках с высшей важностью и приоритетом. По завершении каждого проекта база данных ошибок внимательно анализируется. Интересно распределение ошибок по тому, кто их совершил, по времени исправления, кто чаще ошибки находит и т.д. Если в одну неделю разработчик 1 сделал 10 ошибок, а разработчик 2 – только 2, это еще ни о чем не говорит. Но если же за весь период разработки разработчик 1 сделал 100 ошибок, а разработчик 2 – только 10, то по этим цифрам можно уже судить об их квалификации. Можно также оценивать целые группы или, скажем, качество проектирования, а можно сделать какие-то выводы по мощности и надежности используемых инструментальных средств.

На основе изучения записей в базе данных ошибок руководство проектом принимает решение о возможности выпуска продукта, например, продукт нельзя выпускать, если есть хотя бы одна ошибка с важностью "crash" или с приоритетом "highest/high". Возможна и такая стратегия, когда продукт выпустить обязательно надо, но времени на исправление основных ошибок нет (нужно помнить, что даже небольшие исправления могут повлечь за собой новые ошибки), тогда из продукта просто удаляют часть функций, в которых есть ошибки.

Мы говорили о тестировании, только отдавая дань многолетней традиции. На самом деле, любая зрелая программистская компания имеет большую независимую группу оценки качества ПО (Quality Assurance или просто QA), функции которой намного шире, чем просто тестирование. Для каждого продукта проверяется:

• полнота и корректность документации;
• корректность процедур установки и запуска;
• эргономичность использования;
• полнота тестирования.

QA должна играть роль придирчивого пользователя, но внутри компании. В США разработчики и QA сидят в разных концах коридора, не поощряется даже неформальное общение. В западных компаниях довольно существенную часть зарплаты (примерно 20-30%) составляет бонус, выплачиваемый в конце проекта и только в случае его успешного завершения. Так вот, если QA найдет слишком много ошибок разработчиков, те остаются без бонуса, но если QA принял разработку, а затем пользователи начнут жаловаться, то QA остается без бонуса, хотя жалобы связаны с ошибками разработчиков. Таким искусственным разделением ответственности и непоощрением дружеских отношений между разработчиками и QA владельцы компаний пытаются застраховаться от неудачи на рынке. В США говорят, что каждому продукту дается только одна попытка выхода на рынок. Если пользователям по разным причинам продукт не понравился, репутация теряется навсегда. Поэтому ошибки так дорого стоят.