Я случайно увидел это несколько дней назадTesterHomeинициирован《Отчет об отраслевом исследовании обеспечения качества программного обеспечения за 2023 год》,В статье упомянуто несколько результатов опросов и аналитических выводов, которые меня очень интересуют. Для этого отчета о расследовании,Я хотел бы поделиться своим пониманием и мыслями по поводу следующих трех выводов.

1. Анализ участия в тестировании

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

У меня сложилось впечатление, что в последние несколько лет, особенно с 2015 по 2019 год, все считали, что в процессе тестирования важнее техническая практика, например автоматическое тестирование. В последние годы все начали возвращаться к сути и задумываться о взаимосвязи обеспечения качества и бизнеса с более низкого уровня. Вот как я это понимаю: развитие отечественной ИТ-индустрии до сих пор в основном проходило три этапа. В нескольких словах его можно охарактеризовать как поэтапное, дающее распуститься сотням цветов, и метод осаждения.

Первый этап: шаг за шагом, примерно соответствующий 2004-2010 гг. На данном этапе в отечественной сфере ИТ и Интернет-технологий не так много возможностей для инноваций и применения, а технические работы в основном выполняются путем копирования зарубежных методов. Например, водопадная модель, бизнес-инструменты, такие как QPT/LoadRunner и Jira для управления требованиями и проектами. Несмотря на то, что на протяжении всего процесса исследований, разработок и испытаний будут соблюдаться различные спецификации, тестирование играет более важную роль в обеспечении контроля качества, то есть проверке качества. Взаимосвязь между исследованиями и разработками в этом процессе больше похожа на вход и выход конвейера. Каждый идет своим путем, и хорошей координации нет.

Второй этап: дать распуститься сотне цветков, что примерно соответствует 12-18 годам. С бурным развитием мобильного Интернета бизнес-сценарии становятся все более сложными, нагрузка на доступ к онлайн-трафику возрастает, а архитектура системы становится все более сложной. Сложность и разнообразие бизнеса предъявляют более высокие технические требования, и, соответственно, были реализованы различные технические исследования и инженерные практики. Например, появились штатные автоматизированные тесты, тестирование производительности, разработка тестов и другие должности по тестированию.

Третий этап: метод осадки, обычно соответствующий 19-22 годам. После того, как бурное развитие Интернета замедлилось, все начали сокращать затраты и повышать эффективность, а также гоняться за соотношением затрат и результатов, возвращаясь к сути мышления из предыдущей обширной практики. И после многих лет технической практики и различного обмена каждый постепенно накопил множество методологий, а также появились еще несколько общепризнанных лучших практик, таких как тестирование направо и налево, и роль тестирования постепенно превратилась в обеспечение качества (QA). ).

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

2. Анализ факторов, препятствующих прогрессу тестирования.

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

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

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

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

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

3. Что вызывает проблемы с качеством?

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

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

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

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