[ Первоначально опубликовано на Techbeacon ]
В зависимости от того, где вы работаете, название работы инженера по обеспечению качества может охватить широкий спектр ролей и обязанностей. Вы готовы взять их всех?
Как инженер QA, я получил преимущество в создании своей роли по мере того, как я ухожу, добавляя обязанности и подотчетность за то, что, я считаю важными. До того, как я был нанят, QA в моей компании существовала исключительно в качестве роль тестера в конкретных проектах с высокими ставками. Там не было стабильных процессов QA, непрерывной интеграции/непрерывной доставки и очень мало владения, чтобы соответствовать моим обязанностям.
Из-за этого я закончил тем, что носил три шляпы в своей повседневной работе: тестер, инженер DevOps и архитектор. Я с готовностью взял на себя все три шляпы и узнал, как их носить, и как переключаться между ними — и вы тоже можете. Вот как!
Одной из моих основных обязанностей при ношении моей шляпы тестера является прием приемков для нескольких гибких команд. Во время проектов я рассматриваю каждый билет JIRA по критериям принятия, чтобы обеспечить его соответствие заявленным клиентским и бизнес -потребностям.
Частью приемлемого тестирования является исследовательское тестирование. Обычно я объединяю филиал функций в основную ветвь, поэтому я могу убедиться, что она интегрируется с существующим кодом и функциональностью без введения регрессий или ошибок.
Благодаря приемлемому тестированию вы должны сосредоточиться на опыте пользователя и администратора, который создает ваша команда. Это редко отражается в качестве явных критериев принятия, но это одна из самых важных частей тестирования.
Ваша цель должна заключаться в том, чтобы дать клиентам простой, интуитивно понятный опыт администратора. При рассмотрении функций попробуйте посмотреть на них с точки зрения клиентов — как человека, у которого, возможно, нет опыта обновления и поддержания веб -сайта или приложения. Что -то, что может быть очевидным для инженера, часто неясно или не интуитивно понятно для тех, кто действует в роли администратора сайта.
Общаться через сотрудничество
Когда я думаю, что билет нуждается в переделке, я стараюсь исследовать коренные причины для ошибки или регрессии или дать конкретную рекомендацию для улучшения. Я не хочу просто бросить его обратно на стену. Четкое, чуткое общение всегда играет роль, но особенно здесь.
Для обратной связи QA легко принять обратную связь, поэтому важно сделать ваши отзывы максимально совместными. Ваша цель — дать отзывы или просить изменения такая же, как и все остальные в команде: создать лучшую версию продукта. Убедитесь, что инженеры чувствуют себя комфортно, зная, что они работают с вами, и им не нужно будет ходить вокруг вас.
Создать подробные планы испытаний
Иногда у меня возникает ошибка или регрессия, которая требует более глубокого погружения. Когда это произойдет, я пишу формальный план тестирования, создаю и реализую тестовые случаи и сообщаю о своих выводах, с рекомендациями для улучшения. В зависимости от ситуации, я также тесно сотрудничаю с клиентами, чтобы убедиться, что они зациклены, и они понимают работу, которая выполняется, чтобы облегчить проблему для них.
Потратив время, чтобы подвести итог вашего процесса, когда он изучает, устранение неполадок и исправление этой функции позволяет вашему клиенту установить или восстановить доверие и уверенность в вашей команде. Вы не ожидаете, что инженеры бросят вам работу через стену, поэтому убедитесь, что вы принимаете то же самое со своими клиентами и включили их в итерации и планирование.
Построить основу качества
Потребность в укреплении этого доверия и уверенности является значительной частью того, почему я выступаю за практику QA. Включая эти практики на протяжении всего жизненного цикла разработки программного обеспечения, моя команда показывает клиентов, что мы серьезно относимся к качеству работы, обеспечивая на каждом этапе, которую мы производим, мы гордимся.
Когда вы показываете клиентам, что у вас есть приверженность качеству, вы заверяете всех-от инженеров до менеджеров по продуктам руководителям C-Suite-что у вас есть чеки, чтобы предотвратить и поймать ошибки или регрессии. Эти практики придают вам уверенность в том, чтобы доверять вашему коду и процессам, а также доверять продуктам, которые вы помогаете создавать.
Прежде чем прочитать о шляпе, вы должны понять, что такое DevOps. Есть много более длительных объяснений, но вот моя версия TL; DR: DevOps — это набор практик и процессов, используемых для содействия сотрудничеству между различными ролями для создания устойчивых методов для создания, развертывания и поддержания кода.
Давайте посмотрим, как это переводится на ваши обязанности, когда вы надеваете шляпу DevOps.
Настройка для непрерывной доставки
Впервые я надел шляпу DevOps, чтобы помочь нашим командам создать непрерывную доставку (CD), что было важным приоритетом для наших руководителей инженерного отдела. Мы запланировали рой, где некоторые из нас собрались вместе и настроили рабочий процесс компакт -диска для наших существующих репо.
В течение этого времени я также создал документацию для настройки и поддержания нашего процесса CD, что позволило другим людям добавить новый проект в процесс или устранение неполадок с относительной легкостью.
Когда вы несете ответственность за настройку CD, часть вашей ответственности состоит в том, чтобы гарантировать, что информация не залита. В дополнение к созданию основы для лучших практик CD, вам необходимо помочь своим инженерным группам успешно использовать их.
Документирование вашего рабочего процесса и процессов позволяет вашим командам делиться ответственностью за компакт -диск, но также гарантирует, что они не зависят от вас для выполнения задачи, которая может их блокировать.
Создать стандартизированный рабочий процесс разработки
Прежде чем я начал в качестве инженера QA, не было никакого формального рабочего процесса для шагов QA. Тестирование и обзоры кода были сделаны нечасто и не могли легко допустить полезные, действенные отзывы.
Чтобы решить это, я создал рабочий процесс для спринтерских досок в Джире, с столбцом для каждого статуса билета: выполнять, в процессе, QA, проверка кода, обзор владельца продукта, выполненные. Я провел дискуссии в команде о том, как использовать этот рабочий процесс изо дня в день, и мы установили процесс, когда перемещать билеты между столбцами.
Мы также интегрировали GitHub в Джиру. Это означает, что коммиты, обзоры и развертывания отражаются на каждом билете, поэтому каждый член команды может легко увидеть статус работы.
Вы не можете использовать Jira или GitHub, но принципы стандартизации рабочего процесса разработки все еще применяются. Важно убедиться, что все в вашей команде могут легко увидеть, в каком штате есть билет, и узнать, кто несет ответственность за работу во время каждого шага. Это общее понимание позволяет вашим инженерным командам работать более эффективно и эффективно и не позволяет им потерять время или энергию из -за дезорганизации и недопонимания вокруг работы.
Следуйте практикам и процессам, которые способствуют сотрудничеству и общению
Все эти процессы и инструменты были реализованы с учетом DevOps. Когда вы носите шляпу DevOps, ваши цели должны:
- Уменьшить накладные расходы и повысить понимание
- Сделайте это как можно проще для ваших команд создавать и поддерживать код
- Установить прозрачную ответственность и ответственность за работу Выполнено
Это вещи, которые инженеры QA постоянно пересматривают, отражают и итерации; Работа, которую вы вкладываете здесь, создаст прочную основу для начала.
Моя архитекторная шляпа немного новее, и я все еще чувствую себя комфортно с посадкой. Как и во многих моих обязанностях, эта роль развивалась из -за необходимости, которую я видел в проекте, и я решил посмотреть, смогу ли я помочь улучшить ситуацию.
Увидеть лес
Рассматриваемый проект страдал от отсутствия ясности в отношении общения и требований, а работа спринта создавала много FUD (страх, неопределенность и сомнения). Найдя свою шляпу архитектора, я отступил от вида спринта, чтобы получить более целостный обзор проекта, чтобы увидеть, как я могу помочь решить провод, который происходил.
Я просмотрел билеты на два спринта впереди, просматривая критерии принятия. Если критерии противоречили требованиям, которые изменились в предыдущей работе или казались неясными для установления ожиданий, я добавил комментарий к билету и отметил менеджера по продукту, чтобы уточнить и обновить критерии принятия.
Инженерам может быть легко ограничить свое зрение только работой перед ними, когда они сосредоточены на спринте. Когда вы носите шляпу архитектора, ваша цель состоит в том, чтобы напомнить им о целостном целостном взгляде на проект более высокого уровня-см. Лес, а также деревья.
Непрерывно заглядывая в будущее и подключая стадии работы, вы помогаете создавать и поддерживать общее понимание требований между клиентом, менеджером продукта и инженеров. Это общее понимание важно для успеха команды. Это уменьшает отток и переработку, предотвращая разочарование и потерю морального духа, возникающего в результате этого опыта.
Рекомендую и устранение инструментов
Я также рекомендую инструменты и тесты для инженерных команд, чтобы включить в проекты. Совсем недавно я работал с командой, чтобы создать набор сквозных тестов для проекта. Я сел с ними и сделал обзор инструмента, прошел их по локальной установке и написал несколько тестов, чтобы начать их.
Как архитектор, вы не можете просто отправить ссылку на инструмент и бросить работу по стене. Часть вашей ответственности состоит в том, чтобы помочь командам разработчиков программного обеспечения использовать инструменты, которые вы вставляете.
Один из лучших способов сотрудничества с инженерами — следить за процессом «Я делаю, мы делаем». Запланируйте встречу, на которой вы представляете инструмент, и убедитесь, что каждый может настроить его на местном уровне. Пропустите тест или два, затем поработайте с командой, чтобы сделать еще несколько, прежде чем они продолжат самостоятельно. Также полезно периодически проверять команду и выделять время, чтобы помочь удалить блокаторов или внести улучшения.
Улучшить опыт разработчика
С этими сквозными тестами, которые я упоминал выше, было четыре различных испытательных люкса. Эти тесты часто проводились во время проекта, и новые тесты постоянно добавлялись. По мере развития тестовых люксов команды по запуску тестов стали сложными и разочаровывающими. Чтобы помочь инженерам проще запустить тесты, я добавил в проект Makefile. Это взяло команду из чего -то вроде
codeceptjs run --config=./codecept.mobile.js --grep "site-functionality" --reporter mochawesome --reporter-options reportDir=./output,reportFilename=mobile-sf.html
к
make mobile-sf
Для процессов тестирования, которые мы используем более регулярно в разных проектах, я создал шаблоны для простой настройки. Теперь у нас есть шаблоны для тестирования визуальной регрессии, тестирования доступности и документации, которые могут быть быстро скопированы и настроены на новые проекты.
Инструменты тестирования и рамки являются частью инженерии, но, как правило, это не основная работа для инженера -программиста. Если инструменты, которые вы вкладываете, являются громоздкими или разочаровывающими, инженеры не будут их использовать.
Снижение барьера использования для ваших инженерных команд является важной частью роли архитектора.
Makefiles и Readmes — отличный способ сделать это. Вы также можете исследовать и попробовать инструменты, прежде чем внедрить их в проекте; Найдите блокировщиков и отсеивайте проблемные инструменты, прежде чем попросить инженеров использовать их. Это дает инженерам более позитивный опыт и позволяет вам разделить право собственности на соблюдение стандартов качества, облегчая им работу.
Нет особого определения того, что значит быть инженером QA. Обязанности различаются между компаниями и даже между командами в одной и той же организации. Однако, как правило, существует ряд испытателей, DevOps и архитекторов, которые охватывает любая роль QA.
QA является вспомогательной ролью, но определенно не является незначительной. Это создает основу, на которой могут строить инженеры и менеджеры по продуктам. Это включает в себя широкий спектр задач и обязанностей, от вашей команды до ваших клиентов.
Как инженер QA, вы облегчаете сотрудничество и убедитесь, что у каждого есть то, что им нужно, чтобы добиться успеха. Вы помогаете создать общее понимание работы, которую необходимо выполнить, и убедитесь, что процессы выполнены для ее завершения.
И когда вы переключаете шляпы, не забудьте дать себе время для связанных задач. Я обнаружил, что блокировка времени в моем календаре полезно для отслеживания переключения контекста, и я также использую цветовое кодирование, чтобы легко увидеть, какой тип работы я выполняю каждую неделю.
Когда вы внедряете инструменты тестирования или командную практику, будьте открыты для обратной связи и итерации. Все ваши шляпы должны носить с эмпатией; То, как вы выполняете свою работу, имеет значение в том, как ваши команды могут выполнять свою. Так что наденьте свою шляпу и приходите к работе!
Оригинал: «https://dev.to/angelariggs/the-3-hats-of-quality-assurance-engineers-2ll7»