Существует ли подход к управлению приемочным тестированием, который может работать с кодом в git?

Мы переходим к подходу разработки через приемочное тестирование для определения функций. Вроде работает хорошо, но у нас начинаются проблемы с управлением тестами. На данный момент мы используем SharePoint/Excel для отслеживания приемочных тестов. Это связано с тем, что не технические клиенты, QA и разработчики обновляют тесты. Проблема в том, что тесты не живут с кодом, поэтому они не разветвляются/версионируются вместе с кодом, и все это очень ручное. Мы смотрим на полное программное обеспечение для управления тестовыми сценариями (например, Zephyr, TestRail и т. д.), но оно кажется немного тяжелым, и, в конечном счете, тестовые данные все еще не работают с кодом.

Существует ли приложение для управления тестированием, которое удобно для не-разработчиков, но хранит данные так, чтобы оно работало с git? Является ли попытка сохранить тесты вместе с кодом дурацкой затеей?

Спасибо, Эрик


person Erick T    schedule 23.10.2014    source источник


Ответы (2)


Да, мне нравится ваша идея хранить тесты вместе с кодом.

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

Мы храним наши приемочные тесты, основанные на другой структуре, называемой Concordion, также в нашем репозитории исходного кода. Спецификации Concordion состоят из двух частей: правильно сформированного HTML-документа, описывающего функциональность, и кода приспособления, написанного на языке программирования вашего приложения, таком как Java или C#, который находит в документе конкретные примеры и использует их для проверки тестируемой системы.

Наши исполняемые спецификации написаны с помощью HTML-редактора WYSIWYG, такого как Microsoft WebExpression или BlueGriffon владельцем продукта или тестировщиками. Мы храним их в нашем репозитории и получаем к ним доступ через TortoiseGit, что очень хорошо работает, поскольку все члены нашей команды имеют техническое образование. Чтобы задействовать не технические аспекты, вам, вероятно, потребуется написать небольшой скрипт, который загружает последние обновления в локальный репозиторий, запускает выбранный вами редактор и отправляет изменения после редактирования обратно в центральный репозиторий.

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

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

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

person user3632158    schedule 24.10.2014
comment
Есть ли у вас какие-либо предложения относительно того, как включить ручное тестирование? Сейчас мы бьемся над тем, как вести список тестов, некоторые из которых автоматизированы, а некоторые — вручную. Как отслеживать выполнение ручных тестов, например. - person Erick T; 28.10.2014
comment
Вы можете определить в своей команде крайние случаи для своих функций или пользовательских историй и обсудить конкретные примеры. Когда вы используете инструменты с [удобочитаемым вводом для бизнеса]( blog.jonasbandi.net/2010/03/) можно писать спецификации как для ручных, так и для автоматизированных тестов. Пожалуйста, посмотрите пример для спецификации, основанной на Concordion. Когда функция должна быть протестирована, привлеченный тестер убеждается, что все тесты выполнены (просматривая автоматические тесты и выполняя ручное тестирование). - person user3632158; 29.10.2014

Я думаю, что хранение тестов вместе с кодом — отличная идея.

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

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

person Bryan Oakley    schedule 23.10.2014
comment
Команда обеспокоена тем, что пользователи, не являющиеся техническими специалистами, могут бесплатно работать с git. Знания о том, как использовать git, нелегко приобрести нетехническим людям, и легко сбить ногу (и, следовательно, ногу разработчика). GitHub для Windows может быть решением. - person Erick T; 31.10.2014