Плохие стратегии тестирования и как их избежать
Хорошая стратегия тестирования может привести вашу команду к созданию высококачественного продукта, но плохая стратегия работает против вас. Узнайте, как избежать те, которые убивают проекты.
Любой программный проект, серьезно относящийся к приемлемым методам тестирования, будет иметь надежную стратегию тестирования. На базовом уровне стратегия тестирования описывает, как организация подходит к тестированию в течение цикла разработки проекта. Эта стратегия может затем помочь установить цели и руководящие принципы работы, которую будет выполнять команда, от плана тестирования проекта до индивидуальной производительности каждого тестировщика.
Хорошая стратегия тестирования поможет избежать путаницы и проблем с вашей командой на протяжении жизненного цикла проекта, прояснив, чего организация хочет достичь в отношении качества. Стратегия поддерживает плавное продвижение проекта, а команда согласована с процессом. Он служит путеводной звездой, особенно когда вы находитесь в середине проекта и усердно работаете над тем, чтобы вывести его наружу.
Однако не все стратегии верны. Плохая стратегия тестирования наносит серьезный ущерб проекту, организации и команде. Многие проекты умерли медленной смертью из-за отсутствия ясности и согласованности в отношении направления, в котором следует двигаться, когда дело доходит до тестирования. Я бы сказал, что это хуже, чем отсутствие стратегии вообще, потому что это ведет людей в неверном направлении и затрудняет корректировку курса, когда проект сходит с рельсов.
Проблема плохой стратегии тестирования в том, что большинство организаций не осознают, что она у них есть, пока не станет слишком поздно ее исправлять. Большинство стратегий тестирования начинаются с мыслей об улучшении, но эти улучшения могут быть не тем, на чем ваша команда должна сосредоточиться. В этой статье я расскажу о нескольких плохих стратегиях, с которыми я столкнулся, и о том, что вы можете сделать, чтобы не попасть в те же ловушки.
Плохая стратегия №1: не сосредотачиваться на своих клиентах
Многие стратегии тестирования обращают внимание на улучшение процесса разработки для команды. Например, команда может решить выработать стратегию по улучшению рабочих процессов разработки и тестирования, такие как настроить непрерывную интеграцию и непрерывное развертывание. Это позволяет организации создать для команды лучшие условия для повседневной работы.
Хоть и для получения качественных продуктов за меньшее время необходим эффективный и приятный рабочий процесс, у этой стратегии есть недостаток. Он больше ориентирован на организацию и команду, а не на клиентов - тех, кто платит вам деньги за ваш продукт. Важно, чтобы ваша команда выполняла свою работу с несколькими проблемами, но еще важнее обеспечить, чтобы ваш продукт служил вашим клиентам, поскольку именно они позволяют вам вести бизнес.
Например, в одной компании, в которой я работал, у организации был хорошо организованный рабочий процесс для разработки и тестирования. Они гордились тем, что облегчили жизнь своей команде. Однако их продукт был полон проблем - плохой пользовательский интерфейс, множество проблем с доступностью и так далее. Это говорит о том, что если вы уделяете больше внимания процессу разработки, а не своим клиентам, есть большая вероятность, что вы пропустите важные проблемы, которые оттолкнут их от вашего продукта.
Как избежать этой плохой стратегии
Ваша стратегия тестирования должна делать больший упор на клиентов, которых вы планируете обслуживать. Ваша стратегия также может включать способы улучшения повседневного рабочего процесса вашей команды, но она не должна быть центральным элементом вашего планирования. Расставьте приоритеты в тестировании, чтобы сделать продукт лучше для клиента, и ваш продукт будет лучше благодаря вашим усилиям.
Плохая стратегия № 2: сосредоточение внимания только на одной форме тестирования
Распространенная ошибка компаний заключается в том, что они выбирают только одну форму тестирования и делают это только на протяжении всего жизненного цикла проекта. Обычно это происходит при автоматизированном тестировании - кто-то открывает для себя возможности автоматизации и хочет автоматизировать все. Тем не менее, я также видел, как организации проводят только ручное или исследовательское тестирование проекта.
Проблема этого подхода в том, что ни одна форма тестирования не охватывает все основы вашего продукта. Примером этого является автоматизация тестирования. Автоматические тесты отлично подходят для ускорения регрессионного тестирования и повторяющихся процессов, но они ужасны для выявления ранее неизвестных проблем. Ручное и исследовательское тестирование покрывают эти недостатки, но за счет времени и удержания тестировщиков, которые вынуждены делать одно и то же снова и снова.
При индивидуальном подходе к тестированию нет серебряной пули. Сосредоточившись только на одной форме тестирования, вы создаете огромные слепые зоны в процессе тестирования. Если повезет, вы заметите недостатки и исправите их соответствующим образом. К сожалению, большую часть времени вы будете настолько сосредоточены на том, что делаете, что к тому времени, когда вы поймете, почему ваш QA не работает должным образом, вы сильно отстанете по качеству.
Как избежать этой плохой стратегии
Хорошая среда QA включает многогранный подход, охватывающий автоматизированные и неавтоматизированные решения для тестирования. Вы можете избежать проблем, связанных с одной формой тестирования, сбалансировав ее с другими способами тестирования. Уделите одинаковое время автоматизации, ручному тестированию и исследовательскому тестированию в своем рабочем процессе, чтобы обработать большинство сценариев и поддерживать свое приложение в отличной форме.
Плохая стратегия №3: Оставить тестирование только QA
Многие команды с отделом QA полагаются на них при поиске ошибок и проблемах в проектах, будь то большая группа из нескольких тестировщиков или команда из одного человека. Эти организации думают, что раз это то, за что платят тестировщикам, остальная часть команды не должна беспокоиться о тестировании, выходящем за рамки их работы.
К сожалению, нередко можно увидеть, как разработчики выпускают функции и, как известно, бросают их через стену в QA. Я видел, как команды разработчиков и QA в одном офисе никогда не взаимодействуют друг с другом, кроме трекеров ошибок. В наши дни это происходит с большей частотой благодаря аутсорсингу QA и росту удаленной работы. Но даже со всеми инструментами для удаленного сотрудничества во многих местах все еще есть этот невидимый барьер между ролями.
Передача всей работы по тестированию QA ограничивает возможности вашей организации, потому что вы не можете ожидать, что тестировщики все найдут. Тестировщики отлично умеют обнаруживать проблемы, которые другие роли не могут обнаружить. Однако, как тестировщики, мы должны осознавать, что у нас также есть множество белых пятен и собственных ограничений. Например, большинство тестировщиков могут не знать, как проверять проблемы безопасности, такие как CSRF) или XSS, но разработчик может помочь решить эту проблему. Эти дополнительные навыки обеспечивают больший охват вашего проекта.
Как избежать этой плохой стратегии
Тестирование - это не работа одной команды. Это ответственность организации в целом. Сделайте тестирование и качество частью культуры вашей команды. Каждый, от контроля качества до разработки и продуктовых ролей, должен учитывать результат. Это не значит, что менеджеру по продукту или разработчику нужно часами проводить специализированное тестирование. Тем не менее, они должны осознавать роль, которую они играют в качестве поставляемого продукта.
Плохая стратегия # 4: не делать стратегию своей собственной
В Интернете есть неограниченное количество информации, чтобы узнать что угодно. Благодаря блогам, информационным бюллетеням, видео и подкастам у нас есть доступ к информации о том, как другие организации реализуют свои стратегии тестирования. Подражание тому, как другие создают свои продукты, дает рекомендации и может помочь увидеть, как другие решают проблемы, с которыми сталкиваетесь вы.
Однако вы можете не осознавать, что берете чью-то успешную стратегию и применяете ее, не задумываясь. Есть риск, что вы реализуете что-то, что не идеально для вашей ситуации. Например, вы видите крупную организацию, обрабатывающую несколько установленных продуктов с помощью сложной системы непрерывной интеграции. У них это работает, поэтому вы хотите реализовать нечто подобное для своего стартапа, основанного на одном продукте, который был запущен три месяца назад. Если вы продолжите эту стратегию, вы, скорее всего, потратите впустую время и усилия, которые можно было бы лучше использовать в другом месте.
Даже если вы найдете кого-то в ситуации, похожей на вашу, использование их успешной стратегии тестирования не будет автоматически означать, что она будет успешной для вас. Каждая небольшая разница в размере и масштабах вашего проекта влияет на то, как эта стратегия будет работать на вас. В игру вступают и другие факторы, такие как наличие ресурсов в нужное время - деньги, нужные квалифицированные сотрудники и т. Д. Ни у кого не будет ситуации, подобной вашей.
Как избежать этой плохой стратегии
Возьмите крупинки и кусочки из стратегий тестирования других людей, если вы не копируете их вслепую. Учитесь у них, принимая во внимание то, что у вас есть. Подумайте о своей текущей ситуации и о том, куда движется ваш проект, и используйте то, что, по вашему мнению, будет работать лучше всего. Некоторые команды могут волноваться, что вы создадите стратегию «Франкенштейна», которую никто не поймет. Но поскольку вы будете использовать правильные элементы, соответствующие потребностям вашей команды, каждый быстро присоединится к делу.
Плохая стратегия # 5: разделение графиков разработки и тестирования
Еще одна частая ошибка, которую я видел в продуктовых командах, - это создание отдельных графиков разработки и тестирования. Например, организация решает добавить новую функцию в свой продукт и планирует один месяц на ее выпуск. У команды разработчиков есть три недели на его создание, а последняя неделя посвящена тестированию и исправлению ошибок.
Из-за различия между разработкой и тестированием, QA часто не видит новую работу до последней недели цикла. Это действие обычно приводит к огромным задержкам проекта. Тестировщики неизбежно обнаружат ошибки и другие проблемы в работе, проделанной в течение трех предыдущих недель. Эстафету передают им после того, как они поверили, что выполнили свою роль. После раунда отладки и исправления ошибок проект снова переводится в QA, где цикл, вероятно, повторится.
Разработчики чувствуют необходимость спешить с процессом исправления ошибок, который всегда добавляет больше ошибок. Тестировщики также испытывают необходимость найти как можно больше ошибок, поскольку это конец графика выпуска, что приводит к отсутствию ошибок или их игнорированию. Эта постоянная суета в конце графика убивает проекты и подрывает доверие к этим командам.
Как избежать этой плохой стратегии
У хорошей стратегии тестирования не будет установленного графика тестирования, встроенного в календарь. Этот процесс должен быть частью ежедневного рабочего процесса как для разработки, так и для QA. Разработчикам необходимо сделать свою работу доступной для тестировщиков по мере ее готовности, чтобы у QA было время и пространство для выполнения своей работы, вместо того, чтобы бросать ее всему отделу тестирования сразу. Ваша стратегия станет наиболее эффективной, если тестирование будет выполняться постоянно в течение всего цикла разработки.
Подведем итоги
Чтобы иметь хорошие шансы предоставить своим клиентам высококачественный продукт, у вас с самого начала должна быть продуманная стратегия тестирования. Это поможет вашей команде добиться согласованности и ясности, которые им необходимы на протяжении всего жизненного цикла проекта, и позволит всем узнать, чего вы ожидаете с точки зрения качества того, что вы создаете.
С другой стороны, плохая стратегия тестирования может негативно повлиять на ваш проект гораздо больше, чем отсутствие стратегии вообще. К сожалению, многие команды начинают с плохой стратегии, что ставит их в невыгодное положение по сравнению с любыми конкурентами в их сфере. Такого рода стратегии также являются быстрым способом подорвать моральный дух команды, так как она будет чувствовать, что у них все идет не так.
В этой статье обсуждается пара плохих стратегий, которые, как я видел, влияют на реальные проекты, и способы избежать их включения в вашу стратегию тестирования. Некоторые стратегии, такие как не сосредоточение внимания на клиенте, в первую очередь выполнение одной из форм тестирования и использование исключительно QA для тестирования, с самого начала провалит ваш проект. Вы можете избежать этого, если убедитесь, что тестируете ценность для клиента, сбалансировав тестирование и убедившись, что за тестирование отвечает вся команда.
Никто не начинает свой проект, думая о намеренном создании стратегии тестирования, которая не будет полезна его команде. Тем не менее, эти неидеальные способы могут легко пробраться незаметно в команду, пока у них не возникнет беспорядок. Убедитесь, что вы совершили правильный выбор с надежной стратегией тестирования, которая поможет вашей команде, вашему проекту и вашим клиентам.
Переведено командой QApedia . Подписывайтесь на наш канал