Pavlov Andrey
Sr. Project Manager - Deutsche Telekom IT RUS
Санкт-Петербург, Россия

После годов труда в качестве разработчика, открыл для себя мир тестирования, где, пройдя путь инженера, занимает позицию Test Team Lead. "Печень" Санкт-Петербургского сообщества тестировщиков.

Разрушитель хрупких надежд разработчиков на то, что они пишут высококачественный код.

Доклады (13)
  • 26.11.2019
    Не бойтесь смещать ваше тестирование

    "Shift left" - один из последних трендов тестирования ПО.

    Agile и DevOps, рекомендуют тестерам смещаться влево в знакомой всем нам цепочке "analysis > design > development > TESTING > release", но что это значит? Является ли это единственно верным подходом?

    Смещение тестирования влево или вправо может удовлетворить различные потребности и улучшить различные аспекты. Но как понять, нужно ли вносить изменения?

    При управлении тестированием, смещение фазы теста влево или вправо может быть похоже на переключение передач автомобиля и может помочь вам оказаться в той конечной точке, куда вам нужно.

    • Среднe
    • 20 мин
    • SQA Days / 27
  • 24.02.2019
    Экономика тестирования. Версия 2.0

    Продолжение доклада Александра Александрова "Экономика тестирования. Версия 1.0", где мы расширим поле для обсуждения и обсудим вопросы экономики тестирования с аудиторией. 


    Основные тезисы доклада:

    • Исчерпывающее тестирование невозможно.
    • Тестирование — это в том числе и экономическая деятельность.
    • Версия 1.0, или Что надо сделать. Работаем в рамках плана и оценки, при нехватке ресурсов просим их добавить (экстенсивный подход).
    • Версия 2.0, или Как надо сделать. Работаем в рамках плана и оценки максимально эффективно (интенсивный подход).

    Круглый стол будет посвящен обсуждению, как перейти к версии 2.0, анализируя следующие задачи и используем обоснованные трудозатраты эффективно, анализируя:

    • Какие нужны тест-кейсы (и нужны ли).
    • Какие нужны тестовые данные
    • Какие нужны тестировщики - мало сильных (но дорогих) или много слабых (зато недорогих)
    • Какая нужна автоматизация (и нужна ли вообще), какой инструмент, покрытие
    • И др.

    • Сложнo
    • SQA Days / 25
  • 02.04.2018
    Этика тестирования

    Обычно, когда кто-то говорит об "Этике тестирования", рассматривают самые банальные случаи.


    Избегаем ли мы репортить о багах?


    Сообщаем ли о том, что тестирование идет по плану, даже если очевидно, что мы сильно опаздываем?


    Соври или скажи правду.


    Ответы на эти вопросы крайне просто предугадать, поскольку ситуации рассматриваются в черно-белом цвете. Конечно, мы репортим баги. Конечно, мы не врем о нашем прогрессе.


    Но жизнь подкидывает нам более сложные ситуации, где ответы не так очевидны...

    • Просто
    • 20 мин
    • SQA Days EU / 1
  • 23.11.2017
    "Эффект Бункера" в разработке и тестировании

    "Silo Effect", буквально, "эффект силоса" или "синдром силосной башни", сложно литературно перевести на русский язык.


    В своем кругу мы называем это "Эффекта Бункера", смысл которого заключается в том, что, зачастую, в крупных системах по разным причинам возникают информационные барьеры между различными подсистемами, как архитектурными (тестирование разных функциональных блоков), так и структурными (разработка и тестирование). Эти, разделенные барьером подсистемы, будто бункере", танке" от остальных. Причем, это имеет последствия для обеих сторон, так как у каждого нет доступа к информации по другую сторону барьера.


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

    • Среднe
    • 20 мин
    • SQA Days / 23
  • 17.09.2017
    ТЕСТ-менеджер или тест-МЕНЕДЖЕР - решаем входящие задачи

    Во время круглого стола в Москве на предыдущей конференции мнения разделились. Кем же должен быть тест-менеджер в первую очередь, какие навыки первичны: тест- или менеджерские? На Круглом Столе в Санкт-Петербурге мы в том же составе участников и модератора дискуссии, хотим обсудить подход к решению задач, которые ежедневно приходят команде тестирования и которые решает тест-менеджер.


    На этом круглом столе, как и на предыдущем, предлагается обсудить озвученную проблему и всколыхнуть аудиторию, получить ответы / соображения / высказывания / мнения по ситуациям/проблемам, которые мы предлагаем для обсуждения.

    • Среднe
    • SQA Days / 22
  • 10.01.2017
    Круглый стол: ТЕСТ-менеджер или тест-МЕНЕДЖЕР?

    Во время доклада "Что было, что есть, что будет: Current State vs. Common Sense" в Минске было достаточно много реплик на тему «То, о чем Вы говорите, должны делать тест-менеджеры», а затем общение на эту тему долго продолжалось в кулуарах.

     

    Оказалось, что тест-менеджмент все понимают по-разному.

    На этом круглом столе предлагается обсудить озвученную проблему и всколыхнуть аудиторию, получить ответы / соображения / высказывания / мнения по темам, которые мы предлагаем для обсуждения.


    - Можно ли научить тест-менеджменту (а заодно и тестированию)?
    - Что должен делать (и что не должен делать) тест-менеджер в проекте?
    - Можно ли обойтись без тест-менеджера (и тест-менеджмента)?
    - Как быть, когда в проекте всем управляет менеджер проекта, а тестировщики с ним не всегда согласны?
    - Должен ли тест-менеджер отдаляться от тестирования и если должен, то насколько?
     - Насколько тест-менеджер должен быть барьером для прямого общения тестировщиков со вешним миром?

    • Среднe
    • SQA Days / 21
  • 09.01.2017
    Использование комбинаторного тестирования для мобильных приложений

    О комбинаторном тестировании сказано много.

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

    Но какую специфику может принести в этот подход необходимость применить его на поле мобильных приложений?


    Обычная проблема тестирования мобильных систем - количество девайсов и конфигурации программного обеспечения, которые должны быть проверены. Например, так называемый challenge всего мобильного тестирования, количество Android девайсов, мог бы вынудить команду тестирования проверять сотни устройств и конфигураций программного обеспечения, приведя к тысячам или даже десяткам тысяч тестов.


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

    • Среднe
    • 20 мин
    • SQA Days / 21
  • 10.11.2016
    Очередность требований: от хаоса к FIFO

    Многие организации, работающие как по классическим методологиям разработки, так и использующие Agile подходы, рискуют попасть в различные ловушки работы с требованиями. Особенно это опасно там, где гораздо трудней — если не невозможно — планировать процесс создания спецификации или всего конечного продукта из-за повышенной изменчивости фокуса требований, который заказчик может менять ежедневно.

    Я хочу рассказать свой опыт отказа от потока, формируемого заказчиком на основе каких-то своих приоритетов и перехода к жесткой FIFO очереди (First in – First Out).

    Покажу, как мы до этого дошли, как внедряли, с какой болью столкнулись и какой профит получили в итоге.

    • Среднe
    • 20 мин
    • Analyst Days / 6
  • 18.12.2015
    Тестирование мобильных API: Behind The Scenes

    “Для этого есть специальное приложение”. Эту фразу можно услышать сегодня очень часто. Она относится к любому сайту, социальной сети, даже у ларька с шавермой есть свое мобильное приложение.

    Данные для этих приложений предоставляют сторонние веб и API (Application Programming Interface) сервисы - коммуникационные фреймворки между системами бэкенда и приложениями.

    Тестирование веб-сервисов и API – это несколько больше, чем просто проверка функций приложения. API и службы, которые его вызывают, должны удовлетворять таким требованиям как время отклика, безопасность, устойчивость, производительность и масштабируемость.

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

    • Просто
    • 20 мин
    • SQA Days / 19
  • 01.12.2015
    EARS: The Easy Approach to Requirements Syntax

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

    В своем докладе я расскажу о том, как улучшить описание требований, используя Easy Approach to Requirements Syntax (EARS). EARS - это простой и мощный метод получения функциональных требований.

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

    Я предлагаю простое руководство, которое поможет писать более качественные требования, расскажу, как мы внедряли EARS и какую выгоду из этого получили.

    • Просто
    • 20 мин
    • Analyst Days / 5
  • 19.01.2015
    Правдивая история о тестировании SQL Server Change Data Capture

    В последнее время технология Change Data Capture набирает популярность: о ней пишут на Хабрахабре, рассказывают на профессиональных конференциях для разработчиков.

    А раз об этом думают разработчики, скоро и нам, тестировщикам, придет время тестировать корректность работы CDC на наших проектах.

    В своем докладе я расскажу о том, что такое Change Data Capture, на что следует обращать внимание при ее тестировании и поделюсь информацией о тех граблях, на которые наступил и как решал возникающие проблемы при работе с CDC.

    • Среднe
    • 20 мин
    • SQA Days / 17
  • 20.12.2014
    Немного об отношениях аналитика и тестировщика

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

    • Просто
    • 20 мин
    • Analyst Days / 4
  • 20.01.2014
    Pomodoro Technique: кухонный тайм-менеджмент

    *Pomodoro Technique* – очень простая техника, освоить ее можно за полчаса, а приносить пользу она начнет с первой минуты. Двадцать пять минут работы и пять - отдыха. Преимуществ у такой техники – масса. Преимущество первое – короткие интервалы работы позволяют меньше уставать, а перерывы дают возможность посмотреть на работу свежим взглядом. Преимущество второе – полноценная картина прошедшего дня: число помидорок и их распределение между задачами показывает вашу продуктивность, подсказывает пути улучшения.

    • Просто
    • 20 мин
    • SQA Days / 15
Напишите нам, мы онлайн!