Услуги по обеспечению качества: мы выявляем ошибки до того, как вы это сделаете

Сломанная кнопка, медленная страница оформления заказа или форма, которая отказывается отправляться, могут изменить то, как люди видят бизнес. Многие клиенты не сообщают о проблеме. Они закроют страницу, выберут другую услугу и пойдут дальше. Я видел, как команды тратят недели на улучшение продукта, в то время как небольшая техническая проблема незаметно влияет на регистрацию и продажи. Проблема была не в недостатке усилий. Команда просто протестировала продукт с внутренней точки зрения, вместо того, чтобы использовать его так, как это сделал бы клиент. Процесс практического тестирования может помочь выявить эти проблемы до того, как они станут достоянием общественности. ### Начните с пути клиента. Я начинаю с перечисления действий, которые должен выполнить клиент. Для интернет-магазина путь может выглядеть следующим образом: - Открыть домашнюю страницу - Найти товар - Прочитать информацию о товаре - Добавить товар в корзину - Ввести информацию о доставке - Выбрать способ оплаты - Завершить заказ - Получить сообщение с подтверждением Каждый шаг может содержать отдельную проблему. Панель поиска может возвращать несвязанные элементы. Форма оплаты может отклонить действительный почтовый индекс. Письмо с подтверждением может так и не прийти. Когда я тестирую продукт, я не останавливаюсь после проверки того, загружается ли страница. Я спрашиваю, может ли человек выполнить всю задачу без замешательства и неудач. ### Тестируйте общие действия перед редкими случаями. Продукт может иметь много функций, но обычно несколько действий имеют наибольшее значение. Я проверяю пути, которые влияют на: - Создание учетной записи - Восстановление логина и пароля - Поиск продуктов - Контактные формы - Платежи - Запросы на бронирование - Загрузка файлов - Просмотр мобильных устройств Эти действия заслуживают регулярного тестирования, поскольку клиенты часто их используют. Небольшая проблема в условиях редкого использования может подождать позже. Неработающая форма регистрации не должна использоваться. ### Используйте разные устройства и браузеры Страница, которая работает на моем ноутбуке, может вести себя по-другому на телефоне. Форма, которая хорошо выглядит в одном браузере, может оказаться трудной для использования в другом. Я тестирую простой список устройств: - Настольный компьютер - Телефон Android - iPhone - Планшет - Chrome - Safari - Edge Целью не является тестирование каждого когда-либо созданного устройства. Я сосредотачиваюсь на устройствах и браузерах, которые используют текущие посетители. Аналитика веб-сайта может показать эту информацию. Например, веб-сайт ресторана чаще всего посещается мобильными пользователями в обеденное время. Если меню работает на компьютере, но форму бронирования сложно использовать на телефоне, в плане тестирования отсутствует основная группа клиентов. ### Тестирование с реалистичной информацией. Выборочные данные могут скрыть проблемы. Я использую информацию, похожую на ту, которую могут вводить клиенты: - Длинные имена - Различные почтовые индексы - Специальные символы - Международные номера телефонов - Большие файлы изображений - Пустые поля - Неправильные пароли - Повторяющиеся адреса электронной почты. Клиент может ввести «Хосе Гарсия», использовать длинный адрес квартиры или загрузить фотографию с телефона. Система должна реагировать четко. Сообщения об ошибках должны сообщать людям, что делать дальше. «Неверный ввод» мало чем помогает. «Введите номер телефона из 10 цифр» понять проще. ### Попросите кого-нибудь за пределами проекта протестировать. Люди, создающие веб-сайт, часто знают, как он должен работать. Эти знания могут повлиять на то, как они их проверяют. Я прошу кого-нибудь, кто не участвовал в проекте, выполнить небольшую задачу без руководства. Я смотрю, где они делают паузу, нажимают не на ту ссылку или задают вопрос. Эти моменты выявляют проблемы, которые могут не отображаться в контрольном списке. Команда разработчиков программного обеспечения, с которой я работал, когда-то считала, что процесс сброса пароля прост. Новый тестировщик получил письмо о сбросе настроек, но не смог найти ссылку, поскольку она находилась под длинным блоком текста. Функция сработала. Клиентский опыт не изменился. ### Записывайте каждую ошибку в удобной форме Хороший отчет об ошибках помогает нужному человеку понять проблему, не догадываясь. Я включаю: - Страница или функция - Действия, вызвавшие проблему - Ожидаемый результат - Фактический результат - Устройство и браузер - Скриншот или короткое видео - Сколько раз возникала проблема Я также описываю влияние на клиента. Орфографическая ошибка и несостоявшийся платеж не должны получать одинакового внимания. Простая система приоритетов может помочь: - Высокий: блокирует оплату, вход в систему, бронирование или другое ключевое действие - Средний: вызывает путаницу, но имеет возможное обходное решение - Низкий: влияет на внешний вид или формулировку, не блокируя использование ### Протестируйте еще раз после исправления Исправление может решить одну проблему и создать другую. Когда разработчик меняет форму оформления заказа, я снова проверяю полный путь оформления заказа. Я также проверяю ближайшие действия, такие как редактирование корзины, возврат на страницу продукта и получение электронного письма с заказом. Я веду краткий учет протестированных функций и дат. Это упрощает будущие проверки, особенно когда веб-сайт получает обновления. Тестирование ошибок — это задача не только разработчиков. Маркетинговые команды, сотрудники службы поддержки и владельцы бизнеса могут обнаружить проблемы, используя продукт свежим взглядом. Отзывы клиентов, заявки в службу поддержки, заброшенные формы и аналитика могут показать, на чем следует сосредоточить внимание при тестировании. Мое правило простое: если клиенту нужна эта функция для выполнения важной задачи, я тестирую ее в нормальных условиях, необычном вводе данных и использовании мобильных устройств, прежде чем отправлять туда людей. Короткая проверка может защитить доверие, сократить количество запросов в службу поддержки и предоставить клиентам более плавный путь к продукту.

Продукт может выглядеть готовым к отправке, но при этом иметь небольшие проблемы, которые влияют на доверие клиентов. Незакрепленный разъем, неясная этикетка, неровная отделка или отсутствие записи могут привести к возвратам, задержкам и дополнительной работе для вашей команды. Я помогаю предприятиям построить процесс обеспечения качества, который проверяет продукты в нужных точках, записывает полезные данные и дает командам четкий способ реагировать при появлении проблемы. Мой подход начинается с требований к вашему продукту. Я просматриваю чертежи, образцы, сведения о материалах, потребности в упаковке и критерии проверки. Это помогает мне понять, что должен делать продукт, как он должен выглядеть и какие дефекты могут повлиять на использование. Я не отношусь к каждому вопросу одинаково. Царапина в скрытой области может потребовать иной реакции, чем трещина возле соединения с ключом. Я помогаю определить уровни проверки на основе функциональности, безопасности, внешнего вида и ожиданий клиентов. Практический процесс обеспечения качества может включать в себя: - Проверки поставщиков и материалов - Проверка образцов перед производством - Проверка во время производства - Проверка размеров и функций - Визуальный осмотр - Проверка упаковки и этикетки - Окончательная проверка перед отправкой - Учет дефектов и корректирующие действия В ходе производства я сосредотачиваюсь на тех моментах, где проблемы легче контролировать. Если значение измерения начинает выходить за пределы согласованного диапазона, команда может выяснить причину, прежде чем это повлияет на большое количество. Это может сократить объем доработок и помочь защитить план поставки. Например, однажды я рассматривал партию металлических кронштейнов для поставщика мебели. Детали соответствовали чертежу по длине, но несколько отверстий были немного смещены. Проблему было нелегко обнаружить во время быстрой визуальной проверки. Когда кронштейны были установлены на раму, сборке потребовалось дополнительное усилие. Мы добавили проверку положения отверстия в лист проверки и проверили приспособление для сверления. Следующая партия оснащена меньшей регулировкой. Этот тип проверки не зависит только от внешнего вида. Я смотрю на то, как сделан продукт и как его использует клиент. Четкие записи также способствуют принятию более эффективных решений. Отчет о проверке может включать: - Название продукта и номер партии - Дату проверки - Количество проб - Используемые инструменты тестирования - Результаты измерений - Принятые и отклоненные изделия - Фотографии дефектов - Требуемые действия - Лицо, ответственное за последующие действия Фотографии помогают объяснить визуальные проблемы. Измерения помогают выявить проблемы, связанные с размером. Краткое примечание о причине может помочь в следующем производственном цикле. Эти детали облегчают общение между покупателями, фабриками, инженерами и отделами логистики. При появлении дефекта я фиксирую проблему, не назначая виноватых. Полезные вопросы: - Что случилось? - Где это произошло? - Сколько предметов может быть затронуто? - Что стало причиной проблемы? - Какое действие может предотвратить повторение? - Как будет проверяться действие? Это позволяет сосредоточиться на продукте и процессе. Я также уделяю внимание упаковке. Товар может пройти проверку на заводе и прибыть с повреждениями после транспортировки. Слабые коробки, плохая внутренняя защита, неправильные этикетки или смешанные номера партий могут создать проблемы, даже если сам товар соответствует требуемому стандарту. Проверка упаковки должна соответствовать весу, форме, поверхности и маршруту доставки продукта. Моя точка зрения проста: обеспечение качества должно быть достаточно ясным, чтобы люди могли его использовать, и достаточно подробным, чтобы поддержать принятие решения. Длинный контрольный список не всегда полезен. Если инспекторы не могут понять критерии, документ добавляет усилий, не обеспечивая надежного контроля. Я предпочитаю инструкции по проверке, в которых указаны требования, метод и ответ. Например: - Требование: разъем должен подходить к утвержденной розетке. - Метод: трижды подключить и отсоединить. - Ответ: зафиксировать любые неплотные соединения, повреждения или неисправности. Этот формат дает инспекционной группе прямую задачу. Это также помогает покупателю понять, что было проверено. Эффективный процесс не означает, что каждый продукт будет иметь нулевую вариацию. Материалы, оборудование, люди и условия транспортировки могут повлиять на результаты. Цель состоит в том, чтобы определить приемлемые пределы, выявить проблемы на ранней стадии и отреагировать на них с помощью записей, которые подкрепят следующее решение. Когда я работаю с поставщиком, я стремлюсь создать общий стандарт качества, а не полагаться на устные инструкции. Утвержденные образцы, четкие чертежи, формы проверки и фотографии дефектов дают обеим сторонам одинаковые рекомендации. Ваш продукт заслуживает качественного процесса, соответствующего его фактическому использованию. Благодаря правильным проверкам на правильных этапах ваша команда сможет получить более четкую информацию перед отправкой, устранить дефекты без путаницы и построить более устойчивые отношения с поставщиками и клиентами.

Продукт может выглядеть готовым, но все равно выходить из строя, когда пользователи нажимают не ту кнопку, переключают сети, меняют размер экрана или возвращаются после обновления. Я видел, как команды тратили недели на создание функции только для того, чтобы обнаружить, что небольшая ошибка при оформлении заказа не позволяет клиентам совершить покупку. Проблема со входом в систему может привести к созданию заявок в службу поддержки. Медленная страница может снизить вовлеченность. Эти проблемы часто возникают, когда тестирование начинается слишком поздно или фокусируется только на одном устройстве. Службы контроля качества помогают командам находить эти пробелы, прежде чем они затронут более широкую группу пользователей. Я рассматриваю продукт с точки зрения пользователя и с технической точки зрения. Это означает проверку того, работает ли каждая функция так, как запланировано, а также наблюдение за тем, как продукт ведет себя на разных устройствах, в браузерах, размерах экрана и типичных действиях пользователя. ### Что я проверяю - Функции веб-сайта и мобильного приложения - Регистрация пользователя и вход в систему - Формы, поиск, фильтры и процессы оформления заказа - Ссылки, кнопки, меню и перенаправление страниц - Ответы API и перемещение данных - Совместимость браузера и устройства - Изменения макета в зависимости от размера экрана - Основные факторы доступности - Сообщения об ошибках и пути восстановления - Поведение продукта после обновлений Тест не должен останавливаться, когда ожидаемое действие срабатывает. Я также проверяю, что происходит, когда пользователь вводит неполные данные, теряет соединение, дважды нажимает кнопку «Назад» или покидает страницу и возвращается позже. ### Практический процесс контроля качества Я начинаю с изучения того, как продукт должен работать. Примечания к продукту, пользовательские истории, файлы дизайна и известные проблемы помогают мне составить четкий план тестирования. Когда документация ограничена, я составляю карту основных действий пользователя посредством прямого обзора продукта. Далее я делю продукт на тестовые зоны. Торговый сайт может включать в себя создание учетной записи, поиск продуктов, обновление корзины, оплату, записи заказов и сообщения электронной почты. Платформа SaaS может потребовать проверки разрешений, информационных панелей, загрузки файлов, отчетов и командного доступа. Затем я создаю тестовые сценарии, охватывающие как обычные, так и неожиданные действия. Каждый случай включает необходимые шаги, тестовые данные, ожидаемый результат и фактический результат. Это дает команде общую запись вместо разрозненных комментариев. Ручное тестирование помогает мне понять продукт так, как это сделал бы пользователь. Автоматические проверки могут поддерживать повторяющиеся задачи, такие как проверка входа в систему, тестирование форм и регрессионные проверки. Правильный баланс зависит от продукта, графика выпуска и областей, которые часто меняются. Обнаружив проблему, я записываю четкие сведения: - Где возникает проблема - Действия по ее воспроизведению - Устройство, браузер или операционная система - Ожидаемое поведение - Фактическое поведение - Скриншоты или записи экрана, если они полезны - Возможное влияние на путь пользователя Четкий отчет экономит время разработки. «Оформление заказа не работает» не дает команде возможности действовать. «Кнопка оплаты остается отключенной после ввода действующей карты в Safari 17» — это отправная точка для команды. ### Пример из интернет-магазина Представьте, что покупатель добавляет два товара в корзину в мобильном браузере. Клиент меняет количество, применяет код скидки и переходит к оплате. Сумма, показанная на странице корзины, выглядит правильно, но на странице оплаты отображается старая сумма. Базовый тест может пропустить этот путь, поскольку тестировщик использовал один товар и пропустил код скидки. Более широкая проверка качества может сравнить общую сумму корзины, сумму платежа, запись заказа и электронное письмо с подтверждением. Проблема может быть связана с задержкой обновления данных, проблемой, связанной с браузером, или несоответствием между интерфейсом и платежной службой. Обнаружение причины до выпуска дает команде больше времени для выбора исправления и его повторного тестирования. ### Поддержка качества релизов Перед выпуском я могу помочь команде проверить основные пути пользователя и изменения с высоким риском. После внесения исправлений я повторно тестирую обнаруженные проблемы и провожу регрессионные проверки связанных функций. Небольшое изменение разрешений учетной записи может повлиять на информационные панели, отчеты и доступ к файлам. Новый способ оплаты может повлиять на записи заказов и сообщения с подтверждением. Тестирование релиза должно выходить за рамки измененного экрана. Я также помогаю командам улучшить свои привычки в тестировании, создавая многоразовые контрольные списки, шаблоны дефектов и наборы регрессий. Эти материалы сделают будущее тестирование более последовательным, не замедляя работу команды ненужными шагами. ### Что должен обеспечить хороший контроль качества Хороший контроль качества — это не только список дефектов. Это дает команде полезную информацию для принятия решений о выпуске. Вы должны иметь возможность увидеть: - Что было протестировано - Что не было протестировано - Какие проблемы остались открытыми - Какие устройства и браузеры были проверены - Какие действия пользователя несут больший риск - Работает ли исправление должным образом - Что может потребовать внимания в более позднем выпуске Я предпочитаю четкие выводы расплывчатым отчетам и практическое тестирование вместо длинного списка малоценных проверок. Цель — помочь вашей команде выпустить релиз, лучше понимая поведение продукта, известные риски и влияние на пользователей. Когда контроль качества становится частью процесса разработки, тестирование может начаться раньше, дефекты легче отслеживать, а обсуждения выпуска могут основываться на фактических данных, а не на догадках. Тщательный план тестирования не устранит все возможные проблемы, но может выявить многие проблемы, хотя их легче решить. Хотите узнать больше о тенденциях и решениях в отрасли? Свяжитесь с Фейюном: guxiangdong@suzhouflymg.com/WhatsApp 18051215777.

1. Прессман, Роджер С. 2014. Программная инженерия: практический подход. 2. Международная организация по стандартизации. 2015. Системы менеджмента качества: Требования 3. Канер, Джем, Джек Фальк и Хунг Куок Нгуен. 1999. Тестирование компьютерного программного обеспечения 4. Международная квалификационная комиссия по тестированию программного обеспечения. 2018. Программа 5 сертифицированного тестера базового уровня 5. Джуран, Джозеф М. и А. Блэнтон Годфри. 1999. Справочник по качеству Джурана 6. Нильсен, Якоб. 1994. Юзабилити-инжиниринг.