⚡️Что учить, если хочется тестировать лучше?

Тут мог бы быть длинный список тулзов, но не будет у меня на такие списки аллергия.
Вместо этого принесу нечто другое - идеи, с которыми столкнулась на курсе Rapid Software Testing Explored (автор и тренер: James Bach) и в книге Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord).

Итак, над чем можно поработать?

Собственно, над процессами думания.

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

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

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

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

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

А еще авторы обращают внимание на основные категории мышления, которые помогают нам тестировать хорошо.

1️⃣ Техническое
2️⃣ Практическое
3️⃣ Критическое
4️⃣ Творческое

У меня нехорошее сильное впечатление (с), что при обучении тестировщиков есть явный упор на первые два пункта, менее явный - на критическое мышление, а творческая составляющая как будто остается совсем невидимой. При этом качество тестирования напрямую зависит именно от нее. Это не что-то nice to have! Если мы не можем вообразить проблемы, которые потенциально могут возникнуть, не можем представить себе риски, которые могут сработать - мы не можем покрыть эти риски тестами.

Что еще подчеркивают авторы?

Тестирование - это гораздо больше про работу с неявным (implicit) знанием, чем про работу с явным (explicit).

Примечание: мне кажется, одна из самых больших иллюзий начинающих тестировщиков - то, что кто-то (например, Очень Умный Аналитик) напишет требования, а тестировщики возьмут эти требования и будут по ним тестировать.

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

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

Принесу еще пару ссылок, которыми со мной поделилась Оля Артемьева:

➡️ Круговорот неявного и явного знания в природе. Нельзя так просто взять и зафиксировать знания (превратив неявное в явное). Генерация неявного знания - постоянный процесс, и если хочется это знание фиксировать, придется систематически прилагать усилия по экстериоризации новых неявных знаний.

➡️ Получение неявного знания через общение с пользователями и наблюдение.

⚡️ Как принять решение, что протестировано достаточно и можно завершить тестирование?

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

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

Важно: это не "to do list", это список направлений для подумать, который я структурировала в соответствии со своим чувством прекрасного.

🔣Майнд мапа тут🔣

Пара мыслей, которые высказывали участницы вебинара и которые прямо хочется зафиксировать:

1️⃣ Принятие решений такого рода - это не просто про тестирование, это еще и про личностный рост: развитие умения опираться на себя и прокачка смелости принимать решения.

2️⃣ Принять решение в отсутствие внешних дедлайнов может быть сложнее, чем когда есть давление в плане сроков. Как будто парадокс... Но на самом деле нет. Когда есть жесткие внешние ограничения, они задают некие рамки, на которые можно опереться. Если же эти рамки не заданы извне - нам нужно принимать решения самим:) Это может быть максимально непросто.

⚡️ Мама, я в телевизоре!

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

В этом году (буквально на прошлой неделе) я поставила важную галочку в голове - выступила на труъ оффлайн конференции. Это была айтишная конференция Istacon (проходит ежегодно в Софии).
Я подавалась на нее весной, презентацию в том виде, как она есть, не взяли, но предложили подготовить так называемый lightning talk - выступление на 5 минут.

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

Утрамбовала.

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

Итак, ссылка на те самые пять минут славы: "Think Twice Before Becoming a Team Lead".
Ну и чтобы два раза не вставать - ссылка на весь плейлист с публичными выступлениями.

⚡️ Техники тестирования - не "техники тестирования".

Какое-то время назад (год или два) мимо меня пробежал пост на LinkedIn авторства, кажется, Джеймса Баха. Автор писал: техники тестирования - никакие не “техники” и не “тестирования”.

Я прочитала, пожала плечами и пошла дальше (идею, тем не менее, запомнила).

…Угадайте, до кого сегодня дошло, что хотел сказать автор.

Причем дошло в процессе объяснений другим людям. Видимо, потому, что я обычно не думаю о техниках тестирования. Я смотрю на контекст и придумаваю, что как тестировать, опираясь на этот контекст. То есть в моей голове это работает как “нужно сделать вот так, потому что… чтобы…”, а не “вот тут я применю state transition”.

Так вот. Я посмотрела на свои объяснения и увидела, что я сама же объясняю техники НЕ как способ что-то протестировать, а как что-то другое.

Например, decision table: способ декомпозировать требование на сценарии.

Или state transition: способ визуализировать логику системы с фокусом на какой-то объект, его состояния и переходы между этими состояниями.

То есть это организация знаний в структуру, чтобы на основе этой структуры уже можно было нагенерить идеи, касающиеся тестирования.
Это не “техники тестирования”, это способы посмотреть на систему и/или требование под разными углами, чтобы придумать, как тестировать систему (или делать что угодно другое, ради чего мы эти знания собирали).
Это точно такие же “техники тестирования”, как иерархические списки или таблички, где мы организуем информацию любым удобным для нас способом.

Полезно ли это?
Точно да.
Стоит ли называть это “техниками тестирования”?

Не уверена.

С каким-то приближением можно назвать техниками тестирования boundary value analysis / equivalence partitioning и pairwise testing, но...

BVA / EP это частный случай risk-based тестирования. То есть у нас существует 100500 разных рисков, и некоторые из можно покрыть с помощью BVA / EP, причем тут важно помнить, что эти техники основываются на предположениях. В процессе применения техник их еще надо основательно почелленджить.
Возникает, конечно, вопрос: почему один из вариантов risk-based тестирования так важен, что удостоился названия отдельной “техники тестирования”? Подозреваю, что только потому, что основную идею можно объяснить новичкам на пальцах:)

Pairwise имеет в своей основе идею, которая уже подвергалась критике (вот тут разъяснения на русском с указанием источников).
Даже если у вас есть система со 100500 параметрами (или условиями) - не факт, что имеет смысл суетиться с такого рода тестированием. Возможно, стоит потратить это время на что-то другое, что потенциально принесет ту же пользу (или даже бОльшую).

Не пора ли нам вместо "техник тестирования" придумать уже наконец что-то другое?

Exploratory testing тут является хорошей альтернативой (не знаю пока альтернативы лучше, если честно), но, кажется, под exploratory testing в широких массах часто понимают что-то совсем простое а ля "побродить по приложению без явной цели", а про разработку гипотез и постановку экспериментов для их проверки как-то забывают.

Возможно, нужно говорить про это чаще (и больше).

⚡️Что учить, когда ты опытная QA?

…Да что хочешь!:)

Что хочу лично я:

Тестирование

К сожалению, знаю не очень много курсов по "тестированию вообще". Куда хочу сходить сама:

1️⃣ Курсы “имени Кэма Кейнера” (BBST), основанные Кэмом Кейнером и продолжающие работать до сих пор.

2️⃣ Курсы Баха и Болтона по Rapid Software Testing. Я прошла Rapid Software Testing Explored, хочу продолжить.

3️⃣ Курс “Школа тест-аналитика” от Натальи Руколь. Крайне маловероятно, что узнаю на нем что-то новое, но курс недолгий, стоит недорого, проще пройти, чем не пройти. К тому же считаю, что никогда не помешает перетряхнуть базовые знания в голове - это порой приводит к новому витку профессиональной рефлексии.

Смежные навыки

4️⃣ Критическое мышление. Уже несколько месяцев с интересом смотрю на курс по критическому мышлению, но останавливал бюджет времени и сил. Недавно поняла, что устала бороться с собой:) и записалась на ближайший поток. Выведу свою способность душнить на новый уровень

5️⃣ Основы математики. Не так давно пыталась решить одну задачу через пределы, обнаружила, что уже не могу просто достать это умение из головы, и несколько приуныла. Думаю, что повторение материалов за 9-11 класс как минимум не помешает.

Думаю, этого плана хватит на несколько лет, а дальше посмотрим:)

⚡️Курс по тест-анализу (2024) - итоги

Примерно год назад я решила сделать курс по тестированию - и сделала:) Я уже упоминала про него ранее - например, тут и тут. В этом канале не было никаких анонсов (и не планировалось), так как я хотела проводить курс только в рамках сообщества QA Sisters. Подготовить курс мне помогла Оля Артемьева - она ревьюила контент, давала обратную связь на черновых прогонах и после занятий, и всячески меня челленджила в хорошем смысле этого слова.

Сегодня захотелось подвести некоторые итоги.

Немного статистики:

- Количество участниц: 100 (3 потока, 5 групп по 10-25 человек).
- Потрачено времени: примерно 250 часов (это мое время, олины затраты тут не учтены)
- Подготовлено 6 презентаций (по числу занятий), включающих около 200 слайдов, не считая слайдов с кейсами для практических занятий (бессмысленная метрика, но я люблю цифры, так что пусть будет:)

Вывод: мне понравилось, планирую продолжать:)

Лирическое отступление: требовательность к себе у меня работает следующим образом: по достижении некой планки ожиданий эта планочка автоматически поднимается еще выше. Так что естественным образом курс в его текущем виде уже не полностью удовлетворяет моему чувству прекрасного:)

Пока что есть следующие мысли на этот счет:

1️⃣ Изначальный курс оставлю как вводный курс в тест-анализ (контент оставлю как есть, немного поменяю структуру и формулировки). Следующая группа будет внешняя (не только для участниц QA Sisters) и, скорее всего, не раньше лета (если только не наберется группа очень проактивных людей, которым курс нужен прямо очень остро и прямо сейчас - в этом случае можно обсудить условия индивидуально). Перед набором группы напишу пост с информацией по этому поводу.

2️⃣ Напишу новый, более глубокий курс - включу туда больше работы с эвристиками, материалы по когнитивным ошибкам в тестировании, переосмысление “техник тестирования ака тест-дизайна”, возможно, более сложные примеры и т. п. По самой оптимистичной оценке (…в которую мне пока слабо верится, если честно:) запущу его в районе осени 2025 года. Более реалистичный вариант - 2026 год. Предполагаю, что на подготовку уйдет около 200 часов, а сам курс займет часов 30.

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

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

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

На что-то - могу и, возможно, повлияю.

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

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

⚡️ Операция “П”, или Immigrant Song начинается с “ААААААААА”

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

Процесс небыстрый и нервный. Сейчас занимаюсь оформлением справок об отсутствии судимости (их нужно две - от Болгарии и от РФ) и уже успела пару раз немного поседеть.

А еще после всех вложенных сил и нервов переезд в итоге может не состояться. Слишком много факторов, которые влияют на успешность мероприятия.

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

Шутка.

Никакого тайм-менеджмента (кстати, я его и в других ситуациях не использую). Только "энерджи-менеджмент".

Снижение дополнительных активностей.

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

На мероприятия тоже ходить не буду. Может быть, выступлю на QA митапе в апреле - и все.

Корректировка рабочих целей.

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

Дополнительный отдых.

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

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

Фокус на комфорте.

Где есть возможность доплатить за бОльший комфорт - буду доплачивать за комфорт. Чем более комфортным, а точнее, менее дискомфортным будет переезд, тем быстрее я вернусь в полностью функциональное состояние и смогу работать на прежнем уровне перформанса (ну, плюс-минус:).

...Посты про тестирование буду писать как обычно - по вдохновению:)

⚡️ “Тестирование программного обеспечения. Контекстно-ориентированный подход” Кем Кейнер, Джеймс Бах, Брет Петтикорд (отзыв о книге)

Немного писала о переводе тут. К сожалению, все оказалось сильно хуже, чем я думала. Перевод мало того, что неаккуратный. Мало того, что используется специфическая терминология (например, "журналирование" вместо "логирование"). Он местами попросту искажает смысл авторского текста.

Более-менее нормально переведена примерно половина уроков (половина из тех, что я успела прочитать и сравнить с оригинальным текстом).

Резюме: не рекомендую

В комменты положу файлик с примерами из первой главы книги.

П. С. Готова отдать свой экземпляр за сыр. Правда, есть нюанс - самовывоз из Софии.

П. П. С. Ну и по классике - "she" в тексте перевели как "он"

⚡️Доступность в тестовой документации (1)

Последнее время много думаю про доступность (в смысле accessibility) в рабочей среде. Мне кажется, это гораздо более важная тема, чем доступность, например, e-commerce. Сдается мне, что доступность e-commerce будет меня мало волновать, если в какой-то момент я просто не смогу выполнять работу.

Поговорила на эту тему с коллегами по цеху, со специалистом по Accessibility, с ChatGPT и теперь хочется опубликовать некое саммари.

Почему это важно и нужно?

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

Если плохая доступность не блокирует кого-то в работе и/или не заставляет работать катастрофически неэффективно - это еще не значит, что этот кто-то от нее не страдает!

Мы все бываем в состоянии стресса (позитивный стресс тоже считается!), физического нездоровья, физической/эмоциональной/ментальной истощенности и в этих состояниях тоже надо как-то работать работу. “Просто взять больничный”, увы, работает в случае только явных болезней и в случае, если мы можем себе его финансово позволить (больничные не всегда оплачиваются и не всегда оплачиваются 100%).

Мы можем работать в компании, где язык документации - английский, что сразу увеличивает mental load.

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

Если я хочу (а я хочу!) чтобы в будущем я в принципе могла работать - это значит, что начинать адвокатировать доступность надо прямо сейчас. Прекрасное будущее не наступит само, нужен какой-то общий консенсус, что доступность - это нужно и полезно. Нужна культура доступности в QA сообществе.

На что можем влиять?

Рабочая среда - это очень много всего. Это помещения, это рабочие инструменты… У нас часто почти нет прямого влияния на все это.

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

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

Основной фокус

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

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

Итак, вот те идеи, которые я собрала на данный момент:

Стуктура текста

- Текст читается сверху вниз, слева направо. По возможности никаких «а теперь вернитесь к п. 2». Звучит как очевидная вещь, но нет. Не так давно я столкнулась с инструкцией из N пунктов, которая начиналась примерно так: сначала выполните п. 2 - 5, потом п. 1, потом 6-10.

- Линейная (не табличная) структура. Да, я знаю, что многие специалистки пишут тесты в табличках. Сами по себе таблички не являются чем-то недоступным по умолчанию. Другое дело таблички в контексте TMS. Это таблички, которые окружены огромным количеством элементов интерфейса (визуальным шумом). “Линейная” структура (текст с заголовками) в TMS более доступна. А еще этот текст можно написать в другом редакторе и потом скопипастить в условную джиру.

- Нет длинных непрерывных блоков текста.

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

#подпольный_евангелизм
Очень подходящий тег взяла поносить у Оли Артемьевой:)

⚡️ Доступность в тестовой документации (2)

Формулировки

- В качестве проверочного вопроса можно использовать этот: “Как звучит текст теста?” Да, не все люди имеют ограничения по зрению, но я думаю, что проговаривание текста вслух может помочь увидеть проблемы в формулировках и в общей структуре.

- Все слова несут смысловую нагрузку. Исключаем слова вроде “успешно”, “правильно” и т. п., они не несут никакой полезности.

- Текст максимально простой. Настолько простой, насколько это можно. Из синонимов выбираем самый простой и короткий. Предложения тоже максимально короткие и несложные. Ориентируемся на уровень языка - A1-A2.

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

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

Простой пример:

<Название окна> - <Название параметра> - Ввести значение разными способами
<Название окна> - <Название параметра> - Ввести валидное значение
<Название окна> - <Название параметра> - Ввести невалидное значение
<Название окна> - <Название параметра> - Сохранить
<Название окна> - <Название параметра> - Значение по умолчанию
И т. д.

Форматирование

- Минимум форматирования. Я сама использую только два формата (помимо просто текста): выделение заголовков и выделение фрагментов “кода” (SQL запросы, логи и т.п.).

- Заголовки разделов выделены через форматирование заголовков, а не жирным шрифтом. Если заголовки имеют иерархию - это отражено в форматировании (заголовок 1, заголовок 2 и т. п.)

- Форматирование часто затрудняет читаемость, а не улучшает его. Например, моноширинные шрифты, курсив, декоративные шрифты (менее актуально для нас, но все же), CAPS LOCK, подчеркивание.

- Списки сделаны через форматирование (нумерованный / ненумерованный список), а не проставлением дефисов или тире.

- Для всех картинок прописан альтернативный текст.

- Текст линков содержательный (не просто “вот линк”).

Другое

- Как документ воспринимается, когда масштаб увеличен до 200%?

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

Если вдруг у вас будут еще идеи - набрасывайте! Запишу их в свой списочек.

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