Home

Автор: Брэд Томпсон (Brad Thompson)

Оригинал статьи: http://thinktesting.com/articles/role-of-confidence-in-software-testing/

Перевод: Ольга Алифанова

Уверенность: "Твёрдая вера в кого-что-н., убеждённость". (http://dic.academic.ru/)

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

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

Высокая уверенность: проводим минимально необходимое тестирование перед выпуском в релиз (это, конечно, не касается жизненно критического ПО).

Низкая уверенность: мы тестируем чересчур много, потому что раньше эта команда выдавала код плохого качества, даже если сейчас с кодом все в порядке.

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

Для иллюстрации этого момента давайте рассмотрим подход, который я использую для тестирования и верификации фиксов.

Пример: мобильное приложение, требующее авторизации пользователей.

Допустим, у нас есть мобильное приложение, которое требует авторизации пользователей.

Воображаемый баг, который мы верифицируем, выглядит так:

Заголовок: Экран авторизации – приложение падает после нажатия на кнопку входа.

Предусловия:

Приложение только что установлено.

Шаги для воспроизведения:

1. Запустить приложение и перейти к экрану авторизации.
2. Ввести валидные почту и пароль, существующие в базе.
3. Нажать на "Вход".

Результат:

Приложение падает.

Прежде чем начать верификацию

Когда баг помечен как исправленный, очень важно глубже разобраться в нем перед тем, как верифицировать фикс. Для этого мы задаем вопросы разработчику, правившему баг:

• В чем была проблема?
• Чем она была вызвана?
• Как исправлялся баг?
• Какие области ПО могли быть затронуты фиксом?
• Какой файл менялся?
• Насколько разработчик уверен в фиксе? Убежден ли он, что проблема решена? Даже эта информация может повлиять на то, как мы будем тестировать.

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

Теперь мы полностью понимаем, что именно и как исправлялось. Давайте начнем с проверки основной проблемы (шаги бага описаны мною выше). Ниже – высокоуровневые идеи тестов, начинающиеся со специфичных проверок и переходящие в более общие, как луковичка. Заметьте, что чем больше тестов мы проводим, тем дальше мы отходим от изначальной проблемы и тем выше наша уверенность в фиксе.

Тест 1.

• Точное состояние приложения: следуем "Предусловиям". В данном случае "Приложение только что установлено".
• Точные действия: в точности следуем шагам, описанным выше.
• Убеждаемся, что приложение больше не падает.
• Можно было бы тут и остановиться, но мы пока не очень-то уверены, что баг действительно исправлен и не привел с собой новых друзей.

Движемся на уровень дальше от проблемы: Наша уверенность в фиксе возрастает.

Тест 2.

• Меняем состояние приложения: Приложение установлено заранее, но пользователь не авторизован.
• Точные действия: в точности следуем шагам, описанным выше.
• Убеждаемся, что приложение не падает.

Движемся на уровень дальше от проблемы: Наша уверенность в фиксе возрастает.

Тест 3.

• Меняем состояние приложения: После выхода из системы/после рестарта системы и очистки данных приложения.
• Меняем последовательность действий: недостаточные данные для входа или неверные данные.
• Убеждаемся, что не происходит ничего неожиданного.

Движемся на уровень дальше от проблемы: Наша уверенность в фиксе возрастает.

Тест 4.

Тестирование функциональности, близкой к авторизации, например:

• Сброс пароля
• Регистрация

Движемся на уровень дальше от проблемы: Наша уверенность в фиксе возрастает.

Тест 5.

Переходим на последний, верхний уровень – к стадии тестирования, которая требует более креативных тестов, например, таких (обожаю этот тип тестирования – он наиболее творческий):

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

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

Почему уверенность понижается?

• Изначально низкое качество кода, переданного в тестирование. Как тестировщики, мы будем судить качество фикса, переданного нам, основываясь на скорости, с которой мы изначально нашли этот баг.
• Регулярно низкое качество ПО, выходящего из разработки, заставляет тестировщиков – совершенно справедливо – тестировать чересчур много, потому что это необходимо. Если баги быстро и рутинно находятся, мы будем подозревать страшное, даже если разработка начнет выдавать нам продукт хорошего качества.

Эти предпосылки могут привести к излишнему тестированию, даже если переданный в тестирование продукт достаточно качественный. Такое тестирование не будет иметь особой ценности. Не поймите меня неправильно – может, вы и найдете баги, но это будут, скорее всего, мелочи, а не Must Fix-проблемы. В любом ПО есть баги, наша задача – определить значимые баги, угрожающие качеству продукта.

Как повысить нашу уверенность?

Я считаю, что мы можем тестировать ровно столько, сколько нужно, тогда и только тогда, когда мы свято верим в наших разработчиков. Нам нужно убедиться, что мы добились приемлемого качества еще до того, как мы "достаточно" протестируем приложение. Как это сделать?

1. Автотесты – отличный способ убедиться, что продукт уже более-менее приемлемого качества. Запустите эти проверки, чтобы убедиться в работе базовых функций.
2. Проверните "сдвиг влево" и сотрудничайте с разработчиками, когда они внедряют фичу, чтобы убедиться, что она изначально будет качественной.
3. Замеряйте свои усилия по тестированию, чтобы убедиться, что вы не перетрудились. Научитесь чувствовать, когда надо остановиться.
4. Доносите до команды информацию о некачественных областях продукта. Ретроспективы – прекрасный способ поговорить о проблемах качества с командой. Дайте им знать, что вы не уверены в том, что продукт хорош, и что должно измениться, чтобы его качество улучшилось.
5. Не торопитесь. О нет, это невозможно? Вполне возможно и необходимо, если наша уверенность в качестве продукта невелика.

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

При плохом качестве кода уверенность тестировщиков в разработчиках падает, и QA всегда будут "бутылочным горлом".

Помните об этом.

Обсудить в форуме