Несколько недель назад я решил написать о тестировании фиксов. Главной моей целью было определить, существует ли системный подход, которому можно было бы следовать в общих случаях. Анализируя это, я быстро понял решающую роль уверенности в проверке и одобрении любого тестируемого нами программного обеспечения.
Уверенность диктует, сколько тестов, по нашему мнению, нам нужно выполнить, прежде чем мы сможем подтвердить успешность тестирования. Уверенность в команде разработчиков напрямую влияет на то, сколько времени мы потратим на тестирование, чтобы почувствовать, что наш продукт готов к релизу. Эта уверенность основывается на нашем опыте общения с командой разработки и качества их кода в прошлом.
Высокая уверенность — выполняется только самое необходимое количество тестов, гарантирующих, что программное обеспечение может быть принято. (Примечание: это не относится к критически важным программным системам.)
Низкая уверенность — на основе предыдущего опыта тестировщики могут проводить дополнительные проверки, даже если нынешнее качество кода хорошее.
Я считаю, что уровень уверенности очень влияет на скорость, с которой программное обеспечение может быть разработано. Часто можно услышать, что «QA — это узкое место процесса разработки», но это потенциально связано с исторически низким качеством кода, заставляющим тестировщиков перетестировать, даже когда проверяется код хорошего качества. Чтобы проиллюстрировать этот момент, я привожу ниже подход, который я придумал для тестирования и проверки исправлений ошибок.
Пример: мобильное приложение, которое требует от пользователей входа в систему.
Представьте, что у нас есть мобильное приложение, которое требует от пользователей входа в систему.
Вымышленная ошибка, которую мы будем проверять, выглядит следующим образом: Заголовок: Экран входа в систему — Приложение аварийно завершает работу после нажатия кнопки входа.
Предварительные условия: Приложение недавно установлено.
Шаги воспроизведения:
Запустите приложение и перейдите к экрану входа.
Введите действительный существующий адрес электронной почты и пароль.
Нажмите кнопку «Войти».
Результат: Приложение вылетает.
Перед началом проверки
Как только ошибка получает статус «Исправлено», важно, чтобы мы имели четкое понимание ее характера, прежде чем начали проверять ее исправление. Для этого стоит задать следующие вопросы разработчику, занимавшемуся ее исправлением:
В чем заключалась основная проблема?
Что вызвало эту проблему?
Как проблема была устранена?
Какие другие области вашего приложения могут быть затронуты этим изменением?
Какие файлы были изменены?
Насколько разработчик уверен в фиксе? Является ли он надежным? Даже такая неверифицируемая информация может повлиять на то, как мы будем проводить тестирование.
Специальное примечание: помните, что нам нужно получить контекст от разработчика, но как тестировщик вы не получаете указаний о том, что именно проверять. Это зона ответственности тестировщика. Конечно, если разработчик предлагает протестировать что‑то определенным образом, вы можете это сделать, но ваша роль как опытного тестировщика состоит в том, чтобы использовать свое понимание для тестирования фикса. Теперь, когда мы получили полное представление о том, как была исправлена ошибка, начнем проверку с основного сценария воспроизведения (точные шаги перечислены в исходном описании ошибки). Ниже приведены идеи проверки/тестирования высокого уровня. Обратите внимание, что по мере того, как мы проводим больше тестов и удаляемся от основного сценария ошибки, уровень нашей уверенности в исправлении увеличивается.
Тест 1
Точное состояние программного обеспечения: соблюдайте точные «предварительные условия». В этом случае «Приложение установлено недавно».
Точный ввод: Выполнение точных шагов, перечисленных в ошибках «Шаги воспроизведения».
Убедитесь, что приложение больше не дает сбоев.
На этом мы могли бы остановиться, но у нас не было бы полной уверенности в том, что ошибка полностью исправлена и что мы не добавили новых ошибок, связанных с предыдущей.
Отойдем на один шаг от непосредственного способа воспроизведения ошибки для увеличения нашей уверенности в ее исправлении.
Тест 2
Другое состояние системы: приложение не установлено заново, а пользователь вышел из него и хочет войти заново.
Точный ввод: выполнение точных шагов, перечисленных в ошибках «Шаги воспроизведения».
Убедитесь, что приложение после этого не завершает работу
Пройден еще один шаг: наша уверенность возросла.
Тест 3
Различное состояние — после выхода из системы/после перезапуска приложения и очистки данных приложения.
Различный ввод — Отсутствующие учетные данные/Недействительные учетные данные
Убедитесь в отсутствии неожиданного поведения
Наша уверенность продолжает расти и можно двигаться дальше.
Тест 4
Протестируйте функции/функции входа в систему, такие как:
Забыли пароль
Зарегистрироваться
Проверена еще часть функциональности, и наша уверенность в успешности фикса возросла еще больше.
Тест 5
Двигаясь дальше, мы вступаем в фазу тестирования, которая включает в себя дополнительные тесты нестандартного типа, такие как: (Примечание: я люблю этот тип тестирования, поскольку он очень творческий)
Тестирование с прерыванием — перевод приложения в фоновый режим сразу после нажатия кнопки входа.
Нестабильность сети — изменение соединения во время входа в систему.
Проблемы с синхронизацией. Взаимодействие с элементами пользовательского интерфейса происходит с неестественной скоростью. Пример — быстрое нажатие кнопки входа, затем кнопки «Назад», затем кнопки входа. На этом этапе наша историческая уверенность играет роль в том, продолжаем ли мы тестирование или считаем, что ошибка исправлена. Если уверенность QA будет низкой, мы можем в конечном итоге потратить слишком много времени на тестирование в этом финальном тестовом проходе, и наши усилия в действительности будут мало эффективны.
Какие факторы снижают уверенность?
Низкое качество исходного кода. Как тестировщики, когда мы начинаем тестирование фикса, мы часто оцениваем его качество, основываясь на том, как быстро мы обнаруживаем первую ошибку.
Повторяющиеся фиксы низкого качества приводят к тому, что доверие тестировщика снижается. Если в программном обеспечении при тестировании быстро и часто обнаруживаются ошибки, то это снижает уровень доверия к будущим фиксам, даже если по объективным критериям новый код обладает высоким качеством. Это часто приводит к избыточному тестированию, которое само по себе не дает никакой ценности. Данный пункт не должен быть понят неправильно — возможно, вы найдете ошибки. Но в конечном итоге они окажутся не так уж и важны — все релизы не свободны от багов, а задача тестировщиков — выявлять те из них, которые угрожают качеству использования программного продукта.
Как мы можем повысить нашу уверенность?
Думаю, что мы не можем проводить «правильное» тестирование, если наша уверенность в команде разработчиков недостаточно высока. Нам нужно убедиться, что качество предоставляемых фиксов не ниже определенного уровня, прежде чем можно будет проводить любое «правильное» ручное тестирование. Как это можно сделать?
Автоматизация тестирования — идеальный механизм для установления исходного уровня качества. «Проверка», чтобы убедиться, что все основные функции работают должным образом.
Поддерживайте контакты с разработчиками еще на стадии исправления ошибки, чтобы обеспечить более высокое изначальное качество разработки.
Измеряйте свои усилия по тестированию, чтобы убедиться, что вы не переборщили с тестированием. Научитесь находить золотую середину достаточного количества тестов.
Выявляйте области низкого качества. Ретроспективы — идеальное место для обсуждения вопросов качества с командой. Дайте понять, что у вас нет полной уверенности и что вам нужно что‑то изменить, чтобы восстановить ее.
Помедленнее. О, нет, мы не можем сделать это правильно? Да, мы можем и должны замедлиться, если наша уверенность низка. Если вы слышите что‑то вроде «Контроль качества — это узкое место» в вашей организации, возможно, вам стоит взглянуть на качество кода, которое исторически исходило от вашей команды разработчиков. Возможно, ваши QA‑команды бесконечно тестируют, потому что им не хватает уверенности в работе, исходящей от команды разработчиков, и им приходится тестировать дольше. QA может быть сложно изменить или прекратить тестирование, учитывая отрицательный опыт или низкое доверие к команде.
Если качество вашего кода низкое, уверенность QA в разработке будет низкой, и тогда QA всегда будет узким местом.