Я решил написать этот пост, потому что эта тема снова и снова появлялась во многих проектах, над которыми я работал во время разработки программного обеспечения. Это большое заблуждение, что автоматизация является основной причиной проблем в процессе QA. Тем не менее, я считаю, что для уточнения процесса окружающая культура должна быть благоприятной средой для ее роста и процветания.
В этой статье я подробно рассказал о нескольких инициативах, которые можно следовать и адаптироваться в соответствии с уровнем зрелости команды и автономией.
Общие жалобы:
«Нам просто нужна автоматизация, чтобы улучшить ситуацию», — «Автоматизация — это решение для нас», «просто создайте больше тестов пользовательского интерфейса».
Необходимые навыки качества
Итак, давайте начнем с какого-то саморефлексии:
Моя команда помогает, когда это необходимо?
Качество — общая ответственность?
Тестирование деятельности?
Если QA не болеет, знает ли команда, что делать?
Если ответ на любой из этих вопросов — нет, то, вероятно, культура не верна
Основываясь на этом, я расскажу о некоторых моментах, которые подчеркивают важность вовлечения каждого члена команды к качественной деятельности.
Культура
Если вы ранее сталкивались с этим разговором, вы, вероятно, также слышали, как люди говорили, что этот «сломанный процесс» вызван культурой компании; что нормально. Но почему нет инициативы, чтобы изменить это? Или почему какие -либо предыдущие попытки решить какие -либо проблемы не удались?
Иногда легче продолжать идти, не пытаясь улучшить.
Учитывая вопросы с начала этой статьи. В этих вопросах я выделил некоторые общие проблемы, которые могут вызвать проблемы в вашей компании/проекте:
QA как привратник качества.
Команда не понимает, что делает QA в спринте (я знаю, это почти 2020 год!).
Команда признает QA как задача задачи и не считает их человеком, который является частью процесса, который также предоставляет решения.
Отсутствие понимания того, что обеспечение качества является фазой в цикле разработки.
Изменение мышления
Изменение мышления людей может быть самой большой проблемой. Вы должны научиться справляться с различными ситуациями и как подходить к людям с разнообразным опытом и характеристиками. Я прочитал эту книгу, которую я, вероятно, уже порекомендовал вам, если мы поговорили лицом к лицу, называемой «Agile Testing» Лизы Криспин и Джанет Грегори. Опубликовано в 2008 году, я бы считал это «Библией» для тестировщиков сегодняшнего дня. Меня удивляет, что есть много профессионалов, которые никогда не слышали об этой книге или даже знают, что означает гибкое тестирование.
Эта книга откроет окно разнообразных возможностей в гибком процессе.
Ниже я обрисовал несколько небольших изменений, которые вы могли бы построить.
Начните спрашивать себя, показал ли я своей команде, что такое качество?
Иногда ваша команда или менеджер не понимают, что связано с QA, и что вы на самом деле вносите вклад в каждый спринт. Наша ответственность, как QAS, — четко изложить и определить, что мы делаем. Чтобы рассмотреть это, вы можете организовать небольшие сессии, чтобы обсудить, что вы делали, и как вы можете помочь команде достичь святого Грааля качества.
Проводятся ли ваши тесты в конце процесса?
Это повсеместно, когда тесты все еще являются фазой в процессе: в традиционном мышлении тесты происходят только в конце цикла. Вы не должны тестировать в конце, и вы должны приносить проверку качества как можно раньше; Сделав это, ваши цели также изменится. Вместо того, чтобы играть в догоняние с ошибками, вы не допустите их даже происходить.
Некоторые примеры могут быть:
Предлагаемые мероприятия
Общая ответственность
Общая ответственность должна быть тем, к чему вы стремитесь, поскольку вы не должны быть единственной, которая заботится о качестве. Иногда это может быть проблемой, так как это может потребовать первоначального сдвига в мышлении и мышлении от вас и вашей команды. Как только все будут на одной странице, общая ответственность может начать стать реальностью.
Вот список предложений, основанных на моих предыдущих экспериментах/опыте:
Общая ответственность не означает, что вы потеряете свою работу. Это означает, что у вас будет больше времени, чтобы исследовать вещи, которые имеют значение, вместо того, чтобы застрять, выполняя скучные тестовые вещи.
Ваша команда должна рассматривать вас как важную часть процесса, другими словами, вы должны быть тем, кто будет стремиться к тестированию знаний.
Организуйте предварительные сеансы с командой, чтобы помочь им создать сочувствие и узнать больше о том, как работает продукт и как он выглядит.
В целом, мы склонны работать на маленьких кусочках продукта, и у нас нет видения общей картины, что не очень хорошо, если мы хотим на первое место.
Вы больше не пытаетесь найти ошибки, вы пытаетесь предотвратить их.
Да, это звучит немного странно … но вы привыкаете к этому;)
Мы больше не единственный и единственный человек, обеспокоенный качеством, так почему мы все еще должны ловить ошибки, а не предотвращать их?
Может быть, это не похоже на нашу работу, но во время переработки встреч важно попытаться убедиться, что все находятся на одной странице. Исходя из моего опыта, разговоры с обратными и отделами происходят во время разработки, когда существует недоразумение того, каким должен быть конечный результат функции.
Можно помочь несколько вопросов Simples, например:
Все на одной странице?
Есть ли у нас какие -либо опасения относительно того, как должна работать функция?
Мы чувствуем себя комфортно с критериями принятия?
Инженер -тест, задающий эти вопросы, может звучать немного странно, верно? Но, как я уже говорил, общая ответственность не только связана с качеством; Это все!
Но Веллингтон, с чего мне начать?
Начните с одного человека. Вам нужно привыкнуть к этому способу работы, прежде чем распространять его до остальной части команды. Преимущество того, чтобы сделать это таким образом, это то, что вы развиваете мастерство, и гораздо более вероятно, что этот человек будет вашим союзником в продаже его остальной части команды.
Будьте проактивны и тестируются в начале процесса. Проверьте филиалы, над которыми работают ваши товарищи по команде, и выполняют некоторые проверки.
Не ждите, пока разработчики разместят историю в «Готово для QA» (или какой -либо тип процесса, который вы используете).
Выполните предварительное тестирование вместо утомительного ручного тестирования сценариев.
Вы должны помнить, что серебряной пули нет, и вы должны адаптироваться к различным контекстам и постепенно вносить небольшие изменения. Вскоре вы поймете эффективность пошаговых дел, а не делать все сразу.
Чтобы сделать это правильно, у вас должны быть союзники, последователи, верующие, не только исполнители.
Автоматизация
На этом этапе вам следует удивляться, почему автоматизация не первая тема этой статьи. Позвольте мне объяснить причину.
Автоматизация является вершиной айсберга; Если у вас нет хорошей культуры или даже у вас нет людей, чтобы поддержать вас, будет трудно сделать что -то.
Вы должны тщательно выбирать структуру автоматизации и провести исследование, чтобы понять, что вам и вашей команде подходит.
Что вы должны рассмотреть?
Если структура непрерывно поддерживается и обновляется
Если это соответствует вашим потребностям
Если вы работаете с Backend, не имеет смысла создавать отдельный тестовый проект, он создаст только стену между вами и инженерами.
Рассмотрите возможность использования того же языка программирования, который команда использует для создания тестов; Это удалит разрыв в знаниях и снизит стоимость технического обслуживания.
На Mobile у вас есть разные варианты, используя фреймворки Blackbox, такие как Appium, Robot или даже Frameworks Whitebox, такие как Espresso, Earlgrey, Xctest. Тщательно выберите, и не будьте слишком взволнованы, иначе вы перегружаете слой пользовательского интерфейса тоннами тестов; Вы должны разделить эти проверки. Там может быть целый пост, посвященный этой теме.
Если вы думаете об использовании каких -либо фреймворков BDD для написания ваших спецификаций, проверяйте ее в первую очередь со своей командой. Это имеет огромное преимущество, но только если вся команда продается с этой идеей и помогает сделать это совместно.
Вы должны быть в состоянии написать полезные модульные тесты и помочь команде разработать их, если это необходимо. Помните качество по охвату, узнайте о тестах на мутацию и изучите его с вашей командой; Вы можете быть удивлены тем, сколько «Assert True» вы можете найти.
Непрерывная интеграция
Я мог бы сказать основы здесь. Не поймите меня неправильно, но автоматизация не имеет значения, если она не работает на CI в соответствии с хорошей стратегией. Он должен работать быстро и обеспечивать обратную связь на каждом этапе интеграции. Изучите параллельное выполнение, рассмотрите возможность разделения ваших люксов на более мелкие, чтобы вы могли иметь больше контроля над каждым выполнением теста.
Составление отчетов
Вы также должны найти способ дать видимость тому, что вы делаете. Правильное направление для этого — использовать вашу структуру автоматизации, чтобы предоставить это для вас. В значительной степени у всех инструментов автоматизации есть способ генерировать отчеты. Большинство из них следуют шаблону JUNIT, который легко проанализировать и отображать его на большом мониторе с помощью приборной панели.
Вынос
Люди над процессом автоматизации.
Начните с малого, получите поддержку и станьте больше.
Качество не только автоматизация.
Вместо того, чтобы выбирать инструменты, которые заставляют вас работать, выбирайте инструменты, которые работают для вас.
Ваша работа — убедиться, что все знают, насколько вы важны; Убедительность качества всегда была ролью, которую люди не до конца понимают.
Я надеюсь, что этот пост поможет вам внести некоторые улучшения в вашей команде или, по крайней мере, выступает в качестве катализатора, который вызывает изменения.
Хорошие справочники.
Гибкие тестирование и более гибкая спецификация тестирования по примеру непрерывной доставки
Оригинал: «https://dev.to/assertqa/before-starting-automation-you-should-change-your-mindset-562g»