Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля

⚡️Что учить, если хочется тестировать лучше?Тут мог бы быть длинный список тулзов, но не будет у меня на такие списки аллергия.Вместо этого принесу нечто другое - идеи, с которыми столкнулась на курсе 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 специалиста работа в действительно похожа на что-то в этом роде.Но, скорее всего, чем дальше - тем больше будет работы с неявными знаниями и меньше - с явными. Неопределенности будет больше, чем определенности, эвристик - больше, чем инструкций, и ползунок все больше и больше будет смещаться в сторону творческого мышления.Принесу еще пару ссылок, которыми со мной поделилась Оля Артемьева:➡️ Круговорот неявного и явного знания в природе. Нельзя так просто взять и зафиксировать знания (превратив неявное в явное). Генерация неявного знания - постоянный процесс, и если хочется это знание фиксировать, придется систематически прилагать усилия по экстериоризации новых неявных знаний.➡️ Получение неявного знания через общение с пользователями и наблюдение.

(По мотивам обсуждения презентации коллеги)Darling, you got to let me knowShould I test or should I no?If you say the ticket's mineI'll be testing till the end of timeSo you got to let me knowShould 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 troubleAnd if I test, it will be doubleSo come on and let me know

К вопросу о лишних словах.Я знаю одного человека, который знает одного человека......который запустил поиск по тестам в Jira по слову "успешно" и нашел примерно 2700 тестов.То есть в тестовой документации есть минимум 2700 слов, которые совершенно точно не приносят никакой пользы.Только засоряют пространство.

🌟 Итак, тесты по логированию (big picture)Что точно не хочу делать: - тестировать логирование, когда это не надо (например, тестировать его по умолчанию для каждого релиза, особенно в рамках смоук тестирования)- тестировать функциональность библиотеки логированияЧто хочу делать: - тестировать, что нужная нам информация залогирована- тестировать это недорого (не прогонять 100500 функциональных тестов, чтобы проверить логи)Какое решение вижу:- вынести проверки логирования в отдельные тест-кейсы- убирать или добавлять их в план в зависимости от рисков возникновения проблем с логированиемКакие тесты я бы прогоняла в разных контекстах:Контекст 1: Разработка новой фичи- функциональные тесты: да- тесты на логирование: даКонтекст 2: Фича уже в продакшен (активная работа над ней закончена)- функциональные тесты: да- тесты на логирование: нетКонтекст 3: Фича меняется (изменения функциональности, рефакторинг, что-то еще)- функциональные тесты: да - тесты на логирование: даКонтекст 4: Библиотека логирования существенно меняется (например, переходим на радикально другую версию библиотеки)- функциональные тесты: нет- тесты на логирование: даКонтекст 5: Переходим на другую библиотеку логирования (или интегрируемся с сервисом логирования, или что-то в этом роде)- функциональные тесты: нет- тесты на логирование: даПозже напишу про дизайн конкретных тестов.

Проблема 4: Затраты на автоматизациюЕсли принят процесс, по которому тестировщики пишут тесты для выполнения людьми, а команда автоматизаторов потом их автоматизирует - функциональный тест с кусками логов отправляется на автоматизацию и создает дополнительную работу, которая потенциально не приносит ценности. А что бы мне хотелось: опять же, не делать лишнюю работу: автоматизировать то, что действительно стоит автоматизировать, и не автоматизировать лишнего.Проблема 5: Очень сложно сфокусированно протестировать именно логирование.Например: решили улучшить логирование, для чего начали использовать Кибану. Чтобы логи можно было смотреть через Кибану, логи должны быть в одном формате. В настоящее время они в другом формате. То есть нужно переделать логирование так, чтобы оно производилось в другом формате. Логирование каждого компонента переписывается ручками разных людей и тестируется отдельно. Каждая область логирования может сломаться более-менее независимо от другой.Проверки логов размазаны ровным слоем по примерно всем тестам. Гонять все тесты как есть - очень дорого. Придется проводить много функциональных проверок, причем с точки зрения проверки именно логирования значительная часть этих проверок будет дублировать друг друга. Будет сложно искать пробелы - что мы НЕ проверили в логах и какие функциональные тесты покрывают именно эти пробелы. То есть по сути надо будет полностью продумать тестовое покрытие для логирования, сделать черновик этого покрытия, потом как-то сматчить функциональные тесты на этот черновик… Решать эту задачу "в лоб" довольно долго и мучительно. Что с этими проблемами делать, как решать?Да просто давайте уберем логи из тестов! С вас пять тыщ (с)Шутка. Над решением я еще думаю, но кое-какие идеи есть, я ими обязательно поделюсь в следующем посте.