Этой осенью тотального ковида был замечательный подарок от Влада Орликова — две очные конференции, AnalystDays и SQAdays с интервалом месяц: 9-10.10 #AnalystDays и 6-7.11 #SQAdays. На обоих я был, выступал и вел заметки в FB. Это было такое замечательное живое общение. И, не смотря на ковид, достаточно многолюдное - 400-500 на AnalystDays и несколько меньше - на SQAdays, плюс 150-200 онлайн-участников. Людям нравится живое общение и они его жаждут.

Это напомнило старые времена, тем более, что вскоре после SQAdays facebook напомнил про прекрасную конференцию во Львове, которая была в 2013 году. Я сделал репост старой фотки и получил много комментов с воспоминаниями — они живы не только у меня. Кстати, наверное, уместно напомнить про у конференцию в этом отчете. Потому что тогда не только сама конференция была прекрасная и очень живая, да еще первый раз был полный день с иностранными спикерами на английском языке. Дело в том, что мой отчет в блоге вызвал активное обсуждение позиционирования конференции: «SQAdays — точка роста твоей карьеры» — более 250 комментов на FB, осмысленных еще в блоге организаторов на habr. B это позиционирование работает, по-моему, работает до сих пор: люди осваиваются в профессии у себя в компании, приходят на конференцию — и получают следующий импульс развития. И последняя SQAdays — тому подтверждение.

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

На обоих конференциях выступал не только я, но и Анатолий Левенчук, и с его выступлений я начну. Кстати, он по горячим следам опубликовал свои впечатления AnalystDays пост в ЖЖ и обсуждение на FB и SQAdays пост в ЖЖ.

Правда, на AnalystDays я на докладе Анатолия не был, потому что параллельно участвовал в круглом столе. Анатолий призывал аналитиков стать инженерами, то есть принимать решения, а не просто проводить анализ. А вот на SQAdays я на докладе был, и сначала заметки с него, а потом — с круглого стола по системному мышлению на AnalystDays, в котором Анатолий активно участвовал. Кстати, дискуссия на круглом столе была активно продолжена на FB в моей заметке, и часть ее я вынес в отчет. И это — не единственный доклад, заметки с которого вызвали активное обсуждение — это было в постах про доклады Дмитрия Безуглого, Григория Печенкина и другие. И это хорошо — все-таки устные обсуждения проходят только в головах участников, а тут — остаются зримые следы.

Доклад Анатолия на SQAdays

Пост на FB Вчера после пары докладов я перестал вести репортаж, потому что начался доклад Анатолий Левенчук по Системному мышлению, потом был мой, а потом мы общались в кулуарах почти до завершения конференции. Собственно, конференции замечательны именно общением в кулуарах, на которых от спикеров и других участников можно часто услышать много больше, чем на докладах. Тем более, что доклады доступны в записи. Кирилла Полякова я уже написал, сейчас напишу про доклад Анатолия.

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

А вторая половина доклада была по слайдам. Начало было о том, что мир меняется быстро. 2021 — переломный для многих технологиях. Электромобили + беспилотники типа одновременно. И электросамокаты и электровелосипеды — они конкурируют. И переход на курьеров. И разработки — грузовик, из него робот выгружает пакет. И водителя нет. DHL — испытания идут, несколько компаний по Калифорнии. В Пекине тоже несколько. И как испытания окончатся — это быстро распространится по всему миру. В Москве самокаты — за одно лето появились.

И в этом мире у человека цикл.

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

И тут ключевая вещь — разобрался в новом, получил прикладное мастерство. А не просто вписался в коллектив, софтскилл недостаточно, надо быть T-человеком, должна быть вертикальная ножка. А без нее ты не T-shape, а человек-прочерк! T-люди — работают с интеллектом. Они не просто умеют что-то делать, они умеют разобраться в новой задаче и умеют двигаться по мере изменения нового.

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

Круглый стол «Как мыслить системно» на AnalystDays

Пост на FB Круглый стол «Как мыслить системно». Вводная от Ирина Гертовская про OMG Essence, потом краткий рассказ Сергей Пчеляков про проект модернизации опорной сети оператора мобильной связи (одного из большой тройки), успешный — проект с серьезным отставанием и провалами по бюджету и был сделан на год раньше и в рамках бюджета. А для диагностики и анализа использовали как раз альфы OMG Essence. Я слушал этот доклад весной на школе системного менеджмента Анатолия Левенчука, можно на моем сайте найти отчет.

А дальше — резкий тезис Дмитрий Безуглый.

• Ребята применили давно известные методы Kanban и TOC. И они молодцы.
• Но особенность проекта — в том, что это был проект модернизации технической системы, где результат известен и нормирован.
• С такими проектами все понятно, и системный подход замечательно работают.
• Но мир изменился, область таких проектов — сокращается.
• Большинство проектов — иные, по разработке продуктов. А в них Заказчик не знает, каким должен быть результат. И не может ответственно верифицировать работу проектной команды.
• И OMG Essence, так же системный подход, в принципе не применимы для таких подходов. Поэтому OMG Essence и не взлетел.

Тезис интересный. Вызвал возражения у Анатолий Левенчук, который тоже был на круглом столе. Но дискуссию развернуть не получилось по времени. Ее вынесли в кулуары.

Дальше я продолжил писать заметки в том же посте, и по некоторым из них было обсуждение, привожу его тоже.

Для Анатолия если Заказчик не может сформулировать требования к системе — надо выйти в надсистему, и из нее понять эти требования. Дмитрий полагает, что выход в надсистему — не помогает, мы не можем из надсистемы сформулировать требования к продукту.

Егор Вершинин. Как это не можем? В надсистеме надо описать основные цепочки создания бизнес-ценности. Результат выполнения этих цепочек и будет являться целями/бизнес-требованиями создания одной из систем входящих в надсистему. Продуктовая разработка именно по такому принципу и строится. Для этого пользователей продукта и их потребности надо превратить в надсистему. И далее — здравствуй системный подход.

Дмитрий Безуглый. Теоретически да, а практически доя этого нужно чтобы надсистема была определена с границами и цепочками создания ценности. И этого нет в 99 % организаций

Sergey Pchelyakov. Отсутствие определения/описания не является фактическим отсутствием в реальной жизни при внимательном рассмотрении всё необходимое присутствует ??

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

Sergey Pchelyakov. Кому-то это выгодно ??

Дмитрий Безуглый. Мир такой какой он есть, потому что он таким стал. Если за 15 лет Enterprice Architecture и бизнес-анализ не начал работать, значит на это есть веские причины. Думаю что концепция EA идёт туда же где живёт Delphi, CORBA, MSF, RUP, CMMI и т. д. В нишевую историю которой уже никогда не стать индустриальным стандартом …

Егор Вершинин Веские причины: хайп и жажда бабла помноженные на цифровую трансформацию. А решения и бизнес-процессы все усложняются, а не упрощаются. Закончится все это каким-нибудь Agile 2.0, в котором наконец то придумают как проектировать сложные решения с нормальным качеством за вменяемые деньги и сроки, без того что бы продукт бесил конечного пользователя. Может мы (сообщество) и придумаем :)

Тезис Анатолия, что проектный подход в смысле PMI и PMbok — да, не работает. Но Operation research — никуда не делася. И он — решается через системный подход, там есть предпринимательская часть.

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

И резюме Анатолия. Это разные позиции. Аналитик анализирует и просит решение у высоких дядей, которые не понимают. А инженер — сам принимает решения и ответственность. Говорит: «делаем прототип и будет 5 итераций». И проект идет. И Ирина это подхватила: мы называемся аналитиками. Это исторически сложилось. Но реально мы занимаемся не только аналитическими задачами, хотя эта часть — важная. Но мы еще и принимаем решения.

И еще одно резюме Дмитрия — про зрелость областей по Кеневин. Когда есть область полной неопределенности, непонятных связей, и там не заказывают проектов. Есть запутанная область, когда к результату надо идти экспериментально. И инженер не может сказать, как надо, потому что область — неизвестна. Есть сложная область, где определенность уже выше. И только там инженеры могут выдавать решения — как раз на основе знаний о своей области. И дальше уже область простых проектов. Пару лет назад Дмитрий делал об этом доклад на ЛАФ-2018, подробности в моем отчете https://mtsepkov.org/LAF-2018

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

Андрей Степенко. Отличные тезисы. Что такое r&d мало кто знает. В теории это называют инновационными проектами. Там нет ни литературы ни солюшенов. Да и смысла это знание разбазаривать в учебники нет потому, что оно является либо конкурентным преимуществом либо не хватает широты мысли что связывать системные и предметные уровни (про что Дима говорит)

Анатолий Левенчук. При этом предпринимательство (то место, где формулируется идея нового продукта) в OMG Essence есть. То есть аргумент, что всё хорошо работает только тогда, когда продукт хорошо определён — это смотреть на 7 альф и видеть только 5 (инженерию и менеджмент). Нет, в схеме 7 альф. А если выйти за рамки проекта и попасть в рамки предприятия (где проектов много), то там и более полная диаграмма. Так что я не принимаю высказанных замечаний, они не бьются с фактами.

Церен Церенов. Конечно, только системной схемы не хватает. Сразу в проекте взлетать на OMG не получится. Есть ещё системные уровни и цепочки обеспечения, нужно сначала выделить системы, а уж потом применять 7 альф. Поэтому сначала нужно разобраться с заказчиком и с возможным результатом, а ещё возможно, потом несколько раз уточнить. Системный подход говорит как работать в такой неопределённости, выделяя вниманием системные уровни и разные системы и формулируя гипотезы, которые нужно потом тестировать, в тч используя системную схему. Вот тут коротко описал: https://blog.system-school.ru/2020/08/14/2323/

Екатерина Тихомирова Аналитика 2.0: роль аналитика в инновационных изменениях

Пост на FB Екатерина Тихомирова Аналитика 2.0: роль аналитика в инновационных изменениях. На мой взгляд, в докладе — прикольное проявление клипового мышления, при котором рамка рассуждения ограничивается текущим слайдом. На каждом слайде все правильно. Но межслайдовая логика нарушена. На первом слайде проблема: аналитики сосредоточены на внутреннем устройстве системы, не говорят на одном языке с бизнесом. На слайде, что изменяем при этом первый фокус — понимание архитектуры системы, то есть то, что обозначено как проблема. Правда, второй фокус — как раз освоение предметной области. Но вот понимание языка бизнеса в списке отсутствует. Или еще, вторая проблема заявлена консервативность бизнеса и работа по конкретным кейсам. Но дальше решение — изменение мышления аналитиков. При этом на самом деле решение вообще не показано, потому что дальнейший доклад воспринимается как решение по большому количеству частных кейсов.

Вообще фокус дальнейшего доклада — ускорение конвейера поставки через выбрасывание ненужных бюрократических согласований, через пилотную эксплуатацию на одном магазине, сотрудники которых могут напрямую обращаться при проблемах к аналитикам и разработчикам, а не зависать на службе поддержки, выводя их из зоны комфорта. И другой способ погрузить разработчиков и аналитиков в проблемы пользователей — через стажировку в реальных магазинах с выполнением операций на разработанных ими системах — принцип «сами ешьте свою пиццу». В целом-то идеи правильные и хорошие, так что доклад полезный. Видно, как retail осваивает те технологии, которые давно уже must в публичном web, и разработка становится все более быстрой. Хотя, опять-таки, эффект в цифрах не слишком показан, потому что в начале было распространение по всем магазинам за 2 месяца, а на выходе — установка в пилотном магазине за 3 недели. Другое дело, что если раньше пилотных магазинов не было, то обратная связь была хуже, и качество продукта должно было повышено. Но акцента на этом нет.

Дмитрий Подлужный, AGIMA. Money Driven Design

Пост на FB Дмитрий Подлужный, AGIMA. Money Driven Design. Очень интересный доклад про разницу продуктового мышления и старого подхода «реализации фич по ТЗ», в котором приоритеты и оценка полезности была за рамками проекта. Тезисы.

• Помните, что любой проект — не сотня полезных фич, а сотня гипотез о фичах, которые могут подтвердиться, а могут и нет.
• Для оценки полезности фичи используйте деньги, а не какие-то невнятные, зато измеримые показатели.
• Деньги можно мерить как visitors, conversion, loyalty. Visitors часто вне влияния тех, кто разрабатывает продукт, оно за рамками. А вот conversion и loyalty как раз во многом определяются продуктом и аналитиками, которые его делают.
• У каждой гипотезы есть аудитория, некоторый процент от всех. И дальше — смотрим на конверсию, насколько наша гипотеза на нее повлияет.
• И на лояльность тоже. Оцениваем, при чем исходя из целевого промежутка времени (1 год). Считаем повышение лояльных клиентов и cash flow от лояльных клиентов. Бывает, что гипотеза, слабо влияющая на конверсию — влияет на лояльность.
• Итого получаем список перспективных продуктовых гипотез. B отрабатываем их.
• На денежные показатели, например, доходы от рекламы, влияет очень много факторов. И тогда надо выстраивать цепочку влияний и исходя из этого давать оценку.

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

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

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

Дмитрий Безуглый. Как продукты едят проекты на завтрак

Пост на FB Дмитрий Безуглый. Как продукты едят проекты на завтрак. Основной тезис доклада — противопоставление старого подхода автоматизации новому продуктовому подходу. Сначала — обзор классических подходов автоматизации процессов. Когда летит подход заявок от бизнеса, и IT-департамент захлебывается от них, берет в работу одну заявку из 10, и из 5 взятых в работу 1 дотаскивает до прода. Представьте, что в ресторане из 20 принесли 1… Как вы заказали 3? Значит блюда принесли другому. 10 лет назад было две альтернативы: заказная разработка и инхауз. В инхауз зарплаты 1.5-2 раза выше, чем в заказной, но тупеешь на однородных задачах. Но с тех пор появилась третья альтернатива — продуктовые компании. А там ты стоишь столько, сколько приносит цифровой продукт. Поэтому там громадные зарплаты и работа мозга одновременно.

И дальше на разных кейсах было объяснение разницы. Не всегда систематичное. Основная штука в том, что в продуктовой разработке ты синтезируешь продукт, а не автоматизируешь существующие процессы. Хорошая метафора: цифровой продукт — это не о том, чтобы стиральная машина стирала так как стирает бабушка Глаша вручную. Потому что такая стиральная машина была бы чудовищно неэффективна и дорога. И Амазон стал тем, кем стал вовсе не потому, что автоматизировал работу клерков, собирающих заказы на книги. Но машина корпоративной разработке раскатана, и еще будет жить. И да, там больше рынок труда: в ВТБ разработчиков много больше, чем в Тинькове. Вопрос в характере этого труда и вашем позиционировании.

Собственно, в этом и был основной пафос доклада: осознайте разницу этих миров и займите позицию сознательно. А не считайте, что весь мир одинаков. Кстати, в этом доклад перекликается с утренним докладом Дмитрия Подлужного — тот во многом из нового, цифрового мира, и когда ему задают вопросы: «А как действовать с продуктами в корпорациях, где осваивают бюджеты?» — честно отвечает, что не знает, это другой мир. Но у Димы есть тезис о том, что у мира корпораций никогда не будет столько денег, сколько у мира продуктовой разработки, что тот сегмент — неуклонно уменьшается. И, думая о своем будущем, стоит этот тренд принимать во внимание.

Максим Шаломович и Евгений Асламов. Немного о требованиях, которые все меняют

Пост на FB Максим Шаломович и Евгений Асламов. Немного о требованиях, которые все меняют. На метафоре поездки на автомобиле показывают проблемы, связанные с изменениями требований. И на примерах конкретных кейсов — автомобиль не вписывается в узкую улицу, пытаются забрать чрезмерный груз, заехав куда-то по пути обнаруживают дальше только грунтовку или ремонт, в результате доехали, но дольше, дороже и измучившись по пути, то есть цель достигнута, но удовлетворения нет. Метафора — понятная, и вносило оживление в серьезные кейсы, о которых шел рассказ. И дальше я часть этих кейсов зафиксирую.

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

Ограничения надо выявлять. Задача осложняется тем, что для Заказчика многие ограничения — очевидны.

• Всем известно, что это ГИС 2 класса защищенности
• Всем известно, что у нас нельзя использовать Kafka

Всем известно у них — а ваша задача — выяснить.

Требования к качеству. Ему не нравится названия «нефункциональные», потому что коннотации провоцируют про них забыть. А еще эти требования не существуют без функциональных. Не «система должна обеспечивать отклик 2с», а «Система должна обеспечивать отклик 2с по таким-то функциям». А часто пишут обобщенно — и это бесполезная штука получается.

Что делать? Выявлять требования к качеству через сценарии качества. «CMU SEI ADD» или «quality attribute scenarios». «При падении сервера система восстанавливается не позднее, чем за два часа», «Добавление атрибутов, не связанных с интеграцией, занимает не более 5 часов».

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

По требованиям к качеству смотрят на

• Производительность, надежность, доступность
• Удобство использования (UI/UX)
• Модифицируемость

Архитектура в теории является ограничением для разработчиков. На практике в 3 % случаев они приходят со словами «знаешь, мы хотим сделать по-другому», в 20 % — «мы сделали по-другому, это уже на проде», а в остальных ты узнаешь, когда на проде рвануло или даже «уже пару месяцев взрывается регулярно»…

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

Григорий Печенкин, Расшатываем скрепы: что не так с классификацией требований Вигерса?

Пост на FB Григорий Печенкин, Расшатываем скрепы: что не так с классификацией требований Вигерса? Речь шла о Классификации требований, которую придумал Вигерс. Она вошла в SWEBOK и многочисленные курсы аналитиков, и она реально впечатана в культуру, и потому влияет на мышление. А с этой классификацией, если смотреть на нее формально, есть проблемы. Она делит требования на три уровня, считает, что каждый уровень самодостаточен и выводится из предыдущего. При этом ограничения и внешние интерфейсы появляются на следующих уровнях. А атрибуты качества появляются не на бизнес-уровне, а ниже. А еще концепт «требования» предполагает описание системы как черного ящика. Синтез решения вообще не предполагается этой концепцией. И это приводит к многочисленных перекосам и проблемам.

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

При этом Гриша активно вовлекал зал в обсуждение, чем и выполнял основную задачу — расшатать представления аудитории.

В комментариях к посту — много содержательных обсуждений.

Дмитрий Безуглый. Интересы разработчиков в функциональных требованиях :))))

Григорий Печенкин. Дмитрий Безуглый в требованиях к решению, если использовать терминологию BABOK

Дмитрий Безуглый. Григорий Печенкин Интересная перспектива

Максим Шаломович. Не дале как сегодня к нам подходила девушка и жаловалась, что у нее на работе «принято» писать кучу разных типов требований (например, бизнес-требования и бизнес-правила — это у них разные категории), и если аналитик не принесет архитектору и разработчику нужные требования в нужных табличках, то те их даже читать не будут. Поэтому они тратят дофига времени на то, чтобы определить, в какую именно табличку (какой тип/ класс) требование надо занести, вместо того, чтобы уже реализовывать его)

Денис Мишарин. А вот у нас наоборот — тимлид на обсуждении требований к контракту: «давайте сначала попробуем сделать, а потом напишем». вот прям .. ну просто «респект и уважуха»

Максим Цепков. Значит у девушке на работе правильное оформление документации важнее работающего софта. И для разработчиков и архитекторов тоже. Форма важнее содержания. Так бывает

Arseniy Maslov. Денис Мишарин, завидую неограниченным временным и финансовым ресурсам вашей компании. Перекос в обратную сторону: давайте чего-нибудь напишем, а там разберёмся чего вы хотели. «Жарьте мама! Рыба будет»

Наталья Желнова. Максим Цепков, Архитектору, например, очень не хотелось бы вместо требований иметь мешанину из «а вот тут у нас такую кнопочку надо» и «для того чтобы сократить время обслуживания клиентов, нам надо масштабировать вот этот модуль». Просто потому, что потом все это разгребать — понадобится время. А большинство так и не освоивших искусство составлять User Stories так и пишут. И нет, это не «документация важнее работающей системы», как считают многие крепко покусанные Agile-коучами. Это «кто ясно мыслит, тот ясно излагает, а кто не может — пусть идет и учится». Этому тоже надо учиться — представлять требования в том виде, в котором их будет наиболее удобно воспринимать всем, кто с ними работает.

Максим Цепков. Наталья Желнова Про мешанину я понимаю, сам от этих требований страдал. Но противоположная конструкция, которую я опознал в рассказе Макса о девушке — о ситуации, когда есть шаблон и самое главное — его заполнить, и обязательно все в него запихнуть — тоже знакома. И по многочисленным сдачам документации «по шаблону», и плевать, что твой проект в него не лезет, и по внутренним ситуациям, когда в постановке 100500 очевидных вещей написано и среди них спрятались крупицы действительно важного… Мешанина все-таки проще распутывается, чем формально сделанная документация, за которой не видно главного. А обоснованность решений от волюнтаризма отличаются в любом случае.

Наталья Желнова. Искусство применять шаблоны — это тоже искусство. Например, тот же шаблон ТЗ (хоть 34-я, хоть 19-я серия ГОСТ) — прекрасная вещь, практически совершенство, если уметь его _правильно_ применять. Да, и кроме того, используемые шаблоны значительно экономят время тех, кто будет читать документы. Хорошо структурированный шаблон в индустрии — праздник души, потому что человек, знакомый с шаблоном, не полезет искать требования к масштабированию, например, в разделе, посвященном назначению системы. И ему будет ясно сразу, куда смотреть, чтобы ответить на определенный вопрос, который он должен задать, проектируя систему. Но, повторяю, всякий инструмент (а шаблон — это инструмент) нужно правильно использовать, только тогда от него будет польза.

Андрей Степенко. Максим Цепков а почему архитекторы не могут договориться? Ну которые «и разработчики» с частицей не. У верхних Кракен наступил и им нужно приказами ну в общем уболтать. Источник иссяк. А о том что у него ограничение время горения…. 5-10-15…. Редко 20. Ну не подумали. поэтому никто не выдвигал следующего. Риск потери или нехватки бензина никто не предусмотрел. Митигэйшин нон комплит.

Григорий Печенкин. Максим, меня внезапно зацепил твой комментарий о том, что Вигерс рассматривает требования исключительно в концепции чёрного ящика. Раньше мне это казалось очевидным, но когда я задумался над твоей репликой, эта очевидность вдруг растаяла. Приехал домой, кинулся книгу перечитывать, и не нашёл, где бы это явно было сказано. Более того, там есть такая фраза: «Requirements encompass both the user’s view of the external system behavior and the developer’s view of some internal characteristics. They include both the behavior of the system under specific conditions and those properties that make the system suitable— and maybe even enjoyable— for use by its intended operators.»

Григорий Печенкин. Вот, например, в какую часть картинки ляжет решение использовать микросервисную архитектуру. С одной стороны, это явно не про чёрный ящик. С другой стороны, выбор архитектуры наверняка скажется на требованиях всех уровней. (Можно, конечно, всеми силами этого избегать, оставаясь в концепции чёрного ящика, но непонятно, зачем.) Как по-твоему, такое «требование» лежит за рамками обсуждаемой картинки, или всё же где-то внутри её?

Игорь Беспальчук. Григорий Печенкин Решение об архитектурном паттерне вообще не может быть требованием. Если такое решение идет снаружи, то это тогда некое техническое ограничение на проектирование. Требования все-таки всегда — к черному ящику, даже если это требования с позиции разработчика (например, на тестируемость или модифицируемость)

Дмитрий Безуглый. Григорий Печенкин Если Архитектура влияет на требования значит что-то напутал в небесной канцелярии. Либо не влияет, либо это уже не требования)))

Егор Вершинин. Игорь Беспальчук заказчиком может выступать не только бизнес, но и IT департамент И будет у вас архитектурное требование: уйти от легаси, избавиться от дублирования функций в компонентах решения для снижения эксплуатационных затрат. Ну какой здесь «черный» ящик? Можно конечно попытаться натянуть сову на глобус, но стоит ли в данному случае слепо следовать классическому подходу?

Игорь Беспальчук. Егор Вершинин Я не очень понимаю, что вы называете «классическим подходом», но если альтернатива ему — «что угодно называть чем угодно», то я все-таки его предпочту. Иначе начнется полная вакханалия — дизайн у вас становится требованиями, требования наверное станут пользователями, а пользователи — уж не знаю, наверное будут приравнены к коду. Не, ну а что? Зато «неклассично»!

Егор Вершинин. Игорь Беспальчук есть разные группы заинтересованных лиц: Бизнес, IT, эксплуатация и т. д. Требования от них соответственно также будут разные и не всегда сфрмулированы к системе как к «черному» ящику. Где здесь вакханалия?

Игорь Беспальчук. Егор Вершинин Понятие требования не существует само по себе, оно получает смысл в отношениях с другими понятиями. В системной и программной инженерии требование декларируется к некоторой целевой системе в окружении, а точнее — к ее внешне проявляемым свойствам, качествам, и поведению. Решения о внутреннем устройстве, разные варианты которых могут обеспечить выполнение требований, в совокупности образуют дизайн системы. Дизайн-решения, известные заранее и не подлежащие пересмотру ни при каких обстоятельствах известны как ограничения. Такова топика, онтика, терминология. Если вы вводите, что требования могут быть «про что угодно», в том числе про внутреннее устройство, то вам надо как-то переопределить и остальные термины. Зачем это делать (раширять понятие требования) — мне не очень понятно, но давайте просто будем последовательны. Существует ли тогда в вашей «неклассической» терминологии понятия дизайна, архитектуры, рефакторинга, модульных тестов, и т. п., которые в «классической» инженерии зависят от представления о «черном ящике»?

Егор Вершинин. Игорь Беспальчук, где я написал что требования могут быть «про что угодно»? Я написал про разные группы пользователей и про их разное восприятие системы. Для одних она «черный» ящик, для вторых «белый»; для третьих она подсистема, для четвертых надсистема. Можем конечно поговорить про азы управления требованиями и проектирования, но сабж был про: надо ли всегда все поступившие needs переводить на формальные требования причем формулировать их к системе как к «черному» ящику, или стоит «срезать углы». Если у вас на проектах выделяются ресурсы на полный цикл проектирования (needs->обследование-> требования ?вопрос какого уровня? — >дизайн и так далее) — ну круто. Правда это очень и очень дорого. С удовольствием послушал бы доклад на эту тему, про реальные проекты где внедрен такой подход и это не жрет 30 % — 50 % от общих затрат на реализацию без учета внедрения

Игорь Беспальчук. Егор Вершинин Знаете, я возьму свои слова обратно. Действительно, кое-где рассматривают «design constraints» как разновидность требований. Хотя мне по-прежнему кажется это странным, и провоцирующим известную и также широко упоминающуюся проблему «дизайн-решений, выдаваемых за требования».

Григорий Печенкин. Игорь Беспальчук Кстати, Игорь, а модели пользователей (роли, акторы, стереотипы, персоны) являются требованиями? Если нет, то чем?

Игорь Беспальчук. Григорий Печенкин Моделями пользователей?

Григорий Печенкин. Игорь Беспальчук Но частью требований они являются?

Игорь Беспальчук. Григорий Печенкин Нет, они же сами по себе ничего не утверждают про будущую систему, какой она должна быть. Они отвечают на вопросы про пользователей. И из этого ты можешь родить требования к системе.

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

Игорь Беспальчук. Григорий Печенкин Детские травмы дизайнера тоже могут определить образ будущей системы. Требование — это высказывание о целевой системе в деонтической модальности («должна»). Зачем сюда засовывать что-то еще? В чем вообще мотив??

Григорий Печенкин. Мотив в том, чтобы удовлетворить того, кому она должна. Если мы выбрасываем его из требований, то рискуем получить систему, которая делает то, что «должна» никому.

Игорь Беспальчук. Григорий Печенкин Ерунда какая-то. Если ты варишь борщ, то не надо, конечно, выбрасывать мясо из кастрюли. Но зачем мясо называть картошкой или капустой? Кто тебя может заставить «выкинуть все, что не требования», если ты прекрасно понимаешь, насколько оно тебе полезно? Или это какой-то особый фетиш — все, что полезно и нужно и ценно — называть требованиями «а то пропадет»?

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

Игорь Беспальчук. Григорий Печенкин Некоторые вообще usecase не считают requirement’ами (см. google: requirement vs usecase). Но сценарий довольно просто превращается в требование подразумеваемой добавкой: «Система должна обеспечить выполнение следующего сценария использования: раз, два, три.» Так что в приницпе можно считать сценарии формой требования. В сценарии нет никаких моделей и персонажей (только их имена). Модели и персонажи — это то, из чего ты рожаешь сценарии. Что такое «неотъемлемая часть» — я не очень понимаю. Ну а в один документ можно очень много чего свести и будет хорошо и полезно.

Григорий Печенкин. Игорь Беспальчук Неотъемлемая часть означает, что сценарий без указания конкретного актора (выделенной функциональной роли пользователя) и его цели не имеет ценности и не должен использоваться для создания системы.

Игорь Беспальчук. Григорий Печенкин Ну это ж две разные вещи — без указания на актора, и без самой модели актора, не правда ли?

Григорий Печенкин. Во, нашёл в другой книге Вигерса (More about Software Requirements) целую главу: The Fuzzy Line Between Requirements and Design. И там есть такая фраза (перевод мой): «Вместо того, чтобы зацикливаться на том, содержит спецификация изменений требования или элементы дизайна, лучше вспомнить о ключевом назначении требований: ясной и эффективной коммуникации. Аналитик должен задокументировать любую информацию, необходимую для уверенности в том, что изменения будут правильно реализованы в продукте».

Игорь Беспальчук. Григорий Печенкин Не могу не согласиться тут с Вигерсом. Точно также (следи за руками) _вместе_ с описанием, например, архитектуры как таковой, рекомендуется описывать очень много всего дополнительно в целях понимания — стейкхолдеров, окружение, альтернативы, обоснования, результаты испытаний, и т. п.

Григорий Печенкин. Игорь Беспальчук Да, но тогда в чём практический смысл разделения требований, дизайна и прочей картошки в борще?

Игорь Беспальчук. Григорий Печенкин Хороший вопрос… ну ты ж понимаешь, например, что требования могут быть суше, четче, короче, а объяснения можно делать в свободном формате, например. Из одной модели юзера может вытекать много требований. В разработку в принципе можно попробовать отдать требования, не отдавая объемные объяснения. Для ПМИ (верификации) скорее нужны требования, чем что-то вокруг них. Требования можно вести как-то четче и трассировать, если они унифицированы по фор е. Для дизайна нужны немного другие навыки (иногда). В общем, как-то они во всем разные, если смотреть строго. А если не строго, то, конечно, можно все в один agile-котел закинуть и что-нибудь да сварится вообще без умных слов.

Григорий Печенкин. Игорь Беспальчук У строгости должны быть свои цели. Я отлично понимаю, как разделение требований и дизайна по границе ящика работает при разработке новой системы (желательно ещё водопадным методом: сначала требования, потом дизайн).

Стройность концепции начинает размываться, когда мы продолжаем сопровождать уже существующую систему: ограничения дизайна всё больше влияют на требования и начинают смешиваться с ними до состояния неразличения (появляется та самая fuzzy line, о которой пишет Вигерс). А если посмотреть на современные интернет-сервисы, где функциональность уходит на второй план, нефункциональная сторона становится конкурентным преимуществом, а интеграция всего со всем обязательным условием, то эта концепция трещит по швам. И тогда приходится всё упрощать и возвращаться к истокам: для начала сваливать всё в котел agile за неимением готовых рецептов.

Игорь Беспальчук. Григорий Печенкин Ну не знаю… ну влияет дизайн на требования (делает одни дороже, другие — дешевле, да), ну что ж с того? Ну, допустим НФ-требования становятся важнее.. А что с интеграцией-то не так? В общем, я как-то не улавливаю, чем тут понятийное разделение может мешать людям работать. Мне как-то казалось, что оно всегда только помогает понять, что происходит.

Григорий Печенкин. Напоминаю контекст. На конференции Максим сказал, что обсуждаемая картинка из книги Вигерса с типами и уровнями требований нарисована с позиции «все требования относятся к системе как к чёрному ящику». Я смутился и начал искать у Вигерса подтверждения этому тезису. Но так до сих пор и не нашёл. А нашёл буквально следующее (правда, в другой книге): «It’s often said that requirements are about what you build and design is about how you build it. But there are two problems with this simplistic demarcation.»

Игорь Беспальчук. Григорий Печенкин И какие две проблемы он называет?

Григорий Печенкин.

1. First, this statement makes it sound as though there’s a sharp boundary between requirements and design. There’s not.
2. A second problem is that one observer’s how is another person’s what. It’s really a matter of abstraction.

Игорь Беспальчук. Григорий Печенкин. А примеров там, случайно, не было? Интересно было бы разобрать примерчик.

Максим Цепков. Григорий Печенкин «behavior of the system under specific conditions and those properties that make the system suitable» с моей точки зрения — тоже про черный ящик, описывается внешнее поведение. Про «the developer’s view of some internal characteristics» — надо разбираться. Если это из серии «микросервисная архитектура», или «клиент-сервер на основе СУБД Oracle», или даже «пережевывающий 100к транзакций» то это, на мой взгляд, тоже практически про черный ящик, просто сделанный из некоторого материала и имеющий определенную форму… Такие вот ограничения на проектирования, не более.

Игорь Беспальчук. Максим Цепков Пережевывающий N транзакций — это как раз без всяких вопросов классическое НФТ к черному ящику. А вот про Оракл и архитектурные паттерны — вот это как раз то самое исключение, которые некоторые тоже относят к требованиям, хотя особой категории — ограничение на проектирование, ага.

Сергей Нужненко. Это требования по видам обеспечения? По тому, что учить нужно не Вигерсу, а ГОСТ 34?

Сергей Нужненко. Григорий Печенкин. У строгости должны быть свои цели. Многое тут гораздо более утилитарно, как мне кажется. Очень строгие классификации требований были в моде, когда пытались делать ставку на требования в базе данных с учетом трассировок типа requisite pro с генерацией документов типа SRS. Если брать подход от документа, мы получаем шаблоны ТЗ, например. Требование от не-требования отличается тем, что первое ты (формально) должен покрыть приемочными сценариями, а второе — нет.

Илья Бравин. Борьба с неконсистентностью данных в связанных системах

Пост на FB Илья Бравин. Борьба с неконсистентностью данных в связанных системах. Задача связана с поддержкой одновременной работы старой и новой системы в режиме online-передачи данных с постепенным переносом функционала в новую систему. Высыпаются несогласованности из-за различных ошибок разработки — перекодировка и маппинг, значения по умолчанию, различная обязательность, которая дает сбои на передаче, косвенное изменение триггерами, ручные правки БД скриптами — они у них входят в бизнес-процесс. При этом системы на разных СУБД — MySQL и Postgress. Первый раз столкнувшись с инцидентом и запустив массовое сравнение обнаружили, что проблема есть — несовпадение одного атрибута зафиксировано в 1000 записей из 500к. Но цикл ручной выгрузки, загрузка в локальную СУБД и сверка там заняла около 4 часов разработчика, а для разборок, где данные правильные — потребовалось повторить.

И они решили, что нужен инструмент, чтобы это можно было делать автоматически и быстрее. Выбран Apache Zeppelin, альтернативой был Jupyter, но там R, аналитики его не знают. И дальше был рассказ об инструменте. Он позволяет настроить соединения к нескольким базам данных, забирает во временные таблицы и дальше сравнивает результат. Аналитик пишет запросы к исходным данным, забирает данные с реплик, а дальше пишет запросы сравнения. И видит различия, потом делает анализ. Для решения, где данные правильные часто обращаются к бизнесу, так как различия — старые. И Zeppelin позволяет запоминать результаты сравнений, позволяет посылать ссылки на результаты сравнений. И повторить одни и те же процедуры сравнений через месяц-другой. Настраивает все это аналитик. В общем, вполне понятная задача и рассказ об инструменте. В вопросах упоминали еще несколько инструментов для тех же целей.

В комментах обсуждение

Геннадий Круглов: Jupiter, R, как они смотрели?

Максим Цепков: Он подробно не рассказывал. Потому что предпочтение было не по функционалу, а по технологиям, не знакомым для аналитиков. Я думаю, разработчики (для которых технологии знакомы) пробовали что-то сделать и продемонстрировать. Но выбрали другое.

Геннадий Круглов Очень странно:

• в Jupiter есть всё, что есть в Zeppelin и даже больше. Все указанные задачи можно решить в Jupiter. Он прекрасно поддерживает Python, и не просто поддерживает, его поддержка библиотек для ML шире чем в Zeppelin.
• развитие Zeppelin замедляется, он по сути проиграл Jupiter
• Jupiter — де-факто стандарт для исследователей данных, аналитиков нового поколения

Максим Цепков. Им нужен был не питон, а SQL. Их аналитики не знают питон, не знают R.

Ирина Гертовская. Чтобы не попасть в капкан — о влиянии нефункциональных требований на работоспособность системы

Пост на FB Ирина Гертовская. Чтобы не попасть в капкан — о влиянии нефункциональных требований на работоспособность системы. Очень правильное раскручивание нефункциональных требований от бизнес-сценариев использования системы. Банки: есть интерес, чтобы все транзакции с деньгами гарантировано попали в центральный журнал операций. Другая задача — управление производством непрерывного цикла, идет поток информации от датчиков, и тут потеря отдельного показателя может быть не критична. Зато важна бесперебойность системы 24*7, потому что оборудование работает без остановки. В то время, как в банках возможны технологические перерывы — ночью или в выходные и праздники. На пищевом предприятии может быть критичным полная и своевременная ежедневная отгрузка заказов ночью для доставки в магазины. Для такси — возможность для клиентов гарантированно заказать машину. И так далее.

Для нефункциональных требований есть множество моделей — FURS Роберта Грейди, модель качества Боэма, ISO 25010, Babok. И очень часто с ними работают по одной из этих моделей бездумно: берут атрибуты из модели и начинают выписывать требования. А правильный подход — совершенно иной, он должен быть основан на бизнес-сценариях и контекстах самой системы. А классификация — лишь фокусы внимания, которые мы держим в контексте конкретных сценариев. И сами составляем набор конкретных требований для своих проектов.

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

Ольга Шимкив. Как еще аналитик может помочь сдвинуть с места долгострой

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

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

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

Сергей Медведев. Оптимизация процесса подготовки тестовых данных (SOAP Редактор)

Пост на FB Сергей Медведев. Оптимизация процесса подготовки тестовых данных (SOAP Редактор). У них — аутсорсинг тестирования для госзаказчика. По SOAP идут документы в конвертах с запакованным (или шифрованным) содержимым, которое тоже в xml. На входе от заказчика была GUI-утилита от заказчика, которая умела запаковывать и распаковывать пакеты, и отдельные утилиты для их посылки и извлечения квитанций. В процессе ручного ввода тестировщик запросто мог ошибиться, об этом узнавали на выходе по xml-квитанции. Они сделали редактор, который позволял быстро компоновать пакеты из заготовленных документов, форматировать структуру документов, которая в исходном пакете часто представляет сплошной поток, выделять цветом интересные тестировщику части в большом документе, которые содержат изменяемые тестовые данные и так далее. Ну и еще забирать квитанции и цеплять их к тестам. В результате тестировщики работают с единственной утилитой и производительность возросла с 20 пакетов в день до 40 и более.

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

Andrey Pavlov. Не бойтесь смещать ваше тестирование

Пост на FB Andrey Pavlov. Не бойтесь смещать ваше тестирование. Смещать в названии — от shift left, на более ранние стадии, который год назад был «из каждого утюга». Впрочем, о подключении тестировщиков на ранних стадиях, в частности о тестировании требований слушал доклады и раньше. А в докладе было о том, что можно смещать тестирование вправо, на продакшн. Все курсы говорили, что так тестировать нельзя. Но на самом деле можно. Например, тестирование срочной фичи, для которой сложно сделать адекватное окружение, а при этом риски продакшена — в том, что тестировщик увидит реальные данные, а с 20 заказами возникнут проблемы, которые решит суппорт. Тогда это оправдано — при условии что заказчик понимает и принимает риски, решение — за ним.

И далее — последовательный рассказ о том, что на старте как раз тестирование на продакшн нового функционала — актуально. Потому что надо проверить основные идеи и быстро править. А уже по мере стабилизации продукта — смещать его влево, организуя процесс тестирования. Интересно, что Андрей — из Deutsche Telekom IT, от которого подсознательно ожидаешь как раз следованию процессов.

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

Комментарий Иван Гаммель: Интересно! У меня в инженерной команде «смещение» по факту означало расширение в обе стороны: QA сопровождают проекты от этапа feasibility до оценки успешности проекта после запуска. В быстрорастущей компании достаточно понимать риски и уметь принимать те, которые не сказываются на бизнес-показателях. Интересно, что при этом возникает проблема управления разновидностью технического долга — долгом в качестве: нашли баг в продакшне — хорошо, но когда его исправлять? Поиск багов пользователями в B2C, к сожалению или к счастью, коммерчески неоправдан, поэтому такое тестирование в нашем сегменте это задача команды UX Research, а не QA.

Кирилл Поляков. Автотесты на языке разметки или как мы тестируем микросервисы в Lamoda

Пост на FB Кирилл Поляков. Автотесты на языке разметки или как мы тестируем микросервисы в Lamoda. Интересная история. Хотели писать тесты на Go, а в результате написали библиотеку, чтобы писать сценарии на Yaml, а тестовые данные на Json, и вместе смешивать. Чтобы не было множества хелперов, которые бы каждая команда писала в своем стиле. На мой взгляд, это очень логичная конструкция, переход на декларативное описание для типовых конструкций — эффективен. Хотя из зала были вопросы о том, в чем, собственно, смысл замены Go на декларативное описания. Хотя Кирилл показывал это в обосновании своего решения.

Решение они сделали внутри, а потом выложили это в opensource, и этим пользуются. И даже появились фичи, сделанные сообществом. github.com/lamoda/gonkey И это вообще замечательно, когда не просто рассказывают о внутренних разработках, а делают их достоянием сообщества.

А в комментариях есть ссылка Nicola Ryzhikov: Мы похожую штуку сделали — https://github.com/Aidbox/stresty

Александр Александров. Проявления эффекта Даннинга-Крюгера в тестировании

Пост на FB Александров жжет! Не было бы тестировщиков — не было бы дефектов. В следующем проекте мы постараемся без них обойтись…

И продолжение, логический вывод: давайте за дефекты наказывать именно тестировщиков.

Ответственность тест-менеджера. Есть два критичных бага и 20 обычных, и менеджер проекта предлагает тест-менеджеру принять решение при том, выпускать ли проект — со штрафными санкциями. Его решение — не принимать решений о выпуске, ответственность несет PM и сейчас он явно пытается ее переложить, чтобы в случае чего был виновный.

Понятно, что тут много контекста, который зависит от культуры компании и Александр говорит о своем опыте.

Ситуация выпуска проекта с дефектами в уверенности, что заказчик не найдет. Нет. Во-первых, найдет, во-вторых будет уверен, что команде о них неизвестно и оценит профессионализм команды соответственно.

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

Идея очевидно не реализуемая. Потому что для нормального тестирования, все равно — автоматизированного или ручного, нужен тест-дизайн. А еще поиск дефектов — интеллектуальная деятельность. В том числе по поиску вокруг найденного дефекта. И ее тоже не исключишь.

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

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

И в заключении пара слов об авторе. Александр Александров, один из старейших российских тестировщиков. На FB и в соцсетях его нет. Это выступление будет опубликовано через некоторое время. А так на SQAdays он выступает много, есть записи прошлых лет https://sqadays.com/ru/profile/18107

Алексей Лянгузов. Качество данных

Пост на FB Алексей Лянгузов. Качество данных. Началось все с общекультурных примеров. С Колумба, который не только использовал неточные карты при планировании, но еще почему-то полагал, что они в английских милях, а не в арабских. Но ему повезло. Космонавтам Челленжера не повезло, они погибли. Проблемы с кольцами были известны 9 лет. Была большая статистика, по которой приняли решение о допустимости запуска. Но что важно — при анализе учитывали только запуски с инцидентами. В то время как по всей выборке запусков можно было бы ясно увидеть, что без инцидентов происходят запуски при температуре более 60F. А если ниже — инцидентов много. В день запуска температура была сильно ниже, то есть в опасной области.

Дальше был рассказ про конкретные типовые ошибки, методы измерения и способы работы. А в конце — примеры.

Типовые ошибки с данными:

• Пропущенные таблицы, колонки, строки. Например, забыли убрать limit в SQL
• Невалидные данные
• Неконсистентные данные
• Дубликаты
• Задержки в получении данных
• Данные не достоверны

И другие.

Характеристики качества, которые можно измерять.

• Accuracy — точность. В одной из соцсеток запоминали возраст на момент логина
• Validity — соответствие формальному синтаксису
• Timeliness — своевременность обновления
• Сompleteness — заполненность ключевых атрибутов
• Uniqueness — отсутствие дубликатов
• Consistency — консистентность

Обеспечение

• Категоризация данных — бизнес-правила
• Отслеживание данных
• Мониторинг
• Поиск аномалий
• Очистка данных

А еще — найденные ошибки необходимо исправлять!

Как внедрить мониторинг данных?

• Параллельный мониторинг данных — дополнительные job, которые следят по тем наборам.
• Встройка — в pipeline на передаче дополнительные узлы мониторинга с контролем и, возможно, исправлением. Особенно на входе
• Следующий ход — не просто мониторинг, а alerting с остановкой потока данных

Сравнение с образцом. Взаимодействие может быть push или pull. push — чаще. Сравнение имеет смысл только если есть доступ к источнику данных.

Примеры — практические, из интересного были аномалии с температурой — сбойные узкие пики вверх и вниз в течении часа. Алгоритмы опознают, хотя формальное правило сложно написать.

Сергей Мартыненко. Ключевые метрики тестирования

Пост на FB Сергей Мартыненко. Ключевые метрики тестирования. Проблема часто не в том, что метрик нет, а в том, что метрик слишком много. Сергей ссылается на Синдром стога сена Голдратта. Метрики — полезны, но часто не говорят стало лучше или хуже. Они про другое. А вот метрик, которые определяют лучше или хуже — их не может быть много.

Голдратт. Та самая цель. Метрики.

• Связанный капитал — незавершенка, кредитная нагрузка и так далее
• Скорость генерации дохода
• Операционные расходы (то, что фирма тратит, даже если ничего не делает)

Если перенести это на метрики тестирования, то получаем следующее.

• Уровень бездефектности. Найденные на тестировании на найденные всего. Слишком большой — не экономичен. Считать надо с весами по критичности — по Тагути, 1-4-9-16. 1-10 % для разных видов софта.
• Влияние на общее время поставки фичи. Если вы слишком долго ищите баги — вы медленнее поставляете фичи. Вы не можете найти все ошибки. Равновесие по Парето. Вы можете найти все баги, но при исправлении — вы вносите новые ошибки.
• Операционные расходы. Тестировщик ищет баг, а потом — вносит его в трекер и дальше поддерживает исправление. И часто это — одно из мест улучшения — поставить руку по быстрому занесению, и одинаковому. Как-то видел, что из-за непоставленной руки вносят дефект 30 минут. А еще важно вносить единообразно — чтобы видели дубликаты, и чтобы программисты единообразно работали с дефектами.

В ответах на вопросы Сергей вспомнил старую статью Дмитрия Ручко «Мифы автоматизации» — она актуальна и полезна, читайте!

Ольга Перевозкина. Как тестировать Accessibility и почему это касается каждого

Пост на FB Ольга Перевозкина. Как тестировать Accessibility и почему это касается каждого. Первая часть как раз объясняла почему это касается каждого. Потому что если не говорить про жесткие ситуации глухих или слепых, а держать в памяти отдельные дефекты, то, например, нарушение смешение красного с зеленым в цветовосприятии может привести к проблемам на интерфейсах, которые выделают ошибки подсветкой красным и только этим. Хотя остальным людям будет понятно. Есть проблемы больших разрешений, на которых буквы становятся слишком мелкими, при масштабировании может плыть верстка. У многих стоит переключение в ночную моду с уменьшением цветности. А ковид принес дистанционку и переезд на дачи, когда может быть необходима работа с экранами на ярком солнце работы в беззвучном режиме. Бывает, что недоступна мышка или доступна неполноценно. И так далее.

А дальше началась вторая часть — о том, что все это было продумано, есть стандарт WCAG, и его правила просто надо отработать. Для этого есть инструменты, которые позволяют проверить, насколько это сделано. При этом, хотя способов взаимодействия для людей с разными дефектами много, нет необходимости тестировать со всеми, достаточно проверять на одном из них. инструменты — скринридер, lighthouse и много других. И рассказ о том, как обеспечить соблюдение правил — правильная иерархия заголовков, именование всех компонент интерфейса и картинок, доступность с клавиатуры и так далее. Все вполне по делу.

Где я вижу логическую проблему — это доверие, что соблюдение этих гайдлайнов по accesibility в соответствии со стандартом действительно сделает приложение удобным для людей, работающих у экрана на ярком солнце, или для использования в пути, в шумном месте, с занятой одной рукой для мобильных приложений… Ближе к концу доклада Ольга сказала, что так и есть. Но примерами это было бы более очевидно и ясно.

В конце была ссылка на материалы для доклада http://a11y-sqadays.tilda.ws