Павлов Андрей

Последнее десятилетие очень много внимания в компаниях и проектах уделяется Тестированию. Это здорово, но зачастую мне кажется, что, повторяя как мантру одни и те же утверждения о том, как внедрение на проекте тех или иных практик тестирования, мы перестаем задумываться, какое влияние это имеет на реальное Качество нашего продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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