Robot Framework: перезапуск "упавших" тестов

В автоматизированном тестировании есть хорошая практика делать независимые друг от друга автоматизированные тесты.  

Это означает, в частности, то, что вы можете запускать любой автоматический тест отдельно от остальных и он должен работать корректно: сообщать об ошибках, если они есть и сообщать что "все хорошо" если так и есть ) 

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

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

Запись видео с рабочего стола - незаменимые инструменты

Когда есть необходимость записать демо продукта или воспроизведение бага, нам требуется какой-нибудь хороший инструмент.

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

Синхронизация систем ведения отчётов об ошибках

На многих проектах приходится пользоваться одновременно несколькими системами ведения отчётов об ошибках (bug tracking systems) - такими, как JIRA, launchpad, bugzilla и другие. Причина в основном одна - что-то используется "для команды", а что-то - для заказчика или community.
Часто приходится "синхронизировать" описания багов в различных системах "вручную" - это становится настоящим ночным кошмаром, ведь это работа для роботов (они могут делать её регулярно и максимально аккуратно), а у людей есть множество более интересных занятий.

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

(пример скрипта автоматической синхронизации прилагается ;) )

Обучение специалистов по обеспечению качества в Саратове

Открыта регистрация на курсы QA in Software Development!

ссылочка:  http://www.mirantis.ru/qasaratov/

Место проведения: Саратов

Обучение проходит примерно два месяца, по результатам обучения хорошо себя проявившим участникам предлагается трудоустройство в компании Mirantis (берём на работу студентов дневной формы обучения - и не только ;) ).

Мы проводим подобные курсы регулярно и многие, окончившие их, уже работают с нами.

Регистрируемся и приглашаем друзей-знакомых-одногруппников и всех-всех всех желающих!

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

Как мы находим баги - или "а не роботы ли мы часом?" )

Навеяно 'Звездным крейсером 'Галактика''

Существует два(по сути один, но!) пути, по которым идёт наше сознание, когда мы находим дефект в программном обеспечении.

Путь первый, самый простой - мы хотели что-то сделать, но не можем.

Например, нажимаем на кнопку и ожидаем появления новой формочки для заполнения, а её нет. Как же, конечно - баг.

Или после определённой последовательности действий ожидаем увидеть какую-то надпись, какую-нибудь анимацию, какую-то реакцию нашей системы.

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

Второй путь интереснее.

Мы что-то делаем (или даже не делаем, оно само) и тут появляется что-то подозрительное. Например, мы видим поплывшую верстку. Это, по-сути, вариация первого пути, но здесь есть принципиальное отличие. Мы попали на эту страницу с другой целью.

Мы просто шли проверять что можем обновить пароль пользователя, но тут на середине нашей проверки мы видим красную надпись на половину экрана с какой-нибудь SQL-ошибкой.

Пароль мы поменять сможем, и если бы мы просто шли первым путём - то мы бы проигнорировали эту ошибку. Второй путь включает в себя переключение внимания на окружающую нас обстановку. Мы постоянно анализируем всё, что вокруг нас.

Анализ архитектуры на основе анализа используемой модели данных

Да, заголовок получился длинным. Ночь - голова работает иначе чем рано утром, в ароматах крепкого кофе.

Довелось мне сегодня получить интереснейший опыт, хочу им поделиться.

Вот уже несколько дней, а может и недель - в agile на динамичном проекте время летит незаметно - мы всей командой размышляем над одним сложным вопросом.

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

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

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

Если ты можешь, то не обязательно должен

Отличная статья попалась мне пару дней назад на просторах Интернета.

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

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

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

Конечно, впадать в крайности не следует и для этого есть несколько причин.

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

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

Тестирование кнопки "Далее"

Ещё один баг в коллекцию

Специалист обеспечения качества это не просто должность. После первого обнаруженного бага уже сложно остановиться.
Даже после рабочего дня, пользуясь обычными сайтами, мы постоянно встречаем баги, они как по вежливой просьбе выходят к нам, чувствуя родственную душу )
И у каждого тестировщика есть коллекция багов, своих, "любимых".
Вот у меня, например, есть в коллекции баги с сайтов Антивируса Doctor Web, американского центра оформления виз, cisco.com, на множестве сайтов компаний по созданию сайтов...
Кстати, ещё один эпичный баг был обнаружен мной при тестировании бета версии Windows 8 в программе, предназначенной для отправки отчета об обнаруженных дефектах в Microsoft.
Но больше всего багов, только не обижайтесь ;) - на сайтах по тестированию.
У меня в коллекции есть баги с сайта журнала по тестированию и портала software-testing.ru (на портале уже исправлены).

И сегодня я обнаружил (хотя он и не скрывался) баг на сайте MTS. Этот баг заставил меня вспомнить все баги из "Аллеи Славы" и сподвиг написать этот пост.
И так, знакомьтесь, вот он - публикую в целях демонстрации, это не уязвимость безопасности, компания не должна пострадать:

Здравствуйте, на вашем сайте обнаружен баг.
Как воспроизвести:
1. Открываем страницу https://pay.mts.ru/webportal/payments/2770
2. Указываем номер телефона и сумму платежа, нажимаем "Далее".

Наблюдаемый результат:
Рисунок кредитной карты, изображающий место, на котором указан секретный код CVC2 обрезан.
(пожалуйста, смотрите прикреплённый скриншот для более детальной информации)

Сотрудники MTS очень быстро отреагировали на отчет о баге, так что ждём hot fix.

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

Кстати, в блогах по тестированию тоже множество опечаток и ошибок. Не расслабляемся )

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

Специалисты по тестированию отлично знают, что часто бывают проекты, на которых большую часть времени мы тратим не на само тестирование, но, в основном на две вещи: настройка продукта, подготовка его к тестированию и воспроизведение трудновоспроизводимых багов (да, да, это далеко не всё, что съедает наше время, но это те элементы, которые бы хотелось минимизировать)
Участвуя в 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.
    Отличный элементарный интерфейс и серьёзные возможности.

Selenium тесты на linux server

Часто есть необходимость запускать автоматизированные тесты для веб интерфейсов на Linux сервере без графической оболочки (например, на сервере непрерывной интеграции)

В сети есть хорошая инструкция, которую я себе добавил в закладки и решил поделиться со всеми: ссылочка

Краткая инструкция (на случай недоступности ссылки, в такие времена живём, на днях https://pypi.python.org лежал)

1. Устанавливаем все необходимые пакеты:

apt-get -y install xvfb x11-xkb-utils xfonts-100dpi \

                           xfonts-75dpi xfonts-scalable \

                           xfonts-cyrillic xserver-xorg-core

2. Настраиваем

Xvfb -fp /usr/share/fonts/X11/misc/ :22 -screen 0 1024x768x16 2>&1 

export DISPLAY=:22

3. Готово, если запустить firefox + webdriver, то браузер запускается в виртуальном рабочем столе.

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

Python + BDD = Behave?

О преимуществе разработки тестов в виде историй использования я писал здесь.

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

Давайте напишем простую историю использования в нотации Gherkin.

   Feature: Administrative web interface

     Scenario: Login
          When user opens browser and navigates on the page "site.com"
              and user "admin" enters login and password in the login form 
              and user clicks "Login" 
            Then user should see the administrative web interface 

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

BDD. Тестирование на основе историй использования

При создании набора приемочных тестов необходимо учитывать множество факторов и применение непрерывной интеграции (CI) на проекте накладывает дополнительные требования для организации автоматизированных тестов.

Такими дополнительными требованиями можно назвать, например:
1. Скорость разработки и отладки тестов.
        Такие тесты необходимы как можно раньше, их приоритет выше остальных автоматизированных тестов. Запуск тестов после каждого нового изменения в продукте позволяет быстро реагировать на появление проблем и убедиться, что новая версия проходит хотя бы приемочное тестирование.
2. Легкость взаимодействия с системой непрерывной интеграцией и другими компонентами, задействованными на проекте.
        Необходима простота запуска тестов и анализа результатов. Взаимодействие с популярными фреймворками и плагинами и работа с привычными форматами файлов могут существенно облегчить жизнь и сохранить ваше время.
3. Стабильность тестов.
        Это требование применимо к любым тестам, но к приёмочным оно особенно строго оценивается. Автоматизированные приёмочные тесты должны сообщать о проблемах, которые действительно есть на проекте, у вас не будет времени анализировать результаты после каждого запуска тестов и проверять все упавшие тесты. Просто потому что они запускаются в час ночи, когда вы спите.
        Одновременно с этим мы должны помнить, что еще больше трудностей возникнет, если автоматизированные тесты будут ложно-положительными, потому что в этом случае мы теряем сразу все преимущества непрерывной интеграции, снова тратим время на обнаружение проблемы и поиска причин ее возникновения.

Selenium +

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

Сегодня мы говорим о Selenium и о том, как разрабатываются автоматизированные тесты с использованием таких языков программирования, как Java и Python.

Когда я экспериментировал с Selenium Web Driver на питоне, передо мной явно вставала проблема нечитаемого кода автоматических тестов. Я экспериментировал, писал простые тесты, но явно видел, что это не то, что я хотел бы использовать в своей работе.

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

А потом я посетил сайт pyvideo.org, с которого позаимствовал это видео с выступлением одного из экспертов Selenium

Что интересно тестировщикам?

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

Вы можете оставлять комментарии, у вас точно есть хорошие идеи на этот счёт.