Литература по тестированию

Не притязая на полноту, перечисляю что нашел дома, на полке (не факт, что я их читал *^_^* ).

Сразу дам ссылку на форум где книги обсуждались, если кому интересно зарегтесь, может дадут скачать :)

http://software-testing.ru/forum/forum/78/

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен
   Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений
   http://software-testing.ru/forum/topic/13031/
   Считается библией тестирования
   
2. Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах
   http://software-testing.ru/forum/topic/8133/
   а это катехизисо :)
   
3. Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
   http://software-testing.ru/forum/topic/2167/
   
4. Блэк Р. Ключевые процессы тестирования  http://software-testing.ru/forum/topic/13030/
5. Винниченко И.В. Автоматизация процессов тестирования
   http://software-testing.ru/forum/topic/13032/
   не скажу что в восторге от книги
   

Слабо полезные книги?

1. "Автоматизированное тестирование программного обеспечения"
   Элфрид Дастин, Джефф Рэшка, Джон Пол http://software-testing.ru/forum/topic/7757/

Дополнение про процесс: само тестирование в отрыве от контекста организации процесса разработки занятие с сомнительной полезностью. При тестировании важны следующие аспекты:
1. Приоритеты, сперва тестируются ключевые механизмы потом рющечки. Тк тестировщик не должен обладать всеведением, но благость ему не помещаем :), аналитик/разработчик явно должен сообщать что тестировать в каком порядке. (Почему так прочтите книжку по ТОС или о бережливой разработке ПО) Вопрос на пять рублей с помощью какого механизма? (ответ приоритетов)
2. Исправление ошибок, если ошибки висят долго не исправленными мораль тестировщика падает ниже критического уровня. Если компания не готова исправлять все ошибки.. читай Джоэля, что потом бывает :( на самом деле ничего плохого :)
3. Что нужно тестировать. Вопрос интересный и на него ответит нам регламент тестирования, хотя бы частично. Но формально, тестируют то что написано в задаче (если она есть), что подразумевается, фантазию пользователя и пользовательскую документацию...
4. Про Unit тесты и автоматизацию упомянуть стоит, но для их воплощения нужно приложить усилия. К сожалению усилия сейчас, а результат потом.
5. Воспитательный аспект. Если тестировщик не "несет возмездие во имя луны"* :) то элементы цепи до него будут считать себя локальными центрами вселенной. Я конечно не призываю носить черную одежу и после каждой найденой ошибки являться к программисту и указав на ошибку гнусно хихикать (реальный случай, самая эффективная группа тестирования, к сожалению склероз выкосил знания о месте и времени)

Вывод: Сколько книг ни читай, а императором не станешь. Мао Цзедун **

* я не являюсь поклонником Луны в тельняшке и махо седзе
** достоверность цитаты сомнительна, в Красной книжке ее нет. Проверять в домене .cn нет желания.

Миф о документации

Gaperton разразился текстами про документацию, к сожалению текст не 
везде цензурный, но по делу 

лучше читать сразу продолжение
http://gaperton.livejournal.com/60632.html

исходный пост тут
http://gaperton.livejournal.com/60277.html

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

есть три типа программистской документации:
1) "Договор". - для это ТЗ или задачи в трекере
2) "Справочник". - то что с трудом пытаемся писать в wiki и код, но для 
кода нужен ключ доступа новым читателям.
3) Обучающий материал. - то что нужно создать, но стоит очень дорого

Для ключей к справочникам нужны:
1. номера ревизий закрывающие задачи (чего не всегда делается)
2. коменты по задачам, удаляя срач мы удаляем часто единственные зацепки 
которые позволят понять устройство системы

Отсебятина к тексту, дополнительно нужны:
3. описание архитектуры, как ее состыковать с кодом хз
4. документы по прохождению развилок, хз как писать
5. модель для проверки консистентности постановок, хз как ее реализовать

все выше написанное не отрицает того, что документация важна и нужна