В рамках доклада мы обсудим регулярно встречающиеся концептуальные вопросы Unit тестирования:

• насколько большими должны быть “шаги” \ тесты, в том числе при работе в стиле TDD;
• что подлежит и наоборот не подлежит Unit тестированию;
• как определить качество и необходимое количество тестов;
• можно ли удалять Unit тесты, и если да, при каких обстоятельствах;
• существуют ли метрики простоты повторного использования;
• влияет ли масштаб ПО, язык программирования и IDE на практики Unit тестирования;
• как внедрить Unit тестирование и, шире, практику TDD в середине работы над проектом;
• и многие другие ...

Приходите — будет интересно!

Давайте поговорим о термине “Чистая архитектура” в контексте Автоматизации тестирования. Архитектура, дизайн, компоненты, политики и уровни, а также бизнес-правила, слои, модули и фреймворки, ортогональность и независимость, границы, полные, не полные и их анатомия, большие и малые службы, вариабельность и многое-многое другое. Мы систематизируем наши знания, сформулируем список полезной литературы и, конечно же, проговорим десяток актуальных примеров. Приходите - будет интересно и архитектура :)

Давайте вместе проведем сравнительный анализ инструментов, прямо или косвенно связанных с автоматизацией тестирования API в экосистеме Python. Затем попробуем несколько вариантов группировки инструментов для решения задач «кровавого энтерпрайза» из «зоопарка» Allure, Faker, Flask, TTPX, Models-Manager, PyTest, Pydantic, Radar, Request, SDV, Swagger и многих-многих других. Попробуем сравнить решения, сделать совместные выводы и сформулировать практические советы. 

Приходите – будет интересно.

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

Давайте поговорим в околонаучном ключе об интересующих большинство вопросах: 

• как справиться со стрессом при мыслях о релокации; 
• как найти в себе силы, чтобы решиться уехать, или остаться, или вернуться; 
• как избавиться от стереотипов, навязчивых мыслей, давления, моды, чтобы принять свое и только свое, а не навязанное решение;
• а также таблица стресса Холмса и Раге, пирамида потребностей Маслоу, реакции принятия, выгорание, психологическая самодиагностика и многое другое. 

Разобраться во всех этих вопросах и подготовить доклад мне помог врач – психиатр Алексей Казак. 

Приходите – будет интересно!

В рамках доклада я продемонстрирую наиболее популярные варианты архитектур решений автоматизации тестирования Backend в экосистеме Python, проведу сравнительный анализ, сформулирую чек-лист для проверки проекта на минимальную структурность и, конечно, озвучу, что делать дальше. 

Приходите – будет интересно!

В рамках доклада будут рассмотрены варианты эволюции учебного проекта по автоматизации тестирования UI. Приведены последовательно примеры в нескольких вариантах: самого простого, более сложного, приемлемого и эталонного решения на языке Java. Предложены задачи для самообучения и варианты учебных пособий. 

Приходите – будет интересно!

В рамках доклада мы продемонстрируем наиболее популярные варианты архитектур решений автоматизации тестирования UI в экосистеме Python, проведем сравнительный анализ, сформулируем checklist для проверки проекта на минимальную структурность и, конечно, озвучим что делать дальше. 

Приходите – будет интересно.

В рамках доклада мы тезисно проговорим основные layers, modules и design patterns для решений Автоматизации тестирования UI и Backend. Сформулируем checklist, который поможет при техническом старте нового и трансформации существующего решения. Предложим книги и статьи для дальнейшего изучения, а также несколько вариантов того, что каждый из нас может сделать здесь и сейчас для своего проекта. Приходите – будет интересно!

Давайте проговорим в примерах без привязки к конкретным инструментам концепции zero code, low code, no code и DSL. Перечисленные подходы появились в 60-е годы, но почему сейчас их популярность растет взрывообразно? В чем заключается особая роль Аналитика при реализации этих концепций? Что еще можно посмотреть для глубокого изучения? 

В рамках доклада мы постараемся дать ответы на эти и другие вопросы. 

Приходите – будет интересно!

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

Приходите – будет интересно!

Все мы уже привыкли к изменчивости IT мира, научились систематически заниматься самообразованием. Появляются новые библиотеки, фреймворки, кодогенераторы, языки программирования. Ежегодно выходят сотни книг и тысячи статей. А нам так хочется иметь некий «островок стабильности», набор неизменных принципов, в соответствии с которыми функционирует ПО. 

В рамках доклада я постараюсь сформулировать наиболее фундаментальные инженерные концепции, которые являются основой любой гибкой Архитектуры вне зависимости от языков, библиотек и фреймворков; привести наглядные примеры из области Автоматизации тестирования.

Один из вечных IT вопросов: «как организовать эффективное взаимодействие специалистов по ручному и автоматизированному тестированию» малой кровью. Давайте все вместе рассмотрим решение, основой которого являются гранулярная Traceability Matrix, Test Pyramid и простейший ROI Calculator, а так же, как эти артефакты интегрировать в TMS на примере Zephyr-а.

Давайте все вместе разработаем Checklist и некую линейку «зрелости» для интеграции Автоматизации тестирования в существующие Agile процессы обеспечения качества. Даже опытному специалисту порой трудно интегрировать новую роль и активность в существующие на проекте процессы.

Легко забыть один из важных шагов, не сформулировать артефакт, не ввести необходимый минимум базовых метрик, не задать критерии успеха и неудачи, забыть о приоритетах и коммуникации как с ручными тестировщиками, так и разработчиками, потерять прозрачность прогресса и не сделать множества других необходимостей. Checklist поможет нам избежать большинства из вышеперечисленных ошибок. Приходите – будет интересно!

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

В докладе я попытаюсь дать определение и минимальный полный набор информации об MVP автоматизации тестирования. 

Материал будет полезен как QA Manager, QA Lead, IT Sales Tech Support так и специалистам по автоматизации тестирования в качестве аргументированного списка приоритизированных задач на первые месяцы работы над проектом.

Давайте рассмотрим основные концептуальные и «технические» вопросы QA менеджмента: как сформировать QA команду, мотивировать и развивать сотрудников, делегировать задачи и эффективно контролировать их выполнение, развивать ответственность, налаживать коммуникации. 

Итогом нашей беседы станет условный checklist, разделенный на 2 категории:

• список вопросов, требующих ответов опытных QA менеджеров; 
• список книг \ статей \ рекоммендаций, которые стоит изучить молодым специалистам, прежде чем браться за решение подобных задач.

Our topic covers the most common free tools / frameworks that can be used and integrated into existing framework to automate web services tests.

Agenda:

1. TCP/IP + OSI Model
2.  SOA / Micro Services
3. Client-Service Interaction
4. REST / Web Socket / Micro Services Testing
5. Libraries and code samples
6. Tools analyses

Behavior Driven Development в автоматизации тестирования до сих пор порождает горячие дискуссии, так, кулуарный диалог об этом подходе после конференции SQA Days-21 продолжался более часа, а границы применимости и не применимости, вопросы целесообразности и эффективности так и остались открытыми. Мы попытались расставить точки над и, посвятив BDD 2 доклада на конференции COMAQA Autumn 2017 Piter, но, судя по бурной полемике, однозначные интерпретации и исчерпывающие аргументы так и не были представлены. Давайте попытаемся исправить это досадное недоразумение рассмотрев BDD как треугольник с вершинами Risk Management, QA Management и, само собой, техническая составляющая.

Можно быть замечательным специалистом и, тем не менее, не уметь себя «продавать», регулярно не проходить интервью на новый интересный проект в рамках своей компании или вообще «пролетать» мимо работы своей мечты. Обидно, досадно ... неладно! В докладе мы проговорим ответы на типовые вопросы по Архитектуре Автоматизации Тестирования, презентация станет одновременно и памяткой для подготовки к интервью и серией рекомендаций – планом профессионального развития «что прочитать, посмотреть и сделать», что бы закрыть свои возможные gap-ы

Давайте подойдем к вопросу архитектуры автоматизации «от обратного» и сфокусируем наше профессиональное внимание на том «как не надо делать», на ошибках и провалах, вопреки корпоративной установке “positive way of thinking”. Дополним наши изыскания систематизацией, метафорами и «иллюстрациями» из Дантевской интерпретации 9 кругов Ада. Приходите, будет занимательно: система антипаттернов с многочисленными примерами (check-list архитектурных недочетов) обернутая в литературщину и «мистицизм»

Мы поговорим об эволюции Selenium WebDriver и объективных причинах, трансформировавших одно из решений в Web стандарт; обсудим развитие инструментов мобильной автоматизации, озвучим последние новости Appium-а; задумаемся о следующей фазе решений Desktop-ной автоматизации; вспомним Kotlin; упомянем дополненную и виртуальную реальность в контексте тестирования; проговорим богатство IoT и AI платформ, принципиальные сложности обеспечения качества сегодня и завтра; посмотрим на Robotic Process Automation свежим взглядом; приведем примеры реальных проектов, реализуемых здесь и сейчас; а так же, сведем все эти разности воедино, сформулировав систему координат и эволюционный IT вектор, используя «Закон иерархических компенсаций» Седова и диалектику Гегеля. Понимание будущего отрасли – уникальное конкурентное преимущество. Приходите – будет интересно.

Как совместить, казалось бы, не совместимое: Пирамиду Тестирования Майка Коэна и ROI калькулятор? Как добиться синергетического эффекта от использования обоих инструментов. Как эффективно использовать «парочку» от pre-sales до post-release активностей? Как адаптировать полученное решение для нужд вашего конкретного проекта. Давайте попробуем ответить на эти и многие другие вопросы в процессе нашей беседы. Приходите – будет интересно.

Цели Беседы:

После дискуссии слушатели узнают как:

• Сознательно, аргументированно, эффективно использовать Пирамиду Тестирования Майка Коэна

• Комбинировать Пирамиду Тестирования и ROI Калькулятор

• Адаптировать пару инструментов для нужд Вашего конкретного проекта

План Беседы:

• Пирамида Тестирования Майка Коэна

• ROI Калькулятор

• Варианты эффективного "парного" использования от Pre-Sales до Post-Release

• Адаптация "пары" инструментов

• Примеры

Метрики в тестировании, автоматизированном в том числе, – одна из ключевых тем докладов почти каждой IT конференции, элегантный механизм обратной связи, способ выстраивания коммуникаций с заказчиком и многое-многое другое ... Классификация, определения, критерии применимости, так называемые «пожарные извещатели» - метрики в тестировании далеко не тривиальная область. Трудно переоценить важность метрик в нашей ежедневной работе. Тем важней получить не абстрактную, вне контекстную академическую информацию, но актуальную для СНГ, наших компаний, наших проектов, нашего контекста! Материал построен на практическом опыте автора, теоретической базе, а так же опросах, проводимых сообществом www.COMAQA.by , совместно с www.software-testing.ru и панельных дискуссиях, приведённых в Минске, Новосибирске, Пензе и Саратове. Приходите – будет интересно!

Представим себе ситуацию\проблему - мою :) личную, продуманную, прочувствованную, решенную …  IT компания разделена на около автономные отделы, некоторые отделы состоят из условно независимых под отделов. Нетривиальная топология :) В рамках каждого отдела лучше или хуже, в явном или не явном виде, внедрена та или иная мотивационная модель … единой мотивационной модели в компании нет … Кроссфункциональная проектная команда, Agile, Scrum, Kanban или их комбинация … Для наглядности (и вящего драматизма) возьмем следующий проект: PM, Department Manager Web Front End разработки, Java backend разработки, Manual QA, QA Automation, DevOps. Как организовать эффективную работу команды? Как разрешить потенциальный конфликт интересов менеджеров? Как сдружить отличные мотивационные модели, не вводя общего знаменателя? Как вообще можно идти в ногу в такой ситуации ..? Зачем пытаться найти разрешение ситуации, вместо того, что бы попытаться ввести общую мотивационную модель ..? 

Давайте все вместе попытаемся составить далеко не исчерпывающую и даже не полную, но приемлемую, для всех нас приемлемую, классификацию \ топологию типов тестирования, начиная «широкими мазками» «статическое» и «динамическое» и заканчивая сложно терминологическими названиями конкретных типов. Скажу честно, по-настоящему хорошей классификации из коробки я так и не нашел … даже в рамках всемирно признанных сертификаций, таких как ISTQB  … Таким образом, проделанная нами предварительная работа ценна сама по себе … важная как для начинающих специалистов, так и для Pre-Sales Technical QA консультантов … Основа профессиональной сетки координат любого специалиста по тестированию … Но мы пойдем дальше: через призму совместно сформулированной QA топологии мы посмотрим на методологии разработки ПО, предметно, а не абстрактно, изучим общности и отличия Agile и Waterfall методологий в контексте QA. Уверен, доклад будет полезен не только QA специалистам и PM-ам, но и .... интрига-интрига :)

«ООП - инструмент борьбы с доменной сложностью. Инкапсуляция - сокрытие, прежде всего, изменчивости и лишь затем сложности. Естественное противоречие между попыткой скрыть изменчивость, увеличивая сложность и сокрытием сложности в «чистом виде». Наследование и полиморфизм – как частные случаи инкапсуляции. Характеристики сложных систем – как набор метафор для облегчения ежедневной работы BA специалиста» ... Никогда не слышали подобной интерпритации ООП? Подобный подход позволяет ПОНЯТЬ ООП на концептуальном уровне всего-лишь за 3 часа лекций + несколько практических занятий, специфических для Вашей компании ... Что такое классы, объекты ... а может быть стоит копнуть глубже -  рефакторинг; идиоматические, design и architectural patterns; Best Practices проектирования. Мы же попробуем решить еще более широкую задачу, ответив на вопрос «Как в вашей собственной компании, своими силами, организовать подобный тренинг?»