С вашим тестированием скорее всего что-то не так via XP Injection

вот развёрнутый построчный коммент на сей шедевральный псто Николая Алименкова
http://xpinjection.com/2013/02/08/your-testing-is-not-ok-if/

Тестировщик не участвует в обсуждении и планировании задач, которые он будет потом тестировать.
Ну, это воистену, причём проблема в том, что на практике, особенно в больших проектах (то есть где реально много людей вовлечены в процесс разработки, а много, в моём понимании - это более 30 человек суммарной команды) все, включая отдел тестирования, руководствуются принципом "решать проблемы нужно по мере их поступления" (то есть - будет фича, то будем тестировать, не будет, то и хер с ней) и "моя хата с краю" (то есть, если можно уйти от ответственности за принятие решений, то это будет сделано, а если нельзя, то максимум ответственности будет переложено на кого-то ещё). Результат, как правило, удручающий: всё сделано через жопу и все винят друг друга в "недоработке". Причём, в таких случаях тестировщика выдвигают на конечную стадию оценки (то есть уже по результату) и его же делают виноватым, что "не вмешался раньше". Хотя это, очевидно, проблема не только тестировщика, но и всего процесса тестирования.

1. Существует отдельно стоящий отдел тестирования, в котором каждый тестировщик может тестировать разные проекты. 2. Часто время тестировщика расписано в процентном отношении между этими проектами.
Я разбил это утверждение на 2 части. Первая часть сомнительна. Как минимум в такой формулировке. Отдельно стоящего отдела тестирования не может быть в компании, ибо тестирование - проектно-зависимая активность. Но выделенный отдел тестирования на проекте, который может заниматься разными подпроектами - это реально и нормально. Это, конечно, не идеальный вариант, но имеет право на жизнь.
На вторую часть я ответил в комментарии к статье и дополню: уже само такое допущение является полным бредом даже в пределах одно проекта с несколькими подпроектами. Тестировщик во время одного цикла тестирования должен думать про один проект на протяжении всего цикла релиза, иначе его эффективность на обоих проектах будет не выше 50% на каждом, то есть то, что он делал бы на одном проекте за час, на двух будет делать по два на каждом, причём скорее всего он будет отдавать приоритет внимания на один из проектов и реальная картина будет где-то 80% эффективности на одном проекте и 20% на другом. Мало того - даже переключение между подпроектами туда назад чревато большими потерями времени, ввиду явлений "выбивания из колеи" и "возвращения в строй". Потери времени и концентрации тестировщика будут в любом случае и их практически невозможно не только убрать, а даже минимально понизить эффект. К сожалению, это понимают единицы, а в аутсорсе ваще преобладает принцип "платят - делаем", что, конечно, не повышает ни качество продукта, ни качество процесса, ни уровень профессионализма самих тестировщиков.

Разработчикам плевать на мнение тестировщика, для них он кажется бесполезным грузом.
Любые советы и рекомендации тестировщика проходят через менеджера, который потом пытается продавить их в команде разработки.
Отмечу, что, по моему опыту, "плевать на мнение" не равно "кажется бесполезным грузом". То есть, зачастую девелоперы смотрят на тестировщиков свысока и говорят "ты што, праграмист, што ты гавариж шо мине делать?", но добавляют при этом "занимайся своей работой - ищи баги". То есть "искать баги" по мнению программистов, а часто и менеджмента - это черновая работу, которую просто лень делать программистам и им нужны для этого тестировщики. Я, в общем-то, уже писал, что считаю, что как таковые тестировщики не нужны в виде Quality Control на финальной стадии разработки, но при этом нужен сильный Quality Assurance на этапах инициации разработки и как реалтаймовый контроль качества. Но при этом готов утверждать, что программисты не могут быть высококлассными тестировщиками по определению. Не хочу обидеть никого - тут простая психология и никакого мошенничества: насколько бы ни был критическим склад ума человека - всё равно он сам себе склонен прощать больше, чем другим. Потому для программиста признать, что его код - говно, а написал он херню - всё равно тяжело и избавиться от этого невозможно. Люди, отрицающие это - отрицают своё же существование, по сути. Задача тестировщика - не верить в то, что программист написал работающую программу, что в спеке всё хорошо, что юзер стори корректна, что в баклоге всё нужное учтено и что весь мусор выброшен и т.д. Недоверие, дотошность, граничащая с занудностью, анализ всего происходящего в разработке и понимание того, как устроен софт - вот имхо главные козыри тестировщика. А программисты хотят иметь кликеров, на которых можно свалить облажавшийся релиз и, что пока удручает лично меня очень сильно - многие тестировщики до сих пор считают, что им платят именно за это (особенно в аутсорсе).

В проекте есть отдельная команда автоматизаторов, которая разрабатывает собственный фреймворк для тестирования. При этом фреймворк не применяется в реальной жизни пока не будет полностью закончен.
Насчёт собственного фреймворка - зависит от продукта, хотя, полагаю, это более чем справедливо для веб-стартапов. Но ситуация, когда требуется свой фреймворк для специфического продукта также реальна.
При этом гораздо большей проблемой мне кажется отсутствие правильного отношения к коду автотестов. Ключевое слово в термине "код автотестов" - это не "автотест", а "код". То есть определённые скрипты, которые выполняют те или иные действия. И относиться к ним нужно так же, как и к коду, с некоторыми поправками.
Первое: код автотестов должен быть более читабелен, чем даже код самого приложения. Либо должен качественно комментироваться, чтобы на анализ "а что мы тут делаем" уходило минимум времени. То есть у автотестов должен быть дизайн. А если понять, что написано в автотестах может только автор - ценность этого теста будет крайне невысокая.
Второе: рефакторинг кода автотестов. Если продукт сложный, то у него будет фреймфорк огромный и как бы кто ни хотел - избавиться от накопления мусорного кода не получится. Автотесты должны регулярно рефакториться, чтобы была возможность их использования любым членом команды, при этом не приводя к ситуации "зачем тут миллиарды этого кода?".
Третье: а это уже из "личного опыта" - нельзя смешивать автотесты и ручные тесты. Это разные типы фреймворков, ручные тесты не являются кодом и их стоит рассматривать, как руководство к действию, а не как однозначный скрипт. Особенно это актуально в agile-разработке и с учётом популяризации context-driven school & exploratory методов тестирования. Зы: я говорю не о "применимости", то есть тестировщик может и даже должен проводить тестирование одновременно и ручное и автоматизированное (как там по Баху, ведь автоматизация - это средство в руках тестировщика), но смешивание в одну кашу инструкции для тестирования и код скриптов приведёт к жесточайшему аду и к плохому эффекту "автоматизаторы занимаются автоматизацией, а не тестированием, потому они не обязаны разбираться в функционале, а должны писать автотесты и запускать их".

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

По результатам тестирования тестировщика могут либо наказать либо похвалить.
и сюда добавлю:
Тестировщика могут поощрить за количество найденных дефектов.
При всей очевидности сказанного никак не могу перестать удивляться тому, что не до всех доходит.
Начнём с того, что бонусы не нужны. На эту тему лучше всего сказал Джоэль Спольски и мне добавить просто нечего - http://russian.joelonsoftware.com/Articles/IncentivePayConsideredHar.html
Второй пункт, что результаты тестирования без оценки контекста не дают никакого впечатления о реальной эффективности работы отдельного тестировщика. Я даже не уверен или стоит писать много, просто тем, кто это делает стоит задуматься, вот как оценивать такие результаты:
1) один тестировщик написал 10000 тесткейсов, нашёл один баг;
2) второй тестировщик прошёл 10000 тесткейсов первого - нашёл 50 багов, поправил 5 кейсов;
3) третий тестировщик нашёл 150 багов, важность 95% ниже 3 по 5-бальной шкале, написал 500 тесткейсов;
4) четвертый тестировщик нашёл 10 багов - 9 из них критичные, не проходил тесткейсы вообще, написал 50 тесткейсов, работал напрямую с девелоперами при отладке функционалов;
5) пятый тестировщик не писал багов, не писал тесткейсов, при этом вычитал всю user-end документацию, нашёл тысячи несоответсвий, прокомментировал всё непосредственно в документации, написал недостающие технические документы;
6) в функционалах, которыми занимались тестировщики 2 и 4 было найдено по одному багу после релиза уже непосредственными пользователями.
Как кого оценивать будем? ;).
И таких примеров можно привести тысячи. Оценка работы тестировщика, как и оценка работы программиста, кстати, не может зависеть от численных показателей и нужно учитывать много факторов при оценке работы (речь не о бонусах, а именно поднятии зарплаты в целом, а также позиции/уровня ответственности, так как вот эти пункты реально зависимы друг от друга).

Тестировщики работают по выходным, когда были закончены доработки в коде продукта.
Ой, как классно. Работа по выходным и в овертаймы вообще недопустима. Мало того - я бы рекомендовал штрафовать людей, которые работают более 8-ми часов в день (в том числе и тех, кто сидит на работе 12 часов, а выполняет работы на 8). Хотя, честно - самому иногда хочется работать во внеурочное время, потому что ты себе сел и что-то делаешь и никто точно не помешает. Но это хреновый аргумент - при хорошей организации процесса в целом (не только в тестировании - тут нужна глобально хорошая организация, иначе не взлетит) такого желания возникать не должно.

Отдел тестирования постоянно растет и тестировщиков становится все больше. Потом появляются тест лиды, менеджеры, но процесс не останавливается.
Тут depends. Проекты бывают разные. Разной сложности и разветвлённости структуры. И хоть аджайль их в целом, хоть скрамь частями, хоть канбань, хоть раком становись - нужны люди, которые будут "дробить" общую гору "всего" на отдельные понятные и анализируемые части.
Ещё раз обращусь к Джоэлю Спольски - http://russian.joelonsoftware.com/Articles/HumanTaskSwitchesConsider.html
Статья о программистах, но это в той же степени относится и к тестировщикам и вообще: "Хорошие менеджеры считают своей обязанностью устранение препятствий, мешающих людям концентрироваться на одном деле и добиваться результатов." Ну и скопипащу своё:
Есть определённый предел, после которого рост числа сотрудников в команде будет приводить просто к похабному исполнению работы «ветеранами» и спихиванием работы на «новичков». А ещё неплохо учитывать, что увеличение числа людей в команде приводит к падению производительности, то есть то, что 1 человек сделает за 3 дня, 2 человека сделают в лучшем случае за 2, а не за 1,5, а 3 – за 1,5, а не за 1.

Причём "дробление на части" и занятие бюрократией - это таки работа, причём не самая "комфортная", но если она поставлена правильно, то с одной стороны команда будет самоорганизована в плане выполнения работы, но не будет думать "чо это мне делать и откуда брать задачи и что вообще не хватает", так как хороший лид/менеджер (продакт овнер, скрам мастер, да хоть боингом назовите )))) ) будет это пропускать через себя и выдавать уже фильтрованную информацию.

У тестировщиков нет возможности получить сборку продукта на любую версию в системе контроля версий.
Серьёзная проблема, но почти неустранимая, если проект размером с, например, MS Word. Даже сам по себе, без всего остального офиса, но с доп компонентами. То есть сборки должны быть поставлены правильно и регулярно. О чём ниже.

Сборка продукта проходит руками и часто из-за этого тестирование завершается провалом.
Ну как бы кроме этого есть ещё проблема, когда невозможно БЫСТРО получить нужную сборку никакими методами. То есть хочешь вручную - 6 часов, запросить у девелопера - "занят", дождаться своей очереди на сборку - от 3 до 10 часов, если не сломается. И это считается нормальным на всех уровнях, кроме тестировщиков, а поменять ессесно только силами команды тестирования ничего нереально.

Тестировщику приходится отчитываться перед менеджером за низкое качество продукта.
Скажем так, под "отчитываться" можно понимать разные вещи. Я считаю правильной ситуацию, когда проводится оценка проведённых efforts и выясняется, что было не так, почему и принимается решение о том, как этого в дальнейшем избежать или, хотя бы, сократить риски.
Правда, я часто наталкиваюсь на фактор "гордости/стыда" за свою работу. Когда ты пытаешься выяснить детали проблемы или проанализировать с человеком в чём была проблема, а он либо тупо оправдывается, либо обижается, либо в упор не признаёт, если очевидно было, что он неправ (а раз не признаёт, то 100% допустит эти же ошибки в дальнейшем). Бороться с этим явлением крайне тяжело.

В вашей системе для управления дефектами их больше тысячи в открытом состоянии.
А самое ужасное - это если такая ситуация одобряется. И по личному опыту и знаю о ситуации во многих проектах в разных компаниях: решение не фиксить баги - дико распространено, даже если баги очевидны. Лично я дико ужасаюсь с практики реджекта багов по причине "был всегда" с последующим наездом на тестировщика "почему год назад не нашёл?" От такого руки опускаются и хочется тупо убивать. Значимость бага вообще не зависит от того, когда он найден, а решение не исправлять его может быть короткосрочным и также должно зависеть только от текущей ситуации на проекте и критериях принятия продукта в релиз. У меня приятель с одного крупного проекта рассказывал, что у них таким макаром реджектились сразу целые баглисты по всему функционалу. То есть недели тестирования, а иногда и больше тупо вылетали в трубу. Это адский ад.

В команде есть специальный человек, который отвечает за тест-план. Только он может вносить изменения в тест-план и принимать решения по нему.
Не совсем понятно, что Николай имеет ввиду под тест-планом. Если общий проектный документ, то изменения всё-таки в него должны вноситься консолидированно, с контролем версий, а вот обсуждение вполне должно быть публичным. Правда очень часто, как программисты не хотят учавствовать в организаторских активити (тех же скрам-митингах, считая это пустопорожним трёпом), так и тестировщики не хотят учавствовать в обсуждении и корректировании проджект-левел документации. Работа с конкретным функционалом им представляется единственно нужной и смысла в таких документах они не видят и не читают. К сожалению, это весьма устоявшийся подход в головах и менять его нужно в обязательном порядке.

Отчет о тестировании составляется руками и требует больших усилий.
Отсутствуют метрики тестирования, которые отслеживают по ходу разработки продукта.
Информация о результатах тестирования не доступна публично для всех участников проекта.
Три вместе ибо очень завязаны. Причём желательно, чтобы всё делалось в одной утилите (то есть утилита, где создан план = утилита в которую репортит каждый участник команды = утилита для получения общекомандных статусов), из которой было бы легко потом получить нужную информацию как тестировщику, так и программисту, так и менеджеру.



По мере появления свежих мыслей по темам, поднятым выше - to be continued...