Управление автоматизации тестирования. Что является главным для Вас?

управление
#1

Все мы участвуем в разных проектах и как-то сталкиваемся с автоматизацией в той или иной стадии.

Кому-то надо начать автоматизацию, кому-то надо поддерживать существующую автоматизацию, а некоторые сразу разрабатывают какой-то фреймворк.

Представьте что вы являетесь лицом ответственным за организацию автоматизации. Что для Вас главное в управлении автоматизации?

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

#2

Добрый день

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

ПС.: Немного сумбурно, но если ответ вызывает вопросы, могу что-то пояснить на примерах.

#3

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

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

Ps главное это соотношение  потраченных  денег и полученного профита от тестирования.

#4

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

#5

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

Могут быть и выше, но тогда выгода будет в чем-то другом, как минимум  в этом:

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

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

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

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

Ps главное это соотношение  потраченных  денег и полученного профита от тестирования.

А вот к этому все и сводится.

#6

Про home-grown

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

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

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

Сначала выносят дублирующийся код в функции, процедуры или методы, потом в библиотечки, потом уже делают поделку устанавливаемой (в смысле, что можно поднять на нулёвой, чистой системе) и дистрибутируемой (могут взять и пользовать другие). Отделить кучу денег (оплаченного времени т.е.) на фреймворк от кучи времени на написание кода продукта и/или его тестирование часто не представляется возможным.

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

У нас в конторе были и выделенные создатели тестового тула (имеющиеся на рынке тулы часто тоже не фонтан, особенно для системного ПО). Но к тому времени, как тул подчистили от багов, ребят разогнали.

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

Но вообще это не по теме треда...

 

 

#7

предоставление информации заинтересованным лицам - это конечно заманчиво и необходимо

а как быть с тем, чтобы построить правильную автоматизацию?

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

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

а на счет покрытия тестов, а как быть если Вы приходите в проект, где просто нет подготовленных тестов? соответственно нет понятие, что такое 100% и как измерять вообще покрытие тестами?

 

#8

большой охват авто-тестами имеет как плюсы так и минусы

в моей практике, большое количество тестов все таки не выжывает

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

если много тестов падает, а потом оказывается, что тесты падают из-за того, что система очень часто меняется

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

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

 

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

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

#9

в целом это имеет место быть для больших проектов, где планы производятся на месяцы и годы вперед

там можно расчитать окупаемость самой автоматизации, и если не минус, то все отлично и делаем

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

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

а иногда могут удвоить ее стоимость

 

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

определить стоимость внедрения и поддержки определить не всегда удается

значит, надо акцентировать внимание на других характеристиках

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

#10

>> выгода может быть в чем-то другом

например, из твоего опыта, в чем еще измеряестя?

#11

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

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

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

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

 

#12

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

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

Но вот если приложение относится к какой-то специфичной предметной области - оказывается, что или надо несколько фреймворков срастить в некоего монстра Франкенштейна, или, ещё хуже, фреймворки плюс самобытные утилы от соответствующего вендора. А если это плагин типа коннектор "легаси система -> современная система", тут и восе без C++ бывает не обойтись (не верите? MAPI32).

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

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

Надо сказать, бывают и самовлюблённые авторы - имея трёх пользователей своего фреймворка, бегут выкладывать на гитхаб, чтобы вес мир в лице трёх-пяти пользователей со всего мира узнал про них. Бывает, как ступенька к достижению цели (вот как я, например). Или не знают, что есть альтернатива, которая добавляет 10% покрытия, но не имеет 10% процентов нужного покрытия, которое уже покрыто своим кодом (и чё тогда делать??).

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