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

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

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

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

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

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

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

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

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

  1. Запись тестов (recording). Еще 5 лет назад была книга, что это не работает. Но до сих пор продают и покупают именно это.
  2. UI-автоматизация теста - медленная.
  3. А еще - UI-тестирование нестабильно. 2-3% fail-тестов просто потому что асинхронно.
  4. Слишком дорого разрабатывать и поддерживать.
  5. Автоматизация не используется. И, блин это проблема

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

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

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

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

По инструментам - они используют микс. Часть - требует заказчик. Используют медиавики. Где-то 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 но не работает.