Вы когда-нибудь слышали, как кто-то говорил: «Мы не можем это проверить - это вне нашей компетенции»? Такие фразы иногда звучат в командах, но именно это помогает посмотреть на сложившуюся ситуацию под другим углом.
Обеспечение качества продукта - это совместное усилие, но задача тестировщиков - убедиться, что все сделано правильно. Когда кто-то говорит, что функция не проверяется с помощью методов, которые мы, тестировщики, используем, она не освобождает нас от ответственности за тестирование; это еще наша работа. Но по некоторым причинам иногда тестировщики считают, что оставлять эту задачу нерешенной - нормально, и это влечет за собой новые проблемы.
Выход за пределы функционального тестирования
Рассмотрим тему на примере компании, которая разрабатывала новый встроенный продукт, он был своего рода революционным в интернет-индустрии (IoT), и наиболее важной частью этого был разработанный алгоритм.
До этого времени тестировщики в компании использовали только функциональное тестирование, но алгоритм нового продукта невозможно было протестировать только с помощью него.
Коренная проблема была в отсутствии общих возможностей тестирования. У тестировщиков не было никакого механизма или навыка для проверки этого алгоритма. Вот тогда и начался квест.
Изучение исходного кода
Поскольку функциональное тестирование не было действенным вариантом, было принято решение понять исходный код и посмотреть, как можно его протестировать. Но к сожалению исходный код не был напрямую доступен никому, кроме команды разработчиков, по этому IDE была настроена в режиме эмуляции для запуска кода на продукте, а отладчик подключен к фактическому устройству. Потребовалось некоторое время, но все же удалось запустить базу кода на устройстве.
Через несколько дней поток управления и общая архитектура были изучены. Как только условия алгоритма стали ясны, его стало легко реконструировать.
Тогда стало понятно, что отладчик можно использовать в качестве инструмента тестирования для проверки правильности алгоритма.
Важно помнить, что вы не должны каждый раз проводить тестирование по шаблону. Цель состоит в том, чтобы протестировать продукт, используя любые средства. Даже если придется ввести ошибку в код.
Анализ граничных значений в действии
В зависимости от группы переменных алгоритм решал, что показывать на экране. Все переменные и их точки отсечения были помещены в электронную таблицу, давая четкое представление о границах для каждой переменной. Как только тесты были выше и ниже каждого порога, просто нужно было манипулировать переменными на базе кода в нужное время.
Написание правильного значения было важным аспектом, и в то же время нужно, чтобы в потоке управления было введено тестовое значение. Поскольку эти тесты проводились внутри кода, нужно было держать их как можно ближе к реальной пользовательской среде. Даже при проведении тестов на уровне бизнес-логики, это хорошая идея, чтобы максимально приблизить их к реальному сценарию.
Демонстрация ценности тестирования
Принять и получить одобрение идеи тестировщиков отлаживать исходный код и выполнять тесты в базе кода было непросто. Это означало, что нужно было завершить все запланированные цели вместе с этими исследованиями. Итог заключалась в том, чтобы фиксировать проблемы в алгоритме и демонстрировать эффективность процесса. Нужно было получить одобрение на включение этих тестов в тестовый регулярный процесс, и это было бы легко, как только результаты стали очевидны.
Это был риск, который мы приняли: мы делали ставку на поиск актуальных проблем в алгоритме. Как только мы нашли несколько, проект был привлечен в центр внимания. Он был хорошо принят, и все видели в нем четкую ценность. С тех пор он является неотъемлемой частью процесса тестирования продукта.
Задача тестировщика - проверить
Роль тестировщика заключается в обеспечении надлежащего тестирования продукта. Эта мера должна учитывать скорее не то, что мы можем проверить, а то, что нужно проверить.
Методы тестирования являются рекомендациями, которые помогут с тестированием, а не жесткими правилами, которые должны соблюдаться.
Во время тестирования убедитесь, что тест максимально приближен к реальным условиям конечного пользователя. И, наконец, чтобы ускорить принятие вашего нового процесса, покажите преимущества, а не просто изложите их - это имеет реальное значение.
28 июня/2018
