Как провести Testing Dojo



    Есть такая штука — Testing Dojo. Это соревнования, где участники ищут баги в приложениях. Кто больше найдёт — тот и победил. Обычно соревнуются командами. Если баги приходится искать вручную, участвуют только тестировщики. Если в бой идут автотесты, подключаются разработчики.

    В 2ГИС Testing Dojo уже давно стал доброй традицией: проводим его третий год подряд. За это время мы много поняли о том, как делать лучше. Под катом поделимся опытом: вдруг и вы захотите сделать свой Testing Dojo.

    Правила


    Есть N команд по 2—3 человека. Каждая команда сидит за компьютером: один кодит, а другие помогают советами. Все участники тестируют одно и то же приложение при помощи автотестов.

    Соревнования делятся на шесть сессий по тридцать минут. Каждая «сессия» имитирует релиз приложения. В каждом релизе есть новые фичи и новые и/или старые баги: всё как в реальном продукте.

    Тесты команд выполняются в конце сессии на Continous integration сервере. По результатам тестов жюри подсчитывает баллы. За каждый баг, который найдёт команда, жюри начисляет очки. За каждый пропущенный — вычитает. Победителя выбирают по сумме баллов за все шесть сессий.

    По таким правилам «играем» мы. Для своего Testing Dojo меняйте правила как захочется. Главное, чтобы все их понимали и, желательно, были с ними согласны.

    Что подготовить


    1. Тестовое приложение.
    2. Рабочие места участников с ПО, на котором пишут и запускают тесты.
    3. Репозитории команд.
    4. CI сервер для автоматизированных сборок.

    Теперь расскажем обо всем по порядку и приведём примеры с Testing Dojo, который мы провели 6 июня.

    Тестовое приложение


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

    1. Приложение простое.
      Чрезмерная сложность сильно замедляет разработку тестов: участники тратят много времени, чтобы разобраться с функционалом. Поэтому для нашего Testing Dojo не подходил вариант «взять какой-нибудь продукт 2ГИС и добавить в него багов».
    2. Функционал приложения хорошо разделяется на отдельные фичи.
      Каждую фичу описываем в виде очень короткой спецификации.
    3. Некоторые баги встречаются только в одной сессии, а другие повторяются.
      Так уже готовые тесты приносят баллы в последующих сессиях.
    4. Приложение с нужным функционалом быстро собирается и обновляется.
      Функционал соответствует номеру релиза.

    Для последнего Testing Dojo мы написали достаточно примитивный каталог товаров. В его первой версии был только строгий поиск по части названия. В последней — управление товарами.

    Актуальную версию приложения собирали и деплоили на тестовые ноды сервера Jenkins в конце каждой сессии. В начале следующей сессии участники обновляли приложение до последней релизной версии.

    Скрипт для обновления:
    $appLink = 'http://opensource-ci.2gis.ru/view/Testing%20Dojo/job/td-tested-application/lastSuccessfulBuild/artifact/TestingDojo2015.exe'
    $outFolder = $env:UITestApps
    if ($outFolder -eq $null) { $outFolder = 'C:\app' }
    $outFile = (Join-Path $outFolder 'TestingDojo2015.exe')
    
    if (Test-Path $outFolder)
    {
        Remove-Item $outFile -Force
    }
    else
    {
        New-Item -ItemType directory -Path $outFolder | Out-Null
    }
    
    try
    {
        Invoke-WebRequest $appLink -OutFile $outFile
        Write-Host 'Update successful!'
    }
    catch
    {
        Write-Error $_.Exception.ToString()
        Write-Host 'Update failed!'
    }
    
    Write-Host "Press any key to exit.."
    $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyUp") > $null
    

    Информация о фичах текущей версии (размещали её на страничке мероприятия):
    Версия 5. Фичи
    Добавлена возможность одновременного удаления несколько записей. Выбрать несколько записей одновременно можно удерживая клавишу Ctrl или Shift. Удаление происходит по нажатию кнопки “Удалить несколько”, которая появляется при одновременном выборе более одного элемента.
    Сортировать записи можно как по идентификатору, так и по названию. Нужное поле сортировки можно выбрать из выпадающего списка. Порядок сортировки изменяется с помощью переключателя.

    Информация для жюри о новых и исправленных багах:
    Версия 5. Баги
    Починился баг с сортировкой
    Починился поиск
    Если через Ctrl выделить несколько записей то удаляются все кроме последней

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

    Рабочие места


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

    Для последнего Testing Dojo мы подготовили аудиторию на 10 рабочих мест. Рассчитывали на 20 тестировщиков и разработчиков из разных компаний Новосибирска.

    Соревнования мы посвятили тестированию desktop-приложений для Windows, поэтому предложили участникам писать на Selenium-based драйвере Winium.Desktop. Это обёртка над нашим opensource-инструментом Cruciatus, расскажем о ней в отдельной статье.

    Благодаря Winium.Desktop, мы пишем тесты на разных языках программирования. Для Testing Dojo выбрали C# и Python 3.x и подготовили для них среду. На каждый компьютер с Windows 8 поставили Visual Studio (+ Resharper) и PyCharm.

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

    Пользователей создавали скриптом:
    # Set-ExecutionPolicy -ExecutionPolicy Unrestricted
    
    $hostName = [System.Net.Dns]::GetHostName()
    $cultureLCID = (Get-Culture).LCID
    $userName = "testingdojo"
    $userPassword = "2gisTD2015"
    
    # 1033 - English, 1049 - Russian
    # https://msdn.microsoft.com/en-us/goglobal/bb964664.aspx?f=255&MSPPError=-2147217396
    if ($cultureLCID -eq 1049) { $rdpGroupName = "Пользователи удаленного рабочего стола" }
    elseif ($cultureLCID -eq 1033) { $rdpGroupName = "Remote Desktop Users" }
    else { Write-Host "Unknown LCID:"$cultureLCID; return }
    
    # add user
    # http://blogs.technet.com/b/heyscriptingguy/archive/2014/10/01/use-powershell-to-create-local-users.aspx
    # https://msdn.microsoft.com/en-us/library/aa772300%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
    $comp = [ADSI] "WinNT://$hostName"
    $user = $comp.Create("user", $userName)
    $user.SetPassword($userPassword)
    $user.UserFlags = 64 + 65536 # ADS_UF_PASSWD_CANT_CHANGE + ADS_UF_DONT_EXPIRE_PASSWD
    $user.SetInfo()
    
    # add user to Remote Desktop Users group
    # http://blogs.technet.com/b/heyscriptingguy/archive/2014/10/03/adding-local-users-to-local-groups.aspx
    $group = [ADSI] "WinNT://$hostName/$rdpGroupName,group"
    $group.Add("WinNT://$hostName/$userName, user")
    

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

    Для этого заглянули на полки IKEA и нашли забавные ничего не значащие (надеемся) слова: «duken», «kokbanan», «risdal», «morvik»…

    Итак, проследите за рабочими местами участников. Убедитесь, что установили необходимое ПО, вбили пароль от Wi-Fi и поставили тестовое приложение.

    Репозитории команд


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

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

    Если интересно, гляньте репозитории команд на Гитхабе.

    Автоматизированные сборки


    Для каждой команды мы настроили сборку на Jenkins.

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

    Что в итоге


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

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

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

    Эти правила — неплохая база для хорошего мероприятия. Используйте их, чтобы сделать свой Testing Dojo. Уверена, у вас всё получится!
    • +14
    • 4,1k
    • 1
    2ГИС
    138,00
    Карта города и справочник предприятий
    Поделиться публикацией

    Похожие публикации

    Комментарии 1

      0
      Отличное мероприятие, очень рада, что смогла принять участие :)
      Спасибо еще раз за такую классную идею :)

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

      Самое читаемое