Переход к гибкому (Agile) тестированию
Сейчас рынок быстро развивается во многих отраслях промышленности, и при так называемом традиционном методе выполнения каскадных проектов, когда у вас есть все процедуры, этапы и вся документация об их выполнении, вам очень трудно идти в ногу с конкурентами. На протяжении последних нескольких лет гибкие (Agile) технологии представляли собой одну из ключевых потребностей для изменения процесса разработки, которая позволяет не отставать от следующих лучших поколений продукции. Сейчас конкуренция на многих разных уровнях в промышленности жесткая, многие люди берут уже существующие идеи других людей, а затем просто переносят их на следующий уровень. Так что если вы один из первых, кто сделал отличный продукт, сегодня появляется множество людей, которые автоматически делают то, что делаем мы. Вы должны идти в ногу с ними, а при традиционном каскадном подходе, если бы мы проходили через все эти процедуры, то не добились бы этого. Гибкий подход действительно позволяет нам ускорить процесс и выпускать продукцию на рынок вместе со всеми нашими конкурентами.
Люди не любят изменений. Я имею в виду, в конце концов, это фундаментальное изменение, при традиционной каскадной модели у вас есть все требования, все процедуры, и вы точно знаете, кто за что отвечает, не так ли? Потому что у вас есть определяющие этапы. А когда вы используете гибкую методологию, некоторые из таких процедур и этапов как бы просто исчезают, и дело доходит до прозрачности и донесения информации до людей другим способом. Требования могут быть не полностью конкретизированы - тестирование может начинаться при разработке, как мы никогда бы не сделали раньше. И когда вы вытаскиваете людей из их зоны комфорта, во многих случаях люди не видят ценности (или не хотят ее видеть), потому что они не хотят меняться. Это одна из самых больших проблем, которые я видела в отношении сопротивления переменам.
Существует множество мифов, самый большой, по моему мнению, связан с автоматизацией. Самый большой миф состоит в том, что все должно быть автоматизировано с первого дня. Если мы говорим о переходе к гибкой методологии, вы должны иметь план и представление о том, чего вы хотите достигнуть. Вы должны упорно работать над таким переходом и автоматизацией, будь то для построения структуры или чтобы выяснить, что вы хотите автоматизировать в первую очередь, а затем обучить людей техническим знаниям в сфере автоматизации и только потом приступать к ней. Зачастую люди боятся даже «соваться» туда. Их навыки по обеспечению качества не на должном уровне, но у вас в конце концов автоматизация обязательно должна работать быстро, и это не простая вещь, но она имеет первостепенное значение для достижения вашей цели.
Что интересно, когда вы переходите от каскадного к гибкому тестированию, люди часто думают, что теперь для фактического тестирования программного обеспечения им больше не нужны стандарты и шаблоны, не нужны планы тестирования и больше не нужно писать тестовые сценарии. Как будто документация больше не требуется. На самом деле это очень сильная сторона в области обеспечения качества (QA), которую вы переносите от каскадного к гибкому тестированию, и миф «Я собираюсь перейти от полного документирования к отсутствию какого-либо документирования вообще» в действительности неправильный. Вы должны принять сильные стороны QA, которые у вас есть (фундаментальная особенность QA), и использовать их, но в более легкой форме. Так что у меня по-прежнему есть документ о выполнении стандартных операций QA в гибкой методологии, но он для случаев вроде «Эй, г-н Новичок, который только что пришел к нам, вот так вы должны выполнять свою работу в первый день». Некоторые люди говорят – «Ничего себе, это большой документ. Это документ из каскадной методологии». Да, это так, но в то же время в сфере QA должна иметься согласованность среди десяти разных скрам-команд, и она определяет ход дел. Стандарты очень важны для согласованности.
С точки зрения тестирования и гибкого подхода всегда существует матрица, не так ли? Некоторые команды будут выполнять процедуру QA в соответствии с ходом разработки. Я чувствую, что люди, которые больше заботятся о качестве, предоставляют отчетность для матрицы – менеджеру по обеспечению качества или директору, как я. Я хочу сказать, что нам все равно приходится готовить тестовые сценарии. Мои минимальные два стандарта состоят в том, что вам все равно придется писать тестовые примеры в гибкой методологии, и вам все равно придется написать некоторый план тестирования. Таким образом, вам приходится думать о плане выполнения работы. С точки зрения мифа и перспективы: мы также соблюдаем процедуру QA; у нас также есть задачи с точки зрения тестирования программного обеспечения (чего не было в каскадном методе), которые мы должны выполнить в будущем.
Слабая сторона, очевидно, во многом относится к автоматизации. В то время как одни QA-инженеры в прошлом решили, что они не хотят быть разработчиками, и именно поэтому они пошли в тестирование, нам приходится повышать квалификацию наших QA-инженеров, чтобы они были более технически ориентированными. Появляется множество инструментов, таких как SpecFlow и upscale, которые помогают QA-специалистам в команде постепенно выходить на арену автоматизации. По крайней мере, это должно произойти в тестовых примерах, а затем, кто-то должен их автоматизировать, а как только вы поймете структуру таких навыков, то вам будет легко научиться фактическим примерам автоматизации. Но вы должны повышать свою квалификацию; вы должны потратить время, чтобы привить своим QA-специалистам желание изучать автоматизацию. Всегда найдутся те QA-специалисты, которые скажут: «Черт возьми, нет! Я не собираюсь заниматься автоматизацией». И это нормально. Если они являются экспертами в предметной области, это их основная компетенция – им все равно следует разрешить исследовательскую перспективу. Исследовательское тестирование не уходит; оно просто является хорошим дополнением для технического тестирования. Нам все равно нужно, чтобы кто-то из команды повышал свой технический уровень.
В каскадной методологии, QA несет ответственность за определение характера проблемы – проблема процесса или проблема тестирования? Мы что-то упустили с точки зрения тестирования или вопрос состоит в плохо заданном требовании? Для меня моя работа имеет такой же характер: это проблема гибкого процесса или проблема тестирования «не той вещи»? Я поняла вначале, когда начинала работать скрам-мастером – Scrum «уходит». Я подумала: «О, черт возьми, все – менеджеры среднего звена. Каждый будет самостоятельно руководить, самостоятельно организовываться в команды; моя работа перестает быть нужной».
И я пошла и получила сертификат скрам-мастера и подумала: «Это здорово. Мне нравится. Мне на самом деле нравится заниматься этим. Это может быть второй профессией». Но потом я поняла, что людям все равно придется делать обзоры эффективности работы. Я начала более страстно изучать системы Agile, Scrum, канбан, SP, потому что поняла, что они помогут мне выяснять характер проблем моей QA-команды: проблема процесса или проблема тестирования. Изучение обоих аспектов позволило мне формировать более крепкие гибкие коллективы. Большую часть времени я преподаю гибкий коучинг. Когда я была в Deutsche Bank, я работала главным QA-менеджером, руководя шестнадцатью Scrum-командами, и почти все вопросы там были связаны с процессом. Это привлекает меня с точки зрения гибкой методологии, как и в ChannelAdvisor, где нужно было определять – проблемы связаны с процессом или качеством? Вот почему я страстно отношусь к этому - это помогает мне лучше выполнять свою работу.
Об авторе Мэри Торн – директор по обеспечению качества в ChannelAdvisor в Моррисвилле, Северная Каролина. У нее большой опыт тестирования в сфере автоматизации, хранилищ данных и веб-систем самых разнообразных технологий и методов тестирования. За время ее более чем пятнадцатилетней работы в области здравоохранения, HR, сельского хозяйства и SaaS-продукции, Мэри занимала должности руководителей и исследователей в организациях по разработке программного обеспечения. У нее есть большой интерес к гибким методологиям тестирования и непосредственный опыт руководства гибкими рабочими группами путем внедрения Scrum-методологии и не только.
Оригинал статьи: http://www.agileconnection.com/interview[...]-testing-transition-interview-mary-thorn |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
