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 интерфейс, используя которые возможно делать одни и те же действия.

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