Rex Black. Managing the Testing Processes.
Попытка конспекта.
В идеальном мире тестировщики не нужны - в идеальном мире все программы работают без ошибок.
В идеальном мире не нужна полиция и вооруженные силы - там нет преступлений и агрессивных соседей.
В реальном мире, увы, воруют и убивают, а в одно сентябрьское утро войска соседнего государства переходят границу и начинается Мировая война. Поэтому приходится платить налоги и содержать относительно бесполезную милицию и, казалось бы, совсем уж бесполезную армию.
Возвращаясь к тестированию - чем сложнее программа, чем больше кода, условий и т.д., тем вероятнее появление багов. Баги нервируют клиентов. Совсем уж критические баги клиентов отпугивают. Сам Рэкс приводит пример программы, в которой не было тестеров. Какое-то время ее покупали, но потом они выпустили версию... И вскоре закрылись.
И тут мы переходим к вопросу - а что такое тестирование с точки зрения менеджера и директора?
Инвестиции, которые должны бы окупиться.
Ошибка, найденная в документации, стоит несколько часов времени аналитиков.
Ошибка, найденная на этапе юнит- или компонент-тестирования (и программирования) исправляется относительно легко (то есть, быстро, а следовательно, относительно дешево).
Ошибка, найденная на этапе интеграционного, системного, а тем более приемочного тестирования исправляется мучительно и дорого - но все же дешевле, чем ошибка, найденная покупателем уже после релиза. После релиза надо быстро выпускать "заплатку", отправлять обновление всем покупателям, а это потери не только времени и денег, но и имиджа, а следовательно - потенциально - покупателей.
Отсюда переходим к тому, что надо тестировать.
Тестировать надо то, что в первую очередь будут использовать покупатели, то, чем будет пользоваться большинство покупателей. На все остальное можно не то чтобы забить... Но ограничиться быстрым тестированием, тем, которое smoke. Безусловно, хорошо бы протестировать все - но на это не хватит ни времени, ни денег, ни ресурсов.
Даже если тестерам предложат самим заэстимейтить время, нужное на тестирование - не надо забывать, что инвестиции, вложенные в тестирование, должны окупиться. Иначе отдел тестирования могут закрыть - что и случилось с одним из отделов, в которых работал Рэкс в незапамятные времена. Они тестировали очень хорошо и много - но не уделяли достаточно времени самым популярным фичам (точнее, уделяли им времени столько же, сколько всем остальным). Клиенты расстроились, огорчились, огорчили директора фирмы - а тот опечалил тестеров.
Рэкс предлагает составлять план тестирования на основе категорий рисков.
То есть, когда может возникнуть ошибка, которая расстроит клиента.
"Функционал" - то есть, что система делает то, что от нее ожидают - это только один из пунктов.
Еще есть проверка
- на уровне компонентов: состояний и переходов между состояниями, процессов обработки данных, интерфейса ;
- на этапе интеграционного: интерфейса, объема, качества работы с данными (ничего не теряется и не превращается в тыкву), восстановления после сбоя, производительности;
- на этапе системного/приемочного: функционал, интерфейс, состояния, переходы, качество работы с данными, переполнения данных, стабильность, восстановление после сбоя, производительность, локализации, работа с сетью, настройки конфигурации, безопасность, окружение, инсталляция, документация, поддержка...
Списки эти, естественно, с одной стороны, полностью подходят не всем - с другой стороны, содержат не все риски, поэтому надо много думать и находить, какие риски еще не учтены.
И риски эти желательно расписывать для каждого функционала - а не для всей системы.
И определять, какие риски могут ударить по клиенту - а какие едва ли. То есть какие рвать на части, а какие только бегло просмотреть, чтоб ничего не рухнуло.
На основе таблицы с рисками, можно написать план тестирования - то есть что и когда будет тестироваться.
Бумажка эта нужна,
во-первых, чтобы знать, что делать и знать, когда что-то начинает идти не так;
во-вторых, чтобы знать, какие ресурсы понадобятся;
в-третьих, но не в последних, чтобы добиваться получения этих самых ресурсов (время, люди, инструменты) от начальства.
В план, в частности, можно записать,
сколько прогонов тест-кейсов планируется (и сколько там будет исследовательского тестирования, которое тоже очень важно),
определить для каждого этапа (компонентное-системное-приемочное) "входные" критерии (то есть, имеет ли вообще смысл тестировать это - или это даже тестировать невозможно, не то что использовать) и "выходные" критерии (то есть, можно сказать, что можно завершать тестирование).
Есть несколько шаблонов составных частей тест-планов.
После того, как есть тест-план, можно переходить к созданию тест-системы, которая включает в себя:
- testware (наверное, можно перевести на русский, но зачем?): инструменты, документация, данные, кейсы;
- тестовое окружение ("железо", софт, сетка, бумага для заметок, и т.д.)
- тестовые процессы (тестирование, чеклисты и т.д.)
- тестовая тима (без которой все остальное - груда металлолома).
Каждая часть важна, каждая часть нужна, но самая важная часть - это тест-кейсы. Без них тестирование - хаос, метание и сплошная печаль. Потому как если без исследовательского тестирования просто грустно, то без тест-кейсов - совсем тоска.
Тест-кейс
- может быть "в голове" или письменным (лучше письменным),
- не может быть ни слишком детальным (иначе легче будет убиться, чем поддерживать) ни слишком общим (иначе можно пропустить что-то важное),
- не должен дублировать проверки,
- должен содержать данные "на вход" и "на выход" (чтоб сравнить можно было и сказать - pass/failed)
и многое другое - ссылки на спеку, на условия запуска и т.д.
Помимо прохода тестов в циклах, есть еще проблемы с регрессингом и проверкой фиксов багов.
Рэкс очень не любит, когда версии накатывают чаще, чем раз в неделю (а то и в две). В таких случаях он говорит, тестеры больше проверяют исправление ошибок, чем саму систему. А это плохо. А что делать, как говорится.
Автотестирование может снять проблему с регрессингом - а может добавить проблему с автотестингом, так что не всегда нужно его запиливать. Да, Гугль автотестит все и с самого начала, но где мы - а где Гугль.
Для чего, собственно, нужны тест-кейсы и исследовательское тестирование?
Чтобы находить ошибки до того, как их найдет клиент.
А зачем находить ошибки?
Чтобы программисты их исправили и клиенты их никогда не увидели (или менеджер решил, что дешевле оставить такую ошибку, чем ее править - но это уже работа менеджера, не тестера).
И мы переходим к тому, как программист узнает про ошибку, которую нашел тестер: с помощью bug-report.
Эта вещь не менее важна, чем тест-кейс, хотя тест-кейс все же важнее.
Писать их надо четко и ясно, как Хемингуэй: название, шаги, ожидаемый результат.
Писать не сразу, а воспроизвести раза три.
Изолировать, но не слишком увлекаться с изоляцией (это еще один момент "тестирование - искусство", определять, когда уже садиться писать).
Ошибка, после того, как открывается - может быть сразу ликвидирована, а может быть отправлена на фикс. После фикса - может быть закрыта, переоткрыта или ликвидирована.
Если составить график открытых ошибок, можно узнать много интересного.
Но этого графика очень мало. Нужен еще график открытия и закрытия ошибок.
Много открытых ошибок может быть потому, что их не фиксят - а может быть потому, что фиксят их быстро и много, но число и категория не уменьшается, и это два разных "много".
Только одного такого графика мало. Нужен еще график прохождения тест-кейсов.
Если есть много багов - и пройдены все тест-кейсы, то это совсем другие "столько же много багов" но при этом пройдены только самые первые тест-кейсы.
И этих двух графиков мало. Нужен еще третий - график работы тестеров и прохождения тест-кейсов.
Если найдено много багов, пройдены все тест-кейсы и тестеры все успели сделать в срок - это хорошо. А вот если все то же, но тестеры пахали по двенадцать часов семь дней в неделю - это значит, что прогнило что-то в королевстве, и не исключено, что скоро придется собирать новую тест-тиму. А лучше разобраться - то ли эстимейты для тест-кейсов были занижены, то ли работать было невозможно большую часть времени, то ли еще что.
А чтобы эти самые графики составлять, удобно использовать таблицу:
- какие тест-кейсы запланированы,
- кто их должен проходить,
- сколько это должно занять времени,
- сколько заняло на самом деле,
- сколько прошли, сколько свалились, какие баги заведены.
Собственно, это важно чтобы "держать руку на пульсе" и успевать реагировать на стремительно меняющуюся ситуацию на проекте.
Потому что на любом проекте рано или поздно наступает релиз, а перед релизом все идет кувырком.
По ходу создания программы меняется документация, и любовно сделанные тест-кейсы приходится выкидывать или переделывать, или срочно на коленке дописывать новые.
Добавляются или убираются фичи - во втором случае обидно за время, потраченное на написание т-к, в первом и так понятно.
Но - такая уж жизнь и работа тестировщика. Клиент имеет право менять проект, он платит деньги. Счастливый клиент - счастливый директор - счастливые сотрудники. Клиент, связанный по рукам и ногам документацией несчастен, и в следующий раз не придет. Так что - вовремя отслеживать проблемы и минимизировать вред.
Есть глава, как сделать правильную тест-лабораторию, но ее я просмотрел-пролистал.
Есть глава, как нанимать и управлять тест-тимой. Понимать, что человек хочет быть тестером и имеет к этому склонности. Стараться, чтобы в команде были охвачены все области - и очень желательно, чтобы по два раза минимум.
Вообще заботиться о морали тимы - это хорошая карма:
- "своих" ругать один-на-один, хвалить при всех,
- "своих" отстаивать от "чужих" - как правило, программистов, а еще лучше улаживать конфликты без обид.
Чем можно мотивировать?
- деньгами,
- должностями (то есть повышать с джуника до миддла, до сеньора),
- не перегружать свехурочно, (а уж если перегружать - стараться смягчить, хоть пиццой хоть чем)
- отправлять на семинары и конференции.
Поддерживать нормальный график работы - иначе тестеры "выгорят" и уйдут туда, где рабочая неделя = 40 часов, а не "до релиза".
Присматриваться к каждому и помогать в карьерном росте. Давать задачи те, что нравятся. Стараться не демотиваировать.
И т.п.
И о том, чего делать нельзя:
- давать "пряники" за выслугу лет:
- давать "пряники"-"кнуты" за количество багов, за быстро пройденные тест-кейсы и т.п.
Десятая глава посвящена работе с "удаленными сотрудниками" и ее я тоже пролистал. Уважайте их праздники там, учитывайте разницу в менталитете и все такое прочее.
И напоследок вопрос - должен ли тест-лид стоять насмерть за качество и прочее?
Нет, иначе он превратится в Дон Кихота, который борется с ветряной мельницей.
Тест-лид должен понимать, что тестирование - это вложение инвестиций, что у директора всегда есть куда еще вложить деньги или куда их потратить, и поэтому тестирование надо уметь "продать".
Тест-лид должен понимать, что не все понимают, что такое тестирование и зачем оно вообще надо - и ему надо объяснять это коллегам, но так, чтоб они правда поняли и поддержали. Тест-лиды, как и тестер, постоянно взаимодействует со всеми - программистами, аналитиками, саппортом, продажниками. Кого-то из них можно использовать как "естественных союзников" в борьбе за хороший продукт.
Но все же - не надо думать, что качественный продукт нужен только и исключительно тестерам.
Даже если иногда так кажется.
Можно еще сказать два солва про модели тестирования:
V-модель, Спираль, но сейчас все равно рулит Аджайл, так что смысл?
А вот перечислить факторы, которые улучшают и ухудшают тестирование, можно.
Улучшают:
- начинать тестировать с самого начала, и тестировать все доступные "измерения",
- хорошие сотрудники - и как тестеры, и как понмиающие, что должен делать продукт,
- автоматизация - при всех "но" она таки приносит пользу,
- хорошая тест-система - обеспечивает тестрование как науку, а не как "потыкать еще вот сюда, ну, вроде, готово"
- четко определенные отношения с программистами - какие должны быть репорты,
- точная и ясная документация, значние, что должен делать продукт,
- постоянная прогонка тестов (это в паре с автоматизацией хорошо идет)
Ухудшают:
- слишком детальные и не гибкие планы - ибо планы все равно будут сломаны,
- "слишком оптимистичное число фичей",
- отсутствие поддержки со стороны программистов и руководства,
- постоянные проблемы с системой под тестированием - даже смоуки не проходят,
- экономия на полезных тулзовинах,
- "слишком оптимистичные эстимейты",
- слишком медленная реакция программистов,
- использование тестеров для дебаггинга,
- большое число багов,
- постоянное изменение задач,
- большое число ошибок тестеров.
Часто со вторым списком ничего сделать нельзя, но можно - и нужно - пытаться.
Хотя, конечно, лучше саму книгу почитать, чем этот короткий конспект :)
В идеальном мире тестировщики не нужны - в идеальном мире все программы работают без ошибок.
В идеальном мире не нужна полиция и вооруженные силы - там нет преступлений и агрессивных соседей.
В реальном мире, увы, воруют и убивают, а в одно сентябрьское утро войска соседнего государства переходят границу и начинается Мировая война. Поэтому приходится платить налоги и содержать относительно бесполезную милицию и, казалось бы, совсем уж бесполезную армию.
Возвращаясь к тестированию - чем сложнее программа, чем больше кода, условий и т.д., тем вероятнее появление багов. Баги нервируют клиентов. Совсем уж критические баги клиентов отпугивают. Сам Рэкс приводит пример программы, в которой не было тестеров. Какое-то время ее покупали, но потом они выпустили версию... И вскоре закрылись.
И тут мы переходим к вопросу - а что такое тестирование с точки зрения менеджера и директора?
Инвестиции, которые должны бы окупиться.
Ошибка, найденная в документации, стоит несколько часов времени аналитиков.
Ошибка, найденная на этапе юнит- или компонент-тестирования (и программирования) исправляется относительно легко (то есть, быстро, а следовательно, относительно дешево).
Ошибка, найденная на этапе интеграционного, системного, а тем более приемочного тестирования исправляется мучительно и дорого - но все же дешевле, чем ошибка, найденная покупателем уже после релиза. После релиза надо быстро выпускать "заплатку", отправлять обновление всем покупателям, а это потери не только времени и денег, но и имиджа, а следовательно - потенциально - покупателей.
Отсюда переходим к тому, что надо тестировать.
Тестировать надо то, что в первую очередь будут использовать покупатели, то, чем будет пользоваться большинство покупателей. На все остальное можно не то чтобы забить... Но ограничиться быстрым тестированием, тем, которое smoke. Безусловно, хорошо бы протестировать все - но на это не хватит ни времени, ни денег, ни ресурсов.
Даже если тестерам предложат самим заэстимейтить время, нужное на тестирование - не надо забывать, что инвестиции, вложенные в тестирование, должны окупиться. Иначе отдел тестирования могут закрыть - что и случилось с одним из отделов, в которых работал Рэкс в незапамятные времена. Они тестировали очень хорошо и много - но не уделяли достаточно времени самым популярным фичам (точнее, уделяли им времени столько же, сколько всем остальным). Клиенты расстроились, огорчились, огорчили директора фирмы - а тот опечалил тестеров.
Рэкс предлагает составлять план тестирования на основе категорий рисков.
То есть, когда может возникнуть ошибка, которая расстроит клиента.
"Функционал" - то есть, что система делает то, что от нее ожидают - это только один из пунктов.
Еще есть проверка
- на уровне компонентов: состояний и переходов между состояниями, процессов обработки данных, интерфейса ;
- на этапе интеграционного: интерфейса, объема, качества работы с данными (ничего не теряется и не превращается в тыкву), восстановления после сбоя, производительности;
- на этапе системного/приемочного: функционал, интерфейс, состояния, переходы, качество работы с данными, переполнения данных, стабильность, восстановление после сбоя, производительность, локализации, работа с сетью, настройки конфигурации, безопасность, окружение, инсталляция, документация, поддержка...
Списки эти, естественно, с одной стороны, полностью подходят не всем - с другой стороны, содержат не все риски, поэтому надо много думать и находить, какие риски еще не учтены.
И риски эти желательно расписывать для каждого функционала - а не для всей системы.
И определять, какие риски могут ударить по клиенту - а какие едва ли. То есть какие рвать на части, а какие только бегло просмотреть, чтоб ничего не рухнуло.
На основе таблицы с рисками, можно написать план тестирования - то есть что и когда будет тестироваться.
Бумажка эта нужна,
во-первых, чтобы знать, что делать и знать, когда что-то начинает идти не так;
во-вторых, чтобы знать, какие ресурсы понадобятся;
в-третьих, но не в последних, чтобы добиваться получения этих самых ресурсов (время, люди, инструменты) от начальства.
В план, в частности, можно записать,
сколько прогонов тест-кейсов планируется (и сколько там будет исследовательского тестирования, которое тоже очень важно),
определить для каждого этапа (компонентное-системное-приемочное) "входные" критерии (то есть, имеет ли вообще смысл тестировать это - или это даже тестировать невозможно, не то что использовать) и "выходные" критерии (то есть, можно сказать, что можно завершать тестирование).
Есть несколько шаблонов составных частей тест-планов.
После того, как есть тест-план, можно переходить к созданию тест-системы, которая включает в себя:
- testware (наверное, можно перевести на русский, но зачем?): инструменты, документация, данные, кейсы;
- тестовое окружение ("железо", софт, сетка, бумага для заметок, и т.д.)
- тестовые процессы (тестирование, чеклисты и т.д.)
- тестовая тима (без которой все остальное - груда металлолома).
Каждая часть важна, каждая часть нужна, но самая важная часть - это тест-кейсы. Без них тестирование - хаос, метание и сплошная печаль. Потому как если без исследовательского тестирования просто грустно, то без тест-кейсов - совсем тоска.
Тест-кейс
- может быть "в голове" или письменным (лучше письменным),
- не может быть ни слишком детальным (иначе легче будет убиться, чем поддерживать) ни слишком общим (иначе можно пропустить что-то важное),
- не должен дублировать проверки,
- должен содержать данные "на вход" и "на выход" (чтоб сравнить можно было и сказать - pass/failed)
и многое другое - ссылки на спеку, на условия запуска и т.д.
Помимо прохода тестов в циклах, есть еще проблемы с регрессингом и проверкой фиксов багов.
Рэкс очень не любит, когда версии накатывают чаще, чем раз в неделю (а то и в две). В таких случаях он говорит, тестеры больше проверяют исправление ошибок, чем саму систему. А это плохо. А что делать, как говорится.
Автотестирование может снять проблему с регрессингом - а может добавить проблему с автотестингом, так что не всегда нужно его запиливать. Да, Гугль автотестит все и с самого начала, но где мы - а где Гугль.
Для чего, собственно, нужны тест-кейсы и исследовательское тестирование?
Чтобы находить ошибки до того, как их найдет клиент.
А зачем находить ошибки?
Чтобы программисты их исправили и клиенты их никогда не увидели (или менеджер решил, что дешевле оставить такую ошибку, чем ее править - но это уже работа менеджера, не тестера).
И мы переходим к тому, как программист узнает про ошибку, которую нашел тестер: с помощью bug-report.
Эта вещь не менее важна, чем тест-кейс, хотя тест-кейс все же важнее.
Писать их надо четко и ясно, как Хемингуэй: название, шаги, ожидаемый результат.
Писать не сразу, а воспроизвести раза три.
Изолировать, но не слишком увлекаться с изоляцией (это еще один момент "тестирование - искусство", определять, когда уже садиться писать).
Ошибка, после того, как открывается - может быть сразу ликвидирована, а может быть отправлена на фикс. После фикса - может быть закрыта, переоткрыта или ликвидирована.
Если составить график открытых ошибок, можно узнать много интересного.
Но этого графика очень мало. Нужен еще график открытия и закрытия ошибок.
Много открытых ошибок может быть потому, что их не фиксят - а может быть потому, что фиксят их быстро и много, но число и категория не уменьшается, и это два разных "много".
Только одного такого графика мало. Нужен еще график прохождения тест-кейсов.
Если есть много багов - и пройдены все тест-кейсы, то это совсем другие "столько же много багов" но при этом пройдены только самые первые тест-кейсы.
И этих двух графиков мало. Нужен еще третий - график работы тестеров и прохождения тест-кейсов.
Если найдено много багов, пройдены все тест-кейсы и тестеры все успели сделать в срок - это хорошо. А вот если все то же, но тестеры пахали по двенадцать часов семь дней в неделю - это значит, что прогнило что-то в королевстве, и не исключено, что скоро придется собирать новую тест-тиму. А лучше разобраться - то ли эстимейты для тест-кейсов были занижены, то ли работать было невозможно большую часть времени, то ли еще что.
А чтобы эти самые графики составлять, удобно использовать таблицу:
- какие тест-кейсы запланированы,
- кто их должен проходить,
- сколько это должно занять времени,
- сколько заняло на самом деле,
- сколько прошли, сколько свалились, какие баги заведены.
Собственно, это важно чтобы "держать руку на пульсе" и успевать реагировать на стремительно меняющуюся ситуацию на проекте.
Потому что на любом проекте рано или поздно наступает релиз, а перед релизом все идет кувырком.
По ходу создания программы меняется документация, и любовно сделанные тест-кейсы приходится выкидывать или переделывать, или срочно на коленке дописывать новые.
Добавляются или убираются фичи - во втором случае обидно за время, потраченное на написание т-к, в первом и так понятно.
Но - такая уж жизнь и работа тестировщика. Клиент имеет право менять проект, он платит деньги. Счастливый клиент - счастливый директор - счастливые сотрудники. Клиент, связанный по рукам и ногам документацией несчастен, и в следующий раз не придет. Так что - вовремя отслеживать проблемы и минимизировать вред.
Есть глава, как сделать правильную тест-лабораторию, но ее я просмотрел-пролистал.
Есть глава, как нанимать и управлять тест-тимой. Понимать, что человек хочет быть тестером и имеет к этому склонности. Стараться, чтобы в команде были охвачены все области - и очень желательно, чтобы по два раза минимум.
Вообще заботиться о морали тимы - это хорошая карма:
- "своих" ругать один-на-один, хвалить при всех,
- "своих" отстаивать от "чужих" - как правило, программистов, а еще лучше улаживать конфликты без обид.
Чем можно мотивировать?
- деньгами,
- должностями (то есть повышать с джуника до миддла, до сеньора),
- не перегружать свехурочно, (а уж если перегружать - стараться смягчить, хоть пиццой хоть чем)
- отправлять на семинары и конференции.
Поддерживать нормальный график работы - иначе тестеры "выгорят" и уйдут туда, где рабочая неделя = 40 часов, а не "до релиза".
Присматриваться к каждому и помогать в карьерном росте. Давать задачи те, что нравятся. Стараться не демотиваировать.
И т.п.
И о том, чего делать нельзя:
- давать "пряники" за выслугу лет:
- давать "пряники"-"кнуты" за количество багов, за быстро пройденные тест-кейсы и т.п.
Десятая глава посвящена работе с "удаленными сотрудниками" и ее я тоже пролистал. Уважайте их праздники там, учитывайте разницу в менталитете и все такое прочее.
И напоследок вопрос - должен ли тест-лид стоять насмерть за качество и прочее?
Нет, иначе он превратится в Дон Кихота, который борется с ветряной мельницей.
Тест-лид должен понимать, что тестирование - это вложение инвестиций, что у директора всегда есть куда еще вложить деньги или куда их потратить, и поэтому тестирование надо уметь "продать".
Тест-лид должен понимать, что не все понимают, что такое тестирование и зачем оно вообще надо - и ему надо объяснять это коллегам, но так, чтоб они правда поняли и поддержали. Тест-лиды, как и тестер, постоянно взаимодействует со всеми - программистами, аналитиками, саппортом, продажниками. Кого-то из них можно использовать как "естественных союзников" в борьбе за хороший продукт.
Но все же - не надо думать, что качественный продукт нужен только и исключительно тестерам.
Даже если иногда так кажется.
Можно еще сказать два солва про модели тестирования:
V-модель, Спираль, но сейчас все равно рулит Аджайл, так что смысл?
А вот перечислить факторы, которые улучшают и ухудшают тестирование, можно.
Улучшают:
- начинать тестировать с самого начала, и тестировать все доступные "измерения",
- хорошие сотрудники - и как тестеры, и как понмиающие, что должен делать продукт,
- автоматизация - при всех "но" она таки приносит пользу,
- хорошая тест-система - обеспечивает тестрование как науку, а не как "потыкать еще вот сюда, ну, вроде, готово"
- четко определенные отношения с программистами - какие должны быть репорты,
- точная и ясная документация, значние, что должен делать продукт,
- постоянная прогонка тестов (это в паре с автоматизацией хорошо идет)
Ухудшают:
- слишком детальные и не гибкие планы - ибо планы все равно будут сломаны,
- "слишком оптимистичное число фичей",
- отсутствие поддержки со стороны программистов и руководства,
- постоянные проблемы с системой под тестированием - даже смоуки не проходят,
- экономия на полезных тулзовинах,
- "слишком оптимистичные эстимейты",
- слишком медленная реакция программистов,
- использование тестеров для дебаггинга,
- большое число багов,
- постоянное изменение задач,
- большое число ошибок тестеров.
Часто со вторым списком ничего сделать нельзя, но можно - и нужно - пытаться.
Хотя, конечно, лучше саму книгу почитать, чем этот короткий конспект :)