Последние лет пять я занимаюсь тем, что помогаю делать тестирование системных приложений быстрее и дешевле. По молодости (будучи юн и горяч) я старался просто работать быстрее руками и внимательнее головой, но постепенно пришло понимание, что у ручного тестирования есть предел эффективности: для отдела из руководителя и двух тестировщиков это примерно 30 фич в месяц. Казалось бы — нет проблем, ведь существует хорошо отработанный путь по беспощадной автоматизации тестирования — одно избавление от регресса даст с лихвой свобдного времени, выберем просто систему из того, что есть на рынке, внедрим и будем жить счастливо. И тут жизнь заявляет: «Нет.»
И дело не в том, что все системы автотестов имеют фатальный недостаток или не отвечают простому списку требований, порожденному моей буйной фантазией(ссылка на мои требования) Проблема тестирования системного софта отмечена еще в 2013 году талантливым исследователем Фридлянд Ю. М. и звучит она как «обеспечение
поддержки перезагрузки в системе автотестов». Почти месяц формирований разнообразных запросов к поисковым системам привел меня к факту, что иных релевантных ответов на вопрос «как делать автотесты с перезагрузкой» кроме презентации к дипломному проекту наших партнеров нет. О боги, подумал я, прочитав тот pdf — тащить целый TFS со всей сопутствующей инфраструктурой Microsoft ради жизни после перезагрузки?
За что мне это?
И я стал изучать другие решения. Да-да, я действительно смотрел docker, читал про ci на основе jenkins, пробовал и разочаровывался — либо решение полностью не подходило, либо количество необходимых смежных технологий к изучению давало в перспективе уникально-модифицированное неподдерживаемое решение (либо поддерживаемое штатом высококлассных специалистов), я менял проекты и работодателей(на все более именитых конечно же), но везде видел одно и то же — тестировать системный функционал(обновление драйверов, выключение ОС, лечение вирусов, проверка автозагрузки) руками являлось наиболее быстрым, надежным и дешевым способом.
А потом я открыл для себя python. На одной этой технологии оказалось возможным написать простой менеджер виртуальных машин (import pysphere), веб-интерфейс к нему (import web2py), агента тестирования- win32 службу (import win32service), доставляемого на виртуалку через iso образ, и сами тесты, собранные в отдельные exe-файлы через pyinstaller(чтобы не мучиться с предподготовкой систем, инсталляцией python etc). Все это добро поддерживается 1 специалистом со знанием 1 технологии, bus-фактор минимален, чему я несказанно рад.
Таким вот нехитрым образом мы избавились примерно за полгода разработки своего велосипеда от регресс и смоук-тестов, на ручные тесты падает только новый функционал, от чего у всего отдела тестирования волосы стали мягкими и шелковистыми, чего и вам желаю.
Собственно, после набора некоторого количества новых фич, мы отдаем продукт зондер-команде — нашим бета-тестерам, кстати присоединяйтесь и через фидбек в техподдержке доводим качество до небывалых высот.
ссылка на оригинал статьи https://habrahabr.ru/post/282548/
Добавить комментарий