Про проблему
На собеседовании тестировщиков я обычно задаю вопрос, делают ли в команде ревью. И часто слышу в ответ разные вариации «нет»: разработчики делают, но я не вникал; нам не надо, мы много общаемся; никто не знает питон, а тесты написаны на нём. Так что, неужели ревью подходит только разработчикам?
Давайте начнем с ручного тестирования. Надеюсь, никого не удивлю тем, что ревью относится не только к коду. Все давно слышали про shift left, ревью аналитики и прототипов, ревью тест-кейсов. Слышали, конечно, но не внедряли, потому что а) нам не надо, у нас работают хорошие специалисты, или б) у нас нет времени (ага, всё занято полезными встречами, понимаю).
Я искренне считаю, что в обоих пунктах происходит рационализация одного и того же страха. Нам страшно показывать свою работу другим. Страшно обнаружить пробелы в знаниях и проиграть в сравнении. Узнали себя? Тогда вам в помощь культура ревью.
Про культуру
Все же помнят, что нельзя писать «твой код <вставьте любое нехорошее слово>»? Даже если сильно хочется. Даже если это правда. Обратная связь должна быть развивающей и корректирующей, а не депрессирующей.
Потренируйтесь на котиках не обидчивых коллегах. Научитесь давать такую ОС, за которой будут выстраиваться очереди как за новым айфоном. После вашей обратной связи человеку должно стать понятно, что именно сделано не так, как это можно исправить, и как прекрасна станет его жизнь, если он это сделает. И серьезно, пора научиться давать ОС напрямую человеку. И принимать такую ОС тоже.
Для меня идеальное ревью содержит обоснованную критику, пруфы, новые знания или аргументированный взгляд с другой стороны. От ревью с комментарием “замечаний нет :)” я грущу и прошу посмотреть еще раз.
Ревью кода
Если говорить о ревью автотестов, часто высказывают аргумент «тесты это не настоящий код, зачем тратить время на их ревью». Ребяты, всё, что вы используете в разработке — настоящее. Даже если это скрипт, написанный на салфетке во время обеда. И всё это заслуживает уважительного рассмотрения, в процессе ревью, конечно же.
Какие тесты ревьюить? Все, до которых дотягиваются руки. Можете посмотреть тесты разработчиков? Просите отправлять их вам на ревью. Плохо разбираетесь в языке проекта? Посмотрите хотя бы на покрытие сценариев (и учите язык). Стесняетесь делать ревью тестов более опытного коллеги? Сделайте один раз, найдите 5 ошибок, и скиньте коллегу с пьедестала, который сами и построили.
Вспомню хороший пример. Я как-то проводила мастер-класс по ревью тестов разработчиков среди тестировщиков, не уверенных в своем знании кода. За 3 часа работы неопытные автоматизаторы разобрали один тестовый класс и нашли три проблемы: недостаточное покрытие в одном месте, избыточное в другом, полное несоответствие ТЗ и реализации. 3 часа - это много или мало? Много для ежедневной работы, нормально для обучающего процесса. Я не призываю тратить на ревью всё своё время, предлагаю попробовать и увидеть пользу.
Ну и напоследок, во время ревью можно причинять пользу не только другому, но и себе. Смотрите, как пишут код другие, спрашивайте о непонятных конструкциях, рассматривайте ревью как взаимовыгодный процесс, а не проявление недоверия.
Вместо послесловия
Если кто-то всё ещё не проникся, приведу примеры проблем, которые нахожу на ревью:
разработчик скопипастил тест-кейсы и не удалил лишнее, остались идентичные кейсы
аналитик описал в ТЗ только позитивный сценарий, никаких “если - то”
тестировщик написал селениум тесты там, где были нужны скриншотные
аналитик ввёл переменные Т3 и ТЗ (найдете разницу?)
тестировщик сделал приватный метод публичным, хотя мог обойтись без этого (этим тестировщиком был
Альберт Эйнштейня)разработчик не написал тесты на изменения в API (состоялся диалог «а почему ты не написал?» — «у меня нет ответа на этот вопрос, пойду напишу»).
Хотите такого же веселья? Идите и сделайте ревью!