Вступление
Прежде чем мы начнем, мы должны сообщить вам, что в этой статье мы не собираемся раскрывать конкретные подробности о методах тестирования, поскольку мы понимаем, что это много авторитетных источников в Интернете .
Для некоторых, когда они впервые слышат слово «QAOps», они могут подумать: «Другой (любой) термин Ops? Серьезно?»
Мы все согласны с тем, что качество программного обеспечения играет решающую роль практически во всех компаниях по всему миру, и, тем не менее, для многих этот факт каким-то образом полностью игнорируется и омрачается целью быстрой доставки контента и экономии средств за счет сокращения затрат.
Вам также может понравиться Руководство для начинающих Linode по Terraform .
Есть много компаний, у которых буквально ноль автоматических тестов, даже не требуемых (так и должно быть) модульных тестов. Это больше, чем просто хорошая практика, это хороший здравый смысл. Любая компания по доставке программного обеспечения должна беспокоиться о том, чтобы пытаться гарантировать хотя бы минимальное качество, мы знаем, что только производство — это производство, и практически невозможно предсказать / избежать всех возможных проблем, но, опять же, имеет смысл: разработчики приходят и уходят, программное обеспечение развивается, изменения в инфраструктуре, изменения в бизнесе … так почему бы не попытаться сохранить все работоспособным в течение всего жизненного цикла продукта? Программное обеспечение не просто зависает после продвижения в производственную среду, а наоборот.
В более продвинутом варианте использования представьте, что мы планируем автоматизировать наш приемочный тест с сотнями сценариев, потому что наши ручные циклы занимают слишком много времени. Вскоре вы понимаете, что необходимо подготовить и управлять целым стеком инфраструктуры только для поддержки среды, в которой будут выполняться наши тесты. Это займет время, и для большинства компаний инфраструктура управляется аутсорсинговой компанией, что может внести некоторые сложности в этот рецепт. Весь этот кошмар усугубляется, когда нам нужно поддерживать среду как можно более похожей с производственной, и нам нужно применять исправления безопасности и базовые уровни, обновления программного обеспечения, обслуживать центр обработки данных, и нам придется решать другие проблемы, которые существуют, потому что это так оно и есть, точка.
Внезапно эта среда перестает быть надежной, и выполнение тестов становится (опять же) узким местом. Неизбежное случается, вы (или ваш менеджер, или менеджер вашего менеджера — вы получаете очко) решаете пропустить этап тестирования, потому что вам нужно выполнить поставку, и вы не можете позволить себе, чтобы ваша команда (или чужая команда) была занята попытками выяснить, почему вещи больше не работают, как ожидалось. В этой истории есть еще один злодей: если вы выполняете свои рабочие нагрузки в облачном провайдере, вы в конечном итоге столкнетесь с тем, что эта среда стоит, и кто-то может решить сократить эту дополнительную плату, потому что не имеет смысла платить за то, что не ‘ ничего хорошего не принесет.
QAOps
Мы кратко поговорим о том, почему тесты так важны, теперь пришло время поговорить о QAOps. Но сначала просто напоминание о том, что является нашей главной целью:
Быстро и качественно поставлять программное обеспечение, чтобы иметь возможность реагировать на изменения в бизнесе, обеспечивая время выхода на рынок и большую рентабельность инвестиций для каждого цикла доставки.
QAOps является средством для этого. Речь идет о интеграции ваших этапов QA в ваш конвейер поставки, что обеспечивает непрерывное тестирование и обратную связь по качеству без разрыва между инженерами по тестированию, менеджерами конфигурации, командами инфраструктуры, разработчиками и менеджерами проектов. На самом деле, это больше о культуре, чем технологии. Вам необходимо установить правила и определить процессы, которые будут защищать ваше программное обеспечение и объединять все вместе, чтобы каждый мог наблюдать, учиться и вносить свой вклад.
Автоматизация тестов
Одним из таких процессов является автоматизация тестирования, от модульных тестов до приемочных тестов или более сложных случаев, таких как тесты на наличие уязвимостей и тесты производительности ( пирамида тестирования дает нам хороший обзор того, на что нам следует потратить время / деньги на тестирование).
К сожалению, одни только тесты не оказывают большого влияния на доставку программного обеспечения, но если они каким-то образом вставляются в процесс / конвейер доставки, мы можем извлечь огромную выгоду из этих инвестиций (да, автоматизация не простая задача, и она не бесплатна, но не забывайте слово вложение ).
Объединяя инфраструктуру как код, автоматизацию выполнения тестов, средства контроля качества для обеспечения желаемого уровня качества программного обеспечения, инструменты совместной работы для обеспечения быстрой обратной связи и хороший инструмент CI / CD для планирования и управления выполнением потоков, мы можем достичь наших желаемые цели. Инфраструктура теперь является неизменной, автоматизированной и полностью контролируемой, чтобы вы (или кто-либо другой) могли видеть, что происходит под капотом.
Не более: « Кто-то нарушил среду контроля качества»; просто уничтожь его и воссоздай все как хочешь. Не надо больше: «Я торопился и пропустил этот конкретный сценарий тестирования»; тесты автоматизированы, и у нас есть строгие правила покрытия, чтобы гарантировать это. Больше никаких сюрпризов с «CVE был найден в библиотеке, которая не обновлялась с JQuery 1.0.0…»; качественные ворота призваны не усложнять ситуацию, а постоянно улучшать наше программное обеспечение. Не более: «Мы не заметили, что среда QA не работала в течение 2 недель»; обратная связь будет гарантировать, что проблемы, ошибки тестирования и изменения будут доведены до сведения всех заинтересованных сторон. Мы потерпим неудачу, и мы должны сделать это быстро.
От мобильных тестов до SPA ( одностраничных приложений ) или даже настольных тестов, QAOps принесет пользу вашему программному обеспечению, позволив вам:
- Запускайте параллельные тесты, создавая столько сред, сколько вам нужно
- Экономьте деньги, не испытывая ненужную среду тестирования
- Расписание ночных длительных тестов
- Тест критических путей и общих ошибок
- Виртуализируйте свою среду
Конечно, это некоторые требования, и вам, вероятно, не понравится то, что вы собираетесь прочитать:
Ваша инфраструктура должна быть гибкой, и у вас не может быть IaC (Инфраструктура как код) без нее!
Таким образом, если вам потребуется две недели для установки нового хоста, выделенного для ESX, или 8 часов для установки пакета программного обеспечения, или 3 дня для создания виртуального сервера на балансировщике нагрузки F5, вы будете страдать, и эти барьеры не позволят вам сосредоточиться на том, что. это важно. Архитектура микросервисов, облачные провайдеры, такие как AWS, сервисы хранения (DynamoDB, Aurora, S3) и абстракция инфраструктуры (ECS, EKS, Fargate) позволят вам быть гибкими и декларативными (следовательно, под контролем источника ). Если у вас нет ни одного из этих элементов, возможно, попытка приблизиться к команде инфраструктуры поможет вам набрать скорость, уверенность и, самое главное, завоевать доверие ваших инструментов.
Технологический кирпич
Наличие последовательного набора технологий, отобранных и одобренных командой архитекторов, является ценным шагом для автоматизации и позволяет не тратить время на тупики. Говоря об инструментах тестирования, история одна и та же: вам нужно избегать привязки к поставщику, постарайтесь сохранить желаемый уровень абстракции, чтобы каждый мог воспользоваться вашим программным обеспечением, а вы могли развиваться без особой увязки, быть агностиком, когда это возможно и не изобретать велосипед.
Есть много проверенных в бою инструментов, которые следуют хорошим открытым стандартам с сильной поддержкой сообщества и официальной поддержкой (если это требование).
Некоторые из этих инструментов и их роли описаны на рисунке ниже:
Вот еще несколько примеров того, чего мы можем достичь с помощью простых, но мощных инструментов:
Для инфраструктуры тестирования Robot Framework — это отличный и гибкий инструмент тестирования, который может помочь нам поддерживать чистоту наших наборов тестов, повторно использовать блоки кода и сосредоточиться на нашем бизнесе.
Ниже приведен пример простого теста Windows Calculator, написанного на роботе :
питон
1
*** Settings***
2
Documentation Windows Calculator Acceptance Tests
3
Suite Setup Open Calc application
4
Suite Teardown Close Calc application
5
Library AutoItLibrary
6
Library Screenshot
7
*** Variables ***
9
${BASENAME} ${OUTPUTDIR}${/}screenshot
10
*** Test Cases ***
12
Arithmetic Tests
13
[Documentation] Tests math operations
14
Enter value "3"
15
Take Screenshot
16
Enter value "{+}"
17
Take Screenshot
18
Enter value "9"
19
Take Screenshot
20
Enter value "{ENTER}"
21
Take Screenshot
22
${result} = Get Result
23
Should Be Equal ${result.strip()} 12
24
Enter value "{ESC}"
25
Take Screenshot
26
${result} = Get Result
27
Should Be Equal ${result.strip()} 0
28
*** Keywords ***
30
Open Calc application
31
Run calc
32
WinWait Calculator
33
Enter value "${VALUE}"
35
Send ${VALUE}
36
Get Result
38
${result} = Win Get Text Calculator
39
[Return] ${result}
40
Close Calc application
42
WinClose Calculator
Похвальный отзыв - DataOps
Пожалуйста, не паникуйте, умные слова или нет, есть некоторые термины, которые помогают нам знать, что нам нужно сделать, чтобы достичь определенных целей, и DataOps является одним из них.
Надлежащая практика DataOps будет необходима (посредством автоматизации) для обеспечения наших сред хорошими, безопасными и надежными данными из производства, чтобы каждый (от исследователей данных до тестировщиков) мог ими воспользоваться.