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

[galogenIt]

У меня вопрос к специалистам, опытным инженерам качества ПО.

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

В книгах по тестированию объясняется многое и очень подробно. Неопытному глазу это кажется как в той пословице: "За деревьями леса не видать"

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

Однако у меня ситуация оказалась несколько иная.

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

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

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

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

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

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

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

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

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

Пока по совету oldman я пошел по пути выявления наиболее часто реализуемых вариантов использования системы. Описания этих вариантов, формирования по этим вариантам тестовых случаев, скриптование тех ТС, которые наиболее приемлемы для автоматизации.
Есть проблемы с формированием тестовго плана, разработки графика работ, оценки временных затрат, оценки финансовых затрат (сколько нужно работы сделать и сколько будет это стоить).
Что скажем значит цикл тестирования? И как он формируется?

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

[rlabs]

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

[LeshaL]

...

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

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

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

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

[rlabs]

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

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

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

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

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

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

[Green]

У меня вопрос к специалистам, опытным инженерам качества ПО.

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

2 galogenIt

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

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

Для решения проблем вашей компании необходимо понимать ряд вещей:

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

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

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

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


Как можно поступить в Вашей ситуации?

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

2. Отдать работы на аутсорсинг.
Быстро, но не очень дешево. Зато проблема решается сразу же и, к тому же, лично у Вас есть возможность взять этот процесс в свои руки и повысить квалификацию за счет опыта аутсорсеров.

3. Нанять консультанта и организовать работы "внутри".

Если ваше начальство, вдруг, заинтересуется 2-м и 3-м вариантами, то можете скинуть письмо в личку. С этими пунктами могу помочь.

[ShortLegged]

В данном случае можно использовать следующие подходы:

• Модульное тестирование. Создание unit-тестов для существующих и новых функций системы. Стараться как можно чаще их запускать, например использовать какую-нибудь CI систему (например CruiseControl).
• Автоматизированное приемочное тестирование. Постараться привлечь пользователей к acceptance тестированию системы, что-бы они находили дефекты не в продакшене, а раньше. Вместо пользователей могут быть бизнес-аналитики. Для автоматизации здесь можно использовать FIT/FitNesse.

[galogenIt]

Всем большое спасибо за ответы.

>RLABS
>- тестировщиков у вас нет и не планируется
>- свободного от "созидательной работы" ресурса для написания автоматических тестов нет и не планируется?
тестировщики есть и планируются
ресурс есть. также есть и система Test Complete

>GREEN
>Честно говоря, в Вашем посте нет вопросов.
Да наверное. Пока я просто изложил ситуацию. И хотел бы набрать критическую массу информации скажем так из первых рук. Что в общем получается...

Приобретения опыта за счет фирмы - ну не совсем согласен. И я получу велью, но и фирма его получит.

> Если ваше начальство, вдруг, заинтересуется 2-м и 3-м вариантами, то можете скинуть письмо в личку. С этими пунктами могу помочь.
Начальство посмотрело, возможно и заинтересуется:)

[Green]

>GREEN
>Честно говоря, в Вашем посте нет вопросов.
Да наверное. Пока я просто изложил ситуацию. И хотел бы набрать критическую массу информации скажем так из первых рук. Что в общем получается...

Приобретения опыта за счет фирмы - ну не совсем согласен. И я получу велью, но и фирма его получит.

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

Я не имел ввиду некую негативную подоплеку происходящего (как это может показаться из написанного). Просто, вариант - взяться за автоматизацию тестирования без необходимого базиса - это "бросать деньги на ветер" или тратить их не эффективно.

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

Поясню свою мысль примером. Никто не сомневается, что unit testing повысит уровень качества продукта. Однако, далеко не каждая организация способна ввести у себя unit testing в качестве постоянной практики, так как это связано с целым рядом телодвижений, которые зависят от уровня зрелости компании. Если компания уже готова к введению этой практики, то результат будет положительным. Если нет, то хоть поставь по автоматчику "над душой" у программиста, качество от этого не улучшится (хотя при этом будут писаться тесты и создаваться видимость бурной деятельности). Необходимы поэтапные мероприятия с целью "взросления" компании до нужного уровня.

[galogenIt]

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

Да нет все нормально :)
И насчет бросать деньги на ветер тоже понимаем.

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

Кажется задачи формулируются. Не скажу, что полностью уверены в точности. Примерно так:

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

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

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

Поясню свою мысль примером. Никто не сомневается, что unit testing повысит уровень качества продукта. Однако, далеко не каждая организация способна ввести у себя unit testing в качестве постоянной практики, так как это связано с целым рядом телодвижений, которые зависят от уровня зрелости компании. Если компания уже готова к введению этой практики, то результат будет положительным. Если нет, то хоть поставь по автоматчику "над душой" у программиста, качество от этого не улучшится (хотя при этом будут писаться тесты и создаваться видимость бурной деятельности). Необходимы поэтапные мероприятия с целью "взросления" компании до нужного уровня.

Да, сейчас я понимаю, пусть и не полностью Вас. Месяц назад возможно нет :).
Правда стоит сказать, что пока задача unit testing передо мною не стоит. Предполагается, что этим будет заниматься сам разработчик. Я лишь должен пока убедится, что изменение, вносимое разработчиком, лишено серьезных проблем. Т.е. я пока осуществляю функциональное тестирование, тестирование черного ящика.
Надо отметить, что была попытка разработать свою внутреннюю систему юнит тестирования, правда до конца она не доведена. Также я вижу, что Test Complete предоставляет такие возможности, хотя и треубет компиляции проекта как Open App. Пока эта возможность не проанализирована в полной мере, видны определенные трудности...

[Green]

Правда стоит сказать, что пока задача unit testing передо мною не стоит. Предполагается, что этим будет заниматься сам разработчик.

Вижу необходимость пояснений.

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

[galogenIt]

Я пожалуй созрел для более конкретных вопросов.

Но для начала некоторое резюме.
1. Проект большой и сложный.
2. Систематического тестирования нет.
3. Инциденты от пользователей поступают в достаточном количестве, правда не всех их можно отнести к дефектам.
4. Порой одна и таже ошибка поступает от клиента несколько раз...
5. Модульного тестирования нет, если не считать, что сами разработчики тестируют разрабатываемую ими задачу.
6. Существует система оповещения об ошибки. Правда клиенты отправить непосредственно из приложения не могут.
7. Появился человек, имеющий опыт тестирование .Net приложений на Test Complete.
8. Создана группа тестирования из двух человек + пока два аналитика, которые с группой сотрудничают
9. Создается служба управления инцидентами, поступающим от клиентов
10. По-тихоньку выстраивается процесс тестирования.

Что решено по вопросу тестирования:
1. Тестирование исправлений текущих ошибок, поступающих от клиентов. Скриптование тестов по мере возможности и хранениях их в репозитории автоматизированных тестов. Использование скриптов для прогонки с целью убедится, что ошибка не реанимировалась

2. Формирование тестов для покрытия функциональности системы. Скриптование тестов
Эта работа выполняется сейчас примерно так:
- выделен набор функций системы (задач), типа Биллинг обслуживания, Управление карточкой клиента ...
- по каждой функции определен набор вариантов использования
- произведено ранжирование
- определен набор вариантов использования наиболее важных
- каждый вариант использания описан в виде базового сценария и альтернативного сценариев (название шага ВИ, Действия пользователя в этом шаге, отклик системы или ожидаемый результат)
- на базе этого набора предполагается формирование типа smoke-тестов
- предполагается последовательно покрытие вариантов использования тестами

Вопросы:
1. Разумно ли то, что я предложил? Что на Ваш взгляд тут не правильно или не совсем верно?
2. Следует ли покрывать тестом каждый шаг варианта использования ил достаточно проверить конечные результаты варианта использовния?
3. Какие требования предъявляют к smoke-тест, можно ли посмотреть пример его?
4. Насколько эффективны и неэффективны тесты, основанные на пользовательском интерфейсе

[ShortLegged]

На основании каких артефактов у Вас создаются автоматизированные тесты, сценарии использования, тестовые сценарии или from scratch?

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

Цель smoke тестирования, проверить, что новый билд настолько плох, что не стоит тратить время на дальнейшее тестирование. Поэтому важно проверить корректность версии билда и посмотреть на общую работоспособность системы.

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

[galogenIt]

На основании каких артефактов у Вас создаются автоматизированные тесты, сценарии использования, тестовые сценарии или from scratch?

Для начала давайте говорить по-русски. Я не о терминах в названиях каких-то сущностей, но это ваше from scratch. Ну россияне мы. Почему не сказать случайно, хаотично?

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

Если тесты создаются на основе сценариев использования, то как правило, один flow сценария представляет собой один тест.

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

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

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

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

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

Однако вы пишите один простой сценарий - один тест. Но в каждом сценарии может быть скажем до 5-6 шагов (включая реакцию системы) И ведь каждый шаг по сути есть функция системы, которую при желании можно тестировать. Не следует ли делать тестовые случая по каждому шагу?

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

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

А что вы имете в виду каждой функции в отдельности???

Цель smoke тестирования, проверить, что новый билд настолько плох, что не стоит тратить время на дальнейшее тестирование. Поэтому важно проверить корректность версии билда и посмотреть на общую работоспособность системы.

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

Вопрос сколько подобных smoke тестов достаточно? Какой они должны быть сложности?
Скажем если я просто проделаю 10 тестов, которые проверяют: проведение биллинга, регистрацию коммерческой поставки, создания графика обслуживания, расчет з/п сервисного инженера ... - Этого будет достаочно для приемки на первом smoke уровне?

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

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

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

[rlabs]

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

Вопрос сколько подобных smoke тестов достаточно? Какой они должны быть сложности?
Скажем если я просто проделаю 10 тестов, которые проверяют: проведение биллинга, регистрацию коммерческой поставки, создания графика обслуживания, расчет з/п сервисного инженера ... - Этого будет достаочно для приемки на первом smoke уровне?

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

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

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

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

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

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

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

[ShortLegged]

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

Тестовый случай.

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

По моему мнению, универсального рецепта здесь нет, нужно смотреть на то, как написаны варианты использования. В Вашем конкретном случае, шаги действительно можно сделать отдельными вариантами использования и ссылаться на них как на подчиненные. Тогда получаем минимум один тестовый случай для каждого подчиненного варианта использования (основной flow) + по одному тестовому сценарию на каждый альтернативный flow (если они есть). И как минимум один тестовый сценарий для основного варианта использования. В итоге получаем минимум три тестовых сценария.

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

А что вы имете в виду каждой функции в отдельности???

Некоторое атомарное действие с системой. Например, вставка текста из буфера обмена в текстовом редакторе.

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

Почему тесты только для старой функциональности? Новая ведь так-же может быть нерабочей.

Могли бы вы пояснить данное предложение?
Что значит тестирование бизнес-логики в обход интерфейса?
Т.е. прямое обращение к методам класса?

Не всегда. Например тестирование с использованием другого интерфейса отличного от GUI. Его могут реализовать разработчики по Вашей просьбе. Наиболее часто упоминаемый пример, работа с функциями MS Word через GUI и через COM API.

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

Правильно ли я понимаю, что "компиляция приложения как открытое приложение" термин TestComplete?

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

В определенных случаях, да. Например, добавление данных в базу или прямой вызов процедур/функций на стороне базы данных. Это будет уже gray-box testing. Часто подобные подходы позволяют экономить ресурсы и вполне применимы, за исключением случаев сопротивления со стороны заказчика.

[LeshaL]

Добрый день!
Начну с ответов на предыдущие вопросы.

Вопросы:
1. Разумно ли то, что я предложил? Что на Ваш взгляд тут не правильно или не совсем верно?
2. Следует ли покрывать тестом каждый шаг варианта использования ил достаточно проверить конечные результаты варианта использовния?
3. Какие требования предъявляют к smoke-тест, можно ли посмотреть пример его?
4. Насколько эффективны и неэффективны тесты, основанные на пользовательском интерфейсе

1. Вполне разумно. Насколько я понимаю вашу ситуацию - это лучше чем вообще ничего.
2. Это зависит от ситуации. По логике вещей, более правильный ответ: "да, следует". Объясню - пока не совершаются никакие действия, система находится в определенном состоянии. Каждый шаг переводит систему из одного определенного состояния в другое. Поэтому, для того чтобы постоянно находится в уверенности, что каждый предыдущий шаг выполнен системой правильно, следует проверять его результаты, т.к. они заранее предсказуемы. Например, вы можете избежать выполнения каких-либо долгих действий, если уже на предварительном этапе что-то поломалось. Но бывают случаи когда такие проверки излишни. Например, можно написать тестовый сценарий: "Нажмите на кнопку №1 на тулбаре. Должно появиться диалоговое окно. Проверьте, что данное окно содержит все UI элементы в соотв. с дизайн-документом, что layout правильный, цвета соотв. выбраной цветовой схеме, look-and-feel соовт. выбранному и тд.". Очевидно, что такой тест самодостаточен и должен быть запущен 1 раз. Нет смысла каждый раз при вызове диалога делать такие проверки, если вам надо использовать его функциональность, как предварительный шаг для выполнения вашего тестового сценария.
3. Smoke-тест, как тут уже написали это небольшая и простая проверка на то, что базовая функциональность продукта хоть как-то да работает. Что его вообще возможно использовать. Например, продукт устанавливается, запускается, может соединиться с БД и пользователь может залогинится в систему. Вот и весь смок-тест. То о чем вы говорите:

- на базе этого набора предполагается формирование типа smoke-тестов

Название это просто возможность общаться. Но примерно это от меня пока и требуется.
1.Есть релиз, который мы будем считать устойчивым и корректным.
2. Вносим некоторое изменение - скажем добавляем новую функциональность
3. прогоняем наши проверочные тесты - все окей идем дальше(т.е. тестируем уже новую функциональность), нет возвращаем на доработку
Вопрос сколько подобных smoke тестов достаточно? Какой они должны быть сложности?
Скажем если я просто проделаю 10 тестов, которые проверяют: проведение биллинга, регистрацию коммерческой поставки, создания графика обслуживания, расчет з/п сервисного инженера ... - Этого будет достаочно для приемки на первом smoke уровне?

я думаю, лучше называть либо acceptance test-subset либо sanity check.
Причем №3 здесь - совершенно неправильный подход. Такой подход верен только когда такие проверочные тесты находят критическую проблему в базовой функциональности из-за которой вы не можете проводить дальнейшее тестирование. Иначе, ничего вам недолжно тестировать "новую" функциональность. Причем деление на старое/новое не может быть полностью корректным. Откуда вы знаете, что старая функциональность не периписалась заново?
4. Тут уже сказали как лучше. На мой взляд они совершенно неэффективны для новой, разрабатываемой функциональности, когда GUI может меняться ежедневно. Но они могут быть эффективны при регрессионом тестировании. Хотя и в этом случае надо крепко-накрепко подумать и оценить - может быть дешевле автоматизации использование ручного тестирования.

[galogenIt]

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

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

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

Необходимо оправдывать расходы, сделанные на его приобретение:) Хотя я с вами полностью согласен. Просто пока! боюсь просить что-то сделать у разработчиков довольно проблематично. Но идея понятна.

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

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

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

В качестве примера: при проведении биллинга вначале заполняется регистр дистрибутивов, заполняется таблица с данными биллинга по каждому клиенту. Далее после создание документов биллинга происходит соотвествующее изменение таблиц регистр дистрибутиво, данных биллинга, создания данных по документам...

[galogenIt]

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

Почему тесты только для старой функциональности? Новая ведь так-же может быть нерабочей.

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

Не всегда. Например тестирование с использованием другого интерфейса отличного от GUI. Его могут реализовать разработчики по Вашей просьбе. Наиболее часто упоминаемый пример, работа с функциями MS Word через GUI и через COM API.

Спасибо, понятно.

Правильно ли я понимаю, что "компиляция приложения как открытое приложение" термин TestComplete?

Да это термин данного продукта. Хотя как я полагаю этот термин более широк и обозначет возможность обращения к методам и свойствам объектов приложения. А не только воспринимать его как окно.
Инструмент содержит набор библиотек, которые должны компилирироваться вместе с тестируеммым приложением. Это позволяет Test Complete обращаться напрямую к методом и свойствам объектов. Например с методу(событию) onClick некоего контрола на форме.

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

В определенных случаях, да. Например, добавление данных в базу или прямой вызов процедур/функций на стороне базы данных. Это будет уже gray-box testing. Часто подобные подходы позволяют экономить ресурсы и вполне применимы, за исключением случаев сопротивления со стороны заказчика.

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

[galogenIt]

Простите за трех кратное публикования сообщения, но не понял, как включать цитирование с разных постов.

1. Вполне разумно. Насколько я понимаю вашу ситуацию - это лучше чем вообще ничего.

Да этотак и есть. Нет ничего. Нет ничего в смысле системного подхода. Хотя некоторые начинания делались.

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

Причем №3 здесь - совершенно неправильный подход. Такой подход верен только когда такие проверочные тесты находят критическую проблему в базовой функциональности из-за которой вы не можете проводить дальнейшее тестирование.
Иначе, ничего вам недолжно тестировать "новую" функциональность. Причем деление на старое/новое не может быть полностью корректным. Откуда вы знаете, что старая функциональность не периписалась заново?

Не совсем понял вот это

Иначе, ничего вам недолжно тестировать "новую" функциональность.

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

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

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

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

Я понимаю, что еще надо написать этот самый автотест, проверить его и запустить в серию. Не факт, что корректно работающий тест при включении в библиотеку тестов будет работать корректно.

Я понимаю, что если ежедневно менять GUI- то автоматизация совершенно не приемлема.

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

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

[ShortLegged]

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

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

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

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

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

Автоматизированные тесты для GUI достаточно медленные и маловероятно, что разработчик добавив новую фичу в приложение будет ждать значительное время что-бы получить feedback, скорее он не будет запускать тесты. В данном случае наиболее удобным будет unit тестирование/интеграционное тестирование с использованием xUnit фреймворков.