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

Открыта регистрация на курсы 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 (и некоторые хитрости)