Читать книгу: «QA Engineer», страница 7
6.2.8. Kanban
Kanban – это гибкая методология управления проектами, основанная на эффективном и прозрачном контроле потоков работы. Для этого в основе методологии используют Kanban–доску, как визуализацию стадий реализации задач. Kanban делает упор на оптимизации производительности команды, когда не требуются радикальные изменения в процессах.
Особенности:
– Визуализация работы – с помощью Kanban–доски легко отследить фазы разработки по каждой задаче и понять прогресс команды.
– Ограничение параллельной работы – методология устанавливает ограничения на количество задач, которые могут выполнять члены команды одновременно в каждой фазе процесса, что предотвращает перегрузку и ускоряет выполнение работы.
– Гибкость – позволяется вносить изменения в процессе разработки.
– Непрерывное улучшение – регулярный анализ и оценка потока работы позволяет его улучшить.
Преимущества:
– Улучшение прозрачности – любой участник команды легко видит статусы всех задач и понимает общее состояние проекта.
– Более быстрая доставка – ограничение количества задач в работе помогает сократить время разработки и быстрее доставлять результаты.
– Гибкость в планировании – задачи можно легко переприоритезировть в соответствии с изменяющимися требованиями.
– Уменьшение потерь – методология сфокусирована на сокращении любых потерь. Как следствие продукт непрерывно поставляют пользователю и минимизируют время любых простоев в команде.
Недостатки:
– Зависимость от самодисциплины команды – методология эффективна только если четко соблюдають ее правила, что зависит исключительно от дисциплины участников команды.
– Может потребоваться время на адаптацию – работа в этой методологии предполагает бесконечный поток задач, что отличается от подходов, использующих итерации при разработке продукта.
– Не всегда идеально подходит для сложных проектов – в случае, когда между задачами есть большое количество зависимостей, методология может оказаться недостаточно структурированной.
У Kanban нет этапов, но есть процесс работы:
– Определение рабочего процесса – команда определяет колонки для своей доски Kanban, отражающие этапы рабочего процесса.
– Настройка WIP–лимитов – для каждой фазы рабочего процесса устанавливают ограничения на количество задач, которые могут быть в ней одновременно.
– Работа с доской Kanban – задачи добавляют на доску в виде карточек и перемещают между колонками в соответствии с их выполнением.
– Мониторинг и оптимизация – команда регулярно анализирует поток работы и производительность процесса, оптимизируя его для достижения лучших результатов.
6.2.9. Lean Software Development
Lean Software Development – это методология, в которой делают акцент на максимизации ценности для клиента при минимизации затрат, любых активностей, не добавляющих ценности продукту, улучшении потока работы и поощрении инноваций. Методология предназначена для создания высококачественного программного обеспечения с максимальной эффективностью при сокращении отходов и повышении удовлетворенности клиента.
Особенности:
– Устранение отходов – идентификация и удаление всего, что не добавляет ценности продукту. Например избыточные функции, ненужные встречи, сложные процессы.
– Увеличение скорости и эффективности – непрерывное улучшение процессов для снижения затрат и ускорения разработки.
– Раннее решение проблем – поощряется раннее выявление проблем для их решения и предотвращения повторения.
– Гибкость и адаптация к изменениям – поощряются изменения требований для того, чтобы повысить ценность для клиента.
– Решения, основанные на знаниях – решения принимают, основываясь не на предпочтениях или предположениях, а на глубоком понимании задачи и контекста.
Преимущества:
– Уменьшение цикла разработки – благодаря устранению отходов и оптимизации процессов, доставка конечного продукта происходит быстрей.
– Повышение качества продукта – уделяется внимание качеству и раннему обнаружению ошибок, что предотвращает их накопление.
– Повышение удовлетворенности клиента – достигается за счет фокуса на гибкости к изменениям требований и создании ценности для клиента.
– Инновационность – среда способствует созданию и внедрению инноваций, благодаря экспериментам и устранениям страхов.
Недостатки:
– Сложность внедрения – трансформация команд может потребовать значительных изменений в корпоративной культуре и рабочих процессах.
– Риск сокращения слишком многих процессов – может оказаться так, что будет устранено что–то важное, например документация, что впоследствии приведёт к потере важной информации и знаний.
– Зависимость от команды – все участники команды должны быть хорошо самоорганизованы и вовлечены в процесс.
У Lean Software Development нет этапов, но есть аспекты процесса работы:
– Определение ценности для клиента – создается понимание того, что является ценным для клиента, чтобы сосредоточить усилия на этом.
– Идентификация потока – анализ процессов разработки с целью выявить и устранить препятствия в потоке работы.
– Создание потока – изменение процессов и работы так, чтобы обеспечить плавный и непрерывный поток создания ценностей.
– Установление Pull–системы – чтобы избежать перегрузки и накопления незавершенной работы, её начинают только тогда, когда есть спрос.
– Непрерывное улучшение – постоянный поиск возможностей для улучшения процессов, чтобы повысить эффективность работы команды.
6.2.10. Dynamic Systems Development Method
Dynamic Systems Development Method – гибкий фреймворк для быстрой разработки программного обеспечения. Его особенность заключается в строгом соблюдении временных рамок и бюджета при сохранении гибкости к изменениям и возможности адаптации во время выполнения всего проекта.
Особенности:
– Фиксированные временные рамки и бюджет – соблюдение сроков и бюджета являются приоритетными пунктами, а меняющиеся требования адаптируют под эти ограничения.
– Активное участие пользователя – чтобы результат работы оставался релевантным и ценным, требуется постоянное участие конечного пользователя.
– Доставка функционирующего продукта – результатом каждой итерации является работающее программное обеспечение, готовое к реальному использованию.
– Итеративно–инкрементальный подход – позволяет регулярно уточнять и адаптировать требования, благодаря разбиению на итерации для доставки инкремента.
Преимущества:
– Гарантированное соблюдение сроков и бюджета – осуществляется за счет четкого планирования и приоритезации работ.
– Высокая вовлеченность клиента – означает, что разрабатываемое решение будет максимально соответствовать потребностям бизнеса.
– Гибкость к изменениям – можно вносить изменения даже на поздних этапах разработки.
– Ранняя доставка ценности – регулярные релизы обеспечивают возможность раннего тестирования решения в реальных условиях.
Недостатки:
– Требует опыта и дисциплины – фреймворк будет эффективным только с командой, имеющей опыт в гибких методологиях, и при строгом следовании его принципам.
– Необходимость активного участия пользователя – на практике не всегда легко обеспечить постоянное вовлечение клиента или конечного пользователя, а иногда это невозможно.
– Сложности в масштабировании – в крупных проектах может понадобиться дополнительное время и усилия, чтобы перейти на этот фреймворк разработки программного обеспечения.
Этапы:
– Предпроектный этап – на нём определяют область проекта, формируют команды и обеспечивают все необходимые условия для начала работы.
– Этап основания проекта – устанавливают основные требования, архитектуру, планы.
– Эксплоративный этап – на этом этапе идёт итеративная разработка проекта при тесном сотрудничестве с заказчиками и пользователями.
– Стабилизирующий этап – происходит уточнение разработанного функционала и его стабилизация, осуществляется подготовка к релизу.
– Этап развертывания – выполняется развертывание продукта, тестирование функционала на стороне пользователей, проводится обучение.
– Постпроектный этап – специалисты анализируют проделанную работу для ее оценки, производят поддержку внедренного решения.
6.2.11. Six Sigma
Six Sigma – это методология улучшения процессов, которую, как и немало других, изначально применяли в производственной индустрии, а теперь используют в разработке программного обеспечения. Она направлена на уменьшение ошибок в продукте и несоответствий требованиям, а также на оптимизацию процессов разработки.
Особенности:
– Статистический анализ – методологию активно применяют для анализа и улучшения качества процессов и продукта.
– Ориентация на клиента – она сфокусирована на закрытии потребностей клиента и снижении ошибок до уровня, при котором они почти не влияют на удовлетворенность клиента или пользователей.
– Инструменты качества – в методологии широко применяют специальные инструменты для анализа процессов и принятия решений, такие как гистограммы, причинно-следственные диаграммы и диаграммы Парето.
Преимущества:
– Повышение качества – используется систематический подход к идентификации и устранению первопричин проблем, что приводит к уменьшению дефектов и повышению качества продукта.
– Увеличение производительности – постоянная оптимизация процессов сокращает циклы разработки, улучшая производительность.
– Сокращение издержек – достигается за счет акцента на уменьшении количества ошибок и дефектов.
– Улучшение удовлетворенности клиента – акцент на эффективном общении с клиентом улучшает продукт.
Недостатки:
– Сложность внедрения – оно, вероятно, потребует значительных временных и финансовых инвестиций.
– Необходимость обучения – чтобы эффективно использовать методологию, команде, возможно, придется пройти обучение.
– Возможное сопротивление изменениям – методология может потребовать культурных и организационных изменений.
– Риск сосредоточения на измерениях – статические измерения могут сильно отвлечь команду от других важных аспектов проекта.
Этапы:
– Определение – специалисты определяют цели проекта, требования и ожидания клиентов.
– Измерение – проводят сбор данных о текущем процессе для определения базовых показателей производительности.
– Анализ – собранные данные анализируют для определения причин проблем и ошибок.
– Улучшение – на этом этапе происходит разработка и внедрение решений.
– Контроль – внедрение механизмов контроля для поддержания достигнутых улучшений и предотвращения возврата к предыдущим показателям.
6.2.12. Crystal
Crystal – является семейством методологий разработки программного обеспечения, основная идея которых заключается в том, что не существует универсальной методологии разработки, подходящей для всех проектов, и что методология должна быть адаптирована к конкретному проекту и команде. Crystal предлагает человекоцентричный и гибкий подход к разработке, фокусируясь на адаптации процессов под конкретные проекты и команды для достижения наилучших результатов.
Особенности:
– Гибкость и адаптивность – акцент на адаптации методологии под конкретные нужды проекта и команды.
– Легковесность – минимизация бюрократии и документации.
– Человеческий фактор – особое значение придают коммуникации, вовлеченности и благополучию членов команды.
– Основные приоритеты – безопасность, эффективность, привлекательность.
Преимущества:
– Гибкость – методология крайне гибкая и может подойти большинству проектов с любой спецификой и размером.
– Фокус на людях – особое внимание уделяют удовлетворенности и мотивации команды, что повышает ее продуктивность.
– Снижение издержек – достигается за счет сокращения процессов и документации.
– Улучшение коммуникации – приветствуется прямая и открытая коммуникация между всеми участниками процесса.
Недостатки:
– Требуется опыт – для эффективного применения необходимо глубокое понимание методологии и умение адаптировать ее.
– Риск недостаточной структурированности – высокий уровень гибкости может привести к отсутствию дисциплины и структуры в работе команды.
– Зависимость от команды – успех проекта сильно зависит от квалификации и вовлеченности команды.
Этапы в общем случае выглядят так:
– Планирование – на нём определяют цели проекта, собирают требования, формируют команду и выполняют планирование.
– Циклы разработки – итеративная разработка с регулярным пересмотром прогресса и адаптацией плана.
– Основные проверки – этап проекта, на котором оценивают глобальный прогресс и принимают ключевые решения о дальнейшем направлении разработки.
– Завершение проекта – выполняют финальные доработки проекта, завершающее тестирование и подготовку продукта к релизу.
6.3. Какой процесс лучше для тестирования
На практике далеко не все команды, проекты и компании придерживаются одного подхода, методологии или процесса. На одном и том же проекте у разных команд могут быть разные процессы. В то же время не всегда можно увидеть точное следование одному подходу или методологии внутри одной команды. Это приводит к тому, что там смешиваются несколько методологий или подходов, что не всегда является благом.
Но ответа на то, какой процесс эффективнее, на самом деле нет. Как было описано выше, каждый из них имеет преимущества и недостатки. А невообразимое количество компаний и проектов в мире имеет множество особенностей, на которые накладывают методологии разработки программного обеспечения.
К тому же нужно не забывать, что методологии это не только про компании, но еще и про людей, а значит, не всем из них комфортно работать в команде, где действуют процессы, расходящиеся с их ценностями. Также некоторые методологии требуют исключительно высокой квалификации сотрудников, что тоже не всегда подходит как самим сотрудникам, так и компаниям.
Можно определенно точно сказать, подходит ли процесс компании и лично сотруднику, но для этого необходимо ознакомиться с ним и попробовать на практике. Для обеих сторон значимым показателем является то, насколько точно соблюдается методология. Компании это дает более высокую определенность понимания результата работы по методологии, а сотруднику – понимание о зрелости и стабильности процессов в компании.
Если вы рассматриваете возможность задержаться в своей компании на несколько лет, то хорошее понимание процессов внутри неё и команды позволяет вам видеть дополнительные точки карьерного роста или наоборот, риски для своей успешной карьеры.
7. РЕАЛЬНАЯ ЖИЗНЬ И ПРЕДВЗЯТОСТИ
Быть QA инженером это легко
Довольно относительное понятие. Тем не менее рынок диктует свои условия. Да, вначале эта профессия может некоторым показаться довольно не сложной, но нужно учесть несколько факторов.
Во–первых, это только начало и впереди карьера с потрясающе разнообразными возможностями и трудностями. Во–вторых, это ИТ область, а значит вы всегда будете конкурировать с остальным миром и кроме работы всегда должны учиться, чтобы просто оставаться на одном уровне с другими. А чтобы быть лучше остальных, вам придется вкладывать в себя много ресурсов.
Кроме того, вам нужно учитывать особенности отдельных рынков, к примеру курсы от различных платформ продвигают область ИТ в целом и генерируют множество начинающих специалистов. Это значит, что порог входа на рынке сильно растет из–за конкуренции.
С другой стороны, в некоторых странах Европы наблюдается ситуация, когда ИТ-профессии не сильно востребованы и зарплаты у таких специалистов объективно меньше, чем на русскоязычном рынке. Конкурс в этих странах не такой большой, но и Trainee–Junior уровни мало востребованы. Учитывайте такие факторы, которые актуальны прямо сейчас, чтобы не разочаровываться понапрасну.
QA – самый просто способ начать работать в ИТ
Чтобы просто начать, действительно нужно меньше технических навыков, чем у разработчика, но при этом необходимы другие умения. Можно точно сказать, что если вам не нравится сама профессия, вы начнете выгорать, а ваш карьерный рост замедлится.
Мир перестал делиться на стандартные три столпа индустрии (аналитики, разработчики, тестировщики). Исследуйте рынок вакансий: существует много смежных областей, требующих самого разного баланса навыков и ведущих к другим карьерным возможностям. Ведь самое важное – найти свое любимое дело, даже если на это потребуется много попыток.
На мой взгляд, Support направление проще для входа в ИТ, чем QA. Да и ваш карьерный путь может привести к тому, что вы станете Support, который пишет код. Но зарплаты в поддержке обычно меньше, чем в QA. Бизнес-аналитика по техническим навыкам проще на старте, но как минимум по навыкам общения заметно сложнее, чем QA.
Глобально вам нужно ориентироваться на свои способности, желания и возможности карьерного роста в выбранном направлении.
Быть QA инженером это скучно
Все зависит от вас и вашего места работы. В основном эта деятельность связана с рутиной у компьютера. Однако в мире принято все автоматизировать и работа QA инженера не исключение. Этому процессу как раз подвержены самые повторяющиеся рутинные задачи. Вы и сами будете их автоматизировать в том или ином ключе.
Если вам кажется, что в ходе всей своей работы вы будете только брать подготовленные аналитиками требования, писать по ним тестовые сценарии и проводить тестирование, то вы ошибаетесь. Вам предстоит тестировать требования и думать над различными ситуациями в приложении, ставить себя на место бизнеса, пользователя и злоумышленника. К тому же не всегда в компаниях вообще есть какая-либо документация и аналитики, а значит, вы будете с нуля выполнять большие объёмы работы, каждый раз сталкиваясь с чем–то новым.
Однако восприятие того, чем вы занимаетесь, это только ваше личное и в ваших силах его менять. Я не раз встречал людей, которые не просто более пяти лет работали в одной компании, но и занимали одну и ту же должность и каждый день, по большому счету, делали одно и то же. Это не у всех вызывает скуку. Есть немало людей, которым доставляет удовольствие делать свою работу и быть уверенными в себе и своих навыках.
Автоматизация скоро заменит тестировщиков
Нет, не заменит. Индустрия QA и нуждаемость в её представителях никуда не делась. Потребности в опытных ИТ специалистах во всем мире постоянно растут, новые кадры не успевают рождаться. ИТ индустрия глобально занимается автоматизациями всего, что только можно, в том числе и работы самих ИТ специалистов.
Automation QA очень бурно развивается и кажется, что все внедряют ее на своих проектах. Но этой работой занимаются в основном бывшие Manual QA, которые расширили набор навыков и приспособились к рынку. Автоматизация сокращает расходы компаний на тестирование, что позволяет им расти быстрее и открывать новые проекты, на которых снова нужны как Manual,так и Automation QA инженеры.
Нейросети тоже внесли свой вклад, и мы уже можем его оценить. О замене каких–либо специалистов в тестировании пока нет и речи. Однако нейросети помогают QA инженерам быстрее выполнять их работу.
