SQAdays-12, день первый

Конференция SQAdays-12 в Минске — очень удачно. Много хороших и дельных докладов. Более 500 участников и много общения. Постоянный кофе и перекус в фойе также способствует общению. А вечером — затянувшееся afterparty. И все эти замечательные штуки — традиционны для SQA Days.

Общие темы, которые были в большом количестве докладов.

• Архитектура конструкции для автоматических тестов. Наиболее полно — в докладе Лянгузова, но у других тоже звучала. Отделение тестов от данных и так далее.
• Разделение уровней тестирования: UI — бизнес-логика комплексно (API сервисов) — unit-тесты отдельных частей. Выстраивание пирамиды.
• Доклады о распространенных ошибках и проблемах. Да, это все — известные грабли. Но почему-то по ним любят ходить.
• Об организации тестирования, сотрудничестве разработчиков и тестировщиков, которое необходимо.

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

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

А теперь я быстро перейду к обзору докладов и начну, как обычно, с тех, которые больше понравились.

Алексей Лянгузов, Grid Dynamics. Архитектура автоматизированных тестов. Великолепный доклад про построение архитектуры автоматических тестов. О том, из каких составных частей это должно быть собрано, какие требования к отдельным компонентам и какие взаимосвязи допустимы, а какие — лишние, мешают развитию. С деталями и конкретными вариантами для каждой компоненты, который применяют они и какие еще возможны. При чем, в известных источниках описания такой конструкции — нет, ее продвинутые люди — сами создают, а не продвинутые — делают как получится. Зал сильно переполнен.

Телеграфные записи основных моментов, остальное — смотрите презентацию и видео.

• Библиотеки. Важно поставлять тех же версий, что и в проме. У них Мавен.
• Фреймворк. Обеспечивает отчеты. Определяет формат тестов, это надо учитывать при выборе. Обеспечивает запуск тестов. Обычно начинают с Junit, а так — Fitness и Cucumber совместно.
• У Fitness тесты — Fixture, в других — есть аналоги. Это привязка тестов к исполняемому коду.
• Тестовые данные. От тестов отделяются. Повторное использование, структурирование и систематизация.
• Окружения. Запуск тестов в разной среде — FF и IE
• Конфигуратор. В приложении обычно статические настройки. Но их не всегда достаточно. Например, при запуске тестов под виртуалками с динамическими ip-адресами может быть нужно разбираться с сертификатами и подхватывать эти адреса.
• Важно, чтобы вся внешняя среда ушла из fixture
• Менеджер данных. Тесты не должны говорить «дай мне данные из этого файла, они должны говорить «дай мне данные такого типа в таком количестве». У них совсем умный менеджер не получился, но они туда идут.
• Еще важно контролировать связи между разными компонентами, архитектура зависимостей показана.
• Пример-1. Структура каталогов. Для Java-компонентов. Это — отражение логической архитектуры в структуру реализации, и со своими дополнениями.
• Вопрос уровня тестирования. Можно работать на UI, можно на бизнес-логике. Тест нового пользователя. Запрос пользователя, которого нет — создание — проверка, что есть. Вообще говоря, этот тест можно пускать на UI, можно на веб-сервисах, можно глубже. И в идеале мы должны иметь возможность переключения уровней. В принципе, это не очень сложно — если заранее подумать. Тут что важно — если есть не UI-вход. Потому что UI не может подсунуть неправильные значения — ограничения сверху. А тестировать сервисы — надо.
• Признак нехороше архитектуры — появляются папочки «разное» или классы, которые некуда приткнуть. Я: очень правильно!

Игорь Хрол, ЭПАМ Системз. Автоматизация тестирования: почему умирают проекты? Очень хороший доклад о том, почему умирают проекты автоматизации тестирования, и как поступать, чтобы это не произошло. По его ощущениям 80% таких проектов — провальные, и его это очень волнует. А вспоминая первые проекты — сейчас он видит, что они были мертворожденные. Этим и вызван доклад.

Типичные причины провалов.

1. Запись тестов (recording). Еще 5 лет назад была книга, что это не работает. Но до сих пор продают и покупают именно это.
   • Перестает работать на чуть более сложных проектах, чем демо
   • Невозможно поддерживать по изменениям. Представьте, что recording продают бухгалтеру.
   • Простой выход — не используйте
   • Чуть более сложный: обеспечьте, чтобы работало для вашего приложения. Это доработка. И смиритесь, что когда поменялось — надо перезаписать тест, не пытаемся читать и модифицировать. И под это — заточите методику.
2. UI-автоматизация теста — медленная.
   • Потому что поднять с нуля через интерфейс — тяжело. По данным. Плюс — мы работаем через посредника.
   • Решение: Нормально пишите код. Не используйте sleep для синхронизации
   • Решение: Запускайте тесты параллельно. И сразу стройте архитектуру для этого. Включая разделение данных.
   • Фокусируйтесь на других видов автоматизации тестирования. Комплексно. UI-тесты — верхушка, а под ними — уровень бизнес-логики, API, там больше тестов. Под ними — unit-тесты (здесь: по логическим фрагментам).
3. А еще — UI-тестирование нестабильно. 2-3% fail-тестов просто потому что асинхронно.
   • Тоже не тестируйте все через UI. Я: из зала — неправда. Да, потому что там тоже может быть асинхронность
   • А еще — перезапускать после падения, и анализировать только повторные падения.
4. Слишком дорого разрабатывать и поддерживать.
   • Потому что выполняются медленно, а тестировщик — просто ждет
   • Потому что неверно выбран инструмент. Разработка тестов — тоже разработка ПО. И надо применять технологию.
   • Потому что недостаточно знаний у команды. Для хороших тестов — нужно сотрудничество разработчиков и тестировщиков, по-отдельности получается хреново.
     • Простой механизм от разработчиков, чтобы тест понимал, что все отрисовано
     • Чтобы найти кнопку попросите разработчиков добавить id, а не ищите полчаса как обойти.
   • Используйте хороший фреймворк
   • Отделите фреймворк от скриптов
5. Автоматизация не используется. И, блин это проблема
   • Мы не доверяем автоматическим результатам, лучше проверим руками. — Надо учить работать по-другому, работа с людьми. Интегрировать автотесты с ручными, в общей системе. Userfriendly: ручные писали в Excelб а тут будет какой-то xml. И запуск одной кнопкой.
   • Слишком долго и сложно анализировать автотесты. Это реально, и надо продумывать. Пример: (а) автотест упал — прогнали вручную — внесли дефект на систему при повторении, или на автотест, если ручной прошел.

Подводя итоги

• Выберите правильный фреймворк. Это — разработка
• Внимательно отнеситесь к организацию процесса и разделению обязанностей
• Налаживайте коммуникацию между командами.

Аяз Ашрапов, Fujitsu. Базы знаний на службе у IT-аутсорсеров. Про процессы ведения базы знаний в Fujitsu. Они включены в процесс работы над проектом. Между проектами идет обмен знаний, несмотря на потребность в дополнительном обезличивании для этого. Это касается, например, базы про KPI, например по времени вхождения человека в проект, эффективности выполнения проектных задач и т.п.

Про инструменты.

• Не нужно наворачивать, потому что с базами знаний должны работать все сотрудники компании. А не только продвинутые.
• Расширяемость. Потому что область использования будет расти, а инструмент — не сменишь.
• Поддерживаемость. За инструментом надо будет следить, делать расширения и прочее. И тут вопрос тяжести решения.

Рекомендации напоследок.

• Сделайте обязательным использование базы знаний. Чтобы в ней все было, искать в одном месте.
• Автоматизировать рутину. Ее все ненавидят. Например, поиск устаревших статей. Рейтинги. Поиск. Аудит — отчеты что плохо. У нас тут хорошо. Пример: как только в Project-сервере меняют проект сотрудника, он получает письмо со ссылками на статьи, и он — должен ознакомиться, это тоже контролируют.

По инструментам — они используют микс. Часть — требует заказчик. Используют медиавики. Где-то sharepoint.

Любовь Аверина, Ново-Плей. Пример эффективного управления тест-кейсами при помощи Google docs. Основная идея доклада в том, что Google Docs таблицы представляют собой коллективно и совместно используемый Excel. В таблицах — удобно вести тест-кейсы, но вот совместно работать с Excel-файлами тяжело. А google docs — позволил эффективно работать. И докладчица подробно показывала, как у них это сделано. К сожалению, не видя экрана (а он далеко) это посмотреть не получалось. Но я надеюсь на презентацию.

Елена Андреева, Grid Dynamics. Грабли автоматизации. Учимся на чужих ошибках. Либез по правильной организации кода. Популярные грабли. Коротко и по делу. И, вроде всем известно и очевидно. Но мусорные куски закомментированного кода при этом встречаются повсеместно. И у разработчиков тоже. Плюс — тестовые фенечки, например, логи вместо системного вывода. Великолепная фраза «Результаты проверяйте просто, иначе в проверках — будут ошибки».

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

Проблема в том, что в compile-time не достаточно информации. Например, cast object к конкретному типу. В общем случае — ошибка, но в конкретной программе архитектура может гарантировать, что на вход идут только объекты нужных типов. И чтобы преодолеть это — используют дополнительную разметку, и специальные тулы, которые, опираясь на эту разметку проверяют правильность. И таким образом можно гарантировать, что строка-номер кредитной карты по всей программе имеет правильный формат, который на входе из простой строки — будет проверен. Или поделить все строки, используемые для динамического sql на те, которые заведомо корректные, и те, где нужен контроль sql injection, и обеспечить, чтобы этот контроль был проведен до исполнения. Получаются Pluggable types, дополняющие систему типов. Как средство упоминали Checkit framework.

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

Рина Ужевко, SKAZKA. Тестирование и техподдержка брак или сотрудничество? В общем, название — странное, но сам доклад — хороший и правильный. О том, что логично возложить обязанности техподдержки на тестировщика, и о тех плюсах, минусах и особенностях, которые несет такое решение. В общем, в нашей компании все так и происходит, поэтому для меня лично нового не было, но ведь не везде так. А содержание — правильное. А еще — там было много историй из будней техподдержки по играм.

Виктор Гляненко, VIAcode. Анти шаблоны непрерывной интеграции. О дополнениях оргплана, которые надо накрутить поверх непрерывной интеграции. Например, если сборка по commit — то в пятницу последний час коммитить нельзя. Или если сборка не по коммит, а раз в полчаса — надо понимать, как разбирается ситуация падения билда. Много мелочей, которые очевидны когда на них наступишь, но есть и важные вещи. Одна из них — автотесты гарантируют ограниченную работоспособность и их надо сопрягать с ручным тестированием, включая его в непрерывную интеграцию в некотором объеме.

Алексей Емелин, Яндекс. Тестирование безDOMных объектов современных веб-интерфейсов на примере API Яндекс.Карт Интересный доклад, хотя и далек от меня, поэтому я слушал кусочки. Задача тестирования, когда внутри картинка, а не элементы. При этом там еще накладываются проблемы инструмента. Собственно, дается некоторый путь — как делать. Например, когда ставят метки и прокладывают пути. Там точки — это DOM-элементы, а вот пути — нет, это дополнительная линия. Можно делать API. Но вопрос что там. Второй вариант — пискельное считывание и анализ. Они — сравнивают с эталоном. Они генерируют эталон на продакшн и сравнивают с тестовым, проверяя, что ничего не сломали. Но! для нового функционала не годится.

Еще интересно про обработку ошибок. Есть onerror, но он не ловит на загрузке страницы. А еще — вопрос хостов. Для хостов можно делать доверенные узлы — если есть доступ. Второй метод — плагин JSErrorCollector, ловит ошибки браузера. И со списком можно взаимодействовать. Но только FF.

Илья Кацев, Яндекс. Проект Роботестер Робот как тупой юзер. Умный юзер — пусть будет тестировщик. Но тупая часть работы у него уходит. Краулер — ходит по сайту. По мотивам поиска, только внутри страниц, смотреть состояния и действия. Тут важно, что страницы очень динамические, содержимое сильно меняется. И надо заполнять формы и активировать. И там еще java-script логика, активизация кнопок. В целом интересно.

Наталья Руколь, Лаборатория качества и Андрей Мясников, Undev.ru. Диалектика созидания: курс на сотрудничество. Последний доклад дня, шоу с интерактивом. Четыре миниатюры взаимодействия тест-менеджера Наташи и тестировщика Андрея. Все идеи понятные, но сценки все равно классные, особенно вечером.

Миниатюра где «все не так» и разборка с мест — что именно не так. А потом — разбор ошибок. И рекомендации по исправлению.

1. Собеседование
2. Первый рабочий день
3. Испытательный срок
4. Рутина. В последней сценке менеджер окончательно демотивировал тестировщика, а потом — уволил.

Записывать не было смысла, так — отдельные фразы.

• Нет глупых вопросов, есть глупые люди, которые не задают вопросов.
• Нечеткое задание «познакомься с продуктом»…
• Если свободного времени нет сейчас, то его не будет и потом.
• Менеджер — не чайник, потому что его нельзя выключить.
• Соответствие слова и дела.
• Завел больше всех багов — к кулеру без очереди 🙂

А теперь — про остальные доклады, на которых я был.

Александр Андрущенко VIAcode. Тестирование производительности системы мониторинга на платформе Microsoft SCOM 2012. Доклад о том, что система мониторинга не должна напрочь перегрузить систему, вырубив приложение. Проблема в том, что мониторинг подключают далеко не сразу. Система уже написана и работает. И в этих случаях подключение мониторинга может быть чревато. Поэтому нагрузку самой системы мониторинга — тоже надо мерить и учитывать.

Михаил Матвеев, T-Systems. От ручного тестирования к автоматическому: опыт внедрения в крупном проекте. Была конкретная задача — перейти от ручного тестирования к автоматическому, без дополнительных требований к квалификации того, кто разрабатывает сценарии тестов. Ручные тест кейсы вели в Itorg. Для автоматических выбрали два продукта (от экрана далеко, поэтому не записал, но презентация — будет), один из которых обеспечивает визуальное конструирование тестов из набора шагов, а второй — генерит по этому некоторый исполняемый скрипт. Успешно.

Ольга Киселева, HFLabs. В моем коде багов НЕТ! Странный доклад. Про автотесты, которые делают большим количеством копи-пастов, и их надо вычитывать. И тесты, которые проверяют count, а не содержалку и так далее, слова правильные, но не структурировано. С другой стороны, проблемы-то воспроизводятся во многих случаях. В общем доклад про множественные проблемы плохоорганизованной разработки (тут — тестирования), и о частных решениях, которые надо обеспечивать через человеческий фактов (надо подумать, постараться…). Наверное, так бывает, но решения все-таки нужны более промышленные, процессные по-моему.

Алексей Надененко, Сбербанк Технологии. Автотестирование АБС. Конвейер разработки, конвейер данных, конвейер выполнения. Доклад был хороший по содержанию, но плохой по представлению. Он шел в обед, без альтернативы, и предмет — мне знакомый, так что я не ушел, а через некоторое время — форма перестала мешать восприятию содержания. Но это потребовало усилий.

А речь шла про очень большие системы и функциональные тесты в них. Которые сильно зависят от данных, и потому выстраиваются в цепочки, в каждой из которых 300-400 тестов. Про использование bankwords — предметно-ориентированные (банк) ключевых слов. Про отслеживание зависимостей цепочек для распаралеливания выполнения — чтобы уложить регресс в 6 часов вместо 12 (или больше, могу ошибаться). Про схемы обмена данными, на которых как раз основана зависимость тестов. Но все это, увы, без конкретики — как именно они поддерживают схемы обмена данными, как ведутся цепочки и так далее. На общем уровне.

Владимир Примаков. Мастер Тест План / Тестовая Стратегия К сожалению, доклад оказался методологической инструкцией в буллетах. Без кейсов, обучение истине от скучного лектора. Жаль.

Татьяна Зинченко, Inter Technology Group. MindMap — в мире интеллектуального тестирования. К сожалению, доклад не удался — потому что не получилось поставить тулу, которая рисует mindmap вживую, потребовалось обновить Java, что затянулось на неопределенное время. А доклад был про mindmap как средство работы для тесткейсов. Лично я — это слышал и, по-моему, именно от Татьяны. С другой стороны, на каждой конференции — много новых людей и они-то не слышали 🙂 Зато я быстро нашел сервис http://drichard.org/mindmaps чтобы рисовать через web. Сохраняет в Json, на сайте написано, что может в googledocs но не работает.

Оригинал статьи http://softwarepeople.ru/blog/2012/12/01/sqadays-12-01/