Всем привет!
Столкнулся с тем, что за последнее время несколько клиентов просили примерно такое: “I would like the test scripts so I can have another tester with non programming skills to run it”. Типа сделайте как можно проще.
В итоге наваял простенький интерфейс, используя Qt.PySide:
Фактически это выбиралка и запускалка тестов. Дальше все происходит в консоли и логах, но можно и сюда добавить.
Как думаете, надо ли дальше изобретать велосипед или может уже есть готовые изящные решения?
как вариант, билд на запуск тестов в CI (Jenkins / TFS / etc)
batch файлы?
С облаком все решается на уровне CI. Можно добавить спец. choice параметр - список suites для запуска, каждый из которых будет содержать различный набор тестов (регрешен, смоук и т.п.). Т.е. любой юзер сможет залогиниться, выбрать набор тестов и кликнуть кнопку запуска, все остальное сделает CI.
В случае с локальным экзекьюшеном все немного сложнее. Если уж взялись за GUI, то он должен быть универсальным. Вижу, что вы добавили 4 чекбокса с конкретными тестами. А что если завтра их будет 100? Будете обновлять каждый раз свой UI? Гораздо более эффективней будет соорудить парсер ваших тестовых классов, который выдернет список имеющихся методов и вставит в какой-нибудь list вашего GUI (аля динамическая подгрузка по заданному пути). Вы чекните нужные для запуска методы, тем самым объединив их в suite. Далее останется только сохранить его в формате вашего unit фреймворка и подсунуть в качестве аргумента для последующего экзекьюшена.
К слову, тут же вы можете допилить фичу удаленного тригера CI джобы из вашего десктопного апликейшена, отправив POST тому же дженкинсу с параметром suite’а для запуска.
В общем, с универсальным вариантом придется попотеть. Многое зависит от сложности имеющейся конфигурации вашего фреймворка / окружений и т.п.
Нет, чекбоксы формируются динамически. Модуль интерфейса импортирует тестовые классы и создает из них лист. Правда описания тестов (я их сделал как toolkit для каждого чекбокса) пока надо вставлять вручную.
С CI пока не довелось поработать практически. Но в общих чертах идея понятна, спасибо!
Кастомный UI для рана тестов - это явный оверхед.
Вариантов дальнейшего развития событий всего два:
1-ый. Как показывает практика - наиболее вероятный. Если пользователь не_в_состоянии/не_хочет запускать тесты из_консоли/ci, редактировать .properties файлы, анализировать резалты и т.д., то вероятность, что он будет пользоваться этим “раннером”, со временем будет стремится к нулю.
2-ой. Если таки пользователю действительно нужен такой “раннер” и тестируемая среда перестанет “вписываться” в 2-ва радиобаттона и 4-ре чекбокса - то новые “хотелки” пользователей будут расти по экспоненте - иерархии/группировки/кастомные сьюты/планировщик/приориты/ре-раны/сортировки/хистори/etc. Тут уже у вас будет два варианта: а) терпеть и “велосипедировать” свою собственную TMS; б) послать лесом и научить пользоваться блокнотом и консолью.
Соглашусь с @vmaximv. Я в свое время прошел через это, и сделал вывод, что проще и быстрее сделать все ручками (настроить xml / конфиги / CI), чем изобретать велосипеды с кастомным GUI, которым по факту никто не будет пользоваться.
А мне идея GUI очень даже нравится. Если этот GUI можно будет конфигурировать для различных тулов и он будет прсто отображать содержимое консоли - уже будет замечательно. Многим пользователям даже выполнить cmd уже сложная задача. Конечно, эти пользователи не профессиональные тестировщики, но графический интерфейс явно упростит понимание механизмов тестирования, а также предоставит клиентам возможность самим гонять тесты. Клиентам тоже важно видеть, что то что вы делаете, это не вещь в себе, а нечто, что они сами могут погонять, и потрогать руками.
Мне кажется, должен быть достаточно простой и универсальный конфиг (в json/yaml/xml) позволяющий указать:
а еще можно прикрутить “агентов” аля самописные win (в случае с C# можно юзать WCF) сервисы, поставить их на пул виртуалок и передавать им команды на запуск тестов с “главного запускатора” 
в общем при желании/времени/необходимости можно много чего накрутить
но проще: CI / батники
А можете сделать эскиз этого GUI, т.к.у меня в голове за пару секунд успело пролететь с десяток параметров, которые могут влиять на конфигурацию запуска. И если клиент в состоянии понимать их предназначение, запустить тесты без UI для него не составит особой проблемы 
Все существующие решения для “гуишного” рана тестов во всех популярных нынче TMS - есть смесь ежа с носорогом, передвигающегося исключительно на костылях, что как-бы намекает на “нетривиальность”.
Мне не совсем понятная система: «tester with non programming skills».
Что это за тестировщики, которые не могут запустить в консоли скрипт теста?
Наверное они имели ввиду себя, т.е. менеджмент / стейкхолдерс и т.п.
Но это не есть задача менеджмента лазить в тесты, имхо. Но это уже оффтопик. Всем сорри.
Помню, встречал таких US менеджеров, которым были нужны всякие однокнопочные GUI солюшены, чтобы потом можно было презентовать все высшему менеджменту самостоятельно. Типа “вы все - рабы, и не достойны показывать это кому-либо, я сама покажу”. 
Такие проекты быстро загибались, ибо автомейшен переставал выполнять свои прямые функции, а все сводилось лишь к феерическим абсурдным реквестам кастомеров.
Это смотря что тестами называть. Я делал утилиту, которая по клику запускает смоук тест приложения:
Открывает браузер на локальной машине, обходит каждую страницу приложения и делает ее скриншот.
В результате создает HTML лог работы со встроенными скриншотами.
Изначально все задумывалось как инструмент, который любой участник нашей команды мог скачать и запустить у себя на машине… Был такой этап на проекте.
Потом, необходимость отпала.
Сейчас же, тестами, которые запускается только на CI сервере интересуются только тестировщики.
HTML логи со скриншотами по прежнему генерируются и ими достаточно часто пользовались на протяжении полугода.
Поясню. Клиент заказал фреймворк для автотестов. Но у него проект в начальной стадии и нет необходимости (да и возможности) в постоянной штатной единице тестировщика. Но необходимость тестирования уже ясно обозначилась. Он готов отдать создание фреймворка на аутсорс, но само тестирование пока нет Согласен, что это не лучший подход.
Внедрение CI - это уже глубокая фаза развития проекта. Не все до нее дозревают. Для многих абсолютно достаточно иметь аккаунт на каком-нибудь облачном сервисе типа Crossbrowsertesting или SauceLabs и запускать тесты там. Но с другой стороны хочется минимального удобства, которое можно достичь с gui.
Упомянутый гуй, конечно, не претендует на универсальность, но при минимальном допиливании может внедряться в любой фреймворк на базе unittest. Например, как опция, которой можно пользоваться, а можно нет.
P.S. Хотя тот же SauceLabs уже вроде интегрируется с Jenkins…
А мне кажется нормально. Надо только сделать удобно и чтоб не требовалось переписывать при добавлении/апдейте тестов.
Я на текущем месте писал плагинчик для идеи для облегчения жизни автоматизаторов для запуска тестов в нашей системе запуска(у нас самописная). Удобно, все под рукой
В качестве готового GUI можно посмотреть на http://www.fitnesse.org. Якобы юзеры with non programming skills смогут задавать тестовые данные, запускать тесты, видеть результат и все это в виде wiki страничек. Но я лично от этого инструмента не в восторге, впрочем как и от самой идеи чтобы юзеры with no skills запускали тесты а потом им было облом анализировать результаты.
Облом там будет задолго до резалтов: обновился FF, не сетнули protected mode/zoom level/popup blocker и еще пару тройку “важных” опций в IE, отключили js, не установили джаву, накатили “ломающий” апдейт от $мелкомягких$, в hosts появилась “ломающая” FirefoxDriver строка
127.0.0.1 some_url, не отключили firewall, залочили рабочую станцию/свернули браузер во время “рана” и еще over9000+ проблем.
И да… гайды можно не писать - их все равно не читают, а если и читают - все что в них написано вылетает из головы после закрытия документа.
А можете сделать эскиз этого GUI
GUI сам по себе будет таким же простым как на вашей картинке. Но есть файл конфигурации, который заполняется разработчиком. Пользователь может только включать-выключать чекбоксы, на основе тех опций, что включены в файле конфигурации. Например:
testomat.io управление авто тестами{
command: "codecept run",
options: {
"html-report": {
argument: "--html"
description: "Создать HTML-отчет"
}
}}
пользователь увидит чекбокс 
Создать отчет. При его включении в команду запуска добавляется параметр --html. Как-то так