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