Работая с автотестами на разных проектах, я часто сталкивалась с тем, что к коду тестов люди относятся не так, как к продуктовому. Причем это касается и разработчиков, и тестировщиков, и менеджеров. Коду тестов прощаются грехи, недопустимые в продуктовом коде. Хорошо это или плохо? Зависит от ситуации.

Я работаю тестировщиком больше 10 лет. Побывала в аутсорсе и продуктовой разработке, зрелых и только формирующихся командах. Каждая команда уникальна, но есть серые зоны, которыми тестировщики пренебрегают независимо от зрелости компании и её ценностей.

В последние годы из всех утюгов только и говорят, что без автотестов никуда. Любой уважающий себя разработчик должен писать тесты. Любой стремящийся не оказаться на обочине жизни тестировщик должен писать автотесты. Матерого автотестера от новичка отличает понимание, что не все тесты одинаково полезны. И иногда лучше не писать ничего. Как учила нас мама - “не пиши, за умного сойдешь”. Моя статья будет не о том, как писать тесты, а о том, как их писать не надо.

Вы говорите разработчикам, что теперь на каждую задачу надо писать автотесты. Они кивают, ведь и сами давно об этом говорят. Но когда очередная задача приходит в тестирование – тестов нет.

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

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

Что это? Саботаж? Немая забастовка? Инфантильность? Мой ответ – это наш мозг.

Всем привет. Осенью 2022 года я занялась поиском IT работы в Португалии. В статье поделюсь, как это было и чем закончилось. Дисклеймер: многие подробности я намеренно опустила, будут вопросы – задавайте в комментариях.

На собеседовании тестировщиков я обычно задаю вопрос, делают ли в команде ревью. И часто слышу в ответ разные вариации “нет”: разработчики делают, но я не вникал; нам не надо, мы много общаемся; никто не знает питон, а тесты написаны на нём. Так что, неужели ревью подходит только разработчикам?

Давайте начнем с ручного тестирования. Надеюсь, никого не удивлю тем, что ревью относится не только к коду. Все давно слышали про shift left, ревью аналитики и прототипов, ревью тест-кейсов. Слышали, конечно, но не внедряли, потому что а) нам не надо, у нас работают хорошие специалисты, или б) у нас нет времени (ага, всё занято полезными встречами, понимаю). 

Я искренне считаю, что в обоих пунктах происходит рационализация одного и того же страха. Нам страшно показывать свою работу другим. Страшно обнаружить пробелы в знаниях и проиграть в сравнении. Узнали себя? Тогда вам в помощь культура ревью.