Автор: Константинос Константакопулос (Konstantinos Konstantakopoulos)
Оригинал статьи
Перевод: Ольга Алифанова

Хорошие новости: вы уже системно мыслите!

Эта статья вдохновлена реальным опытом, повлиявшим на мой подход к тестированию ПО. Если вкратце, то ежедневная деятельность требует от вас размышлений о системах вне зависимости от того, подразумевает ли она «технологии». Как только вы осознаете, что уже мыслите системно, вы можете глубже погрузиться в понимание систем, тестированием которых занимаетесь на работе.

Приходилось ли вам в повседневной жизни:

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

Знаете, что? Вы уже мыслите системно! И эта способность очень пригодится вам как тестировщику. Но, возможно, вам нужно развить навыки и глубже практиковать это мышление.

Столкновение со «сломанной» системой: дверь моего гаража

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

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

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

Непрерывное улучшение системного мышления: гаражная дверь сломалась вновь

Естественно, через несколько месяцев дверь снова перестала работать. На этот раз она издавала сильнейший шум, что заставило меня подумать, что что-то сломано непоправимо. Уверенность, приобретенная мной в первый раз, накрылась медным тазом – как оно бывает, когда исправление кода перестает работать на проде.

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

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

Та же логика применима и к моему подходу к тестированию.

Практикуем системное мышление в тестировании ПО

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

Хороший старт: через знание продукта

Несколько лет назад я работал тестировщиком в стартапе, который вырос из команды в 50 человек до более чем тысячи сотрудников (Beat, в прошлом Taxibeat, сейчас часть FreeNow). По мере роста отдела разработки команды начали отвечать за определенные области, чтобы эффективно масштабироваться.

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

На заре своей карьеры тестировщика я в основном проводил приемочное пользовательское тестирование и функциональное тестирование. Для API-тестирования я пользовался Postman, а для веб- и мобильной UI-автоматизации использовал Selenium и Appium. Моим основным преимуществом было глубокое понимание продуктовой области, за тестирование которой я отличал.

Когда хорошего знания продукта недостаточно

Все шло хорошо, пока наша команда не забрала себе новую продуктовую область. Я внезапно растерялся.

Нам нужно было настроить продукт через новый микросервис, подключенный к другому сервису, который получал данные из отдела аналитики данных. Все это управлялось через монолитный бэкенд, соединенный со старой админ-панелью. Функциональность для конечного пользователя должна была быть доступной в мобильных приложениях под iOS и Android, как для пассажиров такси, так и для водителей. Меняя что-то в админ-панели, ты брал на себя риск сломать конфигурацию полностью, учитывая множественные точки интеграции.

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

Освоение глубокого понимания систем

Разбираемся в составных частях конфигурации системы

Я обсудил свое беспокойство с менеджером, и мы согласились, что ответственность за тестирование сама по себе - недостаточная гарантия. Мы решили, что я также должен «владеть» админ-панелью и областью конфигурации микросервисов, чтобы полностью разобраться в их работе.

Я потратил не один день, изучая настройки админ-панели и всю доступную документацию, а также сопоставляя конечные точки API с каждым сервисом. Я изучил, как команда аналитики данных отправляет информацию в микросервисы через события Kafka, и я настроил локальный брокер Kafka, подключенный к стейдж-окружению, чтобы разобраться в потоке сообщений.

Затем я сопоставил каждую настройку админ-панели с конечными точками, используемыми нашими мобильными приложениями. Это было непросто, потому что документация API админ-панели отсутствовала. Я также получил доступ к GitHub-репозиториям админ-панели, бэкенда и микросервисов, клонировал каждый репозиторий и запустил их локально, чтобы понять логику каждой настройки.

Создание образовательной траектории: исследование кода продукта

Поначалу я не чувствовал себя разработчиком, но мало-помалу это изменилось. Я начал изучать git и контроль версий, установил на ноутбук свои первые IDE и использовал текстовые редакторы вроде Sublime для открытия репозиториев и поиска кода. Я изучил конструктивные шаблоны, событийно-ориентированную архитектуру и микросервисы. Я также исследовал репозитории, написанные на PHP, JavaScript и Go, в то время как наши тесты были написаны на Java – то есть знакомился с различными концепциями и языками программирования.

Мой образ мыслей стал экспериментальным. Если я чего-то не понимал, я искал ответ в Интернете и консультировался с разработчиками команды. Я подписался на множество рассылок и блогов, читал экспертов тестирования, и ежедневно изучал концепции разработки. Этот нырок в мир разработки и работы систем стал для меня нормой. Теперь я знаю, что ежедневное обучение и сбор информации - это необходимость для тестировщиков и инженеров.

Налаживание регулярной практики системного мышления в тестировании

Сейчас я регулярно погружаюсь в системы, с которыми работаю. Я получаю доступ ко всем репозиториям, архитектурным диаграммам, документации API, диаграммам C4 и документам, описывающим бизнес-логику. Я стараюсь разобраться в процессе непрерывной интеграции и поставки (CI/CD) и том, как разворачиваются тест-окружения. Полноценное понимание тестируемой системы и поддерживающих систем вроде CI/CD позволяет мне эффективно тестировать, потому что я знаю их работу сверху донизу. Располагая этими знаниями, я могу понять, как приложение работает, выявить, куда относится баг, и, что самое важное, планировать тест-стратегию.

Моя практика системного мышления выражается в следующих действиях:

• Я убеждаюсь, что понимаю риски. Я знаю области, которые надо покрыть, когда меняется определенный аспект кода, а также уровни, которые тестируются и не тестируются.
• Я оцениваю тест-покрытие на низких уровнях, вроде интеграционных тестов в коде приложения.
• Я понимаю, внедряем мы end-to-end тесты в процесс деплоя или нет. End-to-end тест описывает бизнес-процесс или пользовательский путь, а это значит, что нам требуется полностью развернутая система.
• Я сопоставляю приемочные критерии и требования с тест-сценариями.

Как хорошо описано в книге Донеллы Медоуз «Азбука системного мышления»:

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

Тестировщик или инженер? Всем ролям нужно хорошее системное мышление

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

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

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

Хорошая тест-автоматизация зависит от дисциплинированного системного мышления

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

По мере развития вашего ПО систематическая поддержка тест-автоматизации критически важна для получения полезной обратной связи. Системное мышление дает вам навыки, необходимые для эффективного внедрения, поддержки и масштабирования кода ваших тестов. Вы с удовольствием погрузитесь в важные вопросы – например, зачем тестировать, что тестировать, как тестировать, и когда запускать тесты в вашем CI/CD процессе.

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

Заключение

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

Такая установка на выполнение, как и любопытное мышление, нацеленное на рост, может распространиться на все ваши команды. С его помощью вы перевоплотитесь в истинного инженера-тестировщика.

Обсудить в форуме