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

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

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

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

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

Я расскажу, как у нас получилось оживить BDD, превратить Gherkin-сценарии в пользовательские истории и привлечь аналитиков к написанию автотестов.

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

Расскажу про процесс баг-менеджмента клиентских баг, а также их приоритизации в командах и процессами донесения информации по правкам багов до конечного клиента.

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

6 месяцев назад релиз монолита Dodo IS длился три дня. Каждый релиз был неприятной повинностью, которую приходилось выполнять командам. Разработчики старались как можно быстрее выпустить релиз и вернуться к разработке бизнес-задач. В результате конвейер поставки системно не улучшался, тесты чинились костылями, а время развертывания ухудшалось.

Я расскажу о практике «Stop the Line», которая помогла нам системно решить проблему развертывания. Всего за три месяца нам удалось полностью избавиться от ручного тестирования, исправить нестабильные тесты и ускорить развертывание более чем в 10 раз. Сегодня релизный цикл монолита — всего за 4-5 часов.

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

На самом деле это не мы такие плохие и ленивые, не хотим читать умных книжек по Domain Driven Design. При всём желании грамотно построить сервис на абстрактных Django или Rails очень тяжело. Инструменты как будто сопротивляются изменению привычных подходов "тяп-ляп и в production".

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

Примеры будут на dry-python. Но доклад не про python, а про ценные общие подходы, которые применимы к другим языкам программирования.

Любителям DDD, BDD, TDD и *DD быть обязательно!

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

Я расскажу, как видоизменяются общепринятые практики мониторинга при росте нагрузки приложения на примере проекта "Почта Mail.ru" - крупнейшего SPA рунета, а именно:

– почему preproduction тестирования становится недостаточно;
– как мы отслеживаем стабильность инициализации приложения и почему это важно;
– что такое "счётчик белых экранов", как мы его реализовали у себя в проекте и чем он помогает нам в мониторинге работы сервиса;
– как у нас устроен мониторинг клиентских ошибок;
– как мы анализируем характеристики быстродействия приложения.

It is a well known trend: software teams are becoming more distributed. Programmers work from home, communicate remotely, contribute via pull requests, and chat in Slack. How does it affect the quality of software? Can those distributed teams compete with co-located ones? Many managers think that it’s impossible, because real quality is achievable only when people know each other personally and have direct face-to-face contacts on a daily basis. How true is that? I will demonstrate that it’s not true and will illustrate my thoughts with practical examples.

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

Мы все тысячи раз слышали тезис "программисты должны писать качественный код". И все всегда кивают головами и соглашаются с ним. А меня никак не покидает вопрос: кому они должны?

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

Скажу даже больше: попросите определить слово "качество" группу людей – так они все переругаются. Может быть, даже подерутся.

А могут ли, вообще, программисты писать качественный код? Штука в том, что все мы – люди. Мы не можем писать качественный код. Он слишком сложен для нас. Мы будем стучаться головой о сложность, допускать ошибки проектирования, пропускать баги и наступать на одни грабли: просто потому, что можем.

Могут ли люди писать качественный код? Нет.
Должны ли они? Решать вам.
Есть ли способ повысить качество без регистрации и смс? Есть.

О нем – на докладе.

Мониторинг — это тоже тестирование?!

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

Бывает, что тестировать на тестовом окружении слишком дорого, но не тестировать и жертвовать качеством слишком рискованно. Как раз в таком случае хорошо бы иметь возможность БЕЗОПАСНО проверить новую версию на проде и сделать это можно, используя подход Canary Deployment.

В данном докладе я расскажу, как реализовать и как этим пользоваться на живых примерах.

Автор практики моб-программирования Вуди Зил так говорит о ней: "Замечательные люди, работающие над одной вещью в одно время, в одном пространстве, за одним компьютером".

Но как же быть с эффективностью? Ведь все эти люди могли бы сделать больше, работая параллельно? Или нет?

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

Когда у вас на проекте несколько десятков тысяч тестовых кейсов, а кейсы на разные уровни системы описаны в различных местах и зачастую дублируют друг друга, то их анализ и актуализация превращается в полный хаос и вызывает боль. Мы смогли побороть подобный хаос путём перехода к единой упорядоченной экосистеме. В этом нам помог Allure Server (не путать с Allure Report). В докладе я расскажу о нашем переходе к Test Cases as a code, как мы научились использовать все артефакты тестирования в качестве структурированной документации о нашем продукте и как такой подход помогает нам сделать пирамиду тестирования прозрачной на всех ее уровнях.

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

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

Для этого нужны метрики!

Метрики нужны, чтобы управлять проектом, видеть проблемы, исправлять их и добиваться новых целей! Это понимание приходит, только когда мы получаем пользу от той или иной метрики. А если не получаем, значит метрику можно смело выбросить!

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

В погоне за качеством эволюционно развивая тестирование компании, ее сотрудники в определенный момент сталкиваются с потребностью в автоматизированных тестах. Одними движет хайп на уровне "У всех есть, пусть и у нас будут! Зачем? Потом разберёмся!", другими — реальные потребности в сокращении временных затрат на ручное тестирование (вплоть до полного отказа от ручного тестирования), третьими — желание ускорить получение обратной связи о качестве продукта на разных этапах производственного цикла.

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

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

Внедряем customer-driven-подход к управлению качеством.

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

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

Расскажу, как мы внедряли такой подход, строили метрики, тестировали и дополняли их. С какими трудностями и ошибками столкнулись. Какие "основные" и "дополнительные" улучшения мы получили.

* Зачем нужно писать тесты на фронте.
* Какие виды тестов можно и нужно писать.
* Тестирование — это коллективная работа.
* Пирамида тестирования — это важно.
* Каким должно быть приложение, чтобы его можно было тестировать.
* И самое главное — чего НЕ нужно делать в тестах.

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

Мы разберём эти вопросы с экспертами из разных областей.

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

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

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