Как я готовилась к выступлению на оффлайн-конференции в другом городе

Вложила много сил в подготовку к выступлению на SQA Days, гораздо больше, чем ожидала.

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

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

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

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

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

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

Очень помогла встреча с тренеркой по ораторскому мастерству Альфией Замалутдиновой (спасибо организаторам SQA Days за возможность). Благодаря занятиям и материалам у Ани я знала, как разогреть голос и речевой аппарат. Поэтому с Альфией мы скорее обсуждали психологические вещи и общую стратегию на это выступление.

Для меня важным оказалось мочь встретиться с живой аудиторией и быть в контакте с ней.

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

Так и вышло, контакт с людьми очень поддерживал. Особенно помогло видеть знакомых тестировщиц и их живой отклик)

А еще то, что это я веду доклад. И если я что-то забыла, то никто не знает, что у меня было в планах — прости идти дальше к цели. Маршрутов больше, чем один.

Мне очень помогло заранее учесть свои особенности и продумать важные детали.

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

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

Я заранее запланировала расписание на эту поездку, где было много отдыха и восстановления и создавала себе максимально поддерживающую среду. Тут нельзя просто положиться на «разберусь на месте», а надо действительно продумывать.

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

И все это сработало! Я довольна тем и как прошла поездка, и как я выступила)

#подпольный_евангелизм

LLM в тестировании за пределами тест-кейсов

Первое, что люди пытаются сделать с AI, это избавиться от «рутинной работы». В тестировании этим почему-то все время оказывается тестовая документация вместе с тест-дизайном. Такая мечта, что вот загрузишь документацию, а на выходе получишь годные тест-кейсы. Наташа на последней подлодке делала доклад, где показывала сколько грабель и труда лежит за всем этим.

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

Создание тестовых данных

LLM помогает собирать идеи для тест-дизайна, что еще можно проверить и что еще может быть в мире. Из последнего рабочего — какие бывают типы улиц в России - не только площади и переулки, но и тупики и территории. Понятно, что это надо перепроверять, особенно примеры. Но это хорошая точка для старта.

Помощь в подходах к тестированию

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

Или наоборот у вас есть мысли и вы хотите критики и разбора, тут тоже поможет LLM.

Опять же тут надо помнить о безопасности и не загружать в общедоступные системы разнообразные тайны и подробности)

Улучшение документации

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

Или помочь со структурой и примерами, чтобы было больше шансов, что все это прочитают.

Структуризация

Иногда LLM помогает тем, что собирает из каши мыслей что-то осмысленное и структурное, что уже можно использовать дальше. Буквально можно выгрузить все из головы и подумать пусть даже и об машину)

Нигде не использую как замену, но как ассистента.

#AI

Онбординг как обучение

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

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

Коненчо, это нужно далеко не всегда в полном объеме, но хотя бы подумать об этих вещах стоит.

Пожалуй, лучшая стартовая книга для этого – «Обучение со смыслом: 13 правил для тех, кто учит взрослых. Елены Тихомировой».

#учить_и_учиться
#книги

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

Первый пост - в первое воскресенье Адвента - 30 ноября.

#адвент

Вынесу из комментов прекрасное.

@ansh120022 поделилась иллюстрацией про человеческое и автоматизированное, которые она делала для презентации про стратегию тестирования

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

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

Также отмечу элегантность того, как Анастасия передает разницу между testing и checking.

#AI
#база_тестирования

Pairwise и границы его применимости

Несколько лет назад готовила материалы для несостоявшегося курса по тест-дизайну от команды Podlodka и активно разбиралась в pairwaise. А в прошлом году написала про это текст в ZenTest. Поделюсь им и здесь тоже.

Основная идея

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

Набор тест-кейсов с комбинациями параметров можно ставить один из двух способов – либо вручную на основе ортогональных матриц или с помощью алгоритмов генерации всех пар (Allpairs, PICT и т.д). Нет исследований, что какой-то способ лучше другого, поэтому я рекомендую работать с инструментами автоматизации. Это сильно экономит время и силы.

Почему мы берем именно сочетание двух параметров?

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

Большинство это сколько?

Исследования Wallace и Kuhn ретроспективно показали, что попарное тестирование могло бы найти 98% из обнаруженных ошибок, Kuhn и Reilly – 76% из обнаруженных ошибок (Lee Copeland, A Practitioner's Guide to Software Test Design). B. Smith, M. S. Feather и N. Muscettola c другой стороны показывают, что такой метод нашел 88% процентов ошибок одних видов и только 50% ошибок других видов (источник)

Какие задачи решает?

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

Границы применимости

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

Я часто слышу, что этот метод сокращает количество тестов, сохраняя покрытие, но это не так. Если мы уменьшаем количество тестов – мы всегда сокращаем покрытие, вопрос в рисках.

Эффективность метода согласно статье James Bach и Patrick J. Schroeder может зависеть от разных факторов

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

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

3. Серьезность проблемы, которая может быть вызвана сочетанием переменных

4. Какие переменные вы выделили и решаете объединить

5. Какие значения переменных вы решили использовать

6. Комбинации значений, которые вы тестируете

7. Ваша способность обнаружить обнаружить проблему, если она возникнет

Что это значит практически?

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

2. Скорее всего потребуется предварительно использовать другие техники тест-дизайна, например классы эквивалентности и граничные значения, чтобы определить необходимые параметры и их значения.

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

4. Проверить, что критичные комбинации действительно есть в получившемся наборе тестов. И добавить их, если их там нет.

Общие выводы

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

#база_тестирования
#ZenTest

Практические рекомендации из моего опыта

1. Используйте инструмент, где можно построить модель с зависимостями и прямо указать ограничения

Иначе вы можете получить комбинации, которых не существует. Например для браузеров и операционных систем – MacOS и IE9. Первая идея – просто выбросить такие тесты, но тогда нарушается принцип попарного сочетания.

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

IF [Browser] IN {"IE9","IE11","Edge"} THEN [OS] IN {"Windows 11","Windows 10"};

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

Например мы можем объединить Opera, Edge и Chrome в один класс эквивалентности Chrome и явно прописать значения этого класса эквивалентности

Browser: IE9, IE11, Chrome|Opera|Edge, FF, Safari

В этом случае когда будет выпадать пара с этим значением, будет равномерно подставляться что-то из Chrome, Opera или Edge.

3. Иногда может быть важен порядок в котором перечисляются параметры. Можно попробовать разные варианты – от параметров с большим количеством значений к параметрам с меньшим количеством значений и наоборот. Для PICT второй подход — от параметров с меньшим количеством значений может дать выигрыш в количестве тестов. Но тут надо пробовать.

Что я использую

https://pairwise.yuuniworks.com/ – под капотом тот же PICT, но можно удобно работать в веб-интерфейсе. У оригинального PICT консольный интерфейс.

#база_тестирования
#ZenTest

Разработчики учат меня тестировать: devspaining in nutshell

Популяризаторка термина mensplaining Ребекка Солнит в эссе "Мужчины учат меня жить" рассказывает, как ее собеседник объяснял ей же её же книгу. А я вижу ту же тенденцию с тестированием и тестировщицами.

Если задуматься, это нелепо. Люди, которые не погружались глубоко в мою профессию и в лучшем случае слышали о ней на уровне 80-90-ых годов, рассказывают мне как я должна делать свою работу. Ради, которой меня собственно и наняли!

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

Самый абсурдный случай был, когда меня позвали выступать про тестирование на конференцию для разработчиков. И куртор-разработчик пытался доказать мне, что я неправильно понимаю тест-дизайн, потому что Макконнелл пишет иначе. Первое издание «Совершенного кода» вышло в 1993 году и про тестирование, а лучше сказать про checking, там одна глава. Конечно, куда мне с моими 15 годами опыта до Макконнелла.

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

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

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

#подпольный_евангелизм