SQAdays-12, день второй

Второй день SQAdays-12 в Минске — достойное продолжение первого. Темы докладов — развивались и продолжались. Включая тему архитектуры конструкции для автоматических тестов. Интересно, что на предыдущих двух конференциях эта тема не звучала, а на этой — сразу серия докладов, и представляемые конструкции — похожи. По-видимому, развитие автоматических тестов созрело для формулирования типовой архитектуры.

Кроме докладов был круглый стол о будущем профессии тестировщика. В формате выступление эксперта — выступление из зала. В общем, в том, что у профессии — большое будущее, и человека машина тут не заменит — никто не сомневался. Хотя тема замены человека роботами, которую ждали фантасты и которая не случилась — звучала активно. А еще обсуждали развитие разработки в сторону интерактивных приложений, работающих с голосом и жестами — которые тоже надо тестировать. И тема образования, обучения тестировщиков, в том чисое — в контексте работы с ВУЗами. Хочется отметить, что параллельно с обсуждением в зале шло активное обсуждение в твиттере на те же темы. Потому что в зале — микрофон у одного человека. А кинуть реплики — хочется. Компьютеры и планшеты — у многих, и некоторые эксперты тоже успевали следить и, кажется, вклиниваться в твиттер. В целом получается достаточно интересная конструкция, потому что твиттер как раз снимает ограничения на число одновременных реплик. Плюс возможность ответа, которую твиттер отслеживает — позволяет вести параллельные нитки обсуждений, что тоже интересно и полезно.

Правда, требует упаковывать свои мысли в 140 символов и для меня лично — это часто сложно. Даже отдельная мысль укладываетя не всегда, надо 200-250 символов, чтобы отметить нюансы и акценты. Но вообще для меня это — интересный опыт. На SPMconf я поймал мысль, что реплики по поводу выступления хочется бросить в твиттер. Или процитировать (но это-то как раз многие делают). Но — не успеваешь, вернее, это отвлекает внимание от восприятия доклада, а это — жалко. Особенно, когда мысль не влезает на десяток символов — их-то точно можно ужать. Но, думаю, это — тренируемый и полезный навык, так что буду практиковаться. Во всяком случае. на круглом столе у меня получалось 🙂

А еще — хочется отметить организаторов. Геометрия места проведения была не слишком удачная, только один большой зал. Но на второй день (после второго слота) организаторы поставили у зала Б не только монитор с камеры (он был сразу), но и монитор с презентацией, и доклад можно было слушать из коридора, получилось расширение зала. Еще не помешала бы такая же конструкция (монитор с презентацией) в залах С и D, но я понимаю, что ресурсы не безграничны.

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

Игорь Любин, News360. Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестирования!

Великолепный доклад о проактивной позиция тестировщика.

Дальше — фактически содержимое слайдов. Я его переписал, потому что хочу иметь под рукой, а не лазить в презентацию.

1. Тестирование начинается с прихода в компанию. Вопросы на интервью.
   • Определить цели
   • Задать как можно вопросов о проекте
   • Узнать какие проблемы надо решить.
2. Горячие точки. Поговорить с ключевыми участниками, составить список горячих точек
3. Фишки. Пообщаться с командой, собирать идеи.
4. SMART-анализ целей (горячие точки, фишки). Выписать цели, выбрать цели на месяц.
5. Добиться прозрачности. TOP-5 задач на неделю. Таблица Задача, исполнитель, срок, комментарий.
6. День золотого духа. Влиться в проект. Стать junior-тестировщиком на 1 день.
7. feedback. Взять обработку отзывов от пользователей в свои руки.
8. Разделение обязанностей. Мотивация: выявить склонности тестировщиков и предложить им задачи по специализации.
9. Функциональные карты. Сделать тест-анализ по модели Объект-Действие-Параметр-Значение. Выявить основной функционал. Оценить покрытие.
10. Особенности платформы. Усилить покрытие.
11. Чит-листы (не чек-листы). Готовые проверки, их масса в сети — и не надо придумывать самим.
12. sitechko.ru. Там много готовых листов. Руководитель Наталья Руколь.
13. Понятие критического бага. Составить критерии, согласовать.
14. Критерии выпуска версии. Процесс тестирования на выпуске. Когда надо выпускать. Набор чеклистов.
15. Build Verification Tests. Составить, прогонять регулярно.
16. Волны тестирования. Соорганизоваться, продумать итерации тестирования.
17. Стратегия тестирования. Сделать документ на 1 (одну) страницу. Поддерживать его.
18. Шаблон баг-репорта. Сделать. Научить всех пользоваться.
19. Анти «Протестируйте». Организовать процесс передачи версии в тестирование. Антипаттерн: разработчик собирает билд, пишет «протестируйте» — тестировщик день нечто делал, пишет «протестировано» — получается «выпущено» и огребаешь баги. Нужны новости версии и понимание, что трогали.
20. Ежедневные статус-репорты. Ежедневно. А еженедельно — сообщать об успехах.
21. Post morten. После выпуска версии — провести анализ, выявить сильные и слабые стороны.
22. Минтуки встреч. Вести протоколы-минутки, рассылать участникам и другим заинтересованным.
23. Полчаса на автоматизацию. Выделять каждый день. Пусть одному человеку из команды. За это время — пишется один тест. И за мессяц — их уже 20.
24. Все в teamcity (или аналог). Включить запуск автотестов на регулярной основе. А не хранить их где-то локально.
25. Инженерные практики. Быть QA. Поговорить с разработчиками о качестве, об используемых практиках.
26. Roadmap тестирования. Выписать даты выпуска версий, нарисовать карту.
27. Трындеть. Никогда не кушать в одиночку. Ежедневно общаться с разными коллегами.
28. Сплотить команду. Поддерживать ритуалы в команде.
29. Начинаем рабочий день. Никогда с утра не открывайте почту! Первый час — для другого. Для разумного планирования и общения.

Михаил Субоч, ЭПАМ Системз. Построение Keyword-driven фреймворков. Это был доклад об архитектуре тестового фреймворка, воплощенного во фреймворке TAF Core. Фреймворк был создан в EPAM и выложен в open source под LGPL. Но рассказ был именно об общих принципах.

Основной принцип архитектуры — Keyword-Driven. Строгое отделение логики от реализации. Достижимо как на своих фреймворках, так и на готовых — Fitness, Cucumber. Только надо соотвествующим образом использовать, сохраняя указанное разделение. Оно дополняется отделением данных для теста от его логики. В результате получается архитектура с 5 слоями.

1. Данные
2. Логика
3. Шаги
4. Утилиты
5. объекты (ui-локаторы, таблицы БД, web-сервисы)

В презентации есть конкретная схема: Ядро, инструменты, агент для распараллеливания и запуска. И так далее.

И в конце — были общие рекомендации.

• Быстрая смерть — программирование в Excel вместо шага проверки. Нарушение разделения.
• Незапускаемые тесты бесполезны.
• Ломаем утром, строим ночью. Утром — техническая реализация, вторая половина — дизайн. И лучше эти активности не смешивать — разное мышление
• Составление сложных шагов из базовых. CreateProduct и другие подпрограммы. Чтобы вспомогательные шаги, обвязку — убирать из теста. Например, просто Login всюду, кроме автотеста формы логина. И это должно быть доступно тестировщику, а девелопер — пусть ревьюит.
• Важна независимость от технологии. TAF Core — был до Selenium. Но может с ним интегрироваться, равно как с телериком. Низкий порог входа.

Максим Гриневич, Colvir Software Solutions. Промышленный подход к автоматизации тестирования или Keyword-driven testing в жизни. Рассказ был о внутреннем устройстве тестовых сценариев для тестирования большой банковской системы. Как я понял, это касается той же самой системы, о которой накануне говорил Алексей Надененко, впрочем, я могу ошибаться.

Тесты устроены так.

• Разработчики — предоставляют стандартные операции, действия и проверки, которые представляют шаги тестирования, реализуемые как банковские keyword
• На их основе тестировщики реализуют сценарии тестирования.
• Необходимо видеть, что именно делает автотест. По шагам. Для Заказчика и руководства. При этом то, что написано должно соответствовать. И это — важное требование у них. Хотя часто автотесты воспринимают как черный ящик.
• Тестовые сценарии — в xml. Версионность и прочее.
• Для работы используют ALTOVA. Отображение и редактирование в формах. При этом — несколько видов просмотра, из которых можно редактировать ограниченную информацию.
• Верхние узлы — дают пошаговую инструкцию тестирования, и руководители ее смотрят через xml/web
• При прогоне — лежат конкретные значения. Но подставляются они — отдельно.
• По xml — генерируется исполняемый сценарий. Его не правят, при изменении — меняют исходный xml
• Тестовый план или цепочка сценариев тестирования. На вход ему готовят данные. Первый из них — готовит данные — выводит документы в нужное состояние и прочее. Пускается параллельно. Распараллеливание надо учитывать сразу, тогда оно не составляет проблем.
• Ошибки теста бывают трех видов: Данных, Автотеста и Приложения. И с этим надо разбираться.
• Начальный въезд в xml — два дня, и уже может писать, пусть ошибаясь.
• Программисты планируют устроить перегенерацию на лету, или интерпретацию — чтобы исключить хранение сгенеренных автотестов.
• Будут расширять набор стандартных операций. Пока половина автотестов через операцию «другое», но они над этим работают.
• Хочется связать автотесты с функциональностью, чтобы понимать что прогонять. Сложно, потому как структура приложения непроста.
• Текущее приложение — desktop, будет версия под web.
• Вопрос про версии. Ответ: все очень сложно, у них около 30 клиентов, каждому из которых дано право вносить в код.

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

Ирина Тузикова, Grid Dynamics. Простой взгляд на автоматизацию или Как не изобретать велосипед. Доклад о комплекте инструментов Web-тестировщика и особенностях установки и настройки их. Казалось бы, в чем проблема? Но тут — как с администрированием: у одних админов все настроено и тикает, а другие — непрерывно лечат. Так вот, были моменты, которые надо настроить сразу, чтобы не лечить потом. Может быть и очевидные, но наверняка на эти грабли наступает куча народа. В докладе упомянуты были Java, Maven, IDEA, Selenium, Thuсydides, Броузер и Web-драйвер к броузеру.

Из забавного. У Selenium есть один недостаток — он не умеет предсказывать будущее 🙂 И поэтому он часто не совместим с версиями, которые вышли позднее. Так что броузеры должны быть нужных версий (надо смотреть на дату выхода, никаких таблиц совместимости нет) и обновления надо отключить.

И остальные доклады.

Дмитрий Маевский, Одесский политехнический университет. Прогнозирование процесса выявления дефектов при тестировании программного обеспечения. Рассказ о построении математической модели процесса тестирования, которая позволила бы получить предсказания относительно сходимости процесса, его сроков и количества ожидаемых багов. В основе модели — теория переноса. К сожалению, у авторов не получилось построить модель на реальных данных: все фирмы, к которым они обращались — им отказали. И они использовали открытые данные других исследователей. Хорошая манера изложения, отчасти академическая, но с шутками и живо.

Кстати, у Дорофеева на SPMconf была аналогичная модель, касавшаяся прогнозирования сроков завершения обработки. Тоже с обратным потоком дел от программистов в бэклог как одним из факторов. Но — посложнее (и изложена более живо).

Сергей Талалаев, Exigen Services. Oracle-based тестирование. Теория и практика. Это вовсе не про БД-Oracle. Это оракул, предсказания. Основанные на мнениях экспертов — людей, мнения которых близки к истине.

Вообще в основе доклада — реальный проект тестирования для системы, которая работает в области страхования с кредитными договорами. И, в числе прочего, она должна давать оценку, основываясь на большом количестве параметров договоров. И чтобы ее протестировать на достаточном количестве вариантов, был написан калькулятор в Excel, воспроизводящий логику, а дальше в процессе тестирования ответ системы сравнивали с тем, что дает Excel.

Так вот, Excel в данном проекте — и есть ото самый оракул.

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

Виталий Шульга, EPAM Systems. Особенности автоматизации с помощью скриншотов на платформе .NET. Дальнейшее развитие темы автоматизации тестирования приложения, запускаемого под Citrix, для которого недоступна внутренняя структура объектов и потому надо опознавать элементы по их изображению. На прошлой SQA days рассказывали об успешном использовании Sikuli для этих целей. Но дальше они захотели интегрировать эти тесты с другими своими тестами, которые для WPF-приложений. Sikuli — это Java, стыковки с .Net не получалось. Они пару недель помучились, а потом за день написали мини-движок, который умеет опознавать картинки и дергать примитивный WinAPI для мыши и клавиатуры — и дальше можно писать тесты, основанные на скриншотах, однородно с другими на платформе .Net. Там пришлось помучиться с эффективной реализацией алгоритма опознания изображения — сначала сравниваются 5 точек, раскиданных по картинке, и только когда совпали — идем дальше. А первая версия с простым сравнением — была очень долгой.

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