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

[Andrei Kulabukhau]

Привет всем.

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

У кого какие мысли? Буду рад обсудить.

Спасибо.

[PavelB]

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

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

[Green]

У меня есть опыт организации работ по этим двум подходам.

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

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

[van]

Дополню варианты, описанные Green'ом, еще одним, который у нас применяетсяна практике.

Специфика нашего подхода основана на том, что группа тестирования создавалась с нуля и, что самое главное, спусть год после начала разработки системы. До этого серьезно тестированием никто не занимался и, естественно, никаких тестов никто никогда не писал. Речи об автоматизированных регрессионных тестах вообще никогда не было. Точнее, только речь и была :)

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

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

[Portable_Force]

Отдельная группа по автоматизации не нужна! :o :o :o :o
Минусы:
1. Увеличения срока разработки ПО, следовательно и стоимости.
2. Для отдельной группы авт. тест. надо что бы требования к разработки не менялись долгое время. B) (В реали этого не бывает)

Так что если у вас есть много денег как на пример у Microsoft то можети делать отдельно :D

[Taka]

Поддерживаю всех ораторов и не согласна с Portable_Force!

1. В любом проекте прежде, чем начать автоматизировать тестирование, нужно подсчитать затраты на автоматизацию. если затраты на автоматизацию больше, чем на ручное тестирвоание (обычно, это недолгосрочный проект), то и не надо ничего автоматизировать, проще протестить ручками.
Если будет выделена специальная группа по атоматизации, затраты для "новичка" будут намного больше затрат на автоматизацию для опытного автоматизатора.
2. Конечно же, нужно автоматизировать не всё подряд, а в первую очередь основную или критичную функциональность, например, тесты BATS (build acceptance test suite). Требования к данной функциональности могут меняться редко, соотв-но, скрипты нужно будет исправлять редко.
Если автоматизацией будет заниматься опытный человек, то на исправление уйдёт мало времени.

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

Плохо, что на повышение знаний по автоматизации совершенно нет времени, всё приходится осваивать в ходе проекта... Но мы над этим работаем :)

[van]

Давайте постараемся внести ясность в такой вопрос - какие задачи ставятся перед группой автоматизированного тестирования? А потом продолжим дебаты :)

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

[Portable_Force]

Taka :D

Не согласен

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

:blink:
В недолгосрочных проектах частота выхода релиза (билда) выше чем в долгосрочных. И тут следовательно и надо Авто. тестирования. (Смотри XP-progamming) :D

По поводу

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

<_< :blink: Или у вас столько опыта что вы может на глаз определить что лучше Авто или Руч. (то это просто СУПЕР). Но такой методя Я еще не где ни видел и ни слышел
. Я согласен что можно косвено определить но и то уже проанлизировать готовый проект :D B)
Если есть метода поделитесь ПЛИЗЗЗЗЗЗЗЗЗЗ!!

[PavelB]

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

[Green]

В недолгосрочных проектах частота выхода релиза (билда) выше чем в долгосрочных. И тут следовательно и надо Авто. тестирования. (Смотри XP-progamming) :D

Или у вас столько опыта что вы может на глаз определить что лучше Авто или Руч. (то это просто СУПЕР). Но такой методя Я еще не где ни видел и ни слышел
. Я согласен что можно косвено определить но и то уже проанлизировать готовый проект :D B)
Если есть метода поделитесь ПЛИЗЗЗЗЗЗЗЗЗЗ!!

Все с точностью наоборот!
:P

Я запросто, на глаз могу определить следует или нет автоматизировать какой-либо функциональный тест. И опыт здесь не основополагающий фактор.
B)

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

Важен принцип! Чем чаще повторяется тест, тем его шансы быть автоматизированным выше.

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

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

[Portable_Force]

Извените но разделения дискусии не к чему ни привидут!! :o :o :blink: <_<

Вопрос можно поставить так
1. Процесс разработки ПО интерактивный Cool!!!!!!!! :D :D
2. Аддитивный процесс :( :(

[Portable_Force]

Не согласен :o :o :o :o

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

У вас может быть в одном тест каесй несколько десятков переборов состояний объекта или еще жухе билд выходит каждый день. Это просто ..... :ph34r:

[Green]

Давайте постараемся внести ясность в такой вопрос - какие задачи ставятся перед группой автоматизированного тестирования? А потом продолжим дебаты :)

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

Зная специфику работы Андрея могу уточнить, что он имел ввиду автоматизацию функционального тестирования. Так что речь идет о втором случае.

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

[van]

Вопрос можно поставить так
1. Процесс разработки ПО интерактивный Cool!!!!!!!! :D :D
2. Аддитивный процесс :( :(

Не совсем понял, что имеется в виду...
Поясните пожалуйста.

[Portable_Force]

Где имно не нашел :( :(

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

Лмнку дайте :D

[Portable_Force]

интерактивный - процесс часть функционала тестируется при помощи TDD а часть через тестирования GUI (на тестироввание отводится только ночь ) :rolleyes:
Аддитивный процесс - обычный . <_<

[Green]

Не согласен :o :o :o :o

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

У вас может быть в одном тест каесй несколько десятков переборов состояний объекта или еще жухе билд выходит каждый день. Это просто ..... :ph34r:

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

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

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

Координально другая логика автоматизированного тестирования заложена в тулах, тестирующих на основе модели. С этим Вам лучше обращаться к Алексею Баранцеву (barancev).

[Portable_Force]

Да Сергей что вы говорить будет работать в тоери :D на практике все не так :( <_< :(

Sorry

[barancev]

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

Лмнку дайте :D

Какие там линки, это типичное мнение тестировщика, на которого начальство хочет повесить ещё и разработку unit-тестов.

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

Разработчики, конечно, считают, что они никому ничего не должны и они тоже по своему правы, им не тестами отчитываться. Если им TDD помогает - пусть пишут тесты, если мешает - пусть не пишут.

[barancev]

Да Сергей что вы говорить будет работать в тоери :D на практике все не так :( <_< :(

Sorry

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

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

И unit-тесты вместе с TDD и XP и прочими "шустриками" не меняют дела кардинально. Unit-тесты даже ещё реже оперируют с тестовыми последовательностями, чаще дело вообще ограничивается отдельными "точечными" тестами.