Повышение качества с помощью настроек мышления

В Klima мы все работаем вместе для достижения общей цели: создать привлекательный способ удаления углекислого газа из атмосферы. С точки зрения климата и компании мы все в одной лодке, поэтому, хотя наша повседневная деятельность может показаться индивидуальной, наш вклад измеряется в контексте всей команды. Вот почему мы знаем, что просто сидеть вместе в одной лодке недостаточно. В идеале мы не только гребем в одном направлении, но и без усилий управляем веслами.

В этом смысле наши разработчики всегда очень тесно сотрудничали с командой контроля качества. Поскольку наши процессы продолжают развиваться, мы хотим поделиться некоторыми из наших выводов о том, как разработчики могут попытаться, с небольшими изменениями мышления, не только более эффективно работать с QA, но и оставить достаточно места для ног на лодке, чтобы каждый член команды чувствовал себя комфортно, ценится и эффективен - в основном замена этих надоедливых лопастей на настоящий двигатель реактивного катера.

TL;DR:

  • Обратите внимание на склонность к самосборке. Ваш код может быть отличным, но легко потерять объективность, оценивая собственную работу. При кодировании и тестировании будьте сомневающимися и бдительными, а не оптимистичными.
  • Каждая ошибка — это возможность для обучения. Возможно, вы что-то упустили, требования были неясными или изменились, не были учтены крайние случаи — каждая ошибка — это напоминание о том, как подготовиться к будущему.
  • Каждая ошибка — это победа. Цените ошибки, обнаруживаемые до того, как они попадут к вашим пользователям, и не воспринимайте их как источник разочарования.
  • Поток информации имеет решающее значение для поддержания высокого качества. Группа контроля качества часто работает с черным ящиком. Поделитесь с ними дополнительной актуальной информацией о реализации или возможных регрессиях, чтобы сделать это поле немного менее неясным.
  • Рассмотрите возможность совместной работы с инженерами по контролю качества. Коллеги из группы контроля качества могут пролить свет на предлагаемое решение, помочь обеспечить охват всех крайних случаев и привнести в смесь бизнес-знания и точки зрения конечных пользователей.
  • Сначала будьте разработчиком, а потом уже тестировщиком. Будьте активны: тестируйте то, что вы создаете, и сообщайте об этом, или устраняйте любые проблемы, которые вы обнаружите, даже если они не обязательно являются частью вашего кода, чтобы они исправлять до того, как они станут проблемой в будущем.

📼 Попробуйте сломать свою кассету

Эффект IKEA — это когнитивное искажение, при котором мы придаем непропорционально большое значение предметам, которые собираем сами. Одно исследование показало, что мы готовы платить значительно больше за стандартную коробку для хранения IKEA Kassett, если делаем ее сами.

Хотя программирование определенно отличается от сборки шведской мебели, уклон остается прежним. Мы ценим написанный нами код (иногда) непропорционально высоко. Легко быть эмоционально привязанным к решениям, которые мы придумали и реализовали, поэтому мы склонны быть оптимистичными. Но разработка программного обеспечения — это не место для оптимизма, это место для сомнений.

Как разработчик, вы знаете все детали реализации, поэтому, прежде чем сказать, что все готово, подумайте, не вызовут ли какие-либо внесенные изменения некоторую случайную регрессию, и исследуйте это. Спросите себя, насколько хорошо вы подготовлены к интеграции, поскольку ошибка в вашем коде может быть вызвана кодом других команд, и исследуйте это.

Протестируйте свой собственный код и подумайте, как сломать ваш Kassett, прежде чем выкладывать код, и к нему будет привязана реально высокая ценность не только со стороны QA, но и со стороны конечных пользователей. В процессе вы научитесь смотреть на свой код более объективно — в вышеупомянутом исследовании, когда участники уничтожали свои кассеты, предвзятость внезапно рассеялась.

🐞 Учитесь на своих ошибках

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

Помимо поиска (и исправления) корня проблемы, постарайтесь понять, почему эта ошибка вообще возникла. Был ли это тестовый пример, который вы забыли охватить? Вот мотивация, которая вам нужна, чтобы охватить их все в следующий раз. Можете ли вы покрыть это модульным тестом? Если нет, можете ли вы покрыть это тестом пользовательского интерфейса? Это связано с устаревшим кодом? Обратите внимание, чтобы у вас было больше аргументов, когда вы отдаете приоритет работе над техническим долгом вместе с продуктом! Билеты по-прежнему будут возвращаться, но используйте каждый случай как возможность обучения, чтобы снизить вероятность появления большего количества ошибок.

Имейте в виду, что проблема может заключаться в вашем коде, а также в плохих требованиях или недопонимании. Если проблема связана с кодом, вы будете лучше подготовлены к решению этой проблемы в следующий раз. Если это требование или недопонимание, будьте инициатором разговора о проблеме. QA поддержит вас в кратчайшие сроки, поскольку высокое качество должно быть характерной чертой каждого этапа процесса разработки — от идеи функции до создания спецификаций и анализа после запуска.

🏅 Превращаем ошибки в победы

Отчеты об ошибках могут легко стать источником разочарования, но вы также можете рассматривать отчет об ошибке как победу: проблема была обнаружена вашей командой, а не вашими пользователями. Был выявлен неизвестный риск, что сделало планирование более эффективным, а процесс выпуска более безопасным. Это победа. Вы столкнулись с прекрасной возможностью обучения, способом подготовить свой код к другому случаю и проверить свой код с помощью дополнительных тестов. Его. А. Победа. Любой человек, который найдет ошибку, должен быть вознагражден, и все же довольно часто «автор» ошибки недоволен этим.

Разочарование непродуктивно. Это размывает ваш фокус. Получая отзыв, подумайте, как вы реагируете эмоционально, а не как прагматично. Перефразируя Марка Аврелия, решите не причинять вреда, и вы не почувствуете себя обиженным. Сосредоточьтесь на росте с каждой ошибкой и на работе с командой контроля качества (а не против них).

💬 Информация должна течь

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

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

Оставляйте заметки о других системах, которые были изменены с вашей фиксацией. Оставьте список других пользовательских путей или функций, которые могут быть затронуты — даже с уже рассмотренными тестовыми примерами — чтобы быть уверенным, что вы продвигаете код так же хорошо, как вино из винодельни капитана Жана-Люка Пикара. Специалисты по обеспечению качества будут в восторге, увидев эти заметки не только потому, что они означают, что вы заботитесь о качестве продукта, но и потому, что они могут использовать их в своих процессах. Они могут принять решение сосредоточиться на тех связанных, затронутых системах, провести там несколько быстрых исследовательских сессий и выявить регрессии намного быстрее, чем когда живут в темноте.

Ваша команда QA хочет знать, что находится в коробке, и вы держите ключ.

🦆 Экстремальные уклоны от резины

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

Пригласите их на сеанс сопряжения, сеанс отладки QA. Проведите их по коду и объясните, как логика кода охватывает бизнес-логику. Даже не имея опыта программирования, их вопросы могут открыть вам глаза на различные вещи, которые вы могли пропустить, случаи, которые еще не были рассмотрены, поведение, которое было реализовано по-другому из-за несовпадения спецификаций. Это резиновая уточка на стероидах и беспроигрышная ситуация — вы получите быструю обратную связь по своему коду, а QA получит представление о базовой основе приложения.

✨ Настоящие разработчики полного стека

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

Хотя мы все несем ответственность за качество конечного продукта, на личном уровне мы должны стараться изо всех сил и сохранять бдительность. Когда вы видите какое-то сомнительное поведение во время разработки своего изменения, очень легко проигнорировать его и предположить, что это не имеет большого значения или крайний случай. Пески страусиного алгоритма сладки, но часто быстры.

Если вы хотите гордиться своей работой, вам нужно быть активным. Если вы видите странное поведение, исправьте это или, по крайней мере, заявите, что что-то не так. Проактивно тестируйте свой код, старайтесь найти проблемы до того, как они станут проблемами позже в процессе. Если вы создаете свои функции, не прилагая значительных усилий к качеству и тестированию, вероятно, есть возможности для улучшения. Добавьте в процесс разработки немного магии контроля качества, и вся команда (и конечный пользователь!) будут вам благодарны.

Если это звучит интересно, и вы хотите узнать больше о нашем проекте (или о том, как помочь планете!), заходите на klima.com.

Написано Fred Porciúncula и Jedrzej Kaminski, а также опубликовано на Klima Engineering Hashnode.