Опыт настройки облаков - записки на память

Специалисты по тестированию отлично знают, что часто бывают проекты, на которых большую часть времени мы тратим не на само тестирование, но, в основном на две вещи: настройка продукта, подготовка его к тестированию и воспроизведение трудновоспроизводимых багов (да, да, это далеко не всё, что съедает наше время, но это те элементы, которые бы хотелось минимизировать)
Участвуя в open source проекте OpenStack Murano, приходится многократно настраивать не только тестируемый продукт, но и облачную платформу OpenStack, на которой работает наш сервис. За несколько месяцев у меня в блокноте набрались заметки о том, как же учесть все эти маленькие хитрости, которые когда-то отнимали много времени на настройку. Часть из них, ту самую, которую может быть интересна не только мне, я решил опубликовать в дневнике.

Установка OpenStack с использованием проекта devstack (и некоторые хитрости)

Виртуализация. Развёртывание OpenStack + Heat

Вчера я выступал на конференции по автоматизации тестирования AutoConfetQA, немного рассказывая, в частности, о системе OpenStack и развёртывании виртуальных машин с помощью её компонента Heat.

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

К нашему счастью, уже есть готовая статья по настройке этого решения на Ubuntu 12.04, вот она.

О чём умолчали авторы этого руководства - вам точно потребуется проверить файл /etc/hosts, в нём необходимо добавить имя машины в строчку '127.0.0.1       localhost', в конечном итоге должно получиться что-то такое: '127.0.0.1       localhost  ss1283'.

Иначе "кролик" не сможет стартовать и всё сломается).

Вообще, это серьёзная проблема всех сложных систем, когда есть множество зависимых друг от друга компонентов. Стоит сломаться одному компоненту (или, например, кто-то его неправильно настроил) - и нормальная работа всей системы парализована.

(спойлер: о чём ещё умолчали авторы и как всем этим управлять)

Облачный плеер

Пока у меня устанавливается Ubuntu 12.04 на сервере в Соединённых Штатах, я читал статью и открыл для себя облачный плеер.

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

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

До чего дошёл прогресс - уже плееры музыкальные в облаках запускают.

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

И конечно, возможность вставлять новые виджеты в блог )

Компьютер, управляемый голосом

Насмотревшись фильмов про железного человека (и увлекаясь всю жизнь фантастикой) захотел обучить свой компьютер понимать меня "с полуслова".

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

Начнём с ролика, авторы которого не лишены чувства юмора:

Автоматический поиск поля ввода на странице

Идея написать искусственный интеллект не может не цеплять.

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

Проекты бывают разные. Некоторые веб формы содержат сложные элементы, некоторые формы очень просты.

Когда мы вновь и вновь определяем локаторы полей, которые имеют прикрепленные к ним надписи, невольно возникает мысль - эй, а почему автоматические тесты не могут сами понять куда надо ввести значение?

Вот поле, над ним надпись: Имя. Почему бы не писать в тесте "Ввести в поле Имя значение "Вася"", а задачу найти это поле, определить его идентификатор и ввести значение в него предоставить автоматизированным тестам?

Вместо этого мы тратим свое время, усердно записывая идентификаторы элементов (и даже придумываем множество способов делать это разными путями)

(спойлер: пример кода на Python прилагается)

Первый опыт внедрения TDD

Один из моих проектов - программа моделирования кристаллизации в бесконечной системе жестких сфер.

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

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

"у нас нет времени писать юнит тесты, надо делать новый функционал"

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

Через десять минут после принятия решения о создании юнит-тестов в голове появились новые мысли. Новый взгляд на работу с системой помог увидеть существенное изменение архитектуры, которое необходимо сделать для того чтобы последующие изменения было легче вносить в код.

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

Например, написание какого-нибудь скрипта, который выполняет повседневные задачи. Мы откладываем это "на потом", или вообще игнорируем, говоря что "да я и руками все сделаю". И потом постоянно теряем на этом время.

Или не приступаем к рефакторингу кода тестов, по принципу "работает - не трогай". А работает оно медленно и не эффективно, мы знаем, но ничего с этим не делаем.

Вот вам интересное видео, это интервью с крутым дизайнером компьютерных игр, оно вдохновляет меня уже второй день )

http://www.fzdschool.com/programs_design_cinema.html

Качество

    Качество это не контроль и гарантии, не информация.

    Когда перед нами качественная вещь, вот мы вертим ее в руках. О чем мы думаем и что представляем?

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

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


    И, кстати, сегодня я полюбил mongoDB.
    Отличный элементарный интерфейс и серьёзные возможности.