Перейти к содержимому

Фотография

Отдельная группа по автоматизации - плюсы и минусы


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 42

#21 Portable_Force

Portable_Force

    Новый участник

  • Members
  • Pip
  • 21 сообщений

Отправлено 09 декабря 2004 - 13:13

Почему такая неприязнь к разработчикам (Вы правы

Разработчики, конечно, считают, что они никому ничего не должны

B) )
Так вот пусть пишут, а мы тестим авто тестами но тестировщик должен сидеть в команде разработчиков
(Возвращаясь к нашему вопросу) :D
  • 0

#22 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 09 декабря 2004 - 13:13

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

А ещё подробнее можно? В чём суть "интерактивности"? И что значит "аддитивный"?
Или просто слова красивые? :)
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#23 Portable_Force

Portable_Force

    Новый участник

  • Members
  • Pip
  • 21 сообщений

Отправлено 09 декабря 2004 - 13:23

Можно и так сказать

Или просто слова красивые

Так проше понять :D
  • 0

#24 Portable_Force

Portable_Force

    Новый участник

  • Members
  • Pip
  • 21 сообщений

Отправлено 09 декабря 2004 - 13:29

НЕ Согласенн :o :rolleyes: :o

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


Просто это человеческий фактор -- они и считают что пишут всегда правильно
В той комадне разработчиков где полностью функционирует TDD все ок !!

Я бы скзал это культура разработки ПО.
  • 0

#25 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 09 декабря 2004 - 13:56

В той комадне разработчиков где полностью функционирует TDD  все ок !!

Это демагогия :)
Впрочем, тему TDD лучше продолжить в отдельном недавно созданном топике, а здесь вернуться к обсуждению достоинств и недостатков выделения группы автоматизации.

Я бы скзал это культура разработки ПО.

Культура, уважаемый, включает в себя также обычную грамотность. Пишите, пожалуйста, аккуратнее, читать трудно! :)
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#26 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 13:57

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

Да, но не в этом суть.

Я смотрю все тут без меня ушли от темы тописка в сторону. Я писал о большой компании, с множеством разных проектов, как догосорочных, так и короткосрочных. Еще просьба не забывать, что автоматизация включает в себя не только отдельные виды тестов, которые можно и вручную сделать, но и то, что вручную сделать нереально (перебор всех данных из большого массива, например), а также рутинные дела, напрямую к тестирвоанию не относящиеся но помогающие в работе существенно. Я например написал очень прсотой скрипт для деплоинга репортов в Crystal Report на SilkTest за пару часов, а он юзается по сей день от билда к билду и операция занимет пару минут по сравнению с получасом и более (репортов там много).

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

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

Спасибо.
  • 0

#27 Doveangel

Doveangel

    Постоянный участник

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 09 декабря 2004 - 13:59

М-да...
Мне лично кажется что для хорошей работы отдела необязательно разделять группу тестирования на 2: отдел ручного тестирования и автоматизированного. Т.е. это было бы неплохо.. но и бех этого можно качественно работать. Если тестер довольно опытный - хорошо знает стандартные роботы для автоматизации и быстро может написать тест- то почему бы ему в свободное от скриптов время не протестить что-нить ручками? Во-первых -и для него смена работы (в этом наша привилегия по отношению к программерам - мы можем и кодить и тестить))), и для команды иногда лишние руки. Я не могу понять - почему человек, хорошо автоматизирующий должен только автоматизировать. Конечно, если запланировано достаточно скриптов - то пусть автоматизирует. У нас например нечасто приходиться сталкиваться с регрессионным тестированием с количеством прогонов больше 10.. т.е чаще все таки удобнее тестировать руками. Так что даже 1 автоматизатор иногда бы отдыхал - что не выгодно для предприятия. Может здесь играет роль специфика предприятия и объемы продукта.
Мое мнение - надо смотреть конкретные случаи. В идеальном случае- разделение - это хорошо, на практике оно не всегда себя оправдывает))
  • 0

#28 Doveangel

Doveangel

    Постоянный участник

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 09 декабря 2004 - 14:10

Ещё меня заимтересовала фраза насчет того, что тестер должен сидеть в команде разработчиков... Это как?

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

#29 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 09 декабря 2004 - 14:17

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

На счет этого у меня есть более гибкое решение.
Где и как храняться договора физически? В какой - то БД?
Если в БД, то все просто. Один раз руками создаем договора. Пишем скрипт, на сиквеле, который перенесет их в схему, которая не меняется. А когда надо, можно переносить обратно. Вот и все :) Время на создание договоров в сотни раз быстрей.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#30 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 09 декабря 2004 - 14:23

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

Тогда здесь можно говорить и об автоматизации процесса тестирования вообще. А это, наверное, тема отдельного топика.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#31 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 09 декабря 2004 - 14:28

В данном же топике, я так понял, мы все таки говорим о функциональном автоматизированном тестировании. И выделение отдельной структурной единицы для автоматизированного тестирования (в постановке вопроса) предназначается именно для этого.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#32 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 14:28

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

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

#33 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 14:37

Я не могу понять - почему человек, хорошо автоматизирующий должен только автоматизировать.

Потому что в то время пока он отдыхает от автоматизации, кто-то на другом проекте, извините за выражение, тра-ся с новыми для него проблемами и изучает тулы... ;)
  • 0

#34 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 14:41

Ещё меня заимтересовала фраза насчет того, что тестер должен сидеть в команде разработчиков... Это как?

это вы у меня видели фразу? Где? что-то не помню чтоб я такое писал... :huh:

До формирования репортов в кристалле я не додумалась))


Речь шла не о генерации, а о deployment, то есть открытие репорта и прописывание ему нужной базы. И так для всех...
  • 0

#35 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 09 декабря 2004 - 15:41

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

На мой взгляд, выделение авто тестеров в отдельную группу - это прямой путь к automation testing workflow (Андрей, то о чем ты спрашивал не так давно).

Днем пишем автотесты, ночью тестируем приложение, утром получаем результат.

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

#36 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 15:56

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


Понятно, что в принципе можно, но вопрос то был что лучше и почему.

Пора, наверное, высказать свои соображения и посмотреть на реакцию общественности.

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

Итак, плюсы:
1. Узкая специализация и большая эффективность
2. Скиллы совершенствуются
3. Разрабатывается фрэйм-ворк, как утилитарные функции (классы), так и более узкоспециализированные – для целей тестирования и повторно используемые в разных проектах и как следствие меньше изобретенных велосипедов B)
4. Каждый специалист при необходимости и возможности может участвовать в нескольких проектах
5. Специалисты «растут» не только в смысле знания конкретных тулов, но и технологий и могут учить других
6. В целях повышения квалификации можно браться за проекты (если позволяет загрузка) где автоматизация экономического эффекта не дает, но которые интересны с точки зрения неизведанных технологий (.NET, Java, нестандартные контролы, etc.)
7. Еще что-то, что я забыл? :rolleyes:

Минусы:
1. Те, кто наряду с скиллами в автоматизации, является еще и просто хорошим тестировщиком, уже не могут «вести» большие проекты и руководить проектными группами
2. Создание такой группы для руководства зачастую означает, что надо брать наиболее продвинутых в автоматизации людей и «выдергивать» их из тех проектов, где они «выросли», а тут может быть, что человек еще «тянет» на себе кучу других тасков или вообще лидирует команду...
3. «Автоматизаторам» приходится вникать в проектную специфику настолько насколько нужно для успеха их работы и не погрязнуть в текучке :( . А это иногда непросто – нужно подключаться к проекту, брать что надо, потом ждать чего-то от членов проекта (доки, environment, свежий билд, etc), переключаясь на другое... По опыту работы той же группы нагрузочного тестирования могу сказать, что в ней нагрузку (пардон за каламбур) на членов группы планировать сложновато – то нету, то как навалится... Однако тут есть выход – правильно управлять такими “дырками” и направлять людей на разработку библиотек, общих подходов, документирование (точнее доделку хвостов в этом направлении), тренинги, etc.
4. Дык че-то я не вижу больше минусов... :rolleyes:


Фу, пальцы в клочья, глаза в кучку. :blink: Хватит, жду реакции.
Спасибо всем, кто дочитает до конца. Остальных просьба не беспокоить :P
  • 0

#37 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 16:00

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

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

#38 Andrei Kulabukhau

Andrei Kulabukhau

    Активный участник

  • Members
  • PipPip
  • 92 сообщений
  • Город:Minsk, Belarus

Отправлено 09 декабря 2004 - 16:08

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

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

#39 Portable_Force

Portable_Force

    Новый участник

  • Members
  • Pip
  • 21 сообщений

Отправлено 09 декабря 2004 - 16:24

http://www.msdn.micr...ag/html/tsp.asp
  • 0

#40 PavelB

PavelB

    Постоянный участник

  • Members
  • PipPipPip
  • 169 сообщений
  • Город:Санкт-Петербург

Отправлено 10 декабря 2004 - 07:43

Те, кто наряду с скиллами в автоматизации, является еще и просто хорошим тестировщиком, уже не могут «вести» большие проекты и руководить проектными группами


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


Количество пользователей, читающих эту тему: 4

0 пользователей, 4 гостей, 0 анонимных