Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Отправимся в прошлое, когда я впервые столкнулся с открытым исходным кодом ПО.

Моя первая встреча с открытым исходным кодом

Я начал программировать еще в старших классах. В 13 лет я был первокурсником старшей школы Парквилла, класс с углубленным изучением математики, науки и информатики, старый добрый Балтимор, штат Мэриленд (забавный факт: маскотами Парквилла были рыцари – knights – то есть моя фамилия). Все студенты этой спецпрограммы обязаны были иметь программируемый калькулятор TI-83 Plus. Подчеркиваю, это было давным-давно, смартфонов еще не существовало. Модным трендом были телефоны-раскладушки! TI-83 Plus был прорывной карманной технологией тех лет. Он был настолько продвинутым, что когда я его приобрел, то потратил пять минут только на то, чтобы разобраться, как его выключить!

Я быстро понял, что TI-83 Plus был просто замаскированным мини-компьютером. Знаете ли вы, что у этой штуки был полноценный встроенный язык программирования? TI-BASIC! В ходе первых двух недель моего первого курса "Введение в информатику" наш учитель объяснил нам, как программировать математические формулы: Кривую. Окружность круга. Площадь круга. Формулу корней квадратного уравнения. Не перечесть того, что я программировал, даже если это было за рамками домашнего задания. Это было чудесно! Это было для меня куда интереснее видеоигр, и поверьте мне, я был яростным поклонником Nintendo.

У TI-83 Plus была пара дополнительных функций, делающих его идеальным для программирования. Во-первых, у него был сетевой кабель, дающий возможность делиться программами. Два человека могли соединить свои калькуляторы и копировать программы с одного на другой. Само собой, с моими-то формулами я стал очень популярным, когда настало время для тестов. Во-вторых, любой мог открыть любой программный файл с калькулятора и прочитать его код. Исходный код TI-BASIC нельзя было спрятать. Он был по умолчанию "открытым".

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

С того мига, как я написал свой первый калькулятор, я знал, что хочу быть разработчиком. Я поймал эту искру.

Моя первая библиотека с открытым исходным кодом

Промотаем чуть вперед к колледжу. Я поступил на факультет информатики Рочестерского технологического института – вперед, Тигры! На первом курсе колледжа я выучил Java, C++, немного Python и, нежданно-негаданно, COBOL. Весь код всех моих проектов до этого момента был полностью написан мной. Иногда я использовал как руководство книжные примеры, но никогда не пользовался чужим кодом. Вообще-то, если профессор ловил нас на скопированном коде, задание было провалено с риском вылететь из школы.

Затем в ходе моего первого курса по разработке ПО мы научились писать юнит-тесты с использованием библиотеки JUnit. Мы загружали Junit откуда-то из сети – это было до расцвета Maven – и сцепляли его с нашим Java-путем. Затем мы писали тест-классы с методами тест-кейсов, и каким-то образом оно все магически запускалось, но как – я тогда понять не мог.

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

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

Источник

Это было полезным открытием. Спустя несколько лет после этого курса разработки ПО сайты для размещения проектов с открытым исходным кодом вроде GitHub стали очень популярными. Пакеты языков программирования вроде Maven, NuGet, PyPl и NPM стали опорой разработки. Расхожая шутка про Python – импортировать можно все! Это куда круче, чем обмениваться калькуляторными играми через кабель.

Мой первый шанс внести свой вклад

Когда я закончил колледж, то очень радел за ПО с открытым исходным кодом. Я верил в него. Я был его пылким поклонником. Но по большей части я потреблял. Как инженер-тестировщик (SDET), я пользовался многими распространенными тест-инструментами и фреймворками: JUnit, TestNG, Cucumber, NUnit, xUnit.net, SpecFlow, pytest, Jasmine, Mocha, Selenium WebDriver, RestSharp, Rest Assured – список можно продолжать до бесконечности. Как разработчик Python, я пользовался множеством модулей и фреймворков экосистемы Python, вроде Django, Flask и requests.

Затем я получил шанс отплатить добром за добро. Я запустил открытый проект - Boa Constrictor. Boa Constrictor – это .NET-реализация паттерна Screenplay. Он помогает лучше взаимодействовать, автоматизируя тесты. Из коробки он дает возможность для Web UI-взаимодействий на основе Selenium WebDriver, и Rest API-взаимодействий на основе RestSharp, но использовать его можно для внедрения каких угодно взаимодействий.

Я и моя компания выпустили Boa Constrictor публично в октябре 2020 года. Можете посмотреть на его репозиторий на GitHub. Исходно мы с командой в Q2 разработали весь код. Мы выпустили его, как проект с открытым исходным кодом, надеясь, что он поможет нашим коллегам по отрасли. Но затем случилось нечто потрясающее – коллеги начали помогать нам! Мы начали получать пулл-запросы для новых фич. По сути мы даже начали пользоваться новыми, разработанными сообществом взаимодействиями, внутри компании в нашем личном проекте автоматизации. Мы также с гордостью приняли участие в Hacktoberfest в 2020 и 2021 гг.

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

Борьба с плохим качеством

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

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

Вот ряд выразительных примеров:

• Репозитории ручных тест-кейсов полны тестов с шагами-дубликатами.
• Проекты тест-автоматизации переполнены дублирующимся кодом.
• Шаги настройки и очистки постоянно копируются и вставляются, неважно, нужны они или нет.
• Код автоматизации использует плохие практики – например, глобальные переменные вместо инъекции зависимости.
• Успех в 90% считается "хорошим" днем с "ограниченной" нестабильностью.
• Многие тесты покрывают глупые, бессмысленные или неважные вещи вместо значимых, полезных поведений.

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

Разработчик во мне отчаянно хочет решить эти проблемы. Но как? Я могу сделать это для своих проектов, но так как мои тесты заперты за дверями компании, я не могу воспользоваться ими, чтобы показать, как это масштабировать. Многие статьи и курсы о том, как что-то сделать, тоже полны игрушечных примеров.

Изменение нашей культуры качества

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

1. Помогли бы людям научиться тестировать.
2. Помогли бы им тестировать лучше.
3. Помогли бы им лучше поддерживать тесты.

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

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

Открытость через внутреннее сотрудничество

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

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

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

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

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

Мы практиковали сотрудничество Трех Товарищей в моей предыдущей компании, Q2. Мой друг Стив был разработчиком, понимающим ценность составления карт кейсов. Он многократно выбирал плохо сформулированные юзер-стори с противоречивой информацией или упущенными приемочными критериями. Иногда он тратил целый спринт только на то, чтобы разобраться, что происходит! Как только он узнал о составлении карт кейсов, он начал назначать получасовые сессии с остальными двумя Товарищами (одним из них был я), дабы лучше понимать юзер-стори с самого начала. У него все получилось. Благодаря проактивному сотрудничеству он мог безболезненнее разрабатывать стори. Как-то раз, помнится, мы перестали работать над стори, потому что не могли обосновать ее значимость для бизнеса, и это сберегло Стиву две недели бессмысленного труда. История на этом не закончилась: Стив стал инженером-тестировщиком! Он сдвинулся влево так далеко, что пересел на совершенно новую роль.

Открытость через живые спецификации

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

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

1. Стори становятся единицей работы.
2. Правила становятся приемочными критериями.
3. Примеры становятся тест-кейсами.
4. Вопросы становятся спайками или будущими стори.

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

К примеру, предположим, что нам нужно протестировать поисковик. Пример – поиск фразы, например, "панда". Этот пример можно записать как сценарий:

1. Если отображается страница поисковика,
2. Когда пользователь ищет фразу "панда",
3. Тогда страница результатов отображает список ссылок для "панды".

Этот особый формат "Если – Когда – Тогда" известен как язык Gherkin. Gherkin родом из инструментов разработки через поведение вроде Cucumber, но пригодится в любом типе тестирования. Gherkin определяет тестируемые поведения внятным образом, следуя паттерну "Настрой – Действуй – Проверь". Вы настраиваете систему, взаимодействуете с фичей, и проверяете результат.

Более того, Gherkin поощряет спецификацию на основе примеров. Этот сценарий дает внятные инструкции, как выполнять поиск. В нем реальные данные – поисковый запрос "панда", и четкие результаты. Использование реальных примеров в таких спецификациях помогает всем Трем Товарищам понять поведение досконально.

Поведенческие спецификации – многогранные артефакты:

1. Это требования, определяющие, как должна вести себя фича.
2. Это приемочные критерии, которым элемент должен соответствовать, чтобы считаться завершенным.
3. Это тест-кейсы с внятными инструкциями.
4. Они могут стать автоматизированными сценариями в подходящем тест-фреймворке.
5. Это живая документация продукта.

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

SpecFlow – один из лучших фреймворков, поддерживающих такую открытость со спецификациями на основе примеров и живой документацией. Это открытый фреймворк тест-автоматизации с открытым исходным кодом для .NET. В SpecFlow вы пишете кейсы как сценарии Gherkin, и автоматизируете каждый "Если – Когда – Тогда" шаг с использованием методов C#.

Однако одна из самых остроумных функций SpecFlow – это SpecFlow+ LivingDoc. Большинство тест-фреймворков концентрируются исключительно на коде автоматизации. Когда тест автоматизируется, то только программист может прочитать и понять его. Gherkin упрощает это, так как шаги написаны обычным языком, но сценарии Gherkin все равно хранятся в репозитории кода, который недоступен множеству членов команды. SpecFlow + LivingDoc ломает этот шаблон. Он превращает сценарии Gherkin в доступный для поиска сайт с документацией, доступный всем Трем Товарищам. Это делает кейсы и тест-автоматизацию куда более открытыми. LivingDoc также фиксирует результаты тестов для каждого сценария. Зеленые отметки ставятся на пройденных тестах, а красные кресты – на падениях.

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

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

Отчет SpecFlow+ LivingDoc

Такая радикальная прозрачность потребует неимоверных культурных перемен. Не каждой компании подойдет создание публичных информационных панелей, но при мудром применении они могут стать ключевым стратегическим фактором. К примеру, когда я работал в Q2, мы делились отчетами LivingDoc с отдельными заказчиками PrecisionLender после каждого двухнедельного релиза. Это помогало рождению доверия. К тому же отчеты LivingDoc включают лишь высокоуровневые спецификации поведения с простыми результатами, и даже вице-президент может их прочитать! Мы можем делиться тестами, не делясь кодом автотестов. Это было круто.

Открытость через открытый исходный код

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

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

Популярные проекты тест-автоматизации с открытым исходным кодом

Постоянно появляются и крутые новые проекты. Один из моих любимых, начатых в последние годы проектов – это Playwright, отличный инструмент браузерной автоматизации от Microsoft. Playwright делает end-to-end тестирование Web простым, надежными быстрым. Он поддерживает разные браузеры и языки, как Selenium, четкий синтаксис, как Cypress, и ряд продвинутых фич вроде автоматических ожиданий, трейсинга и генерации кода. К тому же Playwright в разы быстрее других аналогичных инструментов. Он взял все, что привело к успеху Selenium, Cypress и Puppeteer, и вывел это на новый уровень.

Открытость через общие тест-наборы

Пока что все подходы к открытому тестированию возможно реализовать немедленно. Возможно, многие из нас уже это делают, даже если не называют это "открытым тестированием". Но куда нас заведут эти идеи в будущем?

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

К примеру, подумайте о последнем заказе в интернет-магазине. Это может быть Amazon, Walmart, Target, что угодно. У абсолютно любого магазина есть виртуальная корзина. Когда вы хотите что-то купить, то добавляете это в корзину. Затем, когда шопинг завершен, вы переходите к оплате всех предметов в своей корзине. Если вы решили, что что-то вам более не нужно – удаляем из корзины. Легко и просто.

Описывая этот тип корзины, я не нуждаюсь в демонстрации скриншотов с сайта магазина, чтобы объяснить, как это работает. У вас такой огромный опыт интернет-шопинга, что вы интуитивно знаете, как с этим быть, вне зависимости от конкретного магазина. Черт, недавно я заказал ряд запчастей для старенького Volkswagen Beetle с сайта по имени JBugs, и корзина выглядела так же.

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

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

ИИ и машинное обучение помогут добиться действительно автономного тестирования

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

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

Как начать свой путь к открытости

Как мы обсудили, открытое тестирование может принимать разные формы:

1. Это может быть открытость к сотрудничеству, чтобы с самого начала добиваться наивысшего качества.
2. Это может быть открытость спецификаций на основе примеров и живой документации.
3. Это может быть открытость тестов и их результатов для заказчиков и пользователей.
4. Это может быть открытость инструментов, фреймворков и платформ.
5. Это может быть открытое создание общих тест-наборов для распространенных поведений.

Некоторые из этих идей могут показаться нереалистичными или амбициозными, но, честно говоря, я думаю, что каждая из них может серьезно повысить ценность тестирования. Думаю, каждый тестировщик и каждая команда должны, глядя на этот список, спросить себя "Можем ли мы это попробовать?" Возможно, ваша команда может делать первые шажки, улучшая сотрудничество или спецификации. Возможно, у вашей команды есть крутой внутренний проект, который можно выпустить как проект с открытым кодом, как мы с моей предыдущей командой сделали с Boa Constrictor. Возможно, существует идея стартапа, применяющего машинное обучение для автономного тестирования. Возможно, есть и не указанные тут способы добиться открытого тестирования. Кто знает? Может выйти круто!

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

Если вы хотите приступить к открытому тестированию, вот три вопроса для начала:

1. Как дела с вашим тестированием сейчас?
   • До какой степени оно уже открыто?
   • До какой степени оно закрыто?
2. Как можно улучшить ваше тестирование, открывая его постепенно?
   • Делаем первые шажки – маленькие улучшения, которые можно легко внедрить прямо сейчас.
   • Это может быть такая мелочь, как работа над составлением карт кейсов или участие в сессии группового программирования.
3. Как можно улучшить ваше тестирование при помощи радикальной открытости?
   • Идите ва-банк! Мечтайте смело! Будьте креативными!
   • В мире ПО возможно что угодно.

Заключение

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

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