Сочинение на тему Softvision – как справиться с утечкой в ​​разработке

«Мы должны были найти это раньше», – сказала она. Мое лицо покраснело, но я знал, что она была права. “Почему не мы?” – спросил я себя. Первое, что пришло на ум, было обвинить всех и все вокруг меня: требования были недостаточно ясны, время для тестирования было меньше запланированного, у нас не было тестов для этой части, но модульные тесты должны были поймал это. Тогда я начал думать, что все они будут винить меня: в конечном счете, ответственность за качество лежит на QA, не так ли?

Это когда я вспомнил совет, который я прочитал некоторое время назад на StackExchange: «Лучшее, что можно сделать в новой ситуации? Слушать. Обратите внимание. Предложение и совет. Не пытайтесь взять все под контроль ». Я попытался это сделать, и вот как мне это удалось.

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

1-я линия защиты – Отношение

 
1. Не принимайте это на свой счет и будьте профессионалом

 

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

 

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

 

2. Рассматривайте это как возможность

 

Мы не должны тратить время на то, чтобы упустить ошибку, вместо этого мы должны рассматривать всю ситуацию как возможность. Мы можем сделать это, показав команде, что мы делали и постоянно делаем, чтобы улучшить качество продукта, демонстрируя в то же время, что мы стремимся продолжать делать это: выявить причину ошибки – отсутствие тестов, документация, ошибки в спецификации, требования, нехватка времени и т. д.

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

Создайте отчет о покрытии, чтобы определить части приложения, которые не были протестированы или недостаточно протестированы.

Продолжайте изучать новые методы тестирования и улучшайте свои навыки

2-я линия защиты – сделать это правильно

 
1. Вход

 

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

 

2. Fix

 

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

 

3. Запретить

 

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

 

4. Ретроспективный

 

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

3-я линия защиты – анализ первопричин

Мы должны предположить, что люди будут продолжать совершать ошибки. Тем не менее, вместо того, чтобы обвинять людей, мы можем начать обвинять наш процесс. Что именно из нашего процесса позволяет допустить ошибки? Как мы можем изменить наш способ работы, чтобы минимизировать частоту ошибок?