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

[irishkaiv]

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

В общем вопрос: люди добрые подскажите к какому отделу в конце-концов должны относиться атотестеры?! Учитывая тот факт, что начальнику группы разработки ими заниматься совершенно некогда - как следствие куча недокументированных автотестов, которые делают непойми что и которым совершенно нельзя доверять.

[KaNoN]

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

В общем вопрос: люди добрые подскажите к какому отделу в конце-концов должны относиться атотестеры?! Учитывая тот факт, что начальнику группы разработки ими заниматься совершенно некогда - как следствие куча недокументированных автотестов, которые делают непойми что и которым совершенно нельзя доверять.

Зависит от того, какое тестирование автоматизируется. Если автоматическое тестирование проводится на уровне кода и/или тестируется непосредственно код, то, пожалуй, такая группа автоматизации должна относиться к отделу разработки.

Если же тестирование проводится на уровне GUI или приложения в целом (не вдаваясь во внутренности) и автоматизируется функциональное/перформанс тестирование на этом уровне, то тут лучше отдать автоматизаторов в подчинение отделу тестирования. При этом отдел тестирования может и должен предъявлть определенные требования к автотестам:
1) Автоматический тест делается на основе ручного теста - таким образом автотесты плавно замещают определенную часть тестирования, которая проводится на данный момент руками. Из этого требования выходит следующий пункт
2) Трассируемость - легко определить, какому ручному тесту сопоставлен автоматический тест. Это отражается в придании автоматическим тестам имен, соответствующих именам ручных тестов, на основе которых пишутся скрипты. Это имеет немаловажное значение в том плане, что некоторые тесты зачастую приходится корректировать. Установка взаимнооднозначного соответствия между ручным и автоматическим тестом незамедлительно влечет за собой необходимость корректировать автоматический тест при корректировках ручного. Вот для этого трассируемость нужна как воздух
3) Полнота автоматических тестов - каждый тест должен делать все действия и все проверки, предусмотренные ручным тестом, иначе данный автоматический тест делает и проверяет непонятно что.
4) Оформление - каждый автоматический тест должен быть оформлен в пригодном для чтения виде. Это важно потому, что автоматический тест пишется всего один раз, а используется множество раз, соответственно, в дальнейшем его больше будут читать, чем писать. Поэтому имеет смысл выработать стандарты написания скриптов, позволяющие создавать хорошо читаемые автоматические тесты, иначе их со временем практически невозможно будет поддерживать.
5) Устойчивость - автоматический тест должен прерываться только в случае выявления блокирующей ошибки в тестируемом продукте (когда дальнейшее выполнение невозможно или непонятно куда дальше идти). В остальных случаях выполнение должно продолжаться, а при обнаружении ошибок в отчет просто кидается сообщение об ошибке.
6) Взаимонезависимость - каждый автоматический тест должен быть способен выполняться как по отдельности, так и при массовом запуске (независимо от последовательности)

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

[irishkaiv]

1. Автотесты: тестирование проводится как на уровне GUI (чточно), так и происходит тестирование кода (наверно!).
2. По однозначности ручному тесту сказать не могу - см п.1
3. Полнота автоматических тестов - к сожалению как показала практика полноты тестов нет (( - тесты проверяют работу только на корректных данных
4. Оформление - оформления никакого нет, т.е. есть код, документов нету
5. Устойчивость - также не выполняется.
6. Взаимозаменяемость - тут уж совсем гибло - некоторые автотесты могут запускаться только в случае выполнения других.

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

Может еще есть какие предложения?

[Mike]

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

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

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

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

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

Наша стратегия, например, содержит и другие цели. А именно:

1) Автоматизировать, то что не может быть проверено руками или слишком трудоёмко для ручного тестирования
2) Максимально возможно автоматизировать ежедневное приёмочное тестирование
3) Находить большую часть регрессионных багов автоматически (то есть, багов в старой функциональности)
4) По возможности автоматизировать регрессионное тестирование наиболее важной с точки зрения бизнеса функциональности.

Для достижения п. 1 и 3 трассируемость не обязательна - некоторых ручных тестов может и не быть.

Да, автотесты надо документировать. И соотносить с ТРЕБОВАНИЯМИ. А вот соотнесение с ручными тестами, необходимо только для приёмочных тестов.

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

3) Полнота автоматических тестов - каждый тест должен делать все действия и все проверки, предусмотренные ручным тестом, иначе данный автоматический тест делает и проверяет непонятно что.

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

По п. 4 и 5. согласен, хотя полное выполнение п.5 больше похоже на утопию (по крайней мере для ВСЕХ типов тестов, и после каждого падения).

А вот далее опять есть вопросы:

6) Взаимонезависимость - каждый автоматический тест должен быть способен выполняться как по отдельности, так и при массовом запуске (независимо от последовательности)

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

[Mike]

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

Чтобы доверять автотестам, для начала надо чтобы автоматизаторы знали цель автотестирования. Если цель не сформулирована, то никакой ответственности автотестер не несёт по определению. Правда цель должна быть _эффективно_ достижима автоматизацией тестирования. И тот, кто управляет автотестированием должен четко понимать, где автотестирование эффективно, а где нет, и ставить цели соответственно.

[globe]

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

[irishkaiv]

У меня стоит задание - поднять тестирование данного продукта.
Автотестированием лично я никогда не занималась - знаю только основы (в принципе и не должна была заниматься!).
1. Я понимаю тот факт, что атотестеры тестирующие сам код продукта скорее относятся к группе разработки.
2. Я также понимаю тот факт, что автотестеры GUI и тестеры по ручному тестированию должны (в моем понимании) находиться в одном отделе (если кто так не считает скажите почему)
3. Я также понимаю, что доверять автотестам можно только в случае полного понимания, что каждый автотест делает - данного понимания у нас нет. Документов по автотестам у нас также нет, необходимо делать полный анализ автотестов.

Mike, к сожалению, ни я (пока еще), ни мое! начальство не вполне понимают цели автотестирования, этим надо заниматься сейчас и плотно.

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

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

[globe]

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

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

А также по поводу Вашего комментария KaNoN:
1. Автоматические (Unit) тесты, тестирующие код(?), пишутся разработчиками, а не специалистами по автоматизированному тестированию.
3. Все заинтересованные люди поставлены в известность, что НЕВОЗМОЖНО сделать автоматизированное тестирование ВСЕГО возможного функционала. Мне очень странно, что до сих пор этот вопрос всплывает.
5. Устойчивость... Ну тут Вы просто неправы. Есть понятия Recovery сценариев. И для некоторых типов ошибок они написаны.
6. По поводу взаимозаменяемости - ну тут за меня ответил Mike. Если знаете - как сделать все тесты независимыми - ну сделайте.

[irishkaiv]

1. никто не говорил, что те кто работал до меня что-то делал плохо - права на это я не имею и говорить так не говорила.
"куча недокументированных автотестов, которые делают непойми что и которым совершенно нельзя доверять." - это мое виденье - в данный момент для меня они непойми что и делают (я то не понимаю), поэтому я и писала - что нужен анализ. А если я не понимаю, что делает тот или иной автотест как я могу ему доверять?
2. под словом автоматические тесты KaNoN скорее имел ввиду автотесты, скорее всего основанных на GUI. Некоторые действительно думают что они должны совпадать с тестплином ручного тестирования - я так не думаю.
3. "Все заинтересованные люди поставлены в известность, что НЕВОЗМОЖНО сделать автоматизированное тестирование ВСЕГО возможного функционала." Это я точно не утверждала высказывание не моё.
Но наверно нужно учитывать тот факт: какой смысл в автотестах, если отдел по ручному тестированию, незнающий чтоже делают эти автотесты, проверяют тоже самое, что и автотесты?
Остальное смысл комментировать не вижу.
Mike действительно сделал ценные замечания и уточнения, которые я приму к сведенью.

[KaNoN]

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

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

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

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

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

Кроме того, есть "нерегрессионные" автотесты - с автоматической генерацией тест-кейсов и тестовых данных. Именно они-то и являются наиболее эффективными.

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

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

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

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

См. выше. И п.1 и п.2 высказаны из предположении о единственной цели автотестирования - замене ручного тестирования. Но
1) Эта цель _никогда_ не бывает достижима на 100%

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

2) Стратегии автоматизации, основанные на этой цели менее эффективны, так как сложно учитывать трудоёмкость разработки автотестов которая сильно вариируется в зависимости от автоматизируемых тесткейсов и применяемых проверок.

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

Наша стратегия, например, содержит и другие цели. А именно:

1) Автоматизировать, то что не может быть проверено руками или слишком трудоёмко для ручного тестирования
2) Максимально возможно автоматизировать ежедневное приёмочное тестирование
3) Находить большую часть регрессионных багов автоматически (то есть, багов в старой функциональности)
4) По возможности автоматизировать регрессионное тестирование наиболее важной с точки зрения бизнеса функциональности.

Ну и в чем же приведенная мной (точнее озвученная как приведенная мной) стратегия в этом не справляется?
Все это делается.

Для достижения п. 1 и 3 трассируемость не обязательна - некоторых ручных тестов может и не быть.

Да, автотесты надо документировать. И соотносить с ТРЕБОВАНИЯМИ. А вот соотнесение с ручными тестами, необходимо только для приёмочных тестов.

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

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

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

[KaNoN]

3) Полнота автоматических тестов - каждый тест должен делать все действия и все проверки, предусмотренные ручным тестом, иначе данный автоматический тест делает и проверяет непонятно что.

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

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

По п. 4 и 5. согласен, хотя полное выполнение п.5 больше похоже на утопию (по крайней мере для ВСЕХ типов тестов, и после каждого падения).

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

А вот далее опять есть вопросы:

6) Взаимонезависимость - каждый автоматический тест должен быть способен выполняться как по отдельности, так и при массовом запуске (независимо от последовательности)

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

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

[KaNoN]

А также по поводу Вашего комментария KaNoN:
1. Автоматические (Unit) тесты, тестирующие код(?), пишутся разработчиками, а не специалистами по автоматизированному тестированию.

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

3. Все заинтересованные люди поставлены в известность, что НЕВОЗМОЖНО сделать автоматизированное тестирование ВСЕГО возможного функционала. Мне очень странно, что до сих пор этот вопрос всплывает.

Почитайте внимательно пункт 3. Я не говорил о 100% покрытии тестами всего функционала. Я говорил о том, что все проверки, предусмотренные тесткейсом, реализованы в автоматическом тесте (рассматривается отдельно взятый тест). То есть то, что вы бы проверяли, проходя тест вручную, проверялось и автоматически. Тут следует сделать поправку на то, что некоторые виды проверок автоматически не реализуются или нецелесообразны. Но не более того.

5. Устойчивость... Ну тут Вы просто неправы. Есть понятия Recovery сценариев. И для некоторых типов ошибок они написаны.

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

6. По поводу взаимозаменяемости - ну тут за меня ответил Mike.

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

Если знаете - как сделать все тесты независимыми - ну сделайте.

Ну спасибки, удружили, а то как же ж я раньше без этого жил.

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

[KaNoN]

2. под словом автоматические тесты KaNoN скорее имел ввиду автотесты, скорее всего основанных на GUI.

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

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

И далее вы писали

какой смысл в автотестах, если отдел по ручному тестированию, незнающий чтоже делают эти автотесты, проверяют тоже самое, что и автотесты?

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

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

3. "Все заинтересованные люди поставлены в известность, что НЕВОЗМОЖНО сделать автоматизированное тестирование ВСЕГО возможного функционала." Это я точно не утверждала высказывание не моё.

Сказано оно не только не вами, но и не в тему, так что вам-то переживать по этому поводу нечего

[Darkus]

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

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

ТОЛЬКО юнит-тестирование должно проводиться разработчиками, т.к. это тестирование ими кода перед тем как передать продукт в отдел тестирования. Как правило юнит-тесты проверяют алгоритмы заложенные внутрь методов и кому, как не разработчику лучше знать как его метод должен работать. По хорошему он пишет mock объекты, которые изолируют его метод от внешней среды.

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

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

Переходим конкретно к вашему вопросу:

В общем вопрос: люди добрые подскажите к какому отделу в конце-концов должны относиться атотестеры?! Учитывая тот факт, что начальнику группы разработки ими заниматься совершенно некогда - как следствие куча недокументированных автотестов, которые делают непойми что и которым совершенно нельзя доверять.

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

[irishkaiv]

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

2. На какой основе решается писать автотесты?
2.1. Если какой-то функционал постоянно видозаменяется - есть ли смысл писать под них автотесты? Или стоит дождаться "стабильности" данного функционала?
2.2. Стоит ли сразу писать автотесты на новый функционал?

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

[Oldman]

А мне разъясняться с ним некогда...

Забудьте такие слова когда вы говорите о людях

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

Все остальные вопросы второстепенны

[irishkaiv]

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

Все остальные вопросы второстепенны

Повторюсь: автотестер не является моим непосредственным подчиненным - его непосредственным начальником является руководитель группы разработки.
Вопросы по увольнению или зачислению работника решается у нас начальником управления\департамента и непосредственным начальником отдела.
Почему они не договорились - я не знаю и не узнаю наверно.

У меня вопрос стоит в другом: Как организовать работу так чтобы уход одного сотрудника не приводило к тому что мы имеем.

[irishkaiv]

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

Все остальные вопросы второстепенны

Повторюсь: автотестер не является моим непосредственным подчиненным - его непосредственным начальником является руководитель группы разработки.
Вопросы по увольнению или зачислению работника решается у нас начальником управления\департамента и непосредственным начальником отдела.
Почему они не договорились - я не знаю и не узнаю наверно.

У меня вопрос стоит в другом: Как организовать работу так чтобы уход одного сотрудника не приводило к тому что мы имеем.

[irishkaiv]

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

Все остальные вопросы второстепенны

Повторюсь: автотестер не является моим непосредственным подчиненным - его непосредственным начальником является руководитель группы разработки.
Вопросы по увольнению или зачислению работника решается у нас начальником управления\департамента и непосредственным начальником отдела.
Почему они не договорились - я не знаю и не узнаю наверно.

У меня вопрос стоит в другом: Как организовать работу так чтобы уход одного сотрудника не приводило к тому что мы имеем.

[Mike]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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