Блог Таси Край

Совсем недавно я закончила проект по созданию автоматических CodedUI-тестов и внедрению их автоматического прогона в рамках выпуска сборки, используя инструментарий TFS. Запуск автоматических тестов происходит по следующей схеме: 1. Инициируется автоматический запуск сборки (по расписанию, 1 раз в неделю) тестируемого приложения. Результатом успешно выполненной сборки является обновление файлов приложения на сервере IIS (тестируется web-приложение). 2. Успешная сборка автоматически запускает ее выпуск, в рамках которого происходит восстановление базы данных, с которой работает приложение; на сервере клиента устанавливается агент тестирования и запускаются автоматические тесты пользовательского интерфейса (запуск тестов настроен в рамках задачи Run Functional Test Task, источник тестов - План тестирования, содержащий тестовые случаи со связанной автоматизацией, тип тестов - Coded UI Test). 3. Результаты тестового прогона анализируются, для каждого Failed-теста определяется тип...

В какой-то момент мы оказались в ситуации, когда в системе были зарегистрированы сотни тестовых случаев, спроектированных разными инженерами без каких-либо договоренностей по их оформлению. Было принято решение разработать некоторые стандарты для проектирования и создания тестовых случаев в системе. Далее я хочу поделиться некоторыми требованиями (а точнее основными их идеями), которые стали обязательными для нас при проектировании тестовых случаев. 1.  Название тестового случая согласно шаблону:  <Специальный код проекта или его название> / <Специальный код продукта или его название> / <Модуль продукта> / <Тестируемая функциональность> . 2.  Шаги тестового случая. Описание  действий  пользователя в системе согласно принципу:  "Что сделать? Где сделать? Как сделать?" . Действия описывать в повелительном наклонении. Например,  Ввести значение "25.12.1998" в поле "Дата начала" путем выбора из календаря....

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

Всем привет! Сегодня мы поговорим о таких рабочих элементах как Пользовательские истории, Тестовые случаи, Тестовые Наборы и Планы тестирования. Требования (Пользовательские истории, User  S tory ) Качество начинается с определения необходимых требований . В правильно сформулированных требованиях должны быть указаны желаемая функциональность продукта и то, как проверить, достигнута ли она. Описание требуемой единицы функциональности оформляется как Пользовательская история (обычно Пользовательские истории в системе  регистрирует руководитель проекта). Проверки этой функциональности оформляются как Тестовые случаи , ассоциированные с Пользовательской историей. План тестирования ( Test Plan) В моем словаре понятие «План тестирования» имеет два определения – в широком и узком смысле. Далее в своих статьях я буду использовать это понятие в его узком смысле и, кроме того, в контексте используемого инструмента – Microsoft Test Manager (и Test Hub в соста...

Всем привет!  А какие инструменты Вы используете для сопровождения процесса разработки ПО и его тестирования? Сегодня мы об этом и поговорим! В процессе разработки ПО удобно использовать какую-либо информационную систему , позволяющую координировать действия всех участников процесса при их совместной работе над проектом. Небольшие организации, как правило, используют отдельные (чаще бесплатные и требующие интеграции), инструменты для управления версиями, сбора данных, построения отчетов, создания и отслеживания статусов «рабочих элементов» по проекту и т.д. В своей работе мы используем комплексное решение – продукт от корпорации Microsoft – Team Foundation Server ( TFS ), который объединяет в себе возможности перечисленных выше инструментов и предназначен для совместной работы над проектами по разработке ПО. Что мне нравится в инструментах Microsoft , так это колоссальная поддержка со стороны официальных сообществ. Всю необходимую информацию по настройке, возможно...

Всем привет!  Сегодня я расскажу вам о процессе тестирования и его месте в цикле разработки.  Процесс тестирования - это совокупность нескольких видов активностей, таких как планирование, проектирование тестов, собственно выполнение тестирования, сбор и анализ полученных результатов.  Отмечу, что для быстрого и эффективного выполнения этих активностей необходимо стремиться к использованию удобных инструментов, позволяющих максимально упростить и ускорить работы, в том числе и автоматизировать некоторую их часть. В своей работе я использую такие инструменты как TFS, Visual Studio, Microsoft Test Manager и, конечно же, расскажу о них более подробно в следующих статьях. Теперь немного поговорим о каждой активности. 1) Планирование (Test Planning).  Я поддерживаю практику, когда процесс тестирования при разработке нового ПО начинается как можно раньше, как только были получены первые спецификации, например, в виде Технического задания. Софт еще н...

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