🌲Из всех активностей, которые я делаю в течение года, адвент-календарь кажется самой доброй и уютной таской!

В этом году я подготовил для вас отдельную страницу с 31 подарком.

14 уже открыто, еще 16 будут открыты после 15 декабря и последнее окно станет доступно 31 декабря.

QA Advent включает задачи, ресурсы, книги, подписки и прочие вещи, которые могут быть полезны как совсем новичкам, так и моим коллегам. Все бесплатно.

В общем, переходите, делитесь, оценивайте!

Надеюсь, что вы полюбите его, как и я ❤️

Также все подарки я буду дублировать каждый день в канале @qa_sklad, если не хотите проходить все разом.

Кстати, черная пятница еще не закончилась, так что буду рад вашей поддержке в посте выше :)

В честь профессионального праздника хочется написать, почему тестирование — это не «сломать все», и чем этот подход вреден (спасибо Артему Русову, на днях упомянувшему это и наведшему меня на эти размышления).

Тестирование — процесс гораздо шире и глубже, чем только «ломание»: проверка требований и дополнение их на основе нашего знания системы; тест-анализ и тест-дизайн «как мы будем это тестировать» и «как эффективно это протестировать». Выстраивание процесса вместе с разработкой. Оценка рисков и трудозатрат (надо ли упарываться в 100500 минорных проверок? но там же можно что-то «сломать»?). И так далее.

Безо всего этого просто «ломание» будет довольно неэффективным. Да, есть ad-hoc тестирование, но это только одна (небольшая) часть тестирования, да и оно тоже не только про это.

Вдобавок самоопределение как «Халк ломать», на мой взгляд, не помогает строить продуктивные отношения с другими членами команды. Кому будет приятно работать вместе с человеком, кто говорит, что его цель — сломать то, что ты сделал, no matter how?

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

Давайте не ломать, давайте строить вместе процессы обеспечения качества.

О, давайте последний день лета отметим нудежом про собеседования и как не надо делать.

Я сейчас много собеседую; поняла тут, что есть три самые бесящие меня на собеседованиях вещи.

Резюме, в котором по описанию работ и обязанностей вообще непонятно, чем человек занимался. «Тестировал тесты». Я говорю не про подготовку резюме к HR-этапу, а именно про этап, когда на резюме перед собеседованием кидает взгляд нанимающий менеджер, чтобы понять бекграунд и скиллы кандидата, о чем вообще спрашивать-то. Иногда по резюме я не могу даже понять, что именно человек тестировал — веб там, бэк, мобилки. Интрига!

Хотелось бы без нее, правда. И если вы думаете, что я преувеличиваю про «тестировал тесты» — увы! Описание, состоящие полностью из такой неконкретики и воды с 0 подробностей я видела своими глазами. Если пишете резюме с ChatGPT — хоть проверяйте после него, дописывайте сами или корректируйте с ним. Всем будет легче.

Рассказ о себе как сага на полчаса, начинающаяся от сотворения мира или тяжелого детства и прибитых к полу игрушек. (Рекорд — 28 минут, и я опять не шучу, я засекала время). «Расскажите о себе и своем опыте» обычно подразумевает краткий, на 5, максимум 10 минут рассказ про ваш профессиональный опыт, сильные стороны и достижения, которые хочется подсветить. (Особенно если достижения вы в резюме не вписали, расскажите о них сейчас!).
Достаточно. Если этого не хватило, вас попросят продолжить или развернуть подробнее. Но попробуйте базовый рассказ о себе уложить в эти 5-10 минут сути, потренируйтесь дома по таймеру, например.

Утомительно, когда это превращается в анекдот «люблю ходить по собеседованиям, можно поговорить о себе» и подробный экскурс во всю жизнь человека… У нас не сеанс психотерапии, спасибо-пожалуйста.
(Нет, у меня есть коллега, который любит такие подробные рассказы, с ним я эти 28 минут и получила, потому что вел собеседование он, но это скорее исключение; и даже с этим исключением — вы всегда можете перейти к более подробному рассказу по наводящим вопросам от интервьюверов).

Вписанные «шоб было» в резюме тулзы-скиллы, к вопросам про которые вы не готовы.
Например, все это прошли только на курсах, в работе не использовали, вписали в резюме, потому что вам на курсах так сказали или чтобы по этим ключам резюме прошло. На собеседовании почему-то часто превращается в диалог формата:

— А у вас автотесты указаны
— Ой, это только на курсах проходили
— А SQL?
— Ой, это тоже только на курсах, в работе не нужно было...
— А (подставить следующее, и так до конца списка)
— Ну это я сам(а) поизучал(а), но не применяла(с)

И с каждым следующим вопросом грустнеет что кандидат, что нанимающий менеджер, у которого ощущение, что он детей бьет.
Ну ребят (и девчат). Нашли в себе силы вписать какую-то тулзу, которую только в теории поизучали или на курсах? Найдите в себе силы на вопрос про нее бодро и уверенно ответить «изучали на курсах/самостоятельно, такой вот уровень знаний, если надо будет разбираться дальше — я готов(а)».

Просто сравните:
— Автотесты?
— Изучала на курсах, писала простые автотесты на фронтенд с такими-то селекторами, знания такие-то
— SQL?
— Писала запросы уровня select, представлю, как работать с join-ами, с ними практики мало было, но если надо будет разобраться, это не проблема.

Всё! Лучше же?

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

Считаю, что вывела только что гениальное.

Отрицание.
Гнев.
Торг: надо решить, сколько и каких проверок провести, чтобы было достаточно (исчерпывающее тестирование невозможно).
Депрессия: можем сказать, какие баги нашли. Сказать, что багов нет — не можем… (Тестирование демонстрирует наличие дефектов, а не их отсутствие).
Принятие: все равно там какие-то баги будут, у всех они есть, это нормально (заблуждение об отсутствии ошибок).

Из случайного диалога на своем балконе (начали за НРИ, продолжили про работу, все как мы любим х) принесу несколько мыслей.

Профессионал — это человек, который умеет не только применять изученные инструменты (или паттерны проектирования), но и понимать, в какой ситуации какие их них нужны и почему.

Для меня джун-тестировщик становится миддлом*, когда на практике понимает принципы «исчерпывающее тестирование невозможно» и «тестирование показывает наличие багов, а не их отсутствие». Перестать верить в то, что можно идеально протестировать все, принять это, и перейти от блокирования собственной грудью (или страданий по выпуску) неидеального релиза к пониманию и оценке рисков — очень важный шаг внутреннего роста.
Сеньором — когда начинает мыслить со стороны бизнеса. Понимать, в каких условиях какие риски для нас приемлемы, уметь говорить с бизнесом на его языке (от «так нельзя» — к «мы можем сделать А или B с такими-то рисками, риски C превышают допустимое всё, но можно посмотреть на это с такой-то стороны и обсудить вариант D») с учетом бизнес value и потребностей для каждого конкретного случая — оценка рисков для MVP и проверки гипотез отличается от ключевого и стабильного продукта.

• Конечно, не только по этому критерию, но в каждой шутке есть доля шутки!

Лид — тот, кто умеет посмотреть на проект широко, учесть те самые риски и потребности бизнеса, принять решение, какая стратегия нам нужна, исходя из этого, и донести это до членов команды — как мы будем делать в этом случае (возможно — еще с «почему»).