Shift left testing что это
Shift left testing что это
Сейчас уже многие говорят о переносе процесса тестирования на ранние стадии разработки. Как же так? Ведь всего лишь несколько недель назад тестирование двигалось вправо, ближе к концу жизненного цикла. Где вы сейчас? Не стоит размышлять о переносе тестирования на ранние либо поздние этапы, без осознания его текущей позиции.
Впрочем, вначале давайте рассмотрим преимущества раннего и позднего тестирования, с учетом того, какие потребности будут покрыты или, что будет улучшено за счет такого смещения.
Чтоб последующая информация воспринималась легче, давайте-ка добавим немного визуализации. Поскольку мы уже упоминали автомобильную коробку переключения передач, представьте ее в виде набора из пяти шестерен с разным количеством зубьев на каждой.
Классика жанра: третья передача
Увы, но это текущее положение вещей в большинстве компаний. На этапе разработки проводятся только основные и технические проверки. Есть специальная система тестирования, в которой и выполняется проверки качества продукта. Все как обычно: разработчики пишут код, а тестировщики проверяют функциональность продукта, в том числе в связке с другим софтом.
Тестируемые приложения «упакованы» таким образом, что общаются друг с другом только посредством специально разработанного функционала, как правило, с ограниченными возможностями. Несмотря на то, что подобная конфигурация довольно-таки статична, для ее поддержки и обслуживания требуется «тонна» усилий, глубокое понимание принципов работы каждого отдельного продукта, знание применяемых технологий и общих принципов рабочего процесса. Поскольку каждое приложение связано с определенной командой разработчиков (иногда даже находящихся в разных компаниях), то в случае появления «багов» вы сильно зависите от того парня, который непосредственно написал проблемный код. А что если сейчас он недоступен? Тогда у вас проблема! Выход продукта на рынок снова откладывается, поскольку нужная вам информация пока недоступна.
Однажды мы сотрудничали с банком, который использовал специальную систему, сконфигурированную таким образом, чтобы тестирование выполнялось на каждом этапе разработки. Тестовые случаи включали ситуации с воссозданными проблемами, раннее выявленными в процессе работы приложения.
Проблемные кейсы включали несогласованность тестовых данных в системах, различия между рабочими средами систем или этапов, а также некоторые ошибки, появляющиеся только при определенных конфигурациях. Большая часть времени, отведенного для тестирования, приходилось на настройку систем и выстраивания их в нужной последовательности, которая, как предполагалось, отвечала бы реальной ситуации.
Базу тестовых данных можно было просто импортировать. Она была полезной еще и потому, что позволяла легко создавать пользователей и учетные записи, подставляя «на лету» любые даты, иначе тестирование заняло бы годы. Есть ли способ получше?
Сдвиг влево: Первая передача
Почему мы привыкли к тому, что в жизненном цикле разработки тестирование проходит на поздних этапах? Ведь это же очевидный факт – чем раньше найдена ошибка, тем проще и дешевле обходится ее исправление. Давайте-ка сдвинем этап тестирование влево по временной оси жизненного цикла разработки программного обеспечения, и переместим его в среду разработки.
Благо, что из-за существенных изменений в конфигурациях, провернуть это дельце сейчас уже не так хлопотно, как раньше. Системы мигрировали в облачные сервисы, а тестировщики перешли к использованию API. Работая в среде, контролируемой на уровне API, каждое приложение может вызвать функцию (универсальную или выделенную) в обход службы, чтобы выполнить более раннее тестирование. После окончания проверки данные передаются через запрос для формирования ответа. Если требуемая система недоступна, этот вопрос решает служба виртуализации (service virtualization).
Служба виртуализации — это простой, но действенный способ для проведения всесторонних испытаний любой подключенной системы, позволяющий тестировщикам «играть» с ней по своим правилам. Виртуализация также помогает создавать сложное окружение, чтобы обучение проходило в обстановке, «приближенной к боевой», а полученная практика уменьшала риски возникновения непредвиденных ситуаций. Тем более, что для последующего воспроизведения требуемых ситуаций, все потоки данных записываются. Вызовы служб выполняются на уровне API и служба виртуализации ведет себя так же, как вел бы себя готовый продукт (система).
Модульный подход к тестированию также вносит свои изменения в правила игры. Разработчики создают модули, которые после используются тестировщиками. Просто представьте перспективы тестируемой системы, в которой разработчик видит только ее часть, а тестировщики видят картину системного «ландшафта» целиком и со всеми возможными конфигурациями. Повторное использование некоторых артефактов создаст новые цепочки процессов либо добавит новые возможности в процесс моделирования. Разработчики могут определить обязательные параметры подключения, такие как логины, пароли, конечные точки и минимально необходимые меры безопасности, а тестировщики просто берут все это и используют в тестовой среде (да-да, именно среде, а не выделенной области тестирования, в которой системы реально взаимодействуют друг с другом без виртуализации.)
Тестовые данные и варианты всех тестов могут быть доступны и для dev- и для test-команд поэтому в зависимости от важности конкретного теста, он может быть запущен уже на этапе разработки, с последующей записью входящих/исходящих данных. Вызов службы можно осуществить типичным способом, но это зависит от данных, которыми оперирует команда. Поиск ошибок на ранних стадиях жизненного цикла приводит к уменьшению ресурсов, выделяемых для последующего тестирования, и ускоряет время выхода продукта на рынок.
Однажды мы участвовали в переносе тестирования на ранние стадии в компании, занимающейся обслуживанием кредитных карт. Хотя в то время им уже удалось избавиться от статической конфигурации тестов и перейти к API, но, несмотря на всю специфичность софта и функционала, на ранней стадии тестирования было выявлено очень много ошибок. Компания располагала отдельной командой тестировщиков, которая просто фокусировалась на уровне API и проверяла связь между ним и приложениями. Тестировщики вместе с разработчиками создавали модули, предоставляющие запросы и ответы. Одни и те же модули использовались повторно при тестировании системы с разными параметрами соединений. Это экономило огромное количество времени, так как команда разработчиков знала, что будет нужно тестировщикам в случае внесения определенных изменений в параметры соединений. Критичные ошибки и нестыковки данных были выявлены еще на этапе разработки и были решены поэтапно, во время развернутого тестирования.
Когда они еще только начали «истязать» приложение с помощью служб виртуализации, разработчики уже успели рассказать нам, как далеко смогут зайти их проверки, чем существенно сэкономили время дальнейшего тестирования и обслуживания.
Сдвиг вправо: пятая передача
Этот особенный метод, потому что мы попытаемся получить лучшее из обоих техник, рассмотренных выше. На этом этапе существенно увеличивается количество тестировщиков, но время выхода на рынок должно сократиться, потому что тестирование происходит в продакшене.
Одним из лучших примеров смещения тестирования вправо (shifting right) является Amazon, так как его заказчики и потребители также выступают в качестве тестировщиков. Все операции глубоко интегрированы. Оптимальный результат достигается в том случае, когда стадия раннего тестирования уже пройдена и на выходе у вас остается только финальный продукт, который проходит автоматическую сборку.
Для того чтобы провести надлежащее тестирование в продакшене, придется потратить больше усилий, чем на предыдущих этапах, потому что все процессы должны быть настроены идеально, а работа – автоматизирована в пользу уровня API. Все, что вы забыли проверить, будет присутствовать в производстве, поэтому функциональность, которая не была покрыта тестами, может привести к реальным проблемам. Ваш продукт должен уже быть сверхстабильным и, возможно, работать с ограниченным числом подключений. По крайней мере, позаботьтесь о том, чтобы все было протестировано с не менее чем 90 % покрытием рисков, иначе некоторые операции не смогут развернуться.
Каждый модуль должен обрабатываться независимо. Полное развертывание в рабочей среде должно состоять из множества фрагментов, так как это обеспечит лучшее покрытие тестами. Большинство фич могут вызвать побочные эффекты. Их может быть даже больше ожидаемого, поэтому их нужно включить в ваши тесты как можно раньше. Конечно, финальное тестирование выполнят непосредственно пользователи, а их отзывы приведут вас к оставшимся ошибкам.
Несмотря на вышесказанное, необходимо не забыть о готовом рабочем конвейере непрерывной интеграции QA, который будет запускаться во время сборки. Большинство тестов запускаются автоматически, во время работы, выбранной CI-тулзы, поэтому сборка выполнится только в случае их успешного прохождения. Тестировщикам нужно позаботиться только о создании тестов, их поддержке и проверке результатов. Идеально, если тестировщики еще и умеют распознавать ложные срабатывания, а также оценивать необходимость вовлечения в процессы тестирования или разработки.
Если вам удалось пройти через все «передачи» воображаемой коробки передач, то вы должны использовать преимущества первой. Здесь модули API могут использоваться повторно, а обслуживание на техническом уровне выполняется только один раз. Качество конечного продукта будет оценено клиентами на основании их отзывов (речь идет о сообщениях-разочарованиях).
Этот способ подходит для увеличения лояльности пользователей и для создания функционала, отвечающего их требованиям, но, чтобы воспользоваться им, нужно, чтобы ваш продукт уже находился на определенном уровне. Если новые «фишки» не слишком сильно повлияют на ваш бизнес, в том смысле, что частота их использования, как и возможный ущерб, несущественны, можно смело экспериментировать в этом направлении. В противном случае постарайтесь убедиться, что тесты покрывают как можно больше функциональности, а все побочные эффекты обнаружены. Чем выше плотность тестового покрытия, тем выше доверие к продукту.
Ранее мы настраивали этот процесс для одного из крупных ритейлеров. Их продукт был уже почти готов и как раз проходил стадию наполнения фичами. Каждое приложение, созданное сторонней командой, виртуализировать и подключалось через API. Каждая сборка проходила через конвейер CI и проверялась на стороне разработчика с помощью автоматизированных API-тестов и JUnit.
Если все «Ok», сборка автоматически перемещалась в специальное тестовое окружение. Там с помощью CI-тулзы в сборку включались тестовая среда и инструменты тестирования, после чего она пересобиралась. Потом запускались автоматизированные функциональные тесты, во время которых использовались UI, API и реальные устройства. Если результаты прохождения тестов «зеленые», сборка передавалась в продакшен и собиралась автоматически. С одной стороны, вы сильно сэкономите время и деньги, с другой — должны быть уверены в используемых системах и приложениях.
В случае необходимости внесения изменений в тесты вам нужно будет работать всего лишь с одним продуктом, что также сильно снимает «головную боль». Благодаря заранее встроенным модулям, не придется создавать одни и те же тесты для разных окружающих сред, но главная проблема – это «ровная» работа виртуализации на различных этапах. При создании тестового набора мы даже ввели принцип “четырех глаз”, чтобы убедиться в том, что все проверено и покрыто тестами.
Не бойтесь использовать передачи
Каждое тестовое окружение зависит от многих факторов, включающих команду, само приложение и конфигурацию инфраструктуры. На разных этапах могут использоваться различные тестовые стратегии и подходы. Если в процессе тестирования вы думаете, что переход вправо либо влево мог бы быть полезнее, либо сам ход процесса «толкает» вас в определенном направлении — сделайте это.
Каждый сдвиг — это целый процесс, а не одно мгновение. Не бойтесь переносить тестирование на разные стадии жизненного цикла программного обеспечения, если считаете, что это принесет больше пользы для общего дела. И, да, мысли о создании совершенно нового плана тестирования всегда будут останавливать вас. Не позволяйте им делать это. Возможность повторного использования теста очень высока, поэтому однажды применив что-то на «третьей передаче», вы можете сэкономить много времени и денег на пятой.
Пусть ваши тестовые циклы сами наталкивают вас на верный путь, подобно тому, как звук мотора автомобиля, с механической коробкой, наталкивает водителя на мысль о необходимости переключить передачу.
10 шагов для начала успешной работы с тестированием в режиме Shift Left
“Ошибки обходятся дешевле, пока они “молоды”.”
Это слова популярного эксперта – Лари Смита, в отношении к концепту Shift Left тестирования’.
Если вы работаете в сфере тестирования программного обеспечения, вы, должно быть, довольно часто слышали о терминах «shift left». С ростом популярности Agile, BDD и DevOps QA компании быстро продвигаются к тестированию Shift Left для повышения своей производительности.
Так что же такое Shift Left тестирование?
Так как же начать работать с Shift Left тестированием?
Ниже перечислены 10 шагов, которые объясняют, как начать работу с Shift Left тестированием легко и эффективно, чтобы получить все преимущества:
1. Определение и планирование жизненного цикла тестирования
Для компаний важно определить и спланировать весь жизненный цикл тестирования до начала фактического процесса разработки. Это поможет разработчикам и тестировщикам понять задачи и ожидаемые результаты проекта. Один из способов сделать это – определить требования к тестированию прямо из этапа планирования проектов и требований.
2. Интеграция процесса разработки и управления проектами с тестированием
Еще одним важным шагом для начала работы с Shift Left тестированием является интеграция всех процессов разработки, управления проектами и операций с тестированием. Это поможет понять, где и на каких этапах должно пройти тестирование. Это также поможет определить приблизительное время необходимое для завершения цикла тестирования и избежать дублирование задач в процессе реализации теста.
3. Определение стандартов качества и контроля для всех этапов SDLC
Также рекомендуется определять ожидаемые стандарты качества и осуществлять контроль качества на разных этапах SDLC. Это поможет определить, совпадает ли процесс разработки с процессом тестирования и выявить любые отклонения от ожидаемого результата. Это, в свою очередь, поможет в принятии корректирующих действий на соответствующем этапе, что в конечном итоге будет определять общее состояние проекта.
4. Планирование релизов
Также рекомендуется планировать релизы до того, как вы приступите к Shift Left тестированию. Это поможет определить возможные задержки, а также управлять ресурсами, требуемыми в каждом спринте, для достижения заранее определенных целей. Планирование релизов также поможет команде сфокусироваться и эффективно управлять циклами релиза.
5. Развертывание процесса, основанное на тест-кейсах и фреймворке
Чтобы плавно перейти к тестированию Shift Left, эксперты также предлагают создавать тест-кейсы и фреймворки, которые в целом покрывают функциональные процессы, а также рабочие шаблоны. Это делается для того, чтобы избежать ошибок во время развертывания приложений со стадии разработки. Разработка тест-кейсов и фреймворков, которые уже проверены в соответствии с функциональным и операционным процессом, помогает сократить количество тест-кейсов, которые будут созданы в будущем, а также ускорит работу SDLC.
6. Внедрение автоматизации тестирования
Чтобы получить максимальную выгоду от тестирования в режиме Shift Left, для компаний рекомендуется использовать автоматизацию тестирования. Благодаря автоматизации тестирования разработчики и тестировщики могут автоматизировать всю сборку для тестирования на всех этапах SDLC (разработка, производство, тестирование, развертывание и т. д.), которые будут способствовать лучшей интеграции между процессами, непрерывной доставке и повышению уверенности в каждом релизе.
7. Стимулирование разработчиков программировать, тестируя свой код в уме
Важно также побудить всех разработчиков приступить к работе таким образом, что каждый разработчик должен быть ответственным за обеспечение качества созданного кода. Это обеспечит надежность, а также позволит преодолеть “разрыв” между разработчиками и тестировщиками для ускорения завершения цикла тестирования.
8. Определение механизма непрерывной обратной связи
Также целесообразно определить механизм непрерывной обратной связи, чтобы тестировщики могли непрерывно предоставлять обратную связь разработчикам во время и после этапа разработки. Сообщать о дефектах и достигать желаемого качества будет намного проще, поскольку при непрерывном мониторинге и обратной связи шансы на ошибки, как правило, снижаются.
9. Поощрение тестировщиков в программировании
Также тсетировщикам рекомендуется улучшать свои знания в области программирования, так как, когда дело доходит до тестирования в спринте, знание программирования может помочь в проведении более глубокого анализа багов. Кроме того, знание программирования может оказаться полезным, если тестировщик захотят внести небольшие изменения в код, не будучи в зависимости от разработчиков.
10. Контроль качества время от времени
Регулярный контроль качества и общая проверка время от времени важны для успеха любого проекта Shift Left тестирования, поскольку она помогает в раннем обнаружении ошибок и уменьшает вероятность возникновения серьезных дефектов на этапе производства и развертывания. Более того, периодический контроль качества экономит много времени для тестировщиков, таким образом они могут сосредоточиться на качестве, а не на выявлении недостатков.
Наконец, чтобы успешно начать работу с Shift Left тестированием, всем членам команды рекомендуется хорошо выполнять именно свою задачу, так как каждый несет ответственность за высокое качество программного обеспечения.
Завершение
Тестирование в режиме Shift Left обеспечивает эффективные средства для проведения тестирования параллельно с процессами разработки, позволяя получать приложения быстрее, лучше и качественнее, улучшая взаимодействие между разработчиками и командой тестировщиков. Если процесс тестирования будет реализован должным образом, он может снизить издержки и риски сбоя приложения, обнаружив баги на раннем этапе SDLC, а также уменьшит вероятность исправления ошибок, что позволит компаниям быть более конкурентоспособными и продуктивными в 10 раз.
Наши курсы Тестирования ПО в Минске тщательно разбирают этот вопрос, поэтому рекомендуем записаться к нам прямо сейчас!
What Is Shift Left Testing? A Guide to Improving Your QA
Have you ever experienced a software project that ran out of budget or time? You probably did. Believe it or…
Share on
Have you ever experienced a software project that ran out of budget or time? You probably did. Believe it or not, incorrect planning often isn’t the root cause of a project running out of time. The real problem lies in the way the project validates the code.
In other words, it all boils down to software testing. Or, more specifically, to software testing that is done too late in the project’s lifetime, and not frequently enough. Shift left testing is a proposed solution to this problem.
The “shift left” testing movement is about pushing testing toward the early stages of software development. By testing early and often, a project can reduce the number of bugs and increase the quality of the code. The goal is to not find any critical bugs during the deployment phase that require code patching.
This article explains the concepts of shift left testing and how you can adopt the approach in your organization.
Did I get your attention? Let’s explore how we can achieve zero bugs during the deployment phase.
Expand Your Test Coverage
What Is the Idea of Shifting Left?
The shift left movement is about moving the testing phase earlier in the software development life cycle—shifting left. We want to avoid approaches where testing is only carried out at the end of the software development life cycle. With shifting left, we introduce testing in the early stages of software development.
Up until the late 1990s, a typical software development process is sequential. Here, stakeholders spend attention to detail and favor quality only at the latest phases of the software development lifecycle. More specifically, the testing and deployment phases. Within this sequential model, testing happens towards the end of the project’s lifetime.
However, software developers or product owners often found problems that weren’t covered by tests. It’s very costly and time-consuming to fix such bugs at a late stage. Worst case, developers have to redesign the application.
Here, the idea of shift left testing originated to involve the testing team as early as possible in the software development process.
Why Is It Called A Shift To The Left?
We’re about to explore the relationship between the shift left testing movement and agile software development. However, before going there, let’s talk some etymology. As you’ve seen, shift left testing essentially means “test often, and start as early as possible.” But why is it called “left”, though?
Well, that’s probably a side-effect of the fact that, in English, and most western languages, we read from left to right. So, if we are to represent sequential phases of any kind, the earliest phase will be at the extreme left, and we’ll progress from that. For instance, the phases in the waterfall methodology can be represented as follows:
Shifting Left and Agile
Often, we find the term “shift left testing” in agile is all about small code increments.
The agile methodology includes testing as an integral part of the shorter development cycle. Therefore, shift left testing fits nicely into the agile idea. The testing engineer has to perform testing after each code increment—often referred to as a two-week sprint.
Some organizations like to push shift left testing even further toward the coding phase. A good approach to adopt is test-driven development (TDD). Test-driven development requires you to first write the tests for the piece of code you want to develop. Therefore, you can immediately verify the validity of your code.
Another way of pushing testing further left includes the use of static analysis tools. A static analysis tool helps to identify problems with parameter types or incorrect usage of interfaces.
For example, ESLint is a very well known static code checker—or linter—within the Node.js community that shows your mistakes while coding.
Furthermore, testing experts believe that behavior-driven development (BDD) can accelerate the shift left movement. BDD defines a common design language that can be understood by all stakeholders, such as product owners, testing engineers, and developers. Therefore, it enables all involved stakeholders to simultaneously work on the same product feature, accelerating the team’s agility.
In other words, BDD stimulates cross-team collaboration while improving feature-delivery time.
Next, let me show you why it’s so important to test early and frequently.
Importance of Early Testing
We often underestimate the effects of testing early on in the software development life cycle as the agile methodology describes. Regularly testing code with each code increment helps to guarantee the quality of the project but also saves you a lot of time and money.
It’s important to first understand when bugs enter the code.
When Are Most Bugs Introduced in the Code?
It’s hard to pinpoint exactly, but roughly 85% of the code defects are introduced during the coding phase. In case your organization believes testing comes after the coding phase, many defects will be found during the testing phase.
Therefore, this means a lot of bugs have to be fixed. With “fixed,” I’m referring to patching, as it’s almost impossible to properly solve all these bugs at once. With this statement, I want to show you the importance of introducing testing as early as possible in the software development cycle.
When an organization believes testing should only happen after the development phase, a lot of time—and money—will have to be invested in stabilizing the product. It’s a frustrating experience that often leaves your product full of patches. This isn’t an ideal boilerplate for future code expansions or service additions.
Added to that, the cost of finding a bug also varies at which stage of the software development cycle the bug pops up. Numbers may vary, but on average, the cost is five to 10 times higher when finding a bug during system testing or even higher during the actual release of a product. Besides the higher cost, you’ll likely find unhappy customers.
Let’s summarize the above points in the benefits section.
Benefits of Shift Left Testing
So, what are the benefits of shift left testing?
Another great benefit of shift left testing is the ability to use test automation tools. As we want to test early and often, test automation helps you accomplish this goal. We don’t want to overload our testing team with manually testing every new feature the development team introduces.
Therefore, a test automation tool can give quicker feedback regarding the stability of the new code. Furthermore, a test automation tool helps your team shift left. Your team can write tests faster and it becomes easier to maintain them using a test automation tool.
For example, Testim offers a solution to codelessly record tests via UI interactions.
As you can see, these are some strong benefits related to shift left testing. It’s safe to say these benefits apply as well to the agile methodology.
How to Get Started With Shift Left Testing
Let’s find out what your organization can do to get started with shift left testing.
Step #1: Coding Standards
First of all, your development team needs to agree on the same coding standards. All developers must be on the same page. It helps them to review code quicker but also guarantees a higher quality of code.
In short, coding standards should decrease the number of bugs as the standards avoid bad or insecure code.
Step #2: Implement Testing in Early Stages of Development
As a team, find out which tools might be relevant for your codebase. I definitely recommend using a static code analyzer like ESLint, which helps to detect bad coding practices and bugs while you’re developing.
Besides that, the team should think about how they want to integrate testing in the early stages of the software development life cycle. A possible strategy is to adopt the agile methodology, which works with small code increments also called sprints.
Next, each sprint includes a development and testing phase. This makes sure that every small feature gets covered with relevant tests.
For some organizations, it’s not possible to make a drastic switch toward the agile methodology. Therefore, the development team can agree on writing unit tests for each feature they develop. This allows them to have confidence in the business logic they write.
In later stages, the development team should write integration tests to make sure that all these units of code nicely integrate.
Step #3: Embrace Test Automation
As shift left testing involves frequent testing, the development team should embrace test automation tools. Besides automating the deployment of new builds, running tests for each code increment should be automated as well.
This will reduce the pressure on the testing team and provides quicker feedback about the stability of the code.
In general, test automation will speed up the development life cycle and allows you to reduce the time to market. Besides that, it ensures fewer bugs will be found later on in the software development life cycle.
If you’re still unsure about why you should invest in test automation, read this great guide created by Testim.
What Changes After You Shift To The Left?
In practice, what does life look like after your organization adopts shift left testing? What are some changes you’re likely to see? That’s what we’ll cover in this section.
Less Waiting In Testing Activities
As a rule, after shifting to the left, you’re expected to have less waiting related to testing activities. It makes sense, right? In traditional, non-agile settings, testers have to wait until developers are finished implementing their features to be able to commence the testing activities.
When you shift left, testing becomes an early and frequent activity. Testing happens before, during, and after development. In general, that means less time waiting for testers.
Additionally, resources are more likely to be used to their fullest, with less idle time for testing environments, for instance. In a nutshell, shift-left results in less waste and more efficiency.
More Customer Involvement
Many agile approaches state that customer involvement is essential for the success of a software project.
As you’ve seen, BDD is one of those approaches, and so is extreme programming (XP). They both require customer participation, particularly when it comes to writing test cases or specifications.
Even though you can shift left without explicitly adopting BDD and/or XP, it is beneficial to include customer involvement in your testing process.
Adherence To The Testing Pyramid
The test automation pyramid is a useful concept in test automation. It helps teams and organizations decide how to prioritize between the many different types of automated software tests.
In a nutshell, the pyramid states you should have more unit tests than any other kind of test since they’re faster to run, and typically cheaper to set up, and easier to write. Then, you should have a smaller number of integration tests and an even smaller number of UI/end-to-end tests.
If your organization practices shift-left testing, that means your developers are likely to write unit tests, either before or after writing the production code. So, you’re likely to end up with more unit tests than any other type of test, meaning you’ll be following the testing pyramid.
A More Diverse Set of Team Members Performing Software Testing
We’re not in the 90s anymore. We’re in the 21st century and it’s now increasingly common for everyone at a software organization to perform testing. This is not only good but essential to true shift-left testing.
There’s no way to make testing a pervasive, constant activity without using all the help you need. Luckily, nowadays there are tools that even professionals with no coding skills can leverage to author robust tests in a way that just wasn’t possible in the past.
Coverage Goes Up
A not-that-surprising consequence of shift-left testing is that it drives test coverage up. It makes sense: if you have more people writing tests more frequently and starting earlier, it stands to reason you’ll have a larger portion of your application covered by tests.
A less guaranteed—but sill likely—consequence of shift letting is the increase in code coverage. I say it’s less guaranteed because shift left doesn’t necessarily imply more unit tests being written, but that’s likely to be the case.
Preventing Painful Test Maintenance Becomes More Important
Painful test maintenance is one of the more serious challenges in test automation. When your test suit is riddled with fragile tests, each seemingly small change to the codebase can result in test failure. The result is that maintaining the tests becomes a heavy burden, undermining the whole test automation effort.
When you adopt shift-left testing, it’s essential to give the test maintenance problem the care it deserves, since you’ll naturally have a larger number of tests of many different types.
Is Shift Left Testing the Way Forward?
This entirely depends on your organization. In theory, every organization can move toward shift left testing. You can start small by introducing coding standards or embracing a static analysis tool.
However, the benefits of shift left testing are clear. By detecting and reducing the number of bugs early on in the software development life cycle, we can ensure a higher quality of code. Besides that, your development team will save time and money by embracing testing in the early stages of software development.
This post was written by Michiel Mulders. Michiel is a passionate blockchain developer who loves writing technical content. Besides that, he loves learning about marketing, UX psychology, and entrepreneurship. When he’s not writing, he’s probably enjoying a Belgian beer!