2012-11-30: SQAdays-12, день первый

Ссылки сюда (2) →

О других конференциях

Конференция 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 но не работает.

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

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 02:20, 1 декабря 2012 • нет комментариев