2012-11-30: 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% таких проектов - провальные, и его это очень волнует. А вспоминая первые проекты - сейчас он видит, что они были мертворожденные. Этим и вызван доклад.
Типичные причины провалов.
- Запись тестов (recording). Еще 5 лет назад была книга, что это не работает. Но до сих пор продают и покупают именно это.
- Перестает работать на чуть более сложных проектах, чем демо
- Невозможно поддерживать по изменениям. Представьте, что recording продают бухгалтеру.
- Простой выход - не используйте
- Чуть более сложный: обеспечьте, чтобы работало для вашего приложения. Это доработка. И смиритесь, что когда поменялось - надо перезаписать тест, не пытаемся читать и модифицировать. И под это - заточите методику.
- UI-автоматизация теста - медленная.
- Потому что поднять с нуля через интерфейс - тяжело. По данным. Плюс - мы работаем через посредника.
- Решение: Нормально пишите код. Не используйте sleep для синхронизации
- Решение: Запускайте тесты параллельно. И сразу стройте архитектуру для этого. Включая разделение данных.
- Фокусируйтесь на других видов автоматизации тестирования. Комплексно. UI-тесты - верхушка, а под ними - уровень бизнес-логики, API, там больше тестов. Под ними - unit-тесты (здесь: по логическим фрагментам).
- А еще - UI-тестирование нестабильно. 2-3% fail-тестов просто потому что асинхронно.
- Тоже не тестируйте все через UI. Я: из зала - неправда. Да, потому что там тоже может быть асинхронность
- А еще - перезапускать после падения, и анализировать только повторные падения.
- Слишком дорого разрабатывать и поддерживать.
- Потому что выполняются медленно, а тестировщик - просто ждет
- Потому что неверно выбран инструмент. Разработка тестов - тоже разработка ПО. И надо применять технологию.
- Потому что недостаточно знаний у команды. Для хороших тестов - нужно сотрудничество разработчиков и тестировщиков, по-отдельности получается хреново.
- Простой механизм от разработчиков, чтобы тест понимал, что все отрисовано
- Чтобы найти кнопку попросите разработчиков добавить id, а не ищите полчаса как обойти.
- Используйте хороший фреймворк
- Отделите фреймворк от скриптов
- Автоматизация не используется. И, блин это проблема
- Мы не доверяем автоматическим результатам, лучше проверим руками. - Надо учить работать по-другому, работа с людьми. Интегрировать автотесты с ручными, в общей системе. 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. Диалектика созидания: курс на сотрудничество. Последний доклад дня, шоу с интерактивом. Четыре миниатюры взаимодействия тест-менеджера Наташи и тестировщика Андрея. Все идеи понятные, но сценки все равно классные, особенно вечером.
Миниатюра где "все не так" и разборка с мест - что именно не так. А потом - разбор ошибок. И рекомендации по исправлению.
- Собеседование
- Первый рабочий день
- Испытательный срок
- Рутина. В последней сценке менеджер окончательно демотивировал тестировщика, а потом - уволил.
Записывать не было смысла, так - отдельные фразы.
- Нет глупых вопросов, есть глупые люди, которые не задают вопросов.
- Нечеткое задание "познакомься с продуктом"...
- Если свободного времени нет сейчас, то его не будет и потом.
- Менеджер - не чайник, потому что его нельзя выключить.
- Соответствие слова и дела.
- Завел больше всех багов - к кулеру без очереди :)
А теперь - про остальные доклады, на которых я был.
Александр Андрущенко 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 но не работает.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.