Сообщений в теме: 33

[Mike]

Так народ, пришло время поставить точки над i.

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

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

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

Что вы называете "логикой"? Алгоритмы и интерфейсы модулей надо тестировать соответстующими тестами (юнит-тестами, компонентными, API-тестами). Компонентные тесты пишут обычно разработчики. API - тестеры.

А почему бизнес-логику нельзя тестировать через GUI неясно. Приведите развёрнутую аргументацию.

[globe]

irishkaiv
Ну что Вы вводите людей в заблуждение. Исторически сложилось, что все роли были прописаны в одном отделе: и разработчики, и тестировщики, и аналитики, и менеджер. Соответственно начальник отдела - менеджер проекта.
Смена руководителя проекта привела к образованию параллельных отделов и развалу группы тестирования в старом отделе.
А автотестер из этого проекта ушёл, если я не ошибаюсь, в июле, а не сейчас уходит.
Никто не обижается, просто будьте честны, когда подаёте информацию для остальных.

[Darkus]

На какой основе решается писать автотесты?

Читайте внимательнее, я дал ссылку на пост.
...
To Mike

Тест-план _включает в себя_ автоматические тесты, но автотесты не должны писаться на основе ручных тесткейсов.

Ещё раз повторюсь. НЕТ ручных тесткейсов. Тесткейс - это СЛУЧАЙ тестовый, который нужно протестировать. Если вы решите его автоматизировать -то будет автоматический тест, нет - будет ручно.

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

Что значит - неудобно? Это его обязанность.

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

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

Что вы называете "логикой"? Алгоритмы и интерфейсы модулей надо тестировать соответстующими тестами (юнит-тестами, компонентными, API-тестами). Компонентные тесты пишут обычно разработчики. API - тестеры.

А почему бизнес-логику нельзя тестировать через GUI неясно. Приведите развёрнутую аргументацию.

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

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

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

[irishkaiv]

Соответственно начальник отдела - менеджер проекта.

- начальник какого отдела? Моего? Начальником моего отдела являюсь я сама.
Начальником отдела разработки является менеджер проекта.
Группа тестирования (занимающаяся автотестами) входит в отдел разработки.

Смена руководителя проекта привела к образованию параллельных отделов и развалу группы тестирования в старом отделе.

Может мне тоже начать цепляться ко словам?

А автотестер из этого проекта ушёл,

Это было до меня. Я не знаю какие были обязанности у того сотрудника.
Я не думаю что нам вообще стоит общаться по данному вопросу и уточнять всю систему и историю в целом на данном форуме.

Никто не обижается, просто будьте честны, когда подаёте информацию для остальных.

Мне нужны были ответы - я их получила. И то что мы с вами (globe) обсуждаем к теМе совсем не относится.

И не стоит цепляться к словам других людей.

[Mike]

Давайте ещё раз.
Тест-кейс - описывает что нужно протестировать и как протестировать.
Вопрос - что нужно протестировать - не относится к автоматизации.
Вопрос - как протестировать - относится.
Но вначале то мы пишем что тестируем, а потом уже решаем как....

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

То есть, всё-таки сначала решаем, что автоматизируем, а что тестируем вручную, а потом только пишем подробный тестплан с подробно документированными тест-кейсами, а не наоборот. Именно по этому пункту у нас и был спор с коллегой KaNoN

Тестирование GUI - это завершающая часть тестирования, когда в принципе уже все готово внутри (ядро) и осталось ответить на вопросы, например:
1. А правильно ли мы вывели управляющие элементы наружу?

Мы говорили о тестировании ЧЕРЕЗ пользовательский интерфейс, а не о тестировании самого пользовательского интерфейса.

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

То что нельзя проверить через GUI надо проверять через тот UI, который есть (коммандная строка, API - например SOAP, COM, CORBA , и т.д.). Но в любом случае, если мы используем метод "чёрного ящика", то тестировать надо через интерфейс (графичиский или нет, не важно - через какой есть, через такой и тестируем). А соответствие спецификации, всё же, корректнее проверять именно методом чёрного, а не белого ящика. Белым ящиком проверяется интерфейсы модулей (то есть низкоуровневая архитектура) и отдельных функций, но не то, соответствует ли система спецификации.

[KaNoN]

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

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

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

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

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

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

Ну, я об этом сказал выше

Теперь ещё раз о стремлении автоматизировать существующие ручные тесты.

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

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

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

[KaNoN]

(globe @ 16.10.2007, 17:00)
5. Устойчивость... Ну тут Вы просто неправы. Есть понятия Recovery сценариев. И для некоторых типов ошибок они написаны.

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

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

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

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

Если подумать - это не единственный способ.

Зато он есть и не требует дополнительных усилий, а также достаточно хорошо интегрируется в уже существующий процесс тестирования

Цитата(globe @ 16.10.2007, 17:00)
6. По поводу взаимозаменяемости - ну тут за меня ответил Mike.

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

Какая разница, как ТЕХНИЧЕСКИ организована подготовка среды и данных - в виде отдельного тестого скрипта, или в виде процедуры, вызываемой тестовым скриптом? Или вы считаете что надо по 40 раз (для каждого теста) выполнять длиннющую процедуру подготовки данных только для того, чтобы он был "независимым"? Чем независимый тест-сет хуже независимого тестового скрипта? Опять категорическое утверждение.

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

[ArtemRudenko]

Очень у вас интересный диалог получился.
В силу своего опыта(правда не такого уж и большого) и высказанного KaNoN я склонен выбрать его сторону как наиболее правильную ( хотя это слово не очень подходит, скорее актуальную/реальную на сегодняшний момент времени) - особенно с учётом "пост-советской" действительности и менталитета.
Что касается тестов и прописывания того, что будет автоматизировано, а что нет, к сожалению, ни на одном проекте из тех, где я работал, не было изначально и мысли о том, что будет вообще что-то автоматизироваться и, соответственно, как сказал KaNoN, сначала все тесты 'ручные', а потом, уже не важно используя какие метрики, происходит выбор из всего множества того, что будет автоматизировано с толком для проекта.
И кто сказал, что сделать тесты независимыми сложно - подходов существует просто масса, выбирай любой(от банального внесения данных напрямую в базу, создания требуемых данных через GUI, через сервисы и тп.), плюс никто не заставляет делать такие глобальные тесты, для которых в отдельный момент времени нужны большие объемы новых сгенерированных данных, каждый кейс при случае можно разбить на множество подкейсов и так до необходимой детализации.
Что до recovery - всё должно быть разумно, и время, затрачиваемое на написание этих сценариев не должно быть настолько велико, чтобы стать самоцелью автоматизации - на мой взгляд, выход опять-таки в декомпозиции и тестов и функционала, хорошо, когда один тест выполняет внутри себя некое множество независимых подтестов, тогда мы просто можем закрыть и поставить ошибку для одного подтеста и выполнять дальнейшую работу, либо останавливать выполнение этого теста в принципе. Реализация, когда один скрипт вызвает некоторое количество других скриптов, каждый из которых в свою очередь реализует набор тестов, как мне показалось,- один из самых оптимальных и достаточно легко реализуемых подходов(с MB к сожалению пока не было возможности познакомится очень близко - но панацей от всех бед я ёё не считаю). Да и для реализации MB что не говорите, а уровень ёё разработчика должен быть весьма высоким, а таких специалистов, скажем так, не очень много, плюс многие достаточно консервативны, чтобы менять проверенные, используемые техники.
И как бы то ни было, почти каждую ситуацию надо рассматривать как отдельно взятую, потому что приведение к единому знаменателю не будет являться самым правильным решением, так как иначе был бы один тул, один способ сделать и тд, мы же имеем кучу средств, массу разновидностей тестов, данных, приложений,технологий, да и банально множество фирм, использующих разные стандарты, разных заказчиков и многое многое другое. Даже, просто если брать автоматизацию как таковую, то мы встретим не один и не два подхода, а множество(DDT,CSDDT,K-WD,ODT,MB и ёщё и ёщё).

[Mike]

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

Если подумать - это не единственный способ.

Зато он есть и не требует дополнительных усилий, а также достаточно хорошо интегрируется в уже существующий процесс тестирования

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

Какая разница, как ТЕХНИЧЕСКИ организована подготовка среды и данных - в виде отдельного тестого скрипта, или в виде процедуры, вызываемой тестовым скриптом? Или вы считаете что надо по 40 раз (для каждого теста) выполнять длиннющую процедуру подготовки данных только для того, чтобы он был "независимым"? Чем независимый тест-сет хуже независимого тестового скрипта? Опять категорическое утверждение.

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

Я не говорил что все тесты связаны каждый друг с другом. Один раз готовим данные (в начале), потом запускаем остальные тесты в произвольном порядке (предполагается что они не влияют друг на друга). Если тесты логически друг с другом не связаны, но при этом влияют друг на друга ("портят" среду тестирования), то да, прийдётся каждый раз сначала подготавливать средУ. А как это делать - повторюсь, детали реализации.

[KaNoN]

Зато он есть и не требует дополнительных усилий, а также достаточно хорошо интегрируется в уже существующий процесс тестирования

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

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

• возможностью доступа к тем или иным объектам,
• возможностями языка (VB Script, 4Test, Java, TSL и другие языки используемые в средствах автотестинга на уровне ГУИ по-разному приспособлены к задачам, возникающим при написании автоматических тестов) и библиотек,
• ну и естественно с уровнем знаний людей, которые эти тесты пишут.

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

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

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

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

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

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

Если тесты логически друг с другом не связаны, но при этом влияют друг на друга ("портят" среду тестирования), то да, прийдётся каждый раз сначала подготавливать средУ. А как это делать - повторюсь, детали реализации.

И это хорошо, когда придется перезапускать целый пакет, который выполняется несколько часов вместо 10-20 минут работы одного теста? А насчет реализации, то вы привели в качестве примера, который может нарушить указанный мной принцип взаимонезависимости тестов, некоторый тест, который с точки зрения логики и восприятия таковым не является (тест должен тестировать, а такой подготовительный этап сам по себе тестом не является), соответственно хорошим примером не является. И зачастую, подобные компоненты выносят немного отдельно и их запуск описывают в отдельных процедурах подготовки среды. В свое время у нас так перед стартом тестирования запускался скрипт, который помимо копирования конфигурационных файлов еще копировал модельную базу данных. Соответственно, непосредственно к системе тестов данный "тест" не относится. Если же делается подготовка данных для конкретного теста, то это более чем нормальное явление, так как у тесткейса всегда должны быть определены начальные условия и ресурсы. Поэтому ваш данный пример я посчитал неудачным в качестве нарушения принципа взаимонезависимости, на основании которого не стоит делать выводы о несостоятельности или ущербности данного подхода (особенно если учесть, что на этапе эксплуатации он избавляет от целого множества неприятностей), что я и указал человеку, выразившему в опосредованной форме данное мнение.

[LeshaL]

Привет! Мне кажется что вашу проблему можно разрешить не задаваясь вопросом "кому подчиняется команда автоматического тестирования". Как я понимаю - основная проблема в том, что вы не уверены в качестве самих автоматических тестов. Чтобы подтвердить ваши опасения вы можете измерить code coverage - на сколько хорошо эти автоматические тесты покрывают код продукта. Т.о. у вас на руках появятся факты в виде цифр. Вы легко сможете обнаружить области вообще не покрытые тестами (или недостаточно покрытые). Дальше вы, как человек отвечающий за качество всего продукта, можете посоветовать людям пишущим автоматические тесты обратить внимание на эти непокрытые области кода. В результате - не важно кому подчиняется команда автоматического тестирования, не важно взаимозависимы автотесты или нет, не важно ГУевые они или нет. Но вы можете достигнуть желаемой цели, направив писателей автотестов в правильном направлении.
ИМХО: если все public API методы покрыты на 80% - то это уже очень неплохо. Причем в независимости от того вызывался метод из теста или из кода программы.

[KaNoN]

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

...

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

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

[irishkaiv]

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

Я с вами полностью согласна.
Собственно я уже разобралась в том как было всё реализовано:
В некоторых командах, разработчики не проверяют тот код, который идет на сборку билда - у нас этим занималась группа тестирования, в которую ко всему входили автотестеры. Как результат появились автотесты разных видов.
Так как Группа тестирования была расформирована (с уходом последнего человека) автотестестированием занимается уже мой отдел: мы взяли на себя автотесты незанимающиеся тестированием непосредственно кода.

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

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

[KaNoN]

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

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