Pavlov Andrey

Биография:
После годов труда в качестве разработчика, открыл для себя мир тестирования, где, пройдя путь инженера, занимает позицию Test Team Lead.
"Печень" Санкт-Петербургского сообщества тестировщиков.
Разрушитель хрупких надежд разработчиков на то, что они пишут высококачественный код.
Доклады
Не бойтесь смещать ваше тестирование
"Shift left" - один из последних трендов тестирования ПО.
Agile и DevOps, рекомендуют тестерам смещаться влево в знакомой всем нам цепочке "analysis > design > development > TESTING > release", но что это значит? Является ли это единственно верным подходом?
Смещение тестирования влево или вправо может удовлетворить различные потребности и улучшить различные аспекты. Но как понять, нужно ли вносить изменения?
При управлении тестированием, смещение фазы теста влево или вправо может быть похоже на переключение передач автомобиля и может помочь вам оказаться в той конечной точке, куда вам нужно.
Экономика тестирования. Версия 2.0
Продолжение доклада Александра Александрова "Экономика тестирования. Версия 1.0", где мы расширим поле для обсуждения и обсудим вопросы экономики тестирования с аудиторией.
Основные тезисы доклада:
- Исчерпывающее тестирование невозможно.
- Тестирование — это в том числе и экономическая деятельность.
- Версия 1.0, или Что надо сделать. Работаем в рамках плана и оценки, при нехватке ресурсов просим их добавить (экстенсивный подход).
- Версия 2.0, или Как надо сделать. Работаем в рамках плана и оценки максимально эффективно (интенсивный подход).
Круглый стол будет посвящен обсуждению, как перейти к версии 2.0, анализируя следующие задачи и используем обоснованные трудозатраты эффективно, анализируя:
- Какие нужны тест-кейсы (и нужны ли).
- Какие нужны тестовые данные
- Какие нужны тестировщики - мало сильных (но дорогих) или много слабых (зато недорогих)
- Какая нужна автоматизация (и нужна ли вообще), какой инструмент, покрытие
- И др.
Этика тестирования
Обычно, когда кто-то говорит об "Этике тестирования", рассматривают самые банальные случаи.
Избегаем ли мы репортить о багах?
Сообщаем ли о том, что тестирование идет по плану, даже если очевидно, что мы сильно опаздываем?
Соври или скажи правду.
Ответы на эти вопросы крайне просто предугадать, поскольку ситуации рассматриваются в черно-белом цвете. Конечно, мы репортим баги. Конечно, мы не врем о нашем прогрессе.
Но жизнь подкидывает нам более сложные ситуации, где ответы не так очевидны...
"Эффект Бункера" в разработке и тестировании
"Silo Effect", буквально, "эффект силоса" или "синдром силосной башни", сложно литературно перевести на русский язык.
В своем кругу мы называем это "Эффекта Бункера", смысл которого заключается в том, что, зачастую, в крупных системах по разным причинам возникают информационные барьеры между различными подсистемами, как архитектурными (тестирование разных функциональных блоков), так и структурными (разработка и тестирование). Эти, разделенные барьером подсистемы, будто "в бункере", "в танке" от остальных. Причем, это имеет последствия для обеих сторон, так как у каждого нет доступа к информации по другую сторону барьера.
В своем докладе я хочу рассказать о существовании этого эффекта для тех, кто о нем раньше не слышал и показать, что мы можем предпринять, чтобы сделать взаимодействие проще тем, кто о существовании этого эффекта знает не понаслышке.
ТЕСТ-менеджер или тест-МЕНЕДЖЕР - решаем входящие задачи
Во время круглого стола в Москве на предыдущей конференции мнения разделились. Кем же должен быть тест-менеджер в первую очередь, какие навыки первичны: тест- или менеджерские? На Круглом Столе в Санкт-Петербурге мы в том же составе участников и модератора дискуссии, хотим обсудить подход к решению задач, которые ежедневно приходят команде тестирования и которые решает тест-менеджер.
На этом круглом столе, как и на предыдущем, предлагается обсудить озвученную проблему и всколыхнуть аудиторию, получить ответы / соображения / высказывания / мнения по ситуациям/проблемам, которые мы предлагаем для обсуждения.
Круглый стол: ТЕСТ-менеджер или тест-МЕНЕДЖЕР?
Во время доклада "Что было, что есть, что будет: Current State vs. Common Sense" в Минске было достаточно много реплик на тему «То, о чем Вы говорите, должны делать тест-менеджеры», а затем общение на эту тему долго продолжалось в кулуарах.
Оказалось, что тест-менеджмент все понимают по-разному.
На этом круглом столе предлагается обсудить озвученную проблему и всколыхнуть аудиторию, получить ответы / соображения / высказывания / мнения по темам, которые мы предлагаем для обсуждения.
- Что должен делать (и что не должен делать) тест-менеджер в проекте?
- Можно ли обойтись без тест-менеджера (и тест-менеджмента)?
- Как быть, когда в проекте всем управляет менеджер проекта, а тестировщики с ним не всегда согласны?
- Должен ли тест-менеджер отдаляться от тестирования и если должен, то насколько?
- Насколько тест-менеджер должен быть барьером для прямого общения тестировщиков со вешним миром?
Использование комбинаторного тестирования для мобильных приложений
О комбинаторном тестировании сказано много.
Я в любой момент могу перечислить доклады на эту тему, прозвучавших на конференции за последние несколько лет.
Но какую специфику может принести в этот подход необходимость применить его на поле мобильных приложений?
Обычная проблема тестирования мобильных систем - количество девайсов и конфигурации программного обеспечения, которые должны быть проверены. Например, так называемый challenge всего мобильного тестирования, количество Android девайсов, мог бы вынудить команду тестирования проверять сотни устройств и конфигураций программного обеспечения, приведя к тысячам или даже десяткам тысяч тестов.
Я расскажу, как комбинаторные методы могут быть применены в тестировании, а, главное, расскажу о специфике использования комбинаторного тестирования для обеспечения качества мобильных приложений.
Очередность требований: от хаоса к FIFO
Многие организации, работающие как по классическим методологиям разработки, так и использующие Agile подходы, рискуют попасть в различные ловушки работы с требованиями. Особенно это опасно там, где гораздо трудней — если не невозможно — планировать процесс создания спецификации или всего конечного продукта из-за повышенной изменчивости фокуса требований, который заказчик может менять ежедневно.
Я хочу рассказать свой опыт отказа от потока, формируемого заказчиком на основе каких-то своих приоритетов и перехода к жесткой FIFO очереди (First in – First Out).
Покажу, как мы до этого дошли, как внедряли, с какой болью столкнулись и какой профит получили в итоге.
Тестирование мобильных API: Behind The Scenes
“Для этого есть специальное приложение”. Эту фразу можно услышать сегодня очень часто. Она относится к любому сайту, социальной сети, даже у ларька с шавермой есть свое мобильное приложение.
Данные для этих приложений предоставляют сторонние веб и API (Application Programming Interface) сервисы - коммуникационные фреймворки между системами бэкенда и приложениями.
Тестирование веб-сервисов и API – это несколько больше, чем просто проверка функций приложения. API и службы, которые его вызывают, должны удовлетворять таким требованиям как время отклика, безопасность, устойчивость, производительность и масштабируемость.
В докладе я предлагаю рассмотреть вопрос функционального и не очень тестирования мобильных API, узнать, чем оно отличается от просто тестирования API и вместе с аудиторией создать пошаговый сценарий тестирования.
EARS: The Easy Approach to Requirements Syntax
Ключ к эффективному определению функциональных требований - минимизация неверных толкований и неоднозначности. Используя непротиворечивый синтаксис в ваших требованиях, вы сможете улучшить удобочитаемость, будете уверены, что все в команде точно понимают, какой продукт необходимо разработать.
В своем докладе я расскажу о том, как улучшить описание требований, используя Easy Approach to Requirements Syntax (EARS).
EARS - это простой и мощный метод получения функциональных требований.
Высокоуровневые требования к системе обычно формулируются на естественном языке. Свободные формулировки на естественном языке могут вызывать различные проблемы интерпретации текста и, как следствие, влиять на качество требований.
Я предлагаю простое руководство, которое поможет писать более качественные требования, расскажу, как мы внедряли EARS и какую выгоду из этого получили.
Правдивая история о тестировании SQL Server Change Data Capture
В последнее время технология Change Data Capture набирает популярность: о ней пишут на Хабрахабре, рассказывают на профессиональных конференциях для разработчиков.
А раз об этом думают разработчики, скоро и нам, тестировщикам, придет время тестировать корректность работы CDC на наших проектах.
В своем докладе я расскажу о том, что такое Change Data Capture, на что следует обращать внимание при ее тестировании и поделюсь информацией о тех граблях, на которые наступил и как решал возникающие проблемы при работе с CDC.
Немного об отношениях аналитика и тестировщика
Аналитик и тестировщик. Казалось бы, коллеги, чьи задачи плотно переплетены, но, с другой стороны, зачастую их взаимоотношения - место настоящих баталий, несущих проблемы как для команды, так и для проекта. В своем докладе я представлю взгляд из-за обеих баррикад и покажу, как легко добиться того, чтобы никаких баррикад не было вовсе.