Современное тестирование - эволюция роли QA
Разработка программного обеспечения развивалась со времен водопада, Agile и теперь DevOps. Естественно, что тестирование как дисциплина также претерпела несколько серьезных изменений, чтобы приспособиться к новым способам работы и доставки программного обеспечения.
Однако до сих пор существует огромное недоразумение и неправильное восприятие роли тестировщиков и обеспечения качества в целом.
В этом посте мы рассмотрим, как развивалось тестирование, особенно за последнее десятилетие, и что нужно делать профессионалам QA, чтобы оставаться впереди всех.
Тестирование может быть только интереснее!
Хотя деятельность по тестированию программного обеспечения изменилась, чтобы адаптироваться к новым способам работы, я все еще вижу много устаревших взглядов на тестирование и роль QA.
Прискорбно видеть, что в ИТ-индустрии по-прежнему много людей, которые считают, что QA или тестировщики - это чистая прибыль. Тестировщиков часто считают просто функциональными тестировщиками, которые тестируют только после того, как разработчики завершили работу над функцией. «Обеспечение качества» воспринимается как тестирование, обнаружение ошибок и сообщение о них, а также разрешение на выпуск.
Что еще более беспокоит, так это то, что такое восприятие роли QA имеет первостепенное значение среди самих тестировщиков и профессионалов QA.
Традиционное тестирование программного обеспечения
Исторически сложилось так, что, играя ведущую роль на заключительных этапах водопадного проекта, тестирование прочно занимало правую часть жизненного цикла проекта. После предварительного определения требований тестировщики принимают эстафету от команды разработчиков в конце фазы разработки и запускают длинные подробные сценарии тестирования, часто вручную и обычно через разрозненные команды и группы малых и средних предприятий.
Сценарии тестирования были тщательно спланированы заранее, сценарии выполнялись специалистами, дефекты обнаруживались и составлялись отчеты, а циклы тестирования выполнялись и повторно выполнялись до тех пор, пока не были достигнуты заданные уровни качества.
В частности, всегда существовало четкое разделение между разработчиками и тестировщиками, без дублирования обязанностей или действий. Действительно, во время отдельной, ограниченной фазы тестирования действия были полностью сосредоточены на функциональной проверке программного обеспечения с основной целью обнаружения дефектов и сообщения о них.
Контроль качества в эпоху Agile
Появление гибких методологий и способов работы соединило деятельность по разработке и тестированию до такой степени, что тестирование программного обеспечения перестало быть отдельным этапом. Вместо этого тестирование стало неявной деятельностью во время кодирования и разработки программного обеспечения.
В некоторых случаях будет трудно увидеть различие между «тестировщиком» и «разработчиком», поскольку каждый из них будет иметь возможность беспрепятственно выполнять действия друг друга.
«Качество» перестало быть исключительной ответственностью тестировщиков и стало общей ответственностью всех, кто участвует в разработке и поставке продукта.
Наряду с этой эволюцией произошла смена обязанностей по тестированию влево от разработки, по сути, с самого начала.
Акцент сместился с поиска дефектов в встроенном программном обеспечении на предотвращение проникновения дефектов в программное обеспечение в первую очередь.
С общей целью - убедиться, что продукт или функция не только функциональны и соответствуют требованиям, но также соответствуют назначению и обеспечивают высокий уровень удовлетворенности пользователей.
Связанный:
Участие тестировщиков в доработке историй, экспертной проверке кода, модульном тестировании и таких практиках, как TDD, BDD и непрерывное тестирование, обеспечило первоочередное внимание к тестированию и качеству и было встроено в разработку.
Но несмотря на то, что Agile прошел долгий путь, чтобы объединить действия и практики разработки и тестирования, операционная группа все еще была разрозненной. Два направления работы (Dev & Ops) часто не знали о деятельности друг друга.
Если что-то пойдет не так на производстве, расследование займет много времени. Разработчики не имели представления о том, как их приложение будет работать в производственной среде в долгосрочной перспективе; не было прозрачности или ясности сотрудничества между двумя командами.
Добро пожаловать в DevOps
DevOps - это сотрудничество групп разработки и эксплуатации в области создания, доставки, обслуживания и поддержки программного обеспечения. Это относится к постоянному объединению ресурсов, процессов и самого продукта.
DevOps позволяет использовать методы непрерывной интеграции и предоставления ценности конечному пользователю.
Движение DevOps открыло новый взгляд на тестирование и открыло новые возможности для самих тестировщиков.
В эту новую эру тестировщики должны быть связаны как с разработкой, так и с эксплуатацией.
Задача тестирования больше не ограничивается продуктом, но также тестированием инфраструктуры, в которой продукт в конечном итоге выполняется.
Непрерывная интеграция (CI) и непрерывная доставка (CD) стали де-факто стандартом в разработке и поставке программного обеспечения, и поэтому большая часть усилий по тестированию теперь тратится на обеспечение конвейера CI / CD, сред и инфраструктуры.
Это позвоночник, который поддерживает как разработку, так и доставку.
Если пренебречь их тестированием, это может привести к нестабильной среде, потере больших усилий на расследование повторяющихся проблем с инфраструктурой и, в конечном итоге, к высокому риску для разработки и быстрой доставки.
Современное тестирование - разработка, ориентированная на качество
Несмотря на то, что многое было сделано для обеспечения качества на каждом этапе разработки, и, как следствие, тестирование имеет гораздо более широкий охват, я все же считаю, что QA тратят большую часть своего времени на поиск функциональных проблем и сосредоточение внимания на проверке программного обеспечения.
Большинство тестировщиков не осознают важность своей роли и влияние, которое они могут оказать на разработку и реализацию.
Несмотря на значительные сдвиги в практике разработки за последние десять лет, я чувствую, что тестировщики по-прежнему придерживаются старомодного взгляда на свою роль и, таким образом, остаются в старой эре тестирования.
Тестирование как профессия и роль тестировщика в течение некоторого времени подвергались критике с появлением «автоматизированного тестирования». И действительно, многие профессионалы отрасли по-прежнему считают, что роль тестировщика - просто тестировать созданное разработчиками приложение, причем все это можно автоматизировать.
Если разработчики лучше подходят и более сообразительны для написания кода, необходимого для автоматического тестирования, то зачем вообще нужен тестировщик в команде?
Пора изменить это восприятие. Мы должны признать разницу в ценности и навыках между «тестированием» и «гарантией качества», поскольку там, где тестирование представляет собой функциональную верификацию и валидацию программного обеспечения, обеспечение качества не является отдельным видом деятельности. QA - это серия процессов, включая тестирование и передовые методы, обеспечивающие предоставление пользователям качественного продукта.
Мы должны стремиться к разработке, основанной на качестве, и рассматривать профессию QA как центральную и ключевую функцию в разработке и поставке программного обеспечения, следовательно, Современное тестирование .
QA теперь является ключевым компонентом разработки от начала до конца, работая на протяжении всего процесса. И хотя обычно говорят, что каждый в команде доставки несет ответственность за поставку качественного продукта, я твердо верю, что обеспечение того, чтобы команда придерживалась методов обеспечения качества, является обязанностью QA.
Кто такой Modern QA
Там, где профессия тестировщика часто рассматривалась как путь доступа к разработке, управлению проектами или другим - обычно более прибыльным - дисциплинам, новый QA - это высококвалифицированная роль, требующая целостного знания практик разработки.
Это требует широкого понимания проблем практики кодирования, понимания методов и сред развертывания, а также стандартов, методов и проблем производительности и безопасности.
Это Т-образная роль с ресурсом, способным не только применять свои глубокие знания и опыт для выполнения своих основных задач, но и применять более широкие контекстные знания в архитектуре и разработке.
Находясь в центре любого проекта, современный QA должен хорошо разбираться в архитектуре, производительности, безопасности и облачных предложениях, быть технически надежным и иметь желание изучать новые технологии, чтобы оставаться в игре.
Примечание:Еще одна область, которая быстро становится очень популярной и необходимой для тестирования качества данных, тестирования больших данных, озер данных и хранилищ данных.Пришло время изменить восприятие роли QA и того, что делают тестировщики. Начать надо с самих тестировщиков. Отправной точкой является глубокая забота о качестве.
Тестировщики существуют не только для того, чтобы выполнять функциональное тестирование и сообщать об ошибках. Роль QA намного больше. Мы поставили проект на обеспечить качество практики .
Когда мы глубоко тестируем приложение, мы должны иметь глубокие знания обо всей работе системы, а не просто смотреть на приложение как на черный ящик.
Чтобы обладать этими глубокими знаниями, мы должны постоянно изучать новые технологии и способы работы и идти в ногу с ними. Самое главное, что QA должны быть адаптируемыми.
Когда QA понимает свою цель в проекте и начинает верить, что их роль является центральным элементом разработки и доставки программного обеспечения, когда мы принимаем современные принципы тестирования, только тогда мы можем изменить восприятие других.
Интересные статьи
