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

Английский для тестировщиков
онлайн, начало 7 декабря
Chrome DevTools: Инструменты тестировщика
онлайн, начало 10 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря
Фотография

Что необходимо для внедрения автоматизации тестирования ПО


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

#21 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 января 2008 - 09:04

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


Да, Слава, ты прав ветка уходит... Только многие уже высказались по поводу когда и как, просто надо подытожить и все...
1. Экономическая целесообразность
2. Высокие критерии качества и надежности ("требования по надёжности 99,999% uptime")
3. Длительность проекта (чем дольше идет проект, тем выгоднее внедрять)
4. Желание и возможность ("структура приложения хорошо вписывается в организацию фреймворка" для тестирования)
5. Наличие квалифицированных автоматизаторов
6. Иногда - требование заказчика

Может что забыл, если так, то просьба дополнить или вычеркнуть лишнее.

Спасибо
  • 0
Алексей Булат
Про Тестинг

#22 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 24 января 2008 - 09:21

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

Что именно непонятно?

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

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

#23 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 января 2008 - 10:28

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


Лично я никогда не считал автоматизированное тестирование только тестированием GUI и через GUI. Это можно назвать верхушкой айсберга. Это еще можно назвать обычным черным ящиком. Но ведь есть же и белые и серые ящики... Но это уже не вопрос внедрения автоматизации, а вопрос уровня, на который вы ее внедряете.
  • 0
Алексей Булат
Про Тестинг

#24 Green

Green

    Гуру

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

Отправлено 24 января 2008 - 10:38

Второй критерий - размер (сроки) проекта. Если проект на три месяца и на полтора разработчика, то в автоматизации смысла нет.

Серёг, а если проект по какой-то там классификации идёт как 4D? Ну банально выводить картинку движения самолётов с терминала А на терминал В - делов на полтора месяца - но требования по надёжности 99,999% uptime. Так что я бы ещё как минимум убытки от простоя добавил - кстати так и считают зачастую в случае внедрения средств нагрузочного тестирования.


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

Тогда можно добавить еще один критерий - если ручное тестирование не эффективно. Например, можно и руками протестировать работу API интерфейса или веб сервиса, но не логично.

Однако!

Экономический фактор в выборе, на мой взгляд, - дело второе, так как любой работодатель для конкретного проекта стремится свести затраты к минимуму и обойтись доступными средствами. Обычно решение о приобретении средств производства (в нашем случае, средств тестирования) принимается на основании долгосрочного анализа использования этих средств и скорости их окупаемости (не только и не столько по конкретному проекту, сколько по всей деятельности компании).
  • 0
Гринкевич Сергей

#25 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 24 января 2008 - 11:15

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

Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)
  • 0

#26 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 24 января 2008 - 11:46

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

Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)

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

#27 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 24 января 2008 - 12:10

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

О, мы кажется приближаемся к сердцу тьмы, фундаментальной проблеме в производительности людей. Case, Вы хотели спорить, где Ваша аргументация?
  • 0

#28 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 24 января 2008 - 12:28

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

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

#29 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 24 января 2008 - 12:35

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

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

Проблема может быть в ограниченных возможностях воздействия на систему. Это во внутренних отделах компании, которая производит свой софт, есть возможность работать и с кодом. Но если брать аутсорс, то далеко не каждый заказчик рискнет расшарить свои исходники. Вот тогда только играем в "черный ящик", чтоб проект просто не сыграл в ящик. Опять же, тут возникает выбор, либо нагнать много народу и всё давить вручную, либо самую рутину поставить на конвейер. В обоих направлениях можно вертеться, оптимизировать процессы. Но все равно есть свои пределы и учитывать их крайне важно
  • 0

#30 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 24 января 2008 - 13:33

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

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


Пока я не запутался, я всё-таки напомню с чем я готов поспорить :)

Я готов спорить с тем, что:

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



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

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

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

Повторю свои мысли:
  • Качество кода на модульном уровне - сфера отвественности разработчиков. Тестировщик говорящий, что пишет unit-тесты с моей точки зрения занимается "утиранием соплей девелоперам" и заниматься этим не должен. Сама практика unit-тестирования пришла, как я понимаю, из практик экстремального программирования, TDD и подобных методик разработки кода, а не тестирования ПО.
  • Я не услышал как мы в данном топике понимаем "компонентное тестирование" (можем ведь и поразному - бывало). Если говорить о тестировании интеграции достаточно автономных модулей системы или функций бэкенда (закрытие месяца - кнопка одна, функциональности вагон, контрольных точек ещё больше) - да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся, так же как не относятся вопросы тестирования embeded систем, например.

  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#31 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 24 января 2008 - 14:24

Мне показалось, что Вы хотели поспорить про приоритеты видов автоматизированного тестирования с точки зрения приносимой пользы вне контекста своей статьи, т.к. компонентное тестирование в ней не рассматривается. Я что-то путаю?

Про то что в первую очередь, а что во вторую я бы поспорил.


Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.
  • 0

#32 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 24 января 2008 - 15:22

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

Я потому и не думал в статье рассматривать конкретные виды автоматизации - это holy war, пока никто не возьмётся что-то подсчитать в цифрах. Как обсчитать инвестицию в автоматизацию функционального тестирования или нагрузочного я знаю, как в UNIT-тестирование - нет. Что с чем сравнивать будем?

Пока нет возможности показать цифры - я не вижу как тут спорить, даже если в теории такой спор мне интересен.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#33 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 24 января 2008 - 15:23

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

По моему это попытка определить множество через множество. Что такое логическая единица кода?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#34 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 24 января 2008 - 16:28

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

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

Это так важно?
Короче, динамическое тестирование такой сущности - это модульное тестирование
UNIT unit1;INTERFACE    PROCEDURE Proc1;IMPLEMENTATIONPROCEDURE Proc1;    BEGIN         ...    END;END;
А такой - компонентное:
class Motto {  public static void main(String[] args) {    System.out.println("Java rules!");    }}

Компонентное тестирование иногда называется модульным, как дань традиции, которой много десятилетий. Разумеется это моя собственная терминология, но мне кажется западное сообщество её поддерживает, наверное, если бы это было не так, то я бы заметил при чтении всякой литературы.
  • 0

#35 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 24 января 2008 - 16:42

это holy war, пока никто не возьмётся что-то подсчитать в цифрах

А если качественную оценку поставить на место - перед количественной. Вы же специалист по бизнес-приложениям и работали на системах с пакетной обработкой, понимаете, что просто нажать кнопку старта недостаточно. Неужто в этом случае работа только через GUI - самый оптимальный вариант, если отвлечься от цены. И так ли уж редка эта ситуация? А системы отчётности, через GUI, без парсера отчёта?
  • 0

#36 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 24 января 2008 - 18:12

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

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

Unit-тестами этот слой - я бы назвал это тестированием бизнес логики - не покрывается. Средствами record-playback зачастую тоже в основном из-за сложности проверок получаемого состояния. Либо руками, либо создаваемыми отдельно для тестовых нужд приложениями (фреймворками).
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#37 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 07:48

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

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

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

Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?
Вообще, у меня к этому отрывку замечаний нет, я со всем согласен, но хотел бы обратить Ваше внимание на следующие обстоятельства:
1. Оказывается что в Ваших прошлых проектах кто-то ведь делал часть работы по обеспечению качества продукта ("это должно делаться разработчиками", "зачастую тестировалась внутренней разработкой"). Причём, Вы не умеете определить этот вклад количественно. Вы как-то учитываете это теперь, когда стали "дорогим консалтером" и вроде бы собираетесь нести ответственность за весь спектр? Хочу напомнить, что тестирование и автотестирование - это не самоцель.
2. Вообще говоря, в процитированном отрывке описана автоматизация того, чего не существует. По крайней мере, можно себе представить (лично я могу вспомнить) случаи, когда это справедливо.
3. Рискну предположить что дохлые лошади именно так и получаются - делается ставка на тестирование через GUI, когда критические с точки зрения качества продукта участки кода доступны только синтетически, люди чувствуют что занимаются фуфлом и перестают работать. При том подходе, который вы описали в процитированном отрывке, я могу понять как лошадь может получиться и как - не получиться, но как она может получиться дохлой - нет.
4. Всё что вы описали не обязательно делать в процессе разработки, всё то же самое может понадобиться проделать при приёмочном тестировании (если понадобится, и unit test тоже). Т.е. непонятно, что может объективно помешать этому, кроме слепой веры в то что "так не делается". Разумеется, делать это должны квалифицированние люди - "разработчики".
5. Непонятно также, при чём здесь процессы? Вот представьте самую плохую ситуацию (кошмар KaNoN-а): вы - аутсорсер, приходите к заказчику, вам дают стенд и какие-то доки, можно спрашивать у разработки, и надо автоматизированно протестировать какую-то функциональность (неважно даже, доступна она через GUI или нет). Какие после это Вам ещё нужны процессы чтобы были у этого заказчика? Можно список, в нём плюсиками отметить те, становление которых Вы случайно можете разрушить неверным движением, внедряя автоматизацию, и звёздочкой - такие, что Вы без них откажетесь работать, а будете требовать, чтобы владельцы бизнеса немедленно взяли под свой личный контроль их внедрение.

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

#38 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 января 2008 - 10:08

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

Что автоматизация тестирования не только GUI? Да, не только. И что?

Что unit-тестирование приносит больше абстрактной пользы - соглашусь если найдёте способ посчитать а до этого останусь при своём мнении. Причём не на пальцах как вы вроде бы описали ("возьмите", "прикинте"...), а в виде метода - лучше всего в виде ексельного калькулятора.

Желательно без фантазий на тему что делал я, а что "делалось само". Это вообще как-то странно, если вы полевой менеджер, а не теоретик, то в такие сказки не должны верить. Если что-то делалось, то наверное кто-то это толкал, организовывал, продавал клиенту, выцарапывал ресурсы. На вопросы "кто" и "зачем" предлагаю пофантазировать на досуге. Если фантазии вдруг окажутся не самым клёвым источником данных - просто снизойдите до спросить :) К вопросу про то что я не могу оценить вклад - да не вклад, а выхлоп.

С одной стороны вы пишите что согласны с тем что я написал и тут же двумя-тремя пунктами ниже пишите про своё понимание вопроса.

Про автоматизиацию того что не существует - повеселили. Описываемые системы существуют, подходы взяты из жизни - сильно поломал представление о реальности?

Unit-тестирование на этапе приёмки - это вы пошутили сейчас верно? Заказчик или сторонний подрядчик на стороне заказчика садится и покрывает код системы (который ему ещё кто-то должен дать, ага) unit-тестами: так и вижу, угу.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#39 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 января 2008 - 10:12

Добавлю про unit-тестирование на этапе приёмки.

Даже если кому-то нечего делать, потратили кусок времени и покрыли unit-тестами код поставляемой системы - при чём сделал это не поставщик в процессе разработки (ради чего собственно практика и создавалась, на минуточку). Поставили стенд, запустили сборку. Не собирается, unit-ы не проходят. А у поставщика собирается - вот незадача. И система собранная из этого же кода работает.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#40 a66at

a66at

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

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 11:10

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

Про "дорогих консалтеров" отсюда: http://software-test...a...ost&p=39704 :)

Что я пытаюсь доказать, я ясным образом уже дал понять - я поддерживаю уже упомянутый тезис SALar-а.

Что автоматизация тестирования не только GUI? Да, не только. И что?

Говорите, что автоматизация тестирования не столько GUI и я немедленно отвалю. Пока что из серьёзных аргументов от Вас слышно только аппеляции к личному опыту, о котором надо спрашивать отдельно. :) Т.е. тезис у Вас открыто висит, а аргументация в персональном порядке, авось и так прокатит?

К вопросу про то что я не могу оценить вклад - да не вклад, а выхлоп.

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

С одной стороны вы пишите что согласны с тем что я написал и тут же двумя-тремя пунктами ниже пишите про своё понимание вопроса.

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

Про автоматизиацию того что не существует - повеселили. Описываемые системы существуют, подходы взяты из жизни - сильно поломал представление о реальности?

В контексте статьи об автоматизации тестирования, заявление о том что нельзя автоматизировать то, что не существует, я посчитал эквивалентным утверждению: "Нельзя автоматизировать тестирование, если не существует тестирования (требований, тест-кейсов)". Привёл контрпример. Что Вы в статье на самом деле имели в виду? Что нельзя автоматизировать бизнес, если нет бизнеса? Что нельзя автоматизировать IT-систему, если нет системы?

Unit-тестирование на этапе приёмки - это вы пошутили сейчас верно? Заказчик или сторонний подрядчик на стороне заказчика садится и покрывает код системы (который ему ещё кто-то должен дать, ага) unit-тестами: так и вижу, угу.

Я вам объясняю-объясняю, что иногда (не так редко) это приходится делать практически в чистом виде, а вы не хотите понимать (и это уже не в первый раз). Что с Вами делать? Я вот не помню, то ли в те времена дебаггера в Query Analyser не было, то ли не умел им пользоваться, так нет проблем, заглушил, наставил "assert"-ов и протестил. Приёмка была, точнее сертификационное тестирование. Unit был, testing был. Другие виды синтетики, впрочем, много чаще случаются.
  • 0


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



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

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

Яндекс.Метрика
Реклама на портале