Сергей ты упорно пишешь программа я же все таки считаю что правильнее программный продукт

Честно говоря, даже не задумывался. Но сейчас действительно возник вопрос.
Есть три варианта (больше пока не пришло в голову):
1. программа
2. программный продукт
3. программное обеспечение

Есть ли в их толковании существенная разница, которую стоит специально отражать в наших переводах?

Wide Band Delphi

Я ЗА

Кстати, только сейчас заметил, что в определении есть слово test. :-(
Получилось следующее:

"Экспертная техника оценки, целью которой является получение более точного значения трудозатрат на тестирование исходя из совокупного опыта членов команды."

Как то раньше не сталкивался с этим понятием, так что до конца не уверен, что правильно его понял.

Примечание: Узел графа потока управления представляет из себя простой блок.

Роман, спасибо.
Исправил.

Упссс...
Дублирование предыдущего сообщения.

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

Жизнеспособна ли такая схема:

Клиент создаёт запрос через вебинтерфейс
Запрос вешается на ответственного
2 случая:
1) Ответственный понимает, что вопрос лажовый - просто юзер что-то не понял. Объясняет ему и закрывает запрос
2)
- Ответственный сам разобраться не может. Перенаправляет запрос на тестировщиков. Помечает в хелпдеске, что запрос в работе
- Тестировщики проверяют, имеет ли баг место. Заносят в трекер
- Баг планово (уже зависит от менеджера проекта) исправляется
- В трекере фиксится. Проверяется. Выпускается очередная версия
- В хелпдеске запрос закрывается

Реально ли такая схема будет работать? Или есть более оптимальные варианты?
Спасибо

Будет.

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

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

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

Я не совсем понял, что значит "...при этом не загружая страницы...". Но вариант решения может быть таким:
1. Пишите скрипт, который "пробегает" по коду каждого файла-страницы (это ведь текстовый файл) и собирает линки в массив (либо записывает в файл). Если линки не текстовые, то скрипт может "вытягивать" их из базы или формировать по заданному алгоритму.
2. После этого другой скрипт берет по одному линку из массива, формирует и отправляет запрос к серверу. При этом запрос к серверу может быть сформирован таким образом, что бы не загружать весь код, а только проверить наличие страницы. Ответ от сервера покажет - жива ли страница.
3. Формируете отчет со списком линков и кодом ответа сервера.

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

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

Однозначно, зарплата должна быть на уровне "рынка". И изменяться она должна на уровне рыночных трендов. Тогда работодатель будет "как большинство". И что дальше? Что дальше, если все вокруг такие же? Именно поэтому, зарплата не является стимулятором производительности в долгосрочной перспективе. Помимо этого, подавляющее большинство людей считают, что им никогда не платят столько, сколько они заслуживают.

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

Я бы определил следующие мотивирующие факторы, помимо денег:

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

2. Сложность (комплексность, новизна) и, как следствие, интересность задач. Без предыдущего пункта это, как правило, является демотивирующим фактором.

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

4. Перспективы роста по служебной лестнице. Как ни крути, а более громкое название позиции всегда являлось очень сильным стимулом. Я как-то читал про результаты опроса менеджеров в США. Более половины опрошенных отметило, что они предпочли бы более "громкую" должность против повышения зарплаты. Социальный статус человека в обществе никто не отменял и более высокое положение на работе подразумевает более высокий статус в обществе.

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

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

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

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

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

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

Коллеги!

Всегда должна быть цель!

Какая цель у вашего пост-мортен митинга?
Что вы хотите получить по итогам митинга?
Кто именно будет являться потребителем метрик?
Вот получит этот чувак несколько показателей и что дальше?

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

С пониманием целей вопросов нет.
И свои идеи по необходимым метрикам есть.

Просто хочется посмотреть на готовые велосипеды :-)

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

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

То, что вы наработали и продумали - характеристика зрелости вашего проекта / компании. Это означает, что есть основа для применения. Есть согласованность в понимании и в желании применять в повседневной работе. Все остальное - от лукавого и для вас не только не подойдет, но и будет вредно, так как попытка применить не свое решение приведет к потере времени, денег и положительного настроя.

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

Коллеги,

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

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

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

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

Коллеги!

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

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

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

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

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

2 galogenIt

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


Роман,

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

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

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

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

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

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

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

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

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

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

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

2 Roman,

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

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

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


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

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

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


Вывод

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

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


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

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

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

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

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

Что-то все затормозилось.... давайте реанимировать активности...

Полностью согласен.
Только у меня сейчас высокая загрузка по работе и не остается времени на другие увлечения.
Буду улучшать планирование.

Мне кажется не совсем верным перевод и unit и component как компонент. В моей практике unit testing всегда было модульным тестированием.

Полностью согласен.
Исправил на "unit" - модуль.

[*]План приёмосдаточных испытаний (ПСИ)

Если мы говорим о российских реалиях, то вместо ПСИ лучше использовать ПМИ (программа и методика испытаний - документ по ГОСТу 34).

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

Коллеги!

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

Есть несколько основополагающих трендов:

1. Рост продаж во многом зависит от автоматизации.
Именно поэтому аппетиты бизнеса ВСЕГДА растут.
Кто нибудь слышал о том, что бы какое-нибудь бизнес подразделение вдруг сказала:
- Да ну эту автоматизацию. Мы лучше вернемся опять к большим гросбухам и огромным справочникам. Будем сами разносить бумажки, а писать перьевыми ручками - просто сплошное удовольствие.

2. Бюджеты на 2008 год уже сформированы. В большинстве случаев деньги зарезервированы.

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

Как эти тренды могут повлиять на ситуации с ИТ?

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

Что отнести к массовым позициям? Программистов и админов. И в первую очередь программистов, работающих с массовыми языками программирования - С# и Java (в меньшей степени, так как есть еще один тренд роста проектов, использующих ПО с открытым кодом, которое в большинстве случаев на Java. Даже американские военные начинают программы по использованию открытого софта, чтобы снизить свою зависимость от конкретных поставщиков.). Но в первую очередь - VB, которых в Америке пруд пруди.

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

3. Традиционно, страны с высоким уровнем зарплат и соц обязательств будут стремиться перенести наиболее дорогостоящие (рутинные) операции в страны с более низким уровнем заплат. Как следствие повышение интереса к аутсорсингу.

Исходя из этого у нас в России будут наблюдаться следующие тенденции:
1. По-прежнему будет активный рост ИТ компаний, специализирующихся на аутсорсинге.
Сейчас хорошее время для создания своей компании, специализирующейся на оказании аутсорсинговых услуг.

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

Следовательно будет рост спроса на ИТ специалистов в городах миллионниках.

Например, в Москве гипотетическая компания будет обходиться в 1 млн (ежегодные затраты) - это примерно 15-20 специалистов. Продать ее можно за 2-10 кратную стоимость (это весьма приблизительно и во многом зависит от того, что именно и сколько она продает). Но такая же компания в регионе может обходиться в 2-3 раза дешевле. Однако стоить она будет примерно столько же или не намного меньше.

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

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

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

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

GalogenIt,

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

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

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

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

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

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

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