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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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