Привет, Хабр!
У нас новая важная тема — качественная разработка IT-продуктов. Мы часто говорим на HighLoad++, как сделать нагруженные сервисы быстрыми, а на Frontend Conf — классный пользовательский интерфейс, который не тормозит. У нас регулярно есть темы про тестирование, и DevOpsConf про объединение разных процессов, включая тестирование. А про то, что можно назвать качество в целом, и как над ним комплексно работать — нет.
Исправим это на QualityConf — будем развивать культуру думать о качестве конечного продукта для пользователя на каждой стадии разработки. Привычку не зацикливаться на своей зоне ответственности, и ассоциировать качество не только с тестировщиками.
Под катом поговорим с главой программного комитета, руководителем тестирования в Тинькофф.Бизнес, создателем русскоязычного QA-сообщества Анастасией Асеевой-Нгуен о состоянии отрасли QA и миссии новой конференции.
— Настя, привет. Расскажи, пожалуйста, о себе.
Анастасия: Я руковожу тестированием в банке, отвечаю за очень большую команду — нас больше 90 человек. У нас важная бизнес-линия, мы отвечаем за экосистему для юридических лиц.
Я училась на мехмате и изначально хотела стать программистом. Но когда у меня появилось интересное предложение, я решила попробовать себя в роли тестировщика. Как ни странно, это оказалось моим призванием. Сейчас всю свою работу я вижу именно в этой отрасли.
Для меня очевидно, что сообщество в этом направлении недостаточно зрелое, по крайней мере в России. Не всегда мы понимаем, что обеспечение качества — это не только сам факт тестирования приложения на соответствие требованиям. Мне бы хотелось изменить эту ситуацию.
— Ты употребляешь слова Quality Assurance и тестирование. В глазах обывателя эти два термина очень часто пересекаются. Чем они отличаются, если копать глубоко?
Анастасия: Скорее, не отличаются. Тестирование — часть дисциплины Quality Assurance, это непосредственная деятельность — сам факт того, что я что-то тестирую. Видов тестирования на самом деле очень много, и за разные виды тестирования отвечают самые разные люди. Но у нас в России, когда появилась волна аутсорсеров, которые поставляют тестировщиков в компании, тестирование свелось к единственному виду.
В большинстве случаев ограничиваются только функциональным тестированием: проверяют, что то, что накодили разработчики, соответствует спецификации и всё.
— Расскажи, пожалуйста, какие еще есть дисциплины обеспечения качества? Что еще, кроме тестирования, сюда входит?
Анастасия: Quality Assurance — это, в первую очередь, про создание качественного продукта. То есть мы задаемся вопросом, какими атрибутами качества должен обладать наш продукт. Соответственно, если мы это понимаем, то можем сопоставить, кто влияет на эти атрибуты качества. Не важно, разработчик, проджект-менеджер или продуктолог — это человек, который влияет на развитие продукта, на его бэклог, на его стратегию.
Тестировщик лучше начинает осознавать свою роль. Он понимает, что его задача не только тестировать на соответствие требованиям, но и тестировать требования, подвергать сомнению формулировки, которые исходят от продуктолога, вскрывать все неявные требования и ожидания клиента. Когда мы поставляем новую функциональность нашему клиенту, мы должны действительно удовлетворить его ожидания и решить его боль. Если мы будем думать обо всех атрибутах качества, клиент будет доволен и будет понимать, что компания, чьим продуктом он пользуется, действительно заботится о его интересах, а не работает по принципу «лишь бы выпустить фичу».
— Кажется, то, что ты сейчас описала, — это задача продуктолога. Это, в принципе, не про тестирование и не про качество — это вообще про product management, нет?
Анастасия: В том числе. Quality Assurance — это не дисциплина, за которую отвечает один конкретный человек. Сейчас есть популярное направление в тестировании, подход, который называется Agile Testing. В его определении прямо звучит, что это командный подход к тестированию, который включает в себя определенный набор практик. За реализацию этого подхода отвечает вся команда, даже не обязательно, чтобы в команде был тестировщик. Вся команда ориентирована на то, чтобы доставить ценность клиенту, и чтобы эта ценность соответствовала его ожиданиям.
— Получается, что качество пересекается чуть ли не со всеми окружающими дисциплинами, накладывая рамки на всё вокруг?
Анастасия: Верно. Когда мы задумываемся о том, что хотим создать качественный продукт, мы начинаем думать о различных атрибутах качества. Например, как проверить, что мы действительно сделали фичу, которая нужна нашему клиенту.
Тут всплывает такой вид тестирования, как UAT (user acceptance testing). К сожалению, в России он редко практикуется, но иногда присутствует в SCRUM-командах, как демо для конечного клиента. В зарубежных компаниях это достаточно распространенный вид тестирования. Перед тем, как открыть функциональность для всех клиентов, мы сначала делаем UAT, то есть приглашаем конечного потребителя, который проводит тестирование и сразу дает фидбэк — действительно ли продукт соответствует ожиданиям и решает боль. Только после этого происходит масштабирование на всех остальных клиентов.
То есть мы ориентируемся на бизнес, на конечного клиента, но при этом не забываем про технологию. От технологий тоже сильно зависит качество продукта. Если у нас будет плохая архитектура, мы не сможем быстро выпускать фичи и соответствовать ожиданиям клиента. Может быть много багов при попытке масштабировать, или при попытке сделать рефакторинг мы можем что-то сломать. Это все будет влиять на удовлетворённость клиента.
С этой точки зрения, архитектура должна быть такой, чтобы мы могли писать чистый код, который позволит быстро вносить изменения и не бояться, что мы все разломаем. Чтобы итерации доработки не растягивались на несколько месяцев просто потому, что у нас так много легаси, и нужно делать длительные этапы тестирования.
— Итого уже задействованы разработчики, архитекторы, продуктологи, продакт-менеджеры, сами тестировщики. Кто еще задействован в процессе обеспечения качества?
Анастасия: Теперь представим, что мы уже доставили клиенту фичу. Очевидно, за качеством продукта нужно следить, и когда он уже в продакшене. На этом этапе могут проявиться ситуации с неочевидными сценариями, так называемые баги.
Первый вопрос — как мы работаем с этими багами после того, как уже выпустили продукт? Как мы, например, реагируем на нагрузку? Клиент будет не очень доволен, если страница загружается больше 30 секунд.
Тут вступает в игру эксплуатация или, как сейчас называют, DevOps. По факту это люди, которые отвечают за эксплуатацию продукта, когда он уже на проде. Сюда входят различные виды мониторинга. Есть даже подвид тестирования — тестирование на проде, когда мы позволяем себе что-то не тестировать до выкатки и тестируем это сразу на проде. Это ряд мероприятий с точки зрения организации инфраструктуры, которые позволяют быстро отреагировать на инцидент, повлиять на него, исправить.
Инфраструктура тоже важна. Часто бывают ситуации, когда во время теста, невозможно удостовериться, что у нас действительно все то, что мы хотели бы дать клиенту. Выкатываем на прод — и начинаем ловить неочевидные ситуации. А все потому, что инфраструктура в тесте не соответствует инфраструктуре на проде. Отсюда вытекает новый вид тестирования — тестирование инфраструктуры. Это различные конфигурации, настройки, миграция баз данных и т.д.
Отсюда возникает вопрос — возможно, команде нужно использовать инфраструктуру как код.
Надеюсь, на конференции будет доклад с реальным кейсом. Напишите нам, если готовы на своем опыте рассказать, как инфраструктура как код влияет на качество. Инфраструктура как код позволяет проще проверять все настройки и тестировать то, что иначе просто невозможно. Поэтому в процесс разработки качественного продукта вовлекается и эксплуатация.
— А что насчет аналитики и документации?
Анастасия: Это относится больше к enterprise системам. Когда мы говорим про enterprise, сразу в голову приходят такие люди, как аналитики и системные аналитики. Иногда их называют техническими писателями. Они получают задание на написание спецификации и выполняют его, например, месяц.
Неоднократно доказано, что написание такой документации приводит в очень длительным итерациям разработки и длительным итерациям доработки, потому что в процессе тестирования выявляются баги, начинаются возвраты. В результате появляется очень много петель, которые увеличивают стоимость разработки. Кроме того, это может внести уязвимости. Мы вроде бы написали эталонный код, но потом внесли изменения, которые ломают идеально продуманную архитектуру.
В итоге получается не совсем качественный продукт, потому что в архитектуре уже появились заплатки, код в некоторых местах недостаточно покрыт тестами, потому что сроки поджимают, нужно быстрее закрыть все баги. А все потому, что в изначальной спецификации не были учтены все моменты, которые нужно реализовать.
Если бы мы изначально продумали спецификацию, в которой были бы освещены все необходимые моменты, то всё было бы реализовано именно так, как и нужно. Но это утопия.
Наверное, написать идеальную спецификацию на 100 страниц невозможно. Поэтому нужно задуматься об альтернативных способах написания документации, специфицирования, постановки задач, которые бы приближали нас к тому, чтобы разработчик делал именно то, что надо.
Тут в голову приходят подходы из Agile — пользовательские истории с acceptance критериями. Это больше применимо для команд, которые развиваются маленькими итерациями.
— Что на счет usability-тестирования, удобства использования продукта, дизайна?
Анастасия: Это очень важный момент, потому в команде есть дизайнеры. Чаще всего дизайнерами пользуются как сервисом — либо отдел дизайнеров, либо дизайнер на аутсорсе. Часто встречаются ситуации, что вроде бы дизайнер послушал продуктолога и сделал то, что понял. Но когда приступаем к итерации, выясняется, что на самом деле сделано не то, что ожидали: дизайнер что-то забыл, не до конца продумал поведение, потому что он не в команде и не в контексте, или фронтенд разработчик не до конца понял его макет. Может понадобиться несколько итераций только из-за того, что есть проблема с понимаем дизайна фронтенд-разработчиком.
Плюс есть еще одна проблема. Сейчас набирают популярность дизайн-системы. Они на хайпе, но выгода от них не совсем очевидна.
В итоге мы делаем не такую фичу, которую клиент хочет получить, а такую, какая удобна нам, потому что у нас уже есть определенные кубики, из которых мы можем ее сделать.
Мне кажется, на эту тему стоит обратить внимание и задуматься, действительно ли в попытке упростить работу над дизайном мы решаем клиентскую боль.
— Получается удивительно много тем, связанных Quality Assurance. В России есть конференция, на которой все их можно обсудить?
Анастасия: Есть самая старая конференция по тестированию, которая в этом году пройдет 25-й раз и так и называется — Конференция по обеспечению качества SQA Days. В основном на ней обсуждаются инструменты и конкретные подходы тестирования для функциональных тестировщиков. Как правило, в докладах на SQA Days глубоко рассматриваются конкретные области в зоне ответственности самих тестировщиков, но не комплексные мероприятия.
Это здорово помогает разобраться в различных инструментариях и подходах, как тестировать базы данных, API и т.д. Но при этом, с одной стороны, не мотивирует вовлекать в создание более качественного продукта не только тестирование. А с другой — тестировщики не становятся более вовлечены в процесс, чтобы думать о глобальной цели продукта и его бизнес-составляющей.
Я руковожу большим отделом, провожу много собеседований, которые на самом деле позволяют представить состояние отрасли в целом. Как правило, наши ребята работают в enterprise, и у них четкая зона ответственности. Коллеги, которые работают в зарубежных проектах, используют разные виды тестирования: сами могут делать нагрузочное тестирование, тестирование производительности, и даже иногда тестирование безопасности (security testing), потому что они действительно помогают команде обеспечивать продукт качеством.
Мне бы хотелось, чтобы у нас в России ребята тоже начали задумываться о том, что на функциональном тестировании отрасль не заканчивается.
— Для этого мы и организуем новую конференцию QualityConf, которая посвящена качеству, как целостной дисциплине. Расскажи про задумку подробнее, в чем основная цель конференции?
Анастасия: Мы хотим создать сообщество людей, заинтересованных делать качественные продукты. Предложить площадку, куда они смогут прийти, послушать доклады и выйти после конференции с конкретным пониманием, что нужно поменять у себя для улучшения качества.
Часто сейчас слышу запрос от консалтинга, что делать, когда есть проблемы с тестированием, с качеством. Когда начинаешь общаться с командами, видишь, что проблема не в самих тестировщиках, а в том, как выстроен процесс. Например, когда разработчики считают, что они ответственны только за написание кода, их ответственность заканчивается ровно в тот момент, когда они передали задачу в тестирование.
Не все задумываются о том, что плохо написанный некачественный код с плохой архитектурой грозит большими проблемами для проекта. Не задумываются о стоимости ошибок, о том, что баги, попавшие в продакшен, могут вылиться в большие издержки для компании и команды. Нет культуры думать об этом. Хочу, чтобы на конференции мы начали её распространять.
Я понимаю, что это не инновация.Эдвард Деминг, автор 14 постулатов качества, писал про стоимость ошибки еще в прошлом веке. На этой книге базируется Quality Assurance, как дисциплина, но, к сожалению, современная разработка, забывает про это.
— А темы непосредственно про тестирование и инструменты планируете затронуть?
Анастасия: Допускаю, что будут доклады про инструменты. Есть достаточно универсальные инструменты, с помощью которых компании и команды могут повлиять на продукт.
У нас точно не будет докладов про инструмент ради инструмента. Все доклады, которые попадут в программу, будут объединены общей целью.
— Кому будет интересно то, о чем ты говоришь, кого видишь в качестве гостей конференции?
Анастасия: У нас будут доклады для разработчиков, которым небезразлична судьба своего проекта, продукта, системы. Аналогично будет интересно тестировщикам и, как мне кажется, особенно менеджерам. Под менеджерами я имею в виду людей, которые принимают решение и могут влиять на судьбу и развитие продукта, системы, команды в том числе.
Это люди, которые задаются вопросом — как повысить качество продукта, системы. На нашей конференции они узнают про различные комплексы мероприятий и смогут понять, что у них сейчас не так, что нужно поменять.
Думаю, главный критерий — понимать, что с качеством что-то не так, и хотеть на это повлиять. Наверное, с первого раза достучаться до людей, которые считают, что и так сойдет, нам не удастся.
— Как ты думаешь, индустрия в целом созрела для того, чтобы поговорить не просто о тестировании, а о культуре качества?
Анастасия: Я считаю, что созрела. Сейчас многие компании отходят от традиционного Waterfall-подхода в сторону Agile. Идет ориентация на клиента, люди в командах действительно начинают задумываться о том, как создать качественный продукт. Даже в enterprise-компаниях происходит переориентация на повышение качества.
Судя по количеству запросов, которые возникают в сообществе, я считаю, что уже пора. Не уверена конечно, что это будет масштабная революция, но мне бы хотелось, чтобы этот переворот в сознании случился.
— Договорились! Будем прививать культуру и переворачивать сознание.
У нас новая важная тема — качественная разработка IT-продуктов. Мы часто говорим на HighLoad++, как сделать нагруженные сервисы быстрыми, а на Frontend Conf — классный пользовательский интерфейс, который не тормозит. У нас регулярно есть темы про тестирование, и DevOpsConf про объединение разных процессов, включая тестирование. А про то, что можно назвать качество в целом, и как над ним комплексно работать — нет.
Исправим это на QualityConf — будем развивать культуру думать о качестве конечного продукта для пользователя на каждой стадии разработки. Привычку не зацикливаться на своей зоне ответственности, и ассоциировать качество не только с тестировщиками.
Под катом поговорим с главой программного комитета, руководителем тестирования в Тинькофф.Бизнес, создателем русскоязычного QA-сообщества Анастасией Асеевой-Нгуен о состоянии отрасли QA и миссии новой конференции.
— Настя, привет. Расскажи, пожалуйста, о себе.
Анастасия: Я руковожу тестированием в банке, отвечаю за очень большую команду — нас больше 90 человек. У нас важная бизнес-линия, мы отвечаем за экосистему для юридических лиц.Я училась на мехмате и изначально хотела стать программистом. Но когда у меня появилось интересное предложение, я решила попробовать себя в роли тестировщика. Как ни странно, это оказалось моим призванием. Сейчас всю свою работу я вижу именно в этой отрасли.
Я ярый адепт дисциплины Quality Assurance. Мне небезразлично, какие продукты создаются, как относятся к качеству в компании, в команде и, в принципе, в процессе разработки.
Для меня очевидно, что сообщество в этом направлении недостаточно зрелое, по крайней мере в России. Не всегда мы понимаем, что обеспечение качества — это не только сам факт тестирования приложения на соответствие требованиям. Мне бы хотелось изменить эту ситуацию.
— Ты употребляешь слова Quality Assurance и тестирование. В глазах обывателя эти два термина очень часто пересекаются. Чем они отличаются, если копать глубоко?
Анастасия: Скорее, не отличаются. Тестирование — часть дисциплины Quality Assurance, это непосредственная деятельность — сам факт того, что я что-то тестирую. Видов тестирования на самом деле очень много, и за разные виды тестирования отвечают самые разные люди. Но у нас в России, когда появилась волна аутсорсеров, которые поставляют тестировщиков в компании, тестирование свелось к единственному виду.
В большинстве случаев ограничиваются только функциональным тестированием: проверяют, что то, что накодили разработчики, соответствует спецификации и всё.
— Расскажи, пожалуйста, какие еще есть дисциплины обеспечения качества? Что еще, кроме тестирования, сюда входит?
Анастасия: Quality Assurance — это, в первую очередь, про создание качественного продукта. То есть мы задаемся вопросом, какими атрибутами качества должен обладать наш продукт. Соответственно, если мы это понимаем, то можем сопоставить, кто влияет на эти атрибуты качества. Не важно, разработчик, проджект-менеджер или продуктолог — это человек, который влияет на развитие продукта, на его бэклог, на его стратегию.
Тестировщик лучше начинает осознавать свою роль. Он понимает, что его задача не только тестировать на соответствие требованиям, но и тестировать требования, подвергать сомнению формулировки, которые исходят от продуктолога, вскрывать все неявные требования и ожидания клиента. Когда мы поставляем новую функциональность нашему клиенту, мы должны действительно удовлетворить его ожидания и решить его боль. Если мы будем думать обо всех атрибутах качества, клиент будет доволен и будет понимать, что компания, чьим продуктом он пользуется, действительно заботится о его интересах, а не работает по принципу «лишь бы выпустить фичу».
— Кажется, то, что ты сейчас описала, — это задача продуктолога. Это, в принципе, не про тестирование и не про качество — это вообще про product management, нет?
Анастасия: В том числе. Quality Assurance — это не дисциплина, за которую отвечает один конкретный человек. Сейчас есть популярное направление в тестировании, подход, который называется Agile Testing. В его определении прямо звучит, что это командный подход к тестированию, который включает в себя определенный набор практик. За реализацию этого подхода отвечает вся команда, даже не обязательно, чтобы в команде был тестировщик. Вся команда ориентирована на то, чтобы доставить ценность клиенту, и чтобы эта ценность соответствовала его ожиданиям.
— Получается, что качество пересекается чуть ли не со всеми окружающими дисциплинами, накладывая рамки на всё вокруг?
Анастасия: Верно. Когда мы задумываемся о том, что хотим создать качественный продукт, мы начинаем думать о различных атрибутах качества. Например, как проверить, что мы действительно сделали фичу, которая нужна нашему клиенту.
Тут всплывает такой вид тестирования, как UAT (user acceptance testing). К сожалению, в России он редко практикуется, но иногда присутствует в SCRUM-командах, как демо для конечного клиента. В зарубежных компаниях это достаточно распространенный вид тестирования. Перед тем, как открыть функциональность для всех клиентов, мы сначала делаем UAT, то есть приглашаем конечного потребителя, который проводит тестирование и сразу дает фидбэк — действительно ли продукт соответствует ожиданиям и решает боль. Только после этого происходит масштабирование на всех остальных клиентов.
То есть мы ориентируемся на бизнес, на конечного клиента, но при этом не забываем про технологию. От технологий тоже сильно зависит качество продукта. Если у нас будет плохая архитектура, мы не сможем быстро выпускать фичи и соответствовать ожиданиям клиента. Может быть много багов при попытке масштабировать, или при попытке сделать рефакторинг мы можем что-то сломать. Это все будет влиять на удовлетворённость клиента.
С этой точки зрения, архитектура должна быть такой, чтобы мы могли писать чистый код, который позволит быстро вносить изменения и не бояться, что мы все разломаем. Чтобы итерации доработки не растягивались на несколько месяцев просто потому, что у нас так много легаси, и нужно делать длительные этапы тестирования.
— Итого уже задействованы разработчики, архитекторы, продуктологи, продакт-менеджеры, сами тестировщики. Кто еще задействован в процессе обеспечения качества?
Анастасия: Теперь представим, что мы уже доставили клиенту фичу. Очевидно, за качеством продукта нужно следить, и когда он уже в продакшене. На этом этапе могут проявиться ситуации с неочевидными сценариями, так называемые баги.
Первый вопрос — как мы работаем с этими багами после того, как уже выпустили продукт? Как мы, например, реагируем на нагрузку? Клиент будет не очень доволен, если страница загружается больше 30 секунд.
Тут вступает в игру эксплуатация или, как сейчас называют, DevOps. По факту это люди, которые отвечают за эксплуатацию продукта, когда он уже на проде. Сюда входят различные виды мониторинга. Есть даже подвид тестирования — тестирование на проде, когда мы позволяем себе что-то не тестировать до выкатки и тестируем это сразу на проде. Это ряд мероприятий с точки зрения организации инфраструктуры, которые позволяют быстро отреагировать на инцидент, повлиять на него, исправить.
Инфраструктура тоже важна. Часто бывают ситуации, когда во время теста, невозможно удостовериться, что у нас действительно все то, что мы хотели бы дать клиенту. Выкатываем на прод — и начинаем ловить неочевидные ситуации. А все потому, что инфраструктура в тесте не соответствует инфраструктуре на проде. Отсюда вытекает новый вид тестирования — тестирование инфраструктуры. Это различные конфигурации, настройки, миграция баз данных и т.д.
Отсюда возникает вопрос — возможно, команде нужно использовать инфраструктуру как код.
Я верю в то, что инфраструктура напрямую влияет на качество продукта.
Надеюсь, на конференции будет доклад с реальным кейсом. Напишите нам, если готовы на своем опыте рассказать, как инфраструктура как код влияет на качество. Инфраструктура как код позволяет проще проверять все настройки и тестировать то, что иначе просто невозможно. Поэтому в процесс разработки качественного продукта вовлекается и эксплуатация.
— А что насчет аналитики и документации?
Анастасия: Это относится больше к enterprise системам. Когда мы говорим про enterprise, сразу в голову приходят такие люди, как аналитики и системные аналитики. Иногда их называют техническими писателями. Они получают задание на написание спецификации и выполняют его, например, месяц.
Неоднократно доказано, что написание такой документации приводит в очень длительным итерациям разработки и длительным итерациям доработки, потому что в процессе тестирования выявляются баги, начинаются возвраты. В результате появляется очень много петель, которые увеличивают стоимость разработки. Кроме того, это может внести уязвимости. Мы вроде бы написали эталонный код, но потом внесли изменения, которые ломают идеально продуманную архитектуру.
В итоге получается не совсем качественный продукт, потому что в архитектуре уже появились заплатки, код в некоторых местах недостаточно покрыт тестами, потому что сроки поджимают, нужно быстрее закрыть все баги. А все потому, что в изначальной спецификации не были учтены все моменты, которые нужно реализовать.
Разработчики — не вредители и не пишут специально код с ошибками.
Если бы мы изначально продумали спецификацию, в которой были бы освещены все необходимые моменты, то всё было бы реализовано именно так, как и нужно. Но это утопия.
Наверное, написать идеальную спецификацию на 100 страниц невозможно. Поэтому нужно задуматься об альтернативных способах написания документации, специфицирования, постановки задач, которые бы приближали нас к тому, чтобы разработчик делал именно то, что надо.
Тут в голову приходят подходы из Agile — пользовательские истории с acceptance критериями. Это больше применимо для команд, которые развиваются маленькими итерациями.
— Что на счет usability-тестирования, удобства использования продукта, дизайна?
Анастасия: Это очень важный момент, потому в команде есть дизайнеры. Чаще всего дизайнерами пользуются как сервисом — либо отдел дизайнеров, либо дизайнер на аутсорсе. Часто встречаются ситуации, что вроде бы дизайнер послушал продуктолога и сделал то, что понял. Но когда приступаем к итерации, выясняется, что на самом деле сделано не то, что ожидали: дизайнер что-то забыл, не до конца продумал поведение, потому что он не в команде и не в контексте, или фронтенд разработчик не до конца понял его макет. Может понадобиться несколько итераций только из-за того, что есть проблема с понимаем дизайна фронтенд-разработчиком.
Плюс есть еще одна проблема. Сейчас набирают популярность дизайн-системы. Они на хайпе, но выгода от них не совсем очевидна.
Я сталкиваюсь с мнением, что дизайн-системы, с одной стороны, упрощают разработку, с другой стороны — накладывают очень много ограничений на интерфейс.
В итоге мы делаем не такую фичу, которую клиент хочет получить, а такую, какая удобна нам, потому что у нас уже есть определенные кубики, из которых мы можем ее сделать.
Мне кажется, на эту тему стоит обратить внимание и задуматься, действительно ли в попытке упростить работу над дизайном мы решаем клиентскую боль.
— Получается удивительно много тем, связанных Quality Assurance. В России есть конференция, на которой все их можно обсудить?
Анастасия: Есть самая старая конференция по тестированию, которая в этом году пройдет 25-й раз и так и называется — Конференция по обеспечению качества SQA Days. В основном на ней обсуждаются инструменты и конкретные подходы тестирования для функциональных тестировщиков. Как правило, в докладах на SQA Days глубоко рассматриваются конкретные области в зоне ответственности самих тестировщиков, но не комплексные мероприятия.
Это здорово помогает разобраться в различных инструментариях и подходах, как тестировать базы данных, API и т.д. Но при этом, с одной стороны, не мотивирует вовлекать в создание более качественного продукта не только тестирование. А с другой — тестировщики не становятся более вовлечены в процесс, чтобы думать о глобальной цели продукта и его бизнес-составляющей.
Я руковожу большим отделом, провожу много собеседований, которые на самом деле позволяют представить состояние отрасли в целом. Как правило, наши ребята работают в enterprise, и у них четкая зона ответственности. Коллеги, которые работают в зарубежных проектах, используют разные виды тестирования: сами могут делать нагрузочное тестирование, тестирование производительности, и даже иногда тестирование безопасности (security testing), потому что они действительно помогают команде обеспечивать продукт качеством.
Мне бы хотелось, чтобы у нас в России ребята тоже начали задумываться о том, что на функциональном тестировании отрасль не заканчивается.
— Для этого мы и организуем новую конференцию QualityConf, которая посвящена качеству, как целостной дисциплине. Расскажи про задумку подробнее, в чем основная цель конференции?
Анастасия: Мы хотим создать сообщество людей, заинтересованных делать качественные продукты. Предложить площадку, куда они смогут прийти, послушать доклады и выйти после конференции с конкретным пониманием, что нужно поменять у себя для улучшения качества.
Часто сейчас слышу запрос от консалтинга, что делать, когда есть проблемы с тестированием, с качеством. Когда начинаешь общаться с командами, видишь, что проблема не в самих тестировщиках, а в том, как выстроен процесс. Например, когда разработчики считают, что они ответственны только за написание кода, их ответственность заканчивается ровно в тот момент, когда они передали задачу в тестирование.
Не все задумываются о том, что плохо написанный некачественный код с плохой архитектурой грозит большими проблемами для проекта. Не задумываются о стоимости ошибок, о том, что баги, попавшие в продакшен, могут вылиться в большие издержки для компании и команды. Нет культуры думать об этом. Хочу, чтобы на конференции мы начали её распространять.
Я понимаю, что это не инновация.Эдвард Деминг, автор 14 постулатов качества, писал про стоимость ошибки еще в прошлом веке. На этой книге базируется Quality Assurance, как дисциплина, но, к сожалению, современная разработка, забывает про это.
— А темы непосредственно про тестирование и инструменты планируете затронуть?
Анастасия: Допускаю, что будут доклады про инструменты. Есть достаточно универсальные инструменты, с помощью которых компании и команды могут повлиять на продукт.
Все доклады глобально будут объединены одной общей миссией: донести до аудитории, что с помощью этого подхода, инструмента, метода, процесса, вида тестирования мы повлияли на качество продукта и улучшили жизнь клиента.
У нас точно не будет докладов про инструмент ради инструмента. Все доклады, которые попадут в программу, будут объединены общей целью.
— Кому будет интересно то, о чем ты говоришь, кого видишь в качестве гостей конференции?
Анастасия: У нас будут доклады для разработчиков, которым небезразлична судьба своего проекта, продукта, системы. Аналогично будет интересно тестировщикам и, как мне кажется, особенно менеджерам. Под менеджерами я имею в виду людей, которые принимают решение и могут влиять на судьбу и развитие продукта, системы, команды в том числе.
Это люди, которые задаются вопросом — как повысить качество продукта, системы. На нашей конференции они узнают про различные комплексы мероприятий и смогут понять, что у них сейчас не так, что нужно поменять.
Думаю, главный критерий — понимать, что с качеством что-то не так, и хотеть на это повлиять. Наверное, с первого раза достучаться до людей, которые считают, что и так сойдет, нам не удастся.
— Как ты думаешь, индустрия в целом созрела для того, чтобы поговорить не просто о тестировании, а о культуре качества?
Анастасия: Я считаю, что созрела. Сейчас многие компании отходят от традиционного Waterfall-подхода в сторону Agile. Идет ориентация на клиента, люди в командах действительно начинают задумываться о том, как создать качественный продукт. Даже в enterprise-компаниях происходит переориентация на повышение качества.
Судя по количеству запросов, которые возникают в сообществе, я считаю, что уже пора. Не уверена конечно, что это будет масштабная революция, но мне бы хотелось, чтобы этот переворот в сознании случился.
— Договорились! Будем прививать культуру и переворачивать сознание.
Конференция про качественную разработку IT-продуктов QualityConf состоится в Москве 7 июня. Знаете, из каких этапов складывается качественный продукт, в запасе есть кейсы успешной борьбы с багами на проде, на своей практике проверили популярные методики — нам нужен ваш опыт. Присылайте свои заявки до 1 мая, а Программный комитет поможет сфокусировать тему для общей целостности конференции.
Подключайтесь к чату, в котором обсуждаем вопросы качества и конференцию, подписывайтесь на Telegram-канал, чтобы быть в курсе новостей программы.
