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 годами опыта до Макконнелла.

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

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

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

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

1 Саббатикал: О терминах и определениях

Опыт саббатикала, про который я хочу рассказать, у меня четвертый. И он самый близкий к классическим саббатикалам.

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

Или вот пример из айти — Julia Evans рассказывает о своем трех месячном неоплачиваемом саббатикале, в который она работала над open-sourse проектом.

В России я тоже часто слышала про саббатикалы, как способ чего-то достичь, следовать за мечтой или реализовать давний проект. Вот например старый пост Вани Замесина про его опыт саббатикала и его рассуждения о том, что страх не найти работу сильно преувеличен. Это 2020 год, кандидатский рынок, но совет стать крутым прежде чем идти в саббатикал все равно напоминает «пусть едят пирожные».

Такой дискурс формирует давление, что саббатикал надо провести продуктивно и вернуться с результатами.

Но еще в 2019 году Леночка Трускова начала исследовать женский опыт саббатикала. И этот опыт тот, который был мои первые три раза. А в последние годы все стало еще сложнее.

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

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

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

Саббатикал, про который буду писать я, был не такой. Я ушла в него по сумме обстоятельств зимой 2022 года. Мне в целом нравилась моя работа, нравилось тестирование и я не чувствовала себя выгоревшей. У меня были планы! Я шутила, что хочу уйти на два года (казалось это почти бесконечность!) и посвятить это время адаптации в Нидерландах и нидерландскому языку. В конце концов я же опытная пользовательница саббатикалов.

Но все пошло не так, как я думала...

#адвент
#sabbatical