Как определиться с выбором стратегии по тестированию программного обеспечения?
Существует ли универсальный объем работ по тестированию, выполнение которого будет гарантировать неизменно высокое качество программного продукта?
Однозначно – нет. И вот почему.
На выбор стратегии по тестированию и определение работ, которые должны быть проведены, влияет множество факторов. Давайте рассмотрим их подробнее.
#1 Особенности решения
Около 80% проектов разрабатываются по методологии Scrum (или хотя бы по принципам Scrum).
Scrum, как и любая другая agile-методология, завязана на постоянные изменения. Работа над ПО ведется по коротким итерациям (спринтам). В начале каждого спринта определяются требования, которые должны быть выполнены, определяется приоритетность задач. Таким образом, процесс разработки постоянно адаптируется под потребности бизнеса.
Как это отражается на процессах обеспечения качества?
В таких постоянно меняющихся условиях возможности для планирования у менеджера крайне ограничены.
Разумеется, после нескольких спринтов вы примерно оцените «скорость» вашей команды (velocity). Однако сможете ли вы с полной уверенностью сказать, какой набор навыков потребуется от инженеров на следующем этапе проекта или в следующем спринте?
Будет ли это тестирование API или UX? Будут ли доступны необходимые для тестов устройства вовремя? Не сорвет ли сроки команда разработки, тем самым лишив команду тестирования времени, необходимого для проведения тестов?
От ответов на эти вопросы зависит ваша возможность планировать QA-нагрузку. Но даже если ответов у вас нет, это не значит, что планировать не нужно совсем.
#2 Внешние факторы
Давайте рассмотрим типичную ситуацию: вам нужно выпустить на рынок абсолютно новый продукт. Для этого вы разработали годовой план.
Разработка началась в декабре 2018 года, когда компания Apple уже выпустила свои обновления, а Samsung все еще работает над релизом, который ожидается в феврале 2019 года.
Ваш релиз запланирован на декабрь 2019 года. К этому моменту Apple презентует очередные обновления функциональности, аппаратных характеристик ПО, новые разрешения экранов устройств и так далее. Чтобы оптимально спланировать работу QA, потребуется изучить актуальную статистику и отобрать именно те устройства, которые выбирают ваши пользователи.
Например, многие все еще отдают предпочтение iPhone 7 и даже iPhone SE. Вероятно, вы сразу решите включить эти модели смартфонов в список поддерживаемых устройств.
Но не стоит торопиться, ведь к декабрю 2019 года многие могут перейти на более новую модель. Как быть в такой ситуации?
Или что делать, если вы сосредоточили весь процесс разработки и тестирования вокруг Apple Watch, а за несколько месяцев до вашего релиза компания отзывает все выпущенные девайсы из-за наличия критических дефектов?
Совет следующий – планируйте, но не загоняйте себя в слишком жесткие рамки, учитесь адаптироваться к быстро меняющимся обстоятельствам. Сегодня выигрывает тот, кто умеет быть гибким.
Существуют ли аспекты качества, которые обязательно должны быть протестированы на любом проекте?
Ранее мы общались со специалистом, который разрабатывал архитектуру SaaS-решения. Задача состояла в том, чтобы создать надежный, высокопроизводительный продукт, который можно было бы настроить под индивидуальные потребности бизнеса.
Инженер поделился набросками будущего решения и рассказал, что в процессе разработки архитектуры он опирался на показатели качества программного обеспечения, прописанные в стандарте ISO 25010. Сегодня эти показатели можно легко найти в сети.
При планировании QA-стратегии мы рекомендуем обязательно сверяться с этим списком и определять, какие из них наиболее важны для вашего продукта на данный момент.
Чаще всего вы отметите важность качественной функциональности и удобства пользования продуктом. Соответственно, ваш план по тестированию будет включать
функциональные тесты, кроссбраузерное и кроссплатформенное тестирование, проверки удобства пользования и графического интерфейса пользователя.
К слову сказать, именно тестированием совместимости с разными браузерами и операционными системами часто пренебрегают. И в этом кроется большая ошибка. При сегодняшнем разнообразии браузеров и смартфонов вы не можете заставить всю свою аудиторию пользоваться одинаковыми устройствами. Уважайте и учитывайте их выбор.
Как правило, выбор девайсов в значительной мере зависит от географии использования продукта. Например, в Китае и США статистика по использованию устройств будет сильно отличаться.
А теперь предположим, что вы разработали программное обеспечение по бухгалтерскому учету для финансового директора, нескольких аналитиков или бухгалтеров.
На создание одного ежегодного отчета уходит в среднем не более пяти минут, поэтому проблем с производительностью не возникнет. Но как быть, если ваше решение предназначено для использования на фондовой бирже? Изменения на таком рынке происходят стихийно, и поэтому на первое место выходит производительность ПО.
Еще один важный аспект качества – безопасность решения. Особенно если ваш продукт связан с хранением личных данных пользователей (например, паспортные или медицинские данные) или их платежных карт. В этом случае проверка безопасности ПО является обязательной.
Лучше заранее убедиться в том, что ПО соответствует нормам ГОСТ или любых других стандартов, которые касаются вашего продукта, чем потом отвечать на иски ваших пользователей в суде.
Подводя итог
Вопрос о важности или необходимости тестирования сегодня уже не вопрос, ответ очевиден. То, о чем действительно стоит задуматься, – о выборе подходящей стратегии тестирования, которая будет учитывать требования пользователей и бизнеса к разрабатываемому ПО.
В подготовке такой стратегии поможет умение быстро адаптироваться к меняющимся условиям и грамотно расставлять приоритеты при разработке продукта.
Закажите
бесплатную консультацию с экспертами «Точка качества» и узнайте, как мы можем помочь улучшить ваш продукт.
