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

Какое-то время назад (год или два) мимо меня пробежал пост на 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 в широких массах часто понимают что-то совсем простое а ля "побродить по приложению без явной цели", а про разработку гипотез и постановку экспериментов для их проверки как-то забывают.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут мог бы быть длинный список тулзов, но не будет ~~у меня на такие списки аллергия~~.
Вместо этого принесу нечто другое - идеи, с которыми столкнулась на курсе 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 специалиста работа в действительно похожа на что-то в этом роде.
Но, скорее всего, чем дальше - тем больше будет работы с неявными знаниями и меньше - с явными. Неопределенности будет больше, чем определенности, эвристик - больше, чем инструкций, и ползунок все больше и больше будет смещаться в сторону творческого мышления.

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

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

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

Помимо промокода, у меня есть две проходки на конференцию. Если хотите получить проходку - напишите, пожалуйста, мне в личку и расскажите, что вас мотивирует пойти на конференцию.
Отдам проходку той (или тому), чья мотивация мне больше понравится.

УПД: приму решение вечером в среду.

УПД 2: решила отдать проходки @justjuju и @snezhana_qa)

(По мотивам обсуждения презентации коллеги)

Darling, you got to let me know
Should I test or should I no?
If you say the ticket's mine
I'll be testing till the end of time
So you got to let me know
Should I test, or should I no?

UPD:

Should I test, or should I no?
Should I test, or should I no?
If I no, there will be trouble
And if I test, it will be double
So come on and let me know

Проблема 4: Затраты на автоматизацию

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

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

Проблема 5: Очень сложно сфокусированно протестировать именно логирование.

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

Логирование каждого компонента переписывается ручками разных людей и тестируется отдельно. Каждая область логирования может сломаться более-менее независимо от другой.Проверки логов размазаны ровным слоем по примерно всем тестам. Гонять все тесты как есть - очень дорого. Придется проводить много функциональных проверок, причем с точки зрения проверки именно логирования значительная часть этих проверок будет дублировать друг друга. Будет сложно искать пробелы - что мы НЕ проверили в логах и какие функциональные тесты покрывают именно эти пробелы. То есть по сути надо будет полностью продумать тестовое покрытие для логирования, сделать черновик этого покрытия, потом как-то сматчить функциональные тесты на этот черновик… Решать эту задачу "в лоб" довольно долго и мучительно.

Что с этими проблемами делать, как решать?

Да просто давайте уберем логи из тестов! С вас пять тыщ (с)

Шутка. Над решением я еще думаю, но кое-какие идеи есть, я ими обязательно поделюсь в следующем посте.

? Проверки логирования в тестах (формулировка проблемы)

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

В чем проблема, собственно? Мне навскидку пришло в голову несколько.

Проблема 1: Консистентность бага тесту. Точнее, ее отсутствие.

Например, баг observability фейлит функциональный тест. Функционально некритичный баг фейлит функционально критичный кейс.

А что бы мне хотелось? Чтобы баги фейлили соответствующие тесты, чтобы была консистентность между багом и тестом. Критичный функциональный баг фейлит критичный функциональный тест. Мелкий баг про смещенную кнопку фейлит некритичный тест про отображение кнопки.

Из проблемы консистентности вытекает проблема прозрачности.

Проблема 2: Прозрачность документации.

Если функционально все ок, а в логах проблема (например, что-то не залогировано или есть эксепшен) - получается, я должна пометить этот кейс как failed.

То есть документация говорит: у нас не работает важный функциональный сценарий!
Чтобы увидеть, что проблема именно с логами, а не функциональностью, нужно уже посмотреть на баг репорт.

А что бы мне хотелось: чтобы документация максимально прозрачно показывала, какие есть проблемы и какова их критичность. Если в тест ране пофейлен тест про создание сделок - значит, у нас проблема именно с созданием сделок (а не с логированием, цветом кнопок, расположением окна создания сделки и т п). Если у нас проблема с логированием/цветом кнопок и т п - то тест на создание сделки Passed, тест на логирование/цвет кнопок и т п Failed.

Проблема 3: Затраты на прогон тестов.

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

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

А что бы мне хотелось: чтобы мы не только тестировали то, что нужно протестировать, но и НЕ тестировали то, что НЕ нужно протестировать. Чтобы мы не только уточняли и расширяли тестовое покрытие там, где нужно, но и сокращали его там, где оно не нужно, и не делали работу, которую можно не делать.

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

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

В эти 106 часов входит подготовка презентаций к 6 вебинарам (перекладывание идеи из головы на “бумагу”, черновые прогоны, обработка фидбэка от Оли), взаимодействие с дизайнеркой и юристкой, административная работа, проведение самих вебинары, подготовка и рассылка сертификатов.

На второй поток (апгрейд презентаций, административная работа, взаимодействие с дизайнеркой, проведение вебинаров (на данный момент - 2 из 6) ) я пока потратила 36 часов. Ожидаю, что в сумме уйдет примерно 50.

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

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

Коротко о разном: всякое бывает (с)

- Приехала в Порту в командировку и отпуск
- Сходила на Geek Girls Portugal (правда, не с докладом, а просто постоять на стойке компании:) Никогда не пробовала этот вид деятельности, было в каком-то смысле интересно
- Выступила с презентацией "Think Twice Before Becoming a Team Lead" на митапе. Видео будет когда-нибудь (скорее всего, в ближайшие дни)
- На следующей неделе уйду в отпуск, планирую максимально гулять, лежать и не думать про трудовые подвиги