Как профессионально протестировать систему домашней автоматизации?

Как профессионально протестировать систему домашней автоматизации?

Полезные советы от гуру в тестировании аудио/видео систем и систем управления.

Руководство по тому, как сделать клиентов довольнее, а прибыль больше.

*Эта статья не является руководством по поиску багов в системе, как может показаться.

Тестирование системы домашней автоматизации является сложной задачей. По моему опыту много профессиональных инсталляторов не проводят тестирование должным образом, оставляют клиентов неудовлетворёнными и в результате снижают итоговую прибыль проекта. Вот список того, что я наблюдал за последние 12 лет на объектах в инсталляциях аудио/видео оборудования и систем управления:

• Не проводится многоуровневое тестирование
• Отсутствует план тестирования в письменном виде
• Тестирование проводит программист вместо отдельного человека
• План тестирования не содержит методологии или недостаточно детален
• После внесения изменений не выполняется повторное тестирование

Рассмотрим каждый из этих пунктов подробнее

Многоуровневое тестирование

Тестирование – это не просто поиск багов в системе автоматизации. Это проверка того насколько проект соответствует потребностям и ожиданиям клиента. Поэтому первый уровень тестирования должен выявлять насколько система управления удовлетворяет потребности конечного заказчика.
Например, если главным пожеланием заказчика было улучшение безопасности дома и удобное управления климатом, а система обеспечивает прекрасный мультирум по всему дому и управление аудио/видео техникой без интеграции климата, то именно это является главной проблемой.

Вторым уровнем тестирования должна проверка на удобство использования системы. Те вещи, которые имеют смыл для программиста далеко не всегда имеют смысл для конечного заказчика. К сожалению, мой опыт говорит о том, что программисты имеют тенденцию к усложнению системы.
Например, при использовании голосового управления для включения света с большим количеством групп, опытный программист при получении команды «включи свет», настроит систему таким образом, что она задаст уточняющий вопрос: «какой именно свет вы хотите включить?». И система задаст уточняющий вопрос, даже если для комнаты назначена группа свет по-умолчанию с названием «свет» и именно её клиент захочет включать/выключать в 99%: случаев.
Разум инженера работает совсем не так, как разум конечного заказчика, идущего по дому в темноте и желающего просто включить свет при помощи простой команды. Логика инженера, скорее всего, заставит конечного пользователя выучить более длинные команды или научиться совершать длительные путешествия по дому в темноте, аккуратно обходя мебель.
Наконец, третий уровень тестирования состоит в том, чтобы проверить то, что всё сделано в интерфейсе на самом деле работает, а это означает, что должна быть проверена каждая функция.

Письменный план тестирования

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

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

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

 Программист не должен являться единственным человеком, который проводит тестирование. Программист имеет слишком много знаний о том, как система работает и предположения, сделанные на основе этих знаний, мешают процессу тестирования. Например, программист, который проверил, что кнопка Play в интерфейсе Blu-ray плеера работает корректно может слишком легко предположить, что и все остальные кнопки управления транспортом (Pause, stop, rewind и fast forward) тоже будут работать корректно.
Это вовсе не означает, что программисты не должны принимать участие в процессе тестирования. Они должны проверять всё, что они делают, но при этом они не должны быть единственными, кто выполняет тестирование.

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

Повторное тестирование

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

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

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

Источник: CEPro https://www.cepro.com/article/how_to_test_a_home_automation_system?utm_source=CEPWeekly&utm_...

Возврат к списку



Создать новый черновик

Обновить черновик

Черновик успешно обновлен

Перейти в черновики

Черновик успешно удален

Черновик скопирован в корзину

Перейти в корзину