Проект выходит на новый уровень? Тестирование необходимо

    Предположим, что вы — создатель продукта — изучили целевую аудиторию, наняли опытную команду разработчиков и аналитиков, заняли долю рынка, маркетологи привлекают партнеров, менеджеры по работе с клиентами обстоятельно консультируют, вы регулярно запускаете рекламные акции.

    Казалось бы, у вас есть всё. Но платежи пользователей и аудитория стали сокращаться, а заказчики — отказываться от продукта.

    Возможно, дело в производстве? Загляните внутрь и, быть может, вы увидите, как:

    • хотфиксы выходят чаще, чем релизы;
    • или служба поддержки завалена запросами и непрерывно разбирает критичные дефекты;
    • или значимые когорты пользователей не могут получить ключевые функции сервиса.

    И, даже выявив проблемы на этом этапе, не всегда возможно понять, как отрегулировать процесс целиком, ведь зачастую каждый элемент цепи в отдельности выполняет свою работу хорошо, а конечный результат не радует. Подумайте, возможно, пришло время нанять тестировщиков?



    ***


    Тестировать может каждый участник команды. Согласно Agile-принципам эту деятельность официально выполняют все, не только тестировщики. Аналитики лучше других знают, какие функции ожидает заказчик, и как они должны работать. Юнит-тесты, ревью кода, парное программирование и обычные самопроверки разработчика обеспечивают качество кода. Но есть случаи, когда этого тестирования становится недостаточно для конечного качества. В этот момент на «сцену» приходит независимое тестирование.

    Тестирование, выполняемое самостоятельной профессиональной группой, называется независимым. Чем меньше команда влияет на проводимые тестировщиками процедуры и выводы, тем более оно независимое. Б. Бейзер в работе «Тестирование черного ящика» писал: «Цель независимого тестирования — взглянуть на продукт с другой точки зрения, а следовательно, выполнить другие тесты; таким образом, выполняется более разностороннее тестирование, чем если бы тестированием занимались только разработчики».
    Профессиональное тестирование начинается с тест-анализа и дизайна тестов:

    • отбор минимального набора проверок, чтобы убедиться в работе максимального количества функционала;
    • установка очередности прогона тестов в соответствии с критичностью функционала и рисками выпуска дефектов.

    Необходимость в профессиональном независимом тестировании возникает при следующих условиях:

    1. Стремительный рост


    Успех продукта в конкурентной борьбе — отличное событие, а также неожиданная нагрузка на производство. Новые пользователи, новые требования, масштабные изменения вынуждают команду выполнять больше задач в меньшие сроки. В итоге у команды не остаётся времени на тестирование либо интуитивное тестирование (Ad-hoc testing) пропускает критичные дефекты.

    Тестирование развивается параллельно с другими областями знаний производства ПО.

    Подходы и методологии не так изменчивы, последнее новшество в области тест-дизайна было опубликовано в 2009 году, Джеймсом А. Уиттакером в книге «Exploratory Software Testing». Тем временем новые инструменты для проведения тестирования разрабатывают непрерывно, среди них:

    • Инструменты для быстрой проверки верстки на разных браузерах и девайсах, сверки с макетами, проверки орфографии, времени отклика страницы и т. д.;
    • Инструменты для выполнения, перенаправления, изменения, декодирования, отслеживания API-запросов;
    • Инструменты для подготовки тестовых данных и условий в web, desktop, mobile, api приложениях.

    Профессиональные тестировщики улучшают и ускоряют тестирование с помощью актуальных техник и инструментов, уделяют особое внимание поиску эффективных решений, позволяя при этом команде сосредоточиться на модернизации бизнес-процессов.

    2. Энтропия


    Программный продукт-долгожитель говорит о стабильности бизнеса. С другой стороны, в течение нескольких лет продукт адаптировался под рынок, заказчиков, пользователей, накапливал разнообразный функционал, в том числе логически противоречивый. Статистика HR-портала показывает, естественный уровень текучести персонала в IT — 8-10% в год, значит за 5 лет команда разработки может обновиться почти на половину. За время жизни продукта в команде может поменяться архитектор и ключевые разработчики, люди, знавшие изначальную архитектуру и логику ее масштабирования.

    По мнению Ф. Брукса в работе   «Мифический человеко-месяц», любая система стремится к разрушению структуры и увеличению энтропии с каждым новым исправлением. Со временем продукт обрастает так называемым legacy-кодом, унаследованным от несовместимого функционала, быстрого багфикса, неопытного разработчика. Вместе с тем под давлением сроков команда не всегда успевает покрывать код юнит-тестами. В таких условиях невозможно предсказать, на какие участки кода повлияет то или иное исправление и какой дефект породит.

    Профессиональные тестировщики проверяют не только новые функции, но и регресс всей системы. Содержание и способ проведения регрессионного тестирования — предмет отдельного фокуса.

    3. Кастомизация


    Хорошо, когда продукт получает новые когорты пользователей, масштабируется на города и страны, специализирует функционал для разных ролей, адаптируется под время жизни пользователей в системе. С позиции системы это увеличивает количество критически важного функционала и способы его использования. Одна и та же функция может использоваться в разных целях и в различных условиях когортами пользователей. В большой сложной системе ролей и условий так много, что аналитик может забыть про одну из них во время разработки требований. На деле killer-feature для одной роли может стать блокирующим дефектом для другой, не менее значимой.

    Профессиональное тестирование проверяет использование системы на соответствие целям пользователей, задает уточняющие вопросы, корректирует содержание регрессионного тестирования в соответствии с новыми приоритетами и бизнес-задачами системы. Актуализация набора и приоритетов тестов — предмет отдельного внимания тестировщика.

    4. Распределённость


    IT-среда сегодня предоставляет бесконечные возможности выбора, микро-сервисная архитектура, облачные дата-центры, распределенные проектные команды. Цельные продукты, с точки зрения пользователя, на деле расщепляются на микро-приложения, написаны на разных языках разработки, размещены на разных континентах, созданы разными проектными командами и компаниями.

    К примеру, покупка безделушки в интернет-магазине, с одной стороны, действие из нескольких кликов, с другой — обработка и передача данных, по крайней мере, в трех приложениях — на веб-сайте магазина, в платежном шлюзе и платежной системе. Каждое приложение разрабатывает проектная команда со своими целями, оргструктурой, планами.

    В этих условиях вероятен результат «пуля вылетела, проблема на вашей стороне»: когда каждая команда разработала свою часть в соответствии с требованиями, но вместе они не складываются в рабочую функцию.
    Профессиональные тестировщики перед сдачей в эксплуатацию консультируют, курируют, выполняют настройку сред для прогона интеграционного тестирования, выполняют проверки с позиции конечного пользователя, а не только требований к отдельным компонентам.

    Таким образом, крупные, возрастные, востребованные, стремительно изменяющиеся продукты обязывают тестирование быть отдельным родом деятельности. Эффективное тестирование вооружено специализированными методологиями, инструментами и конкретной целью, отличной от целей остальной команды. Цель аналитика — выяснить реальные потребности заказчика, цель разработчика — выполнить доставку заказанных изменений в полном объеме, цель тестировщика — испытать систему целиком, изучить пользователя и столкнуться с дефектами вместо него.

    ***


    Делегирование тестирования отдельной роли под управлением команды — второй шаг к независимому тестированию. Тестировщиков можно нанять самостоятельно или воспользоваться аутсорсингом тестирования в независимой организации.

    От аутсорсинг-тестирования на этом шаге компания получает:

    • профессиональное тестирование своего продукта с актуальными инструментами;
    • гарантированно квалифицированные кадры. Аутсорсинг специализируется на подборе и выращивании компетенций сотрудников;
    • возможность воспользоваться тестированием на ограниченный срок, привлечь дополнительный вид тестирования или заменить его;
    • прозрачную работу тестировщиков.

    Компании, занимающиеся аутсорсинг-тестированием, работают на репутацию: она тем выше, чем качественней предоставляемая услуга. Как обстоят дела с тестированием в вашей компании? Делитесь опытом :)
    ICL Services
    Цифровые технологии для бизнеса

    Комментарии 4

      +4
      «СоответСвует» и «РеализоваННо» в посте от представителя компании — это провал. Градус отношения к остальному тексту уже сразу понижен. Требования к качеству материала от компаний должны быть гораздо выше, чем от частников, имхо.
      Компании, занимающиеся аутсорсинг-тестированием, работают на репутацию: она тем выше, чем качественней предоставляемая услуга. Как обстоят дела с тестированием в вашей компании? Делитесь опытом :)

      Как обстоит дело с тестированием выпускаемого в публичное пространство текста? ;)
        0
        Благодарю за проявленный интерес! В публикации использовалось уже готовое изображение. А сделанные, по моему мнению, ошибки автора носят преднамеренный характер и составляют всю «соль» данного демотиватора.
          +1
          Ну ладно, соль так соль — хотя мне кажется, что это просто безграмотный мем. Кроме того, картинка иллюстрирует «к пуговицам претензии есть?» Жванецкого и без подписи :)

          Касательно аутсорсинга тестирования продуктов — здесь все совсем неоднозначно. Аутсорсить хорошо непрофильные и/или эпизодические работы, в то время как тестирование — де-факто неотъемлемая часть цикла разработки продукта, которая как раз замыкает его отрицательной обратной связью по качеству. Зачем искусственно удлинять контур обратной связи, внося в него а) задержку по времени, б) потери на передачу информации, в) оверхеды на кормление менеджерского стека и нормы прибыли аутсорсера?

          Я могу представить внешнюю контору как некоего аудитора, доказывающего заказчику продукта, что, будучи выполненным компанией X, он соответствует заявленному качеству. Однако, чтобы провести глубокий анализ, метода черного ящика редко бывает достаточно, так как сложные программные системы слишком сложны ;), чтобы быть надежно покрытыми чисто снаружи. А погружение в тестирование изнутри требует синхронного общения с источниками БТ и ТТ разрабатываемой системы, и от этого должно по сути проводиться не в фазе сдачи-приемки, а на протяжении доброй половины всего цикла разработки
          –1
          Кроме того, картинка иллюстрирует «к пуговицам претензии есть?» Жванецкого и без подписи :)


          похоже так и есть, по Жванецкому :) Однако с другой коннотацией. Жванецкий говорил о безразличии и непрофессионализме. Я попыталась раскрыть условия, в которых профессиональный тестировщик необходим команде. По моему опыту, мисс коммуникации, человеческий фактор, VUCA-world, постоянные спутники IT-проектов, у кого-то больше, у кого-то меньше. В сложных условиях их влияние возрастает и становится фатальным. Но если есть процессы контроля качества, выполняемые специальными людьми, риски качества значительно уменьшаются.

          Касательно аутсорсинга тестирования продуктов — здесь все совсем неоднозначно.

          абсолютно с вами согласна :) С аутсорсинг-тестированием всё неоднозначно. Неоднозначно, также, как с конкретными видами инструментов и процессов. Думаю, золотых пуль не существует, нет решения, которое бы подошло каждому проекту, на любом этапе зрелости, на любом рынке. Давайте посмотрим, когда аутсорсинг может быть полезен:

          — к примеру компания набирает первых тестировщиков, ни у кого в ней нет компетенций, чтобы достоверно оценить потенциальных кандидатов и понимания, как настраивать QA/QC процессы. А, как я писала ранее, профессионализм в работе тестировщика крайне важен. В этом случае мы можем прийти, настроить процессы и передать наработки компании.
          — или компания готовит MVP нового продукта, никто в ней не может гарантировать, что проект «взлетит». Как поступить в этом случае, нанимать тестировщиков с риском увольнения или привлечь аутсорсеров?
          — или компании понадобился определенный вид тестирования и срочно, а на кадровом рынке нужного специалиста с огнем не сыскать. Почему бы в этом случае не привлечь нас, если у нас такой специалист есть ;)

          если подумать, примеров куда больше. Мы договариваемся о результатах заранее, легко подключаемся и отключаемся. И нам выгодно иметь хорошую репутацию, поэтому уделяем развитию своего сервиса и компетенций достаточно внимания.

          Я могу представить внешнюю контору как некоего аудитора, доказывающего заказчику продукта, что, будучи выполненным компанией X, он соответствует заявленному качеству.


          Мы можем выполнять аудиты, и это, пожалуй, самое независимое тестирование. Но, как вы заметили, оно не всегда эффективно. И я с этим согласна :), хотя и у аудитов есть свое место в истории
          Также мы умеем работать в команде заказчика, в этом случае производственный процесс тестировщика совсем не отличается от работы штатного сотрудника, отличается зона ответственности

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое