Приходите на HL++ 2008 (http://www.highload.ru/).
Я как раз собираюсь рассказать про этот вопрос.

Тестирование - это специфичная деятельность. Она может поглотить любой объем выделенного времени и его окажется недостаточным.

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

Если говорить о более научном подходе, то существуют методики оценки трудозатрат на программирование. Их общая логика сводится к следующему. Делается ревью всей функциональности и она условно делится на 3 (в разных методиках по разному) категории: легкая, средняя и сложная. Каждая категория имеет свой вес в человеко -часах (разные методики различают разные коэффициенты, они могут быть выделены для конкретной технологии, отрасли промышленности и т.п.). Дополнительно применяется поправочный коэффициент для конкретной компании, полученный на основании анализа статистики по большому числу проектов. Потом все перемножается и выводится приблизительная оценка трудозатрат на реализацию каждой функции. Сумма затрат по каждой функции = трудозатраты по проекту.

Некоторые методики включают в себя общий коэффициент затраты на тестирование, некоторые - нет. Введите свой коэффициент и вычисляйте затраты на тестирование.

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

В связи с совпадением по датам с РИФ+КИБ вынужден отказаться от посещения конференции. Жаль.

Блин! И тоже вынужден отказаться по той же причине.
SQA - это хобби, а Интернет - это работа.

Сорри за оф-топ.

Блин! И тоже вынужден отказаться по той же причине.
SQA - это хобби, а Интернет - это работа.

Интересно было бы взглянуть на ваш доклад, как раз собираюсь делать аналогичный для кастомеров нашей компании.
Вы его не собираетесь у себя в блоге выкладывать?

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

Green, а что с переводом глоссария ISTQB получилось? Проект заглох или закончился?

PS
Прошу прощения, если просто пропустил какое-то знаковое мгновение.

Ни то и ни другое.
Временно заморожен.
Но разморозка зреет.

Кстати, это не работает фича по публикации для коллективного доступа.
Но фича по расшариванию и коллективной работе над документом - работает.

Просто для доступа нужен Гугловский экаунт.

Механизм прост:
1. Заходите в гугловский экаунт или в почтовик Gmail.
2. Слева вверху есть ряд линков - жмете на Documents
- открываются Гугл Докс и вы там видите нужный файл и полным доступом на редактирование.

Кто подписывался на файл с НЕ гугловского ящика, можете выслать мне гугловский - я расшарю для вас документ по новой.

P.S.
В личных сообщениях форума не нашел фичу по добавлению файла в сообщение.

Ни то и ни другое.
Временно заморожен.
Но разморозка зреет.

А можно его разморозить?
Конкретно сейчас интересует перевод глоссария. Старые ссылки не работают (http://spreadsheets....w...F3yLA&gid=1), а копии глоссария у меня нет.
И именно сейчас она мне понадобилась.
Хорошо бы просто бросить личное сообщение с Excel файлом, если можно.

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

Сейчас пошел посмотреть и оказалось, что действительно убрали такую фичу в Докс, как расшаривание табличных файлов. Блин! А было так удобно.
Если кому надо, могу выслать полуфабрикат pdf файлов (импорт в экселовский формат почему-то тоже не сработал).

Коллеги,

два сообщения.

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

2. Я решил не раздавать всем желающим не законченный перевод.
Давайте закончим работу!

есть ли у вас план товарищ Alfa? :)

Не понял. Какой план имеется ввиду?

план как закончить данный процесс с нужным результатом, правда вопрос скорее всего к Green

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

Ни от кого ответа пока не получил.
Либо все заняты, либо...

Да, получилось экселевским файлом сделать.
Вышлю.

Только слишком сырой пока словарик.
Будем доделывать!

Ищу альтернативу гуловским докам.
Посмотрю на майкрософт.

Слава, ну ты, блин, конспиратор.
Написал бы по русски, для чего тебе это надо и все сразу бы поняли.

Со своей стороны могу скинуть ссылку на сообщество по тайм-менеджменту, которое организовал Глеб Архангельский. Там много всякого материала, статей. Уверен, ты там сможешь найти что-нибудь подходящее.
http://www.improvement.ru

Коллеги!

Есть ли у кого опыт организации управленческого учета и трекания задач на Jira?
Речь идет как о проектной работе, так и о сервисной.

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

Почему Jira?
Патамучта.
Так сложилось исторически. Теперь нужно из ручного миксера сделать электрический кухонный комбайн.

Сотрудник для удалённой работы на дому.doc

Лохотрон.
Не тратьте время.

Но, возможно, это и пирамида. Я не знаю.

Коллеги,

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

Все остальное работает по стандартной схеме.

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

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

У меня вопрос к специалистам, опытным инженерам качества ПО.

Спасибо за ответы...

2 galogenIt

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

Ну, что ж. Это тоже вариант. Однако Вы выбрали один из наиболее длинных путей - набивание шишек через свой опыт за счет своей компании.

Для решения проблем вашей компании необходимо понимать ряд вещей:

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

2. Повышение качества - это переход к сервисной структуре работ.
Качество возможно только если процесс станет типовым. Если каждый раз все делается по-новому, то и уровень качества будет не предсказуемым.

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

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


Как можно поступить в Вашей ситуации?

1. Развивать область автоматизации тестирования.
Отличный вариант. И, в первую очередь, лично для Вас, как специалиста, заинтересованного в своем профессиональном развитии.

2. Отдать работы на аутсорсинг.
Быстро, но не очень дешево. Зато проблема решается сразу же и, к тому же, лично у Вас есть возможность взять этот процесс в свои руки и повысить квалификацию за счет опыта аутсорсеров.

3. Нанять консультанта и организовать работы "внутри".

Если ваше начальство, вдруг, заинтересуется 2-м и 3-м вариантами, то можете скинуть письмо в личку. С этими пунктами могу помочь.

Чего нет
1. ясного понимания цели.

GalogenIt,

Вы сейчас пытаетесь найти ответы находясь внутри системы. Для того, что бы решить Вашу задачу необходимо "подняться" над проблемой.

Тестирование - это способ выявления дефектов. Оно не обеспечивает качество, оно только дает информацию для улучшения программы (в этом плане говорят, что тестирование это элемент обеспечения качества).

Проблемы могут быть нескольких типов:
1. Сделали не то, что хотел заказчик (не корректная постановка задачи)
2. Реализация расходится с поставленной задачей (сделали не то, что заказали)
3. Сделали не так, как это общепринято (не учли стандарты)
4. Сделали не так, как удобно
5. Исправили то, что было не правильно, но внесли новую ошибку
6. Все работало по отдельности, но когда собрали - что-то перестало работать
Каждый аспект контроля реализуется посредством своего типа проверок (видов тестирования).

То, чем Вы занимаетесь сейчас - это регрессионное тестирование (неоднократное повторение одних и тех же тестов). В результате прогона таких тестов Вы можете выявить только 5 и 6 типы проблем. Следовательно, Ваша основная задача на данном этапе - это проверка целостности билда (что он работает и в нем ничего не поломалось из старой функциональности). Другими словами, Вам нужно сформировать набор автотестов, которые вы будете выполнять каждый раз, когда будет готова новая версия (сборка) продукта.

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

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

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

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

Приобретения опыта за счет фирмы - ну не совсем согласен. И я получу велью, но и фирма его получит.

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

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

Автоматизация - это так же как и разработка. Необходимо точно формулировать задачи, требования, иметь ресурсы и инфраструктуру. Если все это есть, то автоматизация тестирования - перспективное инвестирование в один из аспектов повышения качества продукта.

Поясню свою мысль примером. Никто не сомневается, что unit testing повысит уровень качества продукта. Однако, далеко не каждая организация способна ввести у себя unit testing в качестве постоянной практики, так как это связано с целым рядом телодвижений, которые зависят от уровня зрелости компании. Если компания уже готова к введению этой практики, то результат будет положительным. Если нет, то хоть поставь по автоматчику "над душой" у программиста, качество от этого не улучшится (хотя при этом будут писаться тесты и создаваться видимость бурной деятельности). Необходимы поэтапные мероприятия с целью "взросления" компании до нужного уровня.

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

Вижу необходимость пояснений.

Я привел пример с unit testing именно потому, что это не тестировочная активность. Не хотел, что бы была прямая связь тестирования с примером, чтобы продемонстрировать проблему в целом и избежать "скатывания" на обсуждение плюсов и минусов частной практики.

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

2 Roman,

Алексей (LeshaL) написал ключевую фразу всего поста.

Метрики по конкретному проекту не могут помочь в повышении уровня качества другого проекта напрямую.

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


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

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

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


Вывод

1. Метрики демонстрируют результат управленческого воздействия. Они нужны для управления конкретным проектом, через измерение реакции на конкретные приемы (это могут быть требования процесса, некие сложившиеся правила, распоряжения руководителя и т.п.).

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


Каким образом метрики одного проекта могут быть использованы в работе по другому проекту?

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

Время на написание "шапки" поста очевидно потрачено зря.

Ничего не бывает зря! Просто иногда мы не можем интерпретировать результат.


Роман,

попробуйте дополнить свою информацию всего лишь несколькими строчками. А именно, к каждой метрике допишите конкретное лицо, которое будет получать данную метрику (необязательно фамилию, можно роль в проекте или уровень позиции в компании), способ ее интерпретации и критерий успешности.

Например,
"Количество «псевдо-исправлений» (Re-open после Fixed) – количество багов"

Описание метрики: Тестировщик во время проверки новой версии продукта (релиза), при проверке дефекта, имеющего статус "исправленный", выявил, что дефект не исправлен. Он переоткрывает дефект со статусом "re-open".

Получатель метрики: руководитель проекта

Интерпретация: наличие дефекта со статусом re-open означает, что разработчик, назначенный на исправление дефекта,
а. либо не исправил дефект, но при этом поставил статус исправлено,
б. либо код с исправленным дефектом не попал в выпущенную версию программы.

Критерий: Следует принимать меры в случае, если
а. дефекты данного типа превышают 3 в новой версии продукта;
б. если дефекты со статусом "re-open" проявляются у одного и того же разработчика на протяжении двух релизов подряд.

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

Например
Если разработчик допустил дефекты со статусом "re-open" на протяжении трех релизов, то руководитель проекта должен подойти к нему и "дать по голове", что бы "вправить мозги на место".

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

Вот только после этого у вас появиться инструмент в виде системы метрик, который ВОЗМОЖНО будет работать. Но если он будет "пробуксовывать" в применении некоторых показателей, то, во всяком случае, можно будет понять что и где не работает.

сфера систем физической безопасности, разработка программно-аппаратных комплексов для управления такими системами. Если есть гражданство РФ + не было ранее гражданства других стран + супруга гражданка РФ (и то же ранее не была гражданкой других стран) то можем пообщаться

К сожалению, гражданством не вышли. :-)
У меня и у супруги гражданство РБ.

2 Green
Честно говоря не очень понял почему вы полагаете что бэкграунд сисадминов и программиста навредит ПМ-у, а бэкграунд аналитика, архитектора и тестеровщика наоборот поможет.

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

А Вы задумывались, почему на СТО владельца авто не пускают внутрь тех станции во время ремонта его автомашины? Чтобы он не приставал со своими глупыми советами к профессионалу. Но ПМ (который 2-5-10 лет уже активно не программирует) почему-то считает, что он лучше знает как и что нужно делать и лезет своими кривыми руками прямо во внутрь "двигателя".

2 alkozeltzer,

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

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

2. Главным критерием проектной работы служит удовлетворенность заказчика. Поэтому необходимо понимать, как ПМ будет управлять ожиданиями заказчика и воздействовать на них с целью повышения удовлетворенности:
- способы и методы организации коммуникаций с представителями заказчика
- управление рисками
- презентационные навыки
- широкий профессиональный кругозор
- коммуникационные навыки

Что может быть плюсом для соискателей?
- навыки аналитика
- навыки тестировщика
- знание основ построения архитектуры (необходимо уметь говорить и обсуждать эти темы)
- и просто богатый жизненный опыт

Что не может рассматриваться как преимущество
- навыки программиста
- навыки системного администратора
- навыки администратора баз данных

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

P.S.
Кстати, а что за позиция? В какой сфере?
Я все еще в поисках самого лучшего места работы. Так что могли бы пообщаться.

Сергей, Юлиана, я работаю в аутсорсинговой компании, и я не разделяю вашу точку зрения :)

Да, про школы верно замечено. Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Кстати, эпиграфом к этой заметке служат вот такие слова Майерса, которого вы пытались привлечь как адвоката своей стороны:

"... one usually encounters a definition such as, 'Testing is the process of confirming that a program is correct. It is the demonstration that errors are not present.' The main trouble with this definition is that it is totally wrong; in fact, it almost defines the antonym of testing."

- Glenford Myers,
Software Reliability: Principles & Practices, 1976

Леша,
есть такой старый анекдот.

Принимают двоечника в комсомол и проверяют, как подготовился. Спрашивают:
- Знаешь, кто такой Ленин?
- Кто такой Хрущев?
- Кто такой Брежнев?
А двоечник абсолютно ничего не знает. Мычал он что-то, мычал, а потом спрашивает в ответ:
- А вы знаете Петьку хромого, Ваську косого и Фильку с пятой?
- Нет? Ну, так и нечего меня своими авторитетами пугать!

Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html

Первично то, что у нас есть задача и ее реализация. Нам нужно сравнить то что получилось с тем, что должно было получиться. Другими словами, сложить 2+2 и получить 4. Если мы складываем 2+2 и получаем 5, то это ошибка. В случае программы - дефект. Цель тестировщика - сравнить левую и правую части уравнения и сделать вывод о наличии или отсутствии ошибки. Если этот процесс не является поиском дефектов, то что это?

Теперь представим, что есть нечто сложнее, чем 2+2=4. Допустим по требованиям/спеке дано f(x)=y. По результатам эксперимента получается, что f(x)=2y. Где ошибка?
Если механически сравнить левую и правую сторону, то ошибка всегда получается в программе. А может ошибка в спецификации и правильно f(x)=2y, что и подтвержденено результатами эксперимента. Надо чуть чуть думать, просто сравнить не получается.
...

Вначале 2 LeshaL,
а кто сказал, что часть уравнения, с которой нужно сравнивать, - это программа?
А думать нужно всегда, даже когда просто гвоздь в стену заколачиваешь.


Теперь для двух Алексеев и всех остальных,
давайте рассмотрим типовое поведение тестировщика.

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

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

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


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

В итоге, все нужно выволить на заказчика и пусть он решает, что нужно исправлять, а что нет, дефект это или не дефект и т.п.

Правильно! Сто раз правильно!

Но что это меняет? Суть работы не меняется. У тестировщика есть его ожидания (тестовая модель) и если они не совпадают с действительностью (с моделью реализации), то он оформляет отчет. А уже потом, по этому отчету принимается решение - исправлять или не исправлять, дефект или фича, говорить заказчику или не говорить и т.п.

Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.