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

[galogenIt]

Спасибо за ответы

Тестирование оказывается далеко не тривиальное дело :)

[Mila]

Понятно, думаю, заказчик тут непричем. Скорее ПМ мне не позволяет лезть в эту сторону. Логика по его мнению такова - я буду слишком много времени тратить на разработку подобных тестов, поскольку сначала мне придется узнать структуру данных, понять как там все работает, составить и отладить соответствующие запросы...

На самом деле он не прав, т.к. в реальности все сводится к подзадачам, реализацию которых программист может объяснить за полчаса. (Например, чтобы отчет был виден в базе надо заполнить три-десять таблиц такими-то данными - и тестер уже готов к тому, чтобы их заполнять, если знает SQL). Какие-то процедуры и сценарии можно вобще выдрать из кода и запускать отдельно с разными параметрами - это тоже не отнимет много времени. Вобщем, тут надо донести до ПМ, что при подобном тестировании совсем не обязательно изучать код каждой функции со всеми заморочками, главное - уметь их использовать.
Но с другой стороны, если в базе данных и библиотеках происходят довольно примитивные вещи, то вобщем-то и заморачиваться с этим наверно и не стоит. И определять, есть ли смысл вобще влезать в эти места, нужно с участием программистов.

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

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

[galogenIt]

Спасибо, Mila

На самом деле он не прав

Если ОН не прав смотри пункт первый :)

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

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

Какие-то процедуры и сценарии можно вобще выдрать из кода и запускать отдельно с разными параметрами - это тоже не отнимет много времени.

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

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

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

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

[Mila]

А если требуется посмотреть как составляется этот отчет в системе? Т.е. ситуация такая - данные в БД верны, а выборка не верна. Причем проблема не в алгоритме выборке, а просто кто-то поправил реализацию некоего метода, который используется в отчете?

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

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

Нет, это не unit-тестирование. Unit-тесты рассматривают объекты в изолированной среде. Для этих целей используются всякие заглушки... например, вместо реального объекта, который подключается к базе данных, берется moc-объект, который просто возвращает "все ок" и к базе не обращается. Их прохождение еще не гарантирует, что все будет работать и в комплексе и с реальными объектами. То, что я описывала - это функциональное тестирование. Чаще всего это применяется к библиотекам. Все необходимое подключается к отдельному приложению (можно и собственного изготовления) и вызываем методы с разнообразными параметрами, смотрим, что возвращает или какой объект изменяет. Даже если Вам придется подключить все, что есть, кроме пользовательского интерфейса - ничего страшного. Эффективность от этой деятельности в некоторых случаях может быть гораздо выше, чем реализовывать это через gui. Все это зависит только от архитектуры и весьма индивидуально. Но если это возможно, то процесс настройки и создания много времени не отнимает.
Сорри, что применила слово "выдирать".. не расчитала.

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

А что именно повысит качество и устойчивость? Работоспособность какого-то отдельного модуля? Если Вы автоматизируете биллинг (что-то там было из нескольких шагов), и что это даст? Только сэкономит время? А сколько? Полчаса работы тестировщика? Или целый день? А там вобще были ошибки за последние полгода или его еще будут существенно изменять? Насколько это критично для системы в целом? На каком уровне там появляются ошибки (только в интерфейсе или в логике работы)?
И еще пачка подобных вопросов.
Иначе можете полгода автоматизировать справочники, хотя никто уже и не помнит, в каком году там нашли последнюю ошибку, да и пользователи их уже не открывают. А все проблемы остались. Ну или бесконечно проверять, что если у пользователя фамилия из 15 букв, начинается с согласной, он работает в отделе1, и вот когда шеф в отпуске, то у нас не создается отчет, потому что программист Вася когда-то сделал в коде опечатку.
Может гораздо интереснее проверить, что на таких-то наборах данных проходит правильная выборка хотя бы для всех старых отчетов, т.к. именно там много ошибок - это более критичный фронт работ. Ну или не мучать TestComplete, если ошибки можно найти быстрее в обход интерфейса. Если правильно определить фронт работ и подобрать нужные методы, то деятельность вскоре будет приносить ощутимые результаты.
Как-то так. :)

[galogenIt]

А что именно повысит качество и устойчивость? Работоспособность какого-то отдельного модуля? Если Вы автоматизируете биллинг (что-то там было из нескольких шагов), и что это даст? Только сэкономит время? А сколько? Полчаса работы тестировщика? Или целый день? А там вобще были ошибки за последние полгода или его еще будут существенно изменять? Насколько это критично для системы в целом? На каком уровне там появляются ошибки (только в интерфейсе или в логике работы)?
И еще пачка подобных вопросов.
Иначе можете полгода автоматизировать справочники, хотя никто уже и не помнит, в каком году там нашли последнюю ошибку, да и пользователи их уже не открывают. А все проблемы остались. Ну или бесконечно проверять, что если у пользователя фамилия из 15 букв, начинается с согласной, он работает в отделе1, и вот когда шеф в отпуске, то у нас не создается отчет, потому что программист Вася когда-то сделал в коде опечатку.

Спасибо, Mila. Но ... никаких справочников, всяких 15 или 17 букв в строке фамилия, и прочая прочая важная, но таки ерунда. Нет тестируем общую значимую функциональность. Не только биллинг, хотя он и важен и сильно интергрирован в другие задачи. Полный масштаб всех функций по работе с клиентом. У нас их насчитывается что-то около 30 укрупненных. По каждой примерно 3-5 вариантов использования, а если покапаться то еще можно смело добавить по 5. Правда некоторые ВИ повторяются от функции к функции. Некоторые функции я бы не стал проверять, ряд отчетов тоже, поскольку отчеты важны, но без них можно пережить некоторое время.

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

Понимаете выбор TestComplete в какой-то степени закономер. Работа с интерфейсом сложна и нудна. Usability конечно плачет, но как говорить нужно чем-то жертовать. Бизнес имеет сложные бизнес-процессы, многостадийные, причем с очень хитрыми влияниями на конечный результат. Причем повторить иным способом некоторые действия кроме как в интерактиве сложно.

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

ква не ква, но что-то похожее есть. Хотя всех конкурентных преимуществ открывать не будут :-D

Если правильно определить фронт работ и подобрать нужные методы, то деятельность вскоре будет приносить ощутимые результаты.
Как-то так. :)

Мне бы Ваш оптимизм - ощущение как перед айсбергом. И сверху громадина не охватная - но под водой ощущается что-то уж вообще монстровидное.

[ShortLegged]

Некоторые мысли про разные типы тестов - Flipping the Test Pyramid. Может быть, что-то будет полезно.

[galogenIt]

ShortLeqqed, спасибо за ссылку, наглядно. Почитаю завтра поподробнее.

У меня вопрос в этой же теме.

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

Как следует из развития темы, тестирование у нас в зачаточном состоянии. Сейчас лишь предпринмается попытка выстроить процесс тестирования.

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

Как полагают умудренные опытом и искушенные в тестировании люди, есть в данной логике изъяны, и каковы они? Или вполне нормальная практика?

В качестве примера приведу некий вариант использования (придуман из головы - возможно бредовой :) )
Создание счета вручную
предусловие - вошли в систему с правами бухгалтера, открыт журнал клиентов, клиент выбрал товары и они лежат у него в корзине
1. выбрать клиента по номеру, используя фильтр отбора - отображается выбранный клиент
2. открыть карточку клиента (F2) - открыта карточка клиента на вкладке Регистрационные данные
3. перейти на вкладку счета - вкладка Счета активна
4. нажать клавишу INS - отображается форма нового счета - такие-то поля заполнены таким-то данными
5. нажать кнопку Включить - в табличной части отображается список товаров в корзине, в поле ИТОГО отображается сумма полная, скидка, НДС и итоговая сумма покупки
6. нажать кнопку сохранить - на вкладке Счета - появляется запись данных счета

Это скажем Вариант использования или сценарий. Далее формируем тестовые случая:
т.е
1 указываем номер конкретного клиента - запись о конкртеном клиенте (наименование что-то еще)
2. вероятно проверять не надо
3. аналогично
4. - результат: Номер счета такойто дата такая-то такието данные заполнены (согласно данным клиента)
5. - результат список товаров такой-то (вернее из корзины клиента - которые там уже были), сумма такая-то, скидка такая-то итоговая сумма такая-то
6 ...

Потом то же самое но с другим клиентом у которого скажем нет скидки или не берут НДС.

Так нормально или полное не comme il faut (комильфо)?

[Galina]

Я считаю, что цель тестирования надо определить в первую очередь. Тестирование - вещь дорогая. И очень важно понимать, зачем тестируем, что ждем от тестирования.

На мой взгляд самые очевидные варианты целей:
1. Оценить качество программного продукта
2. Работать в команде, для выпуска качественного продукта

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

На форуме есть тема - Как создать отдел тестирования?

Возможно найдете полезной

[galogenIt]

Galina, спасибо за ответ

Тестирование дорогая вещь - да согласен, хотя раньше не очень понимал этого.

В настоящее время уже:
1. приобрели систему автоматизированного тестирования TestComplete - 24 000 р.
2. приобрели сервер для тестирования - имеющаяся машина слишком активно используется и для других дел, что создает определенные проблемы
3. в течение 2 месяцев мне платят зарплату - не буду говорить сколько (но пока не много)
Итого в целом можно сказать. что общие затраты на тестирования составили порядка 100000 или несколько меньше.

Результаты:
1.составлен список функций, которые предполагается тестировать.
2. по некоторым функциям расписаны варианты использвания или сценарии
3. одна задача-функция заскриптована для TestComplete
4. разработаны предварительные шаблоны документов, организован процесс работы по инцидентам

Чего нет
1. ясного понимания цели.
Вот Вы Галина пишете

1. Оценить качество программного продукта

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

2. Работать в команде, для выпуска качественного продукта

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

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

Если это мои цели - то как я могу гарантировать их достижение? Лично я не совсем это понимаю. Далее руководство меня ориентирует на тотальную автоматизацию тестов. И пока я вижу больше проблем в этом, чем пользы. Хотя следует сказать, что сама система не так хорошо мною изучена, потому приходится тратить на разработку и отладку тестов времени больше, чем я бы затратил просто на ручное тестирование

Есть большая проблема в форме описания тестовых случаев. Книга "Быстрое тестирование" в этом случае хотя и дает примеры написания ТС, но кажется не совсем подходящим.

[Galina]

http://www.slovopedi...199/786542.html

ЗАДАЧА
задачи, ж. 1. вопрос, требующий разрешения, то, что задано для решения, разрешения. Неразрешимая задача для философа. || Математический вопрос, для разрешения которого требуется путем вычислений найти какие-н. величины (мат.). Арифметическая, алгебраическая задача. Задачи на правило процентов. 2. цель; то, что необходимо осуществить, чего необходимо достигнуть; поручение, как заданная кому-н. цель. Вслед за задачами военными встает задача хозяйственная. Ленин. Задача построения фундамента социалистической экономики выполнена. Задача построить внеклассовое социалистическое общество - основная политическая задача второй пятилетки. Ставить себе, перед собой задачу. Иметь что-н. своей задачей. Задача сводится к чему-н., к тому, чтобы... (см. сводиться). Задай лишь мне задачу: без дела, знаешь, от тебя не должен отлучиться я. Пушкин. 3. Удача, успех, счастье; противоп. незадача (обл.). Во всем-то ему задача, что дивится народ даже. Л. Толстой.

:)

Если бы можно было в паре слов дать Вам рецепт того, как все сделать... То, наверное, и форума то не было.

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

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


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

Что касается тест-кейзов... как не банально это звучит, чтобы их научиться писать, надо их писать... Надо, чтобы человек, знающий продукт, проводил ревью тест-кейзов... У вас есть аналитики как я поняла - их можно и даже нужно подключить!

[Green]

Чего нет
1. ясного понимания цели.

GalogenIt,

Вы сейчас пытаетесь найти ответы находясь внутри системы. Для того, что бы решить Вашу задачу необходимо "подняться" над проблемой.

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

Проблемы могут быть нескольких типов:
1. Сделали не то, что хотел заказчик (не корректная постановка задачи)
2. Реализация расходится с поставленной задачей (сделали не то, что заказали)
3. Сделали не так, как это общепринято (не учли стандарты)
4. Сделали не так, как удобно
5. Исправили то, что было не правильно, но внесли новую ошибку
6. Все работало по отдельности, но когда собрали - что-то перестало работать
Каждый аспект контроля реализуется посредством своего типа проверок (видов тестирования).

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

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

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

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

[galogenIt]

Galina, спасибо за ответ

Если бы можно было в паре слов дать Вам рецепт того, как все сделать... То, наверное, и форума то не было.

Трудно с Вами не согласиться :)

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

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

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

- что это значит? То что программа выполняет то, что от нее ожидают?

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

можно ли как-то определить минимальное количество регрессионных тестов, они чем=то отличаются от других тестов? Что значить - когда проводим регрессионное тетсирование?

Что касается тест-кейзов... как не банально это звучит, чтобы их научиться писать, надо их писать... Надо, чтобы человек, знающий продукт, проводил ревью тест-кейзов... У вас есть аналитики как я поняла - их можно и даже нужно подключить!

Опять нечем возразить. Пишем. Уже опробывали несколько форм. Неочень понятна пока только степень их элементарности или дробления. Наберусь нахальства и приведу небольшой пример наработанный мною

TC-7.2.	Формирование счетов
Автор:
я собственно 
Последнее изменение:
1.09.2008
Описание: 
Выбирается клиент, формируется печатная форма счета, результаты сравниваются с правилами биллинга, количеством и ценой дистрибутивов, наличием скидки

Предусловие:
Выполнен биллинг на дату: YY (тест ТС-7.1. )
Система запущена под Операционным бухгалтером  

Результат:
Сформированы документы биллинга в соответствии с правилами и настройками биллинга

Шаги сценария
Шаг	Действие																Результат
1	Выбрать и открыть список задач КонсультантПлюс	открывается дерево списка задач
2	Выбрать задачу Клиенты и дистрибутивы -> Клиенты	Отображается окно Клиенты Консультант +
3	Выбрать клиента с номером Х через папку отбора «По номеру». Запустить диалог клиента клавишей F2	Отображается окно выбранного клиента
4	Выбрать вкладку Документы, затем вкладку Счета	Отображается список счетов
5	Выбрать последний счет (за месяц даты YY). Нажать кнопку Предварительный просмотр.	Загружается печатная форма счета 
6	Распахнуть окно предварительного просмотра	Печатная форма счета занимает максимально возможный размер на экране
7	Сравнить данные счета с ожидаемыми результатами	Счет сформирован корректно

Постусловие:
Откатить систему к исходному состоянию (закрыть предварительный просмотр, закрыть окно клиента, свернуть дерево задач Консультант)
Методы тестирования:
Тестирование вручную
Автоматизированное тестирование: 
1. тестовый скрипт для выполнения через удаленный рабочий стол на сервере \\TESTER\AutoTests\TestBat\test72RD.bat
2. тестовый скрипт для выполнения через назначенное задание под пользователем tester на сервере \\TESTER\AutoTests\TestBat\test72ST.bat

Что здесь Вам не нравится?

Green, спасибо за ответ

Вы сейчас пытаетесь найти ответы находясь внутри системы. Для того, что бы решить Вашу задачу необходимо "подняться" над проблемой.

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

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

Это факт!

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

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

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

И это первое о чем я всегда думаю. Меня подгоняют - пиши как можно больше тестов, но в совершенной растерянности по поводу того как действительно поддерживать большую кучу тестов.
Даже есть пример - это приведенный мною тестовый случай, он заскриптован, работает хорошо, но! ... по сути яим проверяю корректность окончательного формирования счета, т.е. у меня есть набор клиентов с разными типами настроек, которые будут влиять на сам счет: итоговая сумма, дата выставления, список единиц счета и т.п. Я проверяю конечный результат проводя биллинг на некоторую тестовую дату. Попутно проверяется само наличие счета - если он отсутствует уже не порядок, но пусть все окей. Я уже знаю счет формировался, сформировался корректно. Сравнение результатов я провожу с регионом (по сути скриншотом счета) попискельно, проводя сравнение. Знаю, что сравнение с регионами не очень хорошо. Но как иначе проверить что печатная форма счета формируется корректно? (конечно допольнительно я проверяю данные в базе данных).
Однако если вносится изменение в печатную форму счета, то это вынуждает меня сначала вручную проверить, что новая форма счета заполняется верно, а затем перефотографировать эти регионы для всех клиентов. Я примерно подсчитал, что на одно перефотографирование потрачу примерно минуту. Если клиентов 50 - то соответственно 50 минут Х 2 поскольку есть два варианта запуска (паравлв проблему с двойным варинатом можно решить). Очевидно таких тестов должно быть минимальное число, либо вообще отказаться от их автоматизации. Однако минимизировать их не получается, такова специфика приложения. Пока нормального выхода не вижу - что меня и удручает...

[JimR]

1. По поводу описанного теста:

Шаги сценария
Шаг Действие Результат
1 Выбрать и открыть список задач КонсультантПлюс открывается дерево списка задач
2 Выбрать задачу Клиенты и дистрибутивы -> Клиенты Отображается окно Клиенты Консультант +
3 Выбрать клиента с номером Х через папку отбора «По номеру». Запустить диалог клиента клавишей F2 Отображается окно выбранного клиента
4 Выбрать вкладку Документы, затем вкладку Счета Отображается список счетов
5 Выбрать последний счет (за месяц даты YY). Нажать кнопку Предварительный просмотр. Загружается печатная форма счета
6 Распахнуть окно предварительного просмотра Печатная форма счета занимает максимально возможный размер на экране
7 Сравнить данные счета с ожидаемыми результатами Счет сформирован корректно

К сожалению не видел Консультант-плюс. Вопрос: печатная форма открывается в окне приложения и представляет собой картинку или это всё-же отчет во внешнем формате: crystal report, pdf, html и т.п.?
В зависимости от этого можно по-разному получать данные из сформированного отчета при автоматизации теста, но не обязательно попиксельное сравнение. Да и с файлом, думаю, удобнее будет работать, чем с экраном.

По поводу же сопровождения готовых тестов имеется ряд основных правил:
1. модульность тестов. позволяет не дублировать одну работу много раз.
2. динамичность входных данных. Тест должен позволять несложым путем изменять тестовые данные на входе. Проще всего для этого использовать какой-то набор входных данных: файл, таблица в БД или что ещё, не столь важно. Главное, что для каждого теста должна быть четкая зависимость между входными данными и выходными (полученными результатами).
3. правильное логгирование процесса тестирования, чтобы минимизировать необходимость повторного выполнения теста, особенно вручную.
4. не забывать, что в тестах и входных тестовых данных также бывают ошибки.
5. ну и всякие комментарии. Плюс, желательно соблюдать те же правила кодирования, что используются при разработке ПО. Некий бонус, который позволит проще разбираться в тестируемом коде. А также можно будет иногда привлекать за помощью разработчиков.
6. Не забывать планировать время под сопровождение разработанных тестов. И напоминать об этом времени всем: своему руководителю, менеджерам проектов и т.д.

[galogenIt]

1. По поводу описанного теста:
К сожалению не видел Консультант-плюс.

Тестируется не программа КонсультантПлюс. КонсультантПлюс - объект с которым работает приложение. Приложение есть CRM - т.е. инструмент работы с клиентами, которые потребляют (не внутрь) КонсультантПлюс, а компания использующая CRM получает денежки за поставку и информационное обслуживание.

Вопрос: печатная форма открывается в окне приложения и представляет собой картинку или это всё-же отчет во внешнем формате: crystal report, pdf, html и т.п.?

Отчет формируется в окне предварительно просмотра по стандарту WYCWYG. Хотя можно получить картинку, послав ее на виртуальный принтер.
Так же есть возможность просматривать отчет в виде подобном Excel таблицы. Из этого режима отчет можно экспортировать в html, Excel, Word, в тестовый файл, rtf

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

Да согласен, по видимому надо будет писать пасринг например текстового файла или можно использовать filecheckpoint в случае TestComplete

По поводу же сопровождения готовых тестов имеется ряд основных правил:
1. модульность тестов. позволяет не дублировать одну работу много раз.

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

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

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

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

Что Вы имеете в виду? особенно про вручную?

4. не забывать, что в тестах и входных тестовых данных также бывают ошибки.

Это очевидно. Все мы люди, все мы человеки...

5. ну и всякие комментарии. Плюс, желательно соблюдать те же правила кодирования, что используются при разработке ПО. Некий бонус, который позволит проще разбираться в тестируемом коде. А также можно будет иногда привлекать за помощью разработчиков.

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

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

Пожалуй, это первое что мне пришло в голову и первое, что заставляет меня искать универсализм и независимость теста от изменений (по возможности конечно)

Спасибо за Ваши комментарии, но Вы ничего не сказали о стиле тестовго сценария (или варианта использования :) )

[Galina]

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

- что это значит? То что программа выполняет то, что от нее ожидают?

В том то и дело, что Вы ЭТО должны определить для себя, для команды и для клиента.

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

можно ли как-то определить минимальное количество регрессионных тестов, они чем=то отличаются от других тестов? Что значить - когда проводим регрессионное тетсирование?

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


Что касается вашего примера тест-кейза, мне очень-очень не нравится фраза "Счет сформирован корректно". Слишком скользкая "трактовка". Советую избегать неоднозначности.
Тест-кейзы, как и требования, можно тестировать на полноту, однозначность, непротиворичивость....

[galogenIt]

Что касается вашего примера тест-кейза, мне очень-очень не нравится фраза "Счет сформирован корректно". Слишком скользкая "трактовка". Советую избегать неоднозначности.
Тест-кейзы, как и требования, можно тестировать на полноту, однозначность, непротиворичивость....

Я согласен, что фраза счет сформирован корректно - довольно скользкая. Конечно можно поместить в ожидаемых результатах - просто скриншот. Просто все описание счета слишком большое. Тем более данный тест уже заскриптован и в нам производится простое сравнение снимков печатной формы счета в ходе теста с той что была сохранена в репозитории.

Паралельно с этим тестом есть и будут более конкретные - типа выбрать клиента 2, открыть форму счета, убедится что сумма счета равна 3970,16 - в случае скрипта, ожидаемый результат лежит в файле данных и подставляется в сравнение типа
If frmAccount.Edit('Summa').Value <> par[1] then логировать ошибку

[galogen]

Решил не плодить новую тему, мой вопрос вполне согласуется с этой.

Прежде, чем задать вопрос немного деталей.

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

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

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

Я пока использую стиль № 2, выделяя 8 классов эквивалентности:
1. нет особых условий, настройки по умолчанию
2. нет особых условий, настройки индивидуальные
3. особое условие 1, настройки по умолчанию
4. особое условие 1, настройки индивидуальные
5. особое условие 2, настройки по умолчанию
6. особое условие 2, настройки индивидуальные
7. особое условие 1 и 2, настройки по умолчанию
8. особое условие 1 и 2, настройки индивидуальные

Спасибо

[madboy4ik]

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

Вам наверное скорее всего стоит определить какого рода в программе возникают ошибки
Если проект действительно достаточно серъёзный и бывает случаются проколы, за которые часто "гладят" по головке то тут в 1 очередь большее и основное внимание стоит уделить функциоанльному тестированию.

Что для этого нужно ? Наверное скорее всего документация по проекту, спеки или требования от заказчиков если такое есть...
Если такого нет то наверное скорее всего нужен человек которые может полностью рассказать о проекте и показать его функциональность и объяснить как это должно работать.

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

Решил не плодить новую тему, мой вопрос вполне согласуется с этой.

Прежде, чем задать вопрос немного деталей.

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

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

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

Я пока использую стиль № 2, выделяя 8 классов эквивалентности:
1. нет особых условий, настройки по умолчанию
2. нет особых условий, настройки индивидуальные
3. особое условие 1, настройки по умолчанию
4. особое условие 1, настройки индивидуальные
5. особое условие 2, настройки по умолчанию
6. особое условие 2, настройки индивидуальные
7. особое условие 1 и 2, настройки по умолчанию
8. особое условие 1 и 2, настройки индивидуальные

Спасибо

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

А по поводу результатов - можно использовать 3 состоянии.

1. Прошёл успешно - ну тут всё ясно
2. Потерпел неудачу - тут тоже вопросов не должно быть
3. Блокировка - у вас есть некий набор последовательных кейсов, допустим 1 из них "валиться" и это не даёт пройтись по всем остальным кейсам