30 января пройдёт митам по несильно популярному, но очень мощному подходу работе с требованиями и тестированию: Specification by Example

Подробности

“Традиционная модель сбора требований и создания спецификации основана на большом количестве формальностей, передач и переводов “с одного языка на другой”. Бизнес-аналитики извлекают знания из заказчика, и делают по ним спецификацию, затем перекидывают их разработчикам и тестировщикам. Разработчики извлекают знания из спецификации и переводят их в исполняемый код, который потом передается тестировщикам. Затем тестировщики берут спецификации. извлекают знания из них и переводят их в проверочные скрипты которые исполняются над готовой системой, которая передается им от разработчиков.

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

При помощи Agile-процессов разработки циклы обратной становятся значительно короче, поэтому проблемы обнаруживаются раньше. […] Однако, вместо обнаружения проблем нам в первую очередь нужно работать над тем как избавиться от их появления.”
Это выдержка из книги Gojko Adzic “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” вышедшей в свет в 2009 году. Прошло десятилетие, однако индустрия разработки ПО по-прежнему страдает старыми болячками. Давайте лечиться :)

На первом митапе в этом году мы начнем знакомиться с подходом Specification by Example(Spec.by Example, SbE). SbE - это когда все люди, участвующие в создании решения, совместно определяют требования. Подход помогает выявить пробелы и несоответствия в требованиях ещё до создания софта. При его помощи мы можем создать достаточный объем спецификаций, который потом превращается в “живую документацию” в виде автотестов и конечно же это сильно упрощает работу разработчиков и снижает риск создания “неправильного” ПО. Само название “Specification by Example” появилось на свет в 2004 году с легкой руки Мартина Фаулера, однако, сам подход “совместного анализа” уходит корнями в 90е (а может и ещё раньше) и имеет другие разные названия - Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), Test-Driven Requirements и тд.

Нам предстоит поучаствовать в так называемом Specification Workshop, в ходе которого мы совместно создадим требования для настоящей IT-системы :)

https://www.meetup.com/ru-RU/Technical-Excellence/events/267932278/
#DevOps #Agile #Scrum

Быстро поднятое не считается упавшим (с)

⚠️ Ошибки есть у всех и это нормально, при этом чем позже мы найдём ошибку, тем сложнее/дольше/дороже (нудное подчеркнуть) ее будет устранить.

1️⃣ В мире разработки и #DevOps есть (относительно новый) тренд под названием #ShiftLeftTesting, то есть смещение выявления багов «налево», то есть ближе к этапу development, а не как у многих — на ПСИ.
Shift Left можно сделать за счёт правильно настроенных сред, тестовых данных, автоматизации заглушек и других активностей.

2️⃣ В мире бизнеса тоже есть баги, и заключаются они в уходе клиента.
🔸Можно бороться в момент ухода: закидывать клиента скидками (тинькофф уходящим клиентам давал 0 стоитмлсть обслуживания кредитной карты)
🔸Можно сместиться чуть левее и построить ML-модели по выявлению churn-клиентов (сам такое делал)
🔸А можно сходить в самое начало жизненного цикла клиента и посмотреть, а что там не так, что в итоге приводит к уходу.

🎁 Один из способов, что можно делать, есть у Морейниса.