Началось все утром в пятницу, 14 мая. Проводили в Радмир Экспохолле, хотя где еще можно это проводить в Харькове пока придумать не могу.
Пока народ прибывал и регистрировался, я немного поправил здоровье горячим чаем и уточнил программу конференции. Очень приятно, что программа конференции была отдельно в раздатках, потому что в последний день произошли изменения и было бы неприятно бегать в поисках нужного доклада. Хоть рецензий на изменения и не было в распечатаном сборнике тезисов. Также в раздаточных материалах был диск с материалами конференции. Приятно порадовал бонус в виде материалом по SQA Days 4 и 5.
Организаторы, как и положено, обратились ко всем со вступительным словом, рассказали про планируемые плюшки. и все устремились.
В начале слушал "Сокращение времени выполнения регрессионного тестирования", Павел Моцарь. Как человек выступал понравилось. Суть в том, что в их компании начиная с момента, когда еще не было ни Hudson, ни СruiseControl развернули систему управления версиями и, самый важный момент, добились установки системы на тестовую конфигурацию одним кликом.
Далее автоматизация тестирования. Она как раз и используется для регрессионного тестирования. Да, также запуск скриптов в одно касание :). Но тесты, хотя на данный момент идея не так уж и нова, из-за огромного их количества и большого времени прогона, разбиты на suites и каждый suite запускается на отдельной тестовой конфигурации.
Интересный момент, что клиент этой системы автоматизированного тестирования запущены на большинстве рабочих машин работников. И система может запросить хардварные ресурсы рабочей машины работника, чтобы обеспечить свою производительность. :) Мне, правда, сразу вспомнился LoadRunner.
Далее был "Метод Всех пар, или как не убиться тестируя комбинации", Александра Барановского. Кстати по манере изложения один из самых качественных докладов был. И идея полезная, хотя тоже не новая. Суть в том, чтобы сократить число тестов при тестировании взаимодействующих параметров, таких как настройки системы. Метод рассмотрели еще и на конкретном примере. И специальную тулзовину посоветовал.
Почитать можно и в интеренете, но суть в том. Чтобы вычленить все имеющиеся параметры (контролы формы настроек), их значения. А потом можно загрузить в предложенную тулзовину (PICT от Microsoft) и получить упрощенный вариант тестов. В двух словах описать математическую составляющую метода мне тяжело.
Этот метод не дает замену полному перебору. Но предлагает оптимальное количество тестов, при котором можно выловить большую часть ошибок.
После этого пошел на доклад "Страсти по качеству", Владислава Орлика. Доклад вставили вместо другого и получился он спонтанным. Но такой опытный человек смог выйти из положения и предоставил на суд и разбор ситуацию в "Одной Компании". Пересказывать не буду. Были неплохие трения в подходах к решению проблемы. Но разошлись миром. И не странно, чтобы столько управленцев в одном месте не смогли найти общего подхода.
Перед обедом пошел на доклад, "Организация процесса тестирования в Agile команде на основе матрицы квадрантов тестирования", Игорь Бондаренко. Инженерам, на плечи которых только упала ноша управления командой тестирования он бы несомненно помог систематизировать свои знания. Все сорок минут человек рассказывал о тестовых активностях и том, как их разбили на четыре группы, эти самые квадранты. К концу, правда, так и не стало понятно зачем такое разбиения, но после того как был задан этот повисший в воздухе вопрос все стало ясно. Разбиение активностей по группам помогает команде по тестированию при работе на спринте. На этапе планирования все новые фичи и планируемые таски расклеивают по этим группам на тестерском scrumboard и дальше уже проще распределять их внутри по статусам.
Потом был обед и я пока прервусь :)
Комментариев нет:
Отправить комментарий