2012-12-02: SQAdays-12, день второй
Второй день SQAdays-12 в Минске - достойное продолжение первого. Темы докладов - развивались и продолжались. Включая тему архитектуры конструкции для автоматических тестов. Интересно, что на предыдущих двух конференциях эта тема не звучала, а на этой - сразу серия докладов, и представляемые конструкции - похожи. По-видимому, развитие автоматических тестов созрело для формулирования типовой архитектуры.
Кроме докладов был круглый стол о будущем профессии тестировщика. В формате выступление эксперта - выступление из зала. В общем, в том, что у профессии - большое будущее, и человека машина тут не заменит - никто не сомневался. Хотя тема замены человека роботами, которую ждали фантасты и которая не случилась - звучала активно. А еще обсуждали развитие разработки в сторону интерактивных приложений, работающих с голосом и жестами - которые тоже надо тестировать. И тема образования, обучения тестировщиков, в том чисое - в контексте работы с ВУЗами. Хочется отметить, что параллельно с обсуждением в зале шло активное обсуждение в твиттере на те же темы. Потому что в зале - микрофон у одного человека. А кинуть реплики - хочется. Компьютеры и планшеты - у многих, и некоторые эксперты тоже успевали следить и, кажется, вклиниваться в твиттер. В целом получается достаточно интересная конструкция, потому что твиттер как раз снимает ограничения на число одновременных реплик. Плюс возможность ответа, которую твиттер отслеживает - позволяет вести параллельные нитки обсуждений, что тоже интересно и полезно.
Правда, требует упаковывать свои мысли в 140 символов и для меня лично - это часто сложно. Даже отдельная мысль укладываетя не всегда, надо 200-250 символов, чтобы отметить нюансы и акценты. Но вообще для меня это - интересный опыт. На SPMconf я поймал мысль, что реплики по поводу выступления хочется бросить в твиттер. Или процитировать (но это-то как раз многие делают). Но - не успеваешь, вернее, это отвлекает внимание от восприятия доклада, а это - жалко. Особенно, когда мысль не влезает на десяток символов - их-то точно можно ужать. Но, думаю, это - тренируемый и полезный навык, так что буду практиковаться. Во всяком случае. на круглом столе у меня получалось :)
А еще - хочется отметить организаторов. Геометрия места проведения была не слишком удачная, только один большой зал. Но на второй день (после второго слота) организаторы поставили у зала Б не только монитор с камеры (он был сразу), но и монитор с презентацией, и доклад можно было слушать из коридора, получилось расширение зала. Еще не помешала бы такая же конструкция (монитор с презентацией) в залах С и D, но я понимаю, что ресурсы не безграничны.
А теперь - обзор докладов второго дня, начиная с тех, которые больше понравились.
Игорь Любин, News360. Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестирования!
Великолепный доклад о проактивной позиция тестировщика.
Дальше - фактически содержимое слайдов. Я его переписал, потому что хочу иметь под рукой, а не лазить в презентацию.
- Тестирование начинается с прихода в компанию. Вопросы на интервью.
- Определить цели
- Задать как можно вопросов о проекте
- Узнать какие проблемы надо решить.
- Горячие точки. Поговорить с ключевыми участниками, составить список горячих точек
- Фишки. Пообщаться с командой, собирать идеи.
- SMART-анализ целей (горячие точки, фишки). Выписать цели, выбрать цели на месяц.
- Добиться прозрачности. TOP-5 задач на неделю. Таблица Задача, исполнитель, срок, комментарий.
- День золотого духа. Влиться в проект. Стать junior-тестировщиком на 1 день.
- feedback. Взять обработку отзывов от пользователей в свои руки.
- Разделение обязанностей. Мотивация: выявить склонности тестировщиков и предложить им задачи по специализации.
- Функциональные карты. Сделать тест-анализ по модели Объект-Действие-Параметр-Значение. Выявить основной функционал. Оценить покрытие.
- Особенности платформы. Усилить покрытие.
- Чит-листы (не чек-листы). Готовые проверки, их масса в сети - и не надо придумывать самим.
- sitechko.ru. Там много готовых листов. Руководитель Наталья Руколь.
- Понятие критического бага. Составить критерии, согласовать.
- Критерии выпуска версии. Процесс тестирования на выпуске. Когда надо выпускать. Набор чеклистов.
- Build Verification Tests. Составить, прогонять регулярно.
- Волны тестирования. Соорганизоваться, продумать итерации тестирования.
- Стратегия тестирования. Сделать документ на 1 (одну) страницу. Поддерживать его.
- Шаблон баг-репорта. Сделать. Научить всех пользоваться.
- Анти "Протестируйте". Организовать процесс передачи версии в тестирование. Антипаттерн: разработчик собирает билд, пишет "протестируйте" - тестировщик день нечто делал, пишет "протестировано" - получается "выпущено" и огребаешь баги. Нужны новости версии и понимание, что трогали.
- Ежедневные статус-репорты. Ежедневно. А еженедельно - сообщать об успехах.
- Post morten. После выпуска версии - провести анализ, выявить сильные и слабые стороны.
- Минтуки встреч. Вести протоколы-минутки, рассылать участникам и другим заинтересованным.
- Полчаса на автоматизацию. Выделять каждый день. Пусть одному человеку из команды. За это время - пишется один тест. И за мессяц - их уже 20.
- Все в teamcity (или аналог). Включить запуск автотестов на регулярной основе. А не хранить их где-то локально.
- Инженерные практики. Быть QA. Поговорить с разработчиками о качестве, об используемых практиках.
- Roadmap тестирования. Выписать даты выпуска версий, нарисовать карту.
- Трындеть. Никогда не кушать в одиночку. Ежедневно общаться с разными коллегами.
- Сплотить команду. Поддерживать ритуалы в команде.
- Начинаем рабочий день. Никогда с утра не открывайте почту! Первый час - для другого. Для разумного планирования и общения.
Михаил Субоч, ЭПАМ Системз. Построение Keyword-driven фреймворков. Это был доклад об архитектуре тестового фреймворка, воплощенного во фреймворке TAF Core. Фреймворк был создан в EPAM и выложен в open source под LGPL. Но рассказ был именно об общих принципах.
Основной принцип архитектуры - Keyword-Driven. Строгое отделение логики от реализации. Достижимо как на своих фреймворках, так и на готовых - Fitness, Cucumber. Только надо соотвествующим образом использовать, сохраняя указанное разделение. Оно дополняется отделением данных для теста от его логики. В результате получается архитектура с 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 точек, раскиданных по картинке, и только когда совпали - идем дальше. А первая версия с простым сравнением - была очень долгой.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.