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

[VitalyD]

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

Его руководство тоже хочет автоматизации, для чего договорилось с моим руководством что меня на 50% времени туда отправили.
Проект новый с нестабильным UI.
Юнит-тесты не пишуться.

Я никак не могу их убедить что в таком случае UI Тестирование избыточно, что если посадить человека тестировать после выхода блида, пользы будет куда больше.
Тем более что для этого продукта, на котором я раньше был 100% времени регрессионные UI тесты пишутся отлично, т.к. очень стабильный интерфейс - и пользы принесут всяко больше.
В общем помогите найти нужные слова, а? :)

[SALar]

http://blog.shumoos.com/archives/92
http://blog.shumoos.com/archives/138

[VitalyD]

Сергей, спасибо.

[Natalya Rukol]

Рассчитайте ROI - Return of Investment. Руководство это обычно больше всего впечатляет. Здесь Вы можете найти вариант таблички: http://quality-lab.r...I-Calculations/ Можете посчитать ещё проще. Но в итоге - укажите конкретные трудозатраты, которые будут ПОТЕРЯНЫ. После этого здоровые люди уже не будут с Вами спорить, гарантировано :) Неподкреплённые цифрами слова "эффективно"/"неэффективно", "правильно"/"неправильно" мало на кого действуют, и это логично.

[DrVal]

Здесь Вы можете найти вариант таблички: http://quality-lab.r...I-Calculations/

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

Опять же, при отсутствии авто-тестов количество прогонов резко сокращается :-)

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

[SALar]

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

Нет. Подход в корне неверный.
Правильный подход в первую очередь считает изменение времени проекта и полученную/упущенную прибыль, а только потом какие-то смешные трудозатраты. Расказывать надо в терминах "проход / связанный капитал / операционные затраты". Изменение первых двух принципиально влияет на финансовое состояние фирмы, а последнее опосредовано.

В вебинаре "Описание дефекта" я опосредовано касался этой темы. Без "маджонга и гейш", но с диаграммой и объяснением.

Ох. Неужели таки придется мне писать третью часть статьи?

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

Прикрепленные файлы

•  ROI_avtotest.PNG   27,5К   91 Количество загрузок:

[Pryanik]

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

Нет. Подход в корне неверный.
Правильный подход в первую очередь считает изменение времени проекта и полученную/упущенную прибыль, а только потом какие-то смешные трудозатраты. Расказывать надо в терминах "проход / связанный капитал / операционные затраты". Изменение первых двух принципиально влияет на финансовое состояние фирмы, а последнее опосредовано.

В вебинаре "Описание дефекта" я опосредовано касался этой темы. Без "маджонга и гейш", но с диаграммой и объяснением.

Ох. Неужели таки придется мне писать третью часть статьи?

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

Уж больно "идеальный" вариант у вас на диаграмме. Разработка автотестов совпадает с разработкой кода. Я правильно понял?

[ch_ip]

Уж больно "идеальный" вариант у вас на диаграмме. Разработка автотестов совпадает с разработкой кода. Я правильно понял?

А в чем тут проблема?

[Pryanik]

Уж больно "идеальный" вариант у вас на диаграмме. Разработка автотестов совпадает с разработкой кода. Я правильно понял?

А в чем тут проблема?

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

[SALar]

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

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


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

[Pryanik]

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

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


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

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

Затраты на тестирование возросли, но проект от этой автоматицации сильно выиграл.

В чем рассчитывается выигрыш? Во времени?

[KaNoN]

В чем рассчитывается выигрыш? Во времени?

Походу, учитывая название диаграммы ( Экономия времени ), таки да :-). В частности выигрыш получается за счет уменьшения времени отладки.

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

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

Ну, и наверное третьей части статьи.

[Natalya Rukol]

здесь ничего нет :)

[Pryanik]

В чем рассчитывается выигрыш? Во времени?

Походу, учитывая название диаграммы ( Экономия времени ), таки да :-). В частности выигрыш получается за счет уменьшения времени отладки.

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

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

Ну, и наверное третьей части статьи.

Тогда иначе переформулирую мои начальные высказывания сомнения насчет идеальной диаграммы.
Автор (имеется ввиду диаграммы) откуда данные: из книжек, головы или практики? Мои практические данные не совпадают с вашими в корне. Во-первых, я объяснил почему по времени процесс автоматизации начинается гораздо позже момент первоначального кодирования ПО. Во-вторых, процесс кодирования тестов может в несколько раз быть больше (даже для самого простейшего If --else надо 2 закодированных теста). В-третьих, почему на диаграмме при одинаковых ошибках/багах время работы по отладке ПО разное? В-четвертых, я нарисую диаграмму на своих данных и выигрыша по-времени не будет.

[KaNoN]

В чем рассчитывается выигрыш? Во времени?

Походу, учитывая название диаграммы ( Экономия времени ), таки да :-). В частности выигрыш получается за счет уменьшения времени отладки.

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

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

Ну, и наверное третьей части статьи.

Тогда иначе переформулирую мои начальные высказывания сомнения насчет идеальной диаграммы.
Автор (имеется ввиду диаграммы) откуда данные: из книжек, головы или практики? Мои практические данные не совпадают с вашими в корне. Во-первых, я объяснил почему по времени процесс автоматизации начинается гораздо позже момент первоначального кодирования ПО. Во-вторых, процесс кодирования тестов может в несколько раз быть больше (даже для самого простейшего If --else надо 2 закодированных теста). В-третьих, почему на диаграмме при одинаковых ошибках/багах время работы по отладке ПО разное? В-четвертых, я нарисую диаграмму на своих данных и выигрыша по-времени не будет.

1) Это высокоуровневые тесты появляются только после определенного времени. При использовании ТДД автотесты фактически кодируются вместе с программным кодом.
2) Тут с вами согласен, особенно учитывая, что те же юнит-тесты пишут сами разработчики и на это тратится доп. время.
3) Если автоматизация охватывает не только ГУИ, но и более низкие уровни, то те же самые баги обнаруживаются раньше и лучше локализованы. Например, одна ошибка на уровне ядра может вызвать десяток ошибок на уровне ГУИ, но она ловится одним юнит-тестом. Да и юнит-тесты обычно более быстрые по сравнению с более высокоуровневыми тестами.
4) Честно говоря, просто данных недостаточно. Имеет значение еще и процесс. Для разных проектов одни и те же подходы могут оказывать разный эффект

[Pryanik]

1) Это высокоуровневые тесты появляются только после определенного времени. При использовании ТДД автотесты фактически кодируются вместе с программным кодом.
2) Тут с вами согласен, особенно учитывая, что те же юнит-тесты пишут сами разработчики и на это тратится доп. время.
3) Если автоматизация охватывает не только ГУИ, но и более низкие уровни, то те же самые баги обнаруживаются раньше и лучше локализованы. Например, одна ошибка на уровне ядра может вызвать десяток ошибок на уровне ГУИ, но она ловится одним юнит-тестом. Да и юнит-тесты обычно более быстрые по сравнению с более высокоуровневыми тестами.
4) Честно говоря, просто данных недостаточно. Имеет значение еще и процесс. Для разных проектов одни и те же подходы могут оказывать разный эффект

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

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

[SALar]

Господа, я все понял. Без серьезного объяснения эта диаграмма имеет не более ценности, чем схема ядерного реактора для философов древней Греции.
Для понимания нужно знать принцип. У вас есть несколько вариантов:
1) ждать покая я это все это не напишу. Писать надо много и ждать придется долго.
2) Начать читать литературу по современному менеджменту. Начните с "Цель-3" и "Цель"
3) Как нибудь попасть ко мне или кому то другому на тренинг по этой тематике

[barancev]

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

Редиска! Лучше бы легенду к диаграмме сделал, правда! :)