2012-04-23: SQAdays весна 2012 - день второй

Второй день весенней SQA Days 2012 в Киеве был достойным продолжением первого. Было много достойных докладов, о которых я напишу. Правда, после обеда я три слота пропустил - Susumu Sasabe и Yaron Tsubery, чьи выступления мне очень понравились в субботу отвечали на вопросы и это надо было слушать: доклады можно посмотреть в трансляции, а это - нет.

Слушая Susumu, я осознал принципиальное отличие японского способа мышления от западного (американского и европейского) в представлении процессов. Западный человек представляет процесс как объект, статически - картинка as is. Если его зачем-то надо изменить - ставим цель, рисуем картинку to be. И меняем. Если изменения велики, то ищем траекторию as is ⇒ to be, вырабатываем план и меняем по плану. Японцы же знают, что процесс сам по себе изменчив и всегда держат в голове траектории их изменения. Когда Susumu говорил о разных процессах, а он в своих ответах описывал их несколько, он всегда держал эту траекторию изменения, представлял их. И, собственно, японский подход непрерывного улучшения - он как раз опирается на это представление, работает на сознательный выбор траектории, ведущей к улучшению.

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

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

Оговорюсь, что все это - сугубо мое осознание, полученное по осмыслению описания Susumu разных процессов, на контрасте вопросами и ответами Yaron. Я не обсуждал его с Susumu и могу ошибаться. Но оно хорошо соотносится с моей картиной мира. А еще - несмотря на малую практическую разницу, это отличие, думаю, имеет очень большое значение для понимания японских методик изменения процессов, прежде всего kaizen и lean, которые сейчас очень распространены. Преломляясь в западном сознании они теряют восприятие процесса вместе с траекториями его изменения. Я еще буду осмысливать это. Понимание не значит, что я научился мыслить по-японски, я всего лишь понял, в чем отличия.

А сама беседа была в совершенно неформальной обстановке стендовой секции, на шарах-креслах. Yaron сел сразу, а Susumu долгое время отвечал стоя, но потом - тоже присоединился к сидящим, это был определенный разрыв шаблона. Посмотрите потом фотки.

А теперь, после такого размышления о японском способе мышления, перейдем к описанию докладов. Я не буду их делить по категориям как вчера - все доклады, о которых я пишу мне понравились. А еще они сформировали некоторую целостную картину в части автоматического тестирования, которую я изложил сегодня. И дали много информации о всяких инструментах для этого, которую я не буду приводить в описании докладов - для этого надо смотреть презентации, а они не выложены. Но готов рассказывать заинтересованным лицам при обсуждении конкретных проектов.

IT в стоматологии. Купили другую компанию, у которой система для полного цикла - от слепка через трехмерную модель до изготовления пломбы на станке. Система из многих приложений, распределенная, web и нативный интерфейс. На входе - тестирование вручную, тестировщики основное время готовят на подготовку данных и конфигурирование стенда, да еще часто ошибаются. Плюс система без документации, все в людях - разработчиках и тестировщиках, знания которых противоречивы. А еще - система работает во многих вариантах, с разными конфигурациями.

Они решили пойти на автоматизацию теста, идя последовательно по полному циклу E2E, а заодно получить знания о системе. Подготовка проекта - экспертный опрос, оценка, прототипирование, плюс интуиция. Я: догадайся, что главное.

Сделали прототип шагов E2E на HP QTP, проводили тестовые коммуникации. Автоматизировали тесты не от интерфейсов, а по внутренним данным, для чего составили wishlist для разработчиков, 3 приоритета. После прототипа - отказались от HP QTP, потому что он тяжелый, а лицензии - дорогие. И использовали Auto IT X и Selenium WebDriver.

Делали скриптовое тестирование, гибкое и расширяемое. С учетом микса системы - и web и клиент. Пришлось поднять тестовые наборы машин - там еще засада, что не все Win-приложения могли совместно устанавливаться на одну машину. Обновление - через Git, данные - через файлы. Data-driven подход - можно дать множество разных входных данных, которые проходят через тесты. Пользователь-тестировщик - готовит данные, дальше скрипты это прогоняют. А заодно - они получили решение для автоматизации ручного тестирования. Да еще - снизили число требуемых виртуальных машин от 40 до 6, и получили тулу их конфигурирования.

В целом за 3 месяца двойной чистый профит. Делали это 3 человека, первый вариант получился за 2 месяца. Решение использовано в других командах, например, в для финансового отдела. Поддерживают скрипты 5 человек, пользуются скриптами 30-40 человек. Система постоянно дорабатывается.

В конце: high наука - цикл получения знаний, спроецированный на их ситуацию. И это правильная вещь - рисовать конкретное воплощение общего цикла.

Хороший доклад с очень существенным недостатком - докладчик несколько раз начинал рисовать на доске и это было почти не видно. Очень жаль. А рисовать на компе конференции он не мог - он показывал живые коды и подключал свой ноут. Решение, наверное, было, но тяжелое - выступать с компа конференции, чтобы на рисовать на экране, а на свой ноут заходить через rdp. В общем, жаль что была доска.

Начался доклад с небольшой теоретической части о ATDD - Agile Test Driven Development. А дальше был рассказ про Robot Framework - фреймформ для создания тестов, с помощью которого все этом можно воплотить. Он - один из многих, в презентации был список, но именно он нравится докладчику, и он показывал его функциональные возможности, структурировано и соотнося с применяемыми методами. И в результате я получил представление не только о конкретном фреймворке, но и о всем спектре функционала, который должны обеспечивать такие фреймворки.

Итак, что за это функционал?

• Это средство для создания гетерогенных тестов - WebService, DB, MQ, между которыми можно перебрасывать данные, подключаясь с помощью стандартных библиотек.
• Это скриптовый язык написания тестов, в данном случае - Python. На котором можно писать в keyword-driven тесты, которые (если за этим следить) представляют собой белый ящик, понятный тестировщикам. Настолько понятный, что в принципе how to demo, тесткейс можно писать как заготовку теста. Тесты в формате BDD, given-whet-then формат и создавать keyword по ходу дела.
• Это средство ведения каталога тестов, с структурированием, разметкой через тэги.
• Это ведение лога запуска тестов.
• Это отчеты, для менеджеров и инженеров, разные. Для менеджеров - 2 состояния, зеленый и красный на весь отчет, а для инженеров - куда более подробный.
• Это ide для написания тестов, с autocomplete, и с графическим представлением, которое, однако, сохраняется в файле в хорошо структурированном, читаемом человеком формате, а не в виде уродливых xml.
• Подключение к серверу continious integration, докладчик говорил о jenkins, для чего есть html-формат представления.
• Сам фреймворк - свободный. И вокруг него - очень большое комьюнити и библиотеки.

Вообще докладчик - евангелист в хорошем смысле этого слова. Он пишет на Java, но любит Python - и потому ему нравится RobotFramework. Но в целом выбор фреймворка - он зависит от конкретных проектов и задач. Только - выбирайте хороший, они есть, и в докладе показано - каким должен быть хороший фреймворк.

Я был на кусочке доклада, потом пошел на обед чтобы успеть на следующий доклад. Доклад содержательный и интересен тем, кто занимается распределенной разработкой и взаимодействует с Индией. О культурных различиях, позитивный и полный конкретных примеров. Например, в Индии не могут сказать "нет", это культурная черта, не принято сообщать плохие новости. О том, что для такой команды устная коммуникация - часто хуже письменной, преимущества невербальной коммуникации сводятся на нет слабыми навыками устной речи. Поэтому надо переходить в письменное общение, но при этом полностью убрать устную коммуникацию нельзя, надо понимать собеседников.

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

Рассказ о проекте, в котором надо было автоматизировать тестирование полностью закрытого приложения, запускаемого под citrix. С точки зрения системы такое приложение представляет собой окно с меняющейся картинкой, никакого доступа к внутренней структуре - нет. Оказывается, существуют средства автоматизированного тестирования и для таких случаях, распознающие элементы экрана по их графическим образам, которые вырезаются из screen shot'ов.

И это можно успешно использовать.

• Когда нет доступа к дереву элементов.
• Свойства все время меняются - динамическая перестройка дерева или что-то подобное.
• Legacy-приложение. В том числе при интеграция с такой системой.
• Нехватка времени. Говорит, что так быстрее всего.

Существенная проблема при таком тестировании - проверка ответа, реакции на действия. По-сути есть только два способа: распознавание текста в заданном элементе или копирование результата в буфер обмена и проверка его содержимого. А еще - тесты могут получаться зависимыми от разрешения, и от окружения: skype выкинул popup, закрыл нужную часть экрана - тест упал.

Рассказывали про два инструмента: eggPlant, мощный но дорогой, и sikuli.org, свободный, но по-проще. Они выбрали sikuli - его оказалось вполне достаточно, слабые по сравнению с eggPlant места оказались некритичными, а местами были преимущества. Но отчеты и подробный лог пришлось писать самим - правда, это оказалось легко.

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

А еще sikuli можно использовать вызов через api и делать композитные тесты Java+Sikuli, в том числе Web - когда на странице апплеты, например, видео, а также когда есть только отдельные элементы, с которыми не получается работать обычными тестовыми средствами.

Совместный доклад. Попробовали сделать в стиле Орлова и Панкратова - элементы получились неплохо :)

Рассказ был о типичной для многих ситуации: Много знаю, Меньше умею и Еще меньше делаю.

Что нам мешает тестироовать? А виноват Заказчик. Жадный мальчиш-плохиш сидит на бочке с вареньем. И не дает делать правильные вещи, не платит за них :) Но! зачем заказчику отдавать печеньки? За какие-то автотесты. Надо убедить и ответить.

Матрица ROI на опыт, 2х2. Примеры - метафоры, а потом в тех же квадратах артефакты. Чтобы учиться надо работать в области, где мало опыта и убедить заказчика можно, только если имеется ожидаемый ROI, хотя бы в форме плюсов. А не там, где просто интересно. Как искать такие области - SWOT-анализ.

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

• Будете работать быстрее - будете быстрее сдавать продукт?
• Улучшите качество - я буду меньше платить за поддержку?

И так далее. На них тоже надо иметь ответ.

Еще один парный доклад, в форме театрализованного представления. С привлечением активности зала. С костюмами. Только актерских интонаций не хватало - получалось впечатление фильма с дикторской озвучкой. Но все равно - впечатляет.

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

Доклад конкурировал с Руколь и Мясниковым, поэтому народа было мало, и я сам слушал только кусочек. А тема - была интересная, хотя и не моя. О том, как тестировать производительность приложений, которые работают в облаке. Когда у тебя есть тестовый стенд, и он - не такой как боевой, а слабее и дешевле, хотя в том же облаке. На какие характеристики можно опираться, а на какие - нельзя. На что обращать внимание. На совсем неожиданные варианты, когда под малой нагрузкой приложение работает медленнее, чем под большой из-за сброса кэшей. В общем, если эта тема для вас актуальна - посмотрите.

А еще было немного про визуализацию результатов. R-Project - инструмент для визуализации. Бесплатный, кроссплатформенный, жрет миллионы строк. Язык - скриптовый. Лучше gnuplot и bash.

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

[ Хронологический вид ]Комментарии