Секреты тестирования интерфейсов в ТКС Банке

Постараюсь рассказать в общих чертах о том, как выглядит процесс тестирования интерфейсов в ТКС банке.

Смутное прошлое

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

Очаровательное настоящее

Наш коллектив сильно изменился – маленький отдел веб-разработки стал в разы больше. Изменился и сам процесс — теперь наши интерфейсы покрыты тестами как внутри (код), так и снаружи. И да, у нас есть code review, а разработку задач осуществляем в ветках, пишем старательно документацию в wiki и генерим JS DOC.

Тестирование кода

Очевидно, там, где есть обработка данных, различные расчеты – должны быть и unit-тесты. Да, что там скромничать – где есть код, должны быть тесты.

Есть различные подходы к разработке через тестирование: TDD, BDD и др. Не будем разбираться, чем они отличаются друг от друга, а остановимся подробнее на нашем процессе тестирования.

За сборку статики и запуск тестов у нас отвечает Grunt. Мы используем связку Grunt + Karma + PhantomJS +Jasmin + Sinon + CoffeeScript. Да, вы не ослышались CoffeeScript.

Когда то у нас были бурные дискуссии о том, что CS красивый, модный и сильно ускоряет разработку, но все же по многим причинам мы отказались от этой дурной затеи писать весь код на CS. Но! Мы пишем тесты на CS по одной основной причине – писать и читать простыню callbacks куда приятнее на CS, чем на JS. Код получается более компактным и приятным.

Jasmine – выбрали за простоту, Sinon – для эмулирования запросов к API, Karma – просто крутой test runner, а PhantomJS – для запуска автотестов из Team City.

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

У нас есть Team City, который по нашему указанию автоматически запускает сборку и тесты для каждой ветки переданной на code review и если что-то пойдет не так, разработчик об этом узнает и битый код не попадет в master.
Все наши тесты разбиты по модулям. Модуль – это тест-кейсы + конфига для запуска. Такой подход дает возможность запускать нужные тесты по отдельности, либо, используя общий файл конфигурации, запустить все сразу.

Есть определенные моменты, когда хочется покрыть юнит-тестами DOM, и нам в этом помогает CS, своей чудной возможность многострочных комментариев. Вы просто пишите нужный HTML-код в тест-кейсе или в отдельном файле, а потом подключаете его там, где это нужно.

Тестирование GUI

Как написал ранее, разработчики не покрывают юнит тестами работу с DOM, потому что считают это бессмысленной затеей. Для этого в ТКС Банке есть отдел тестирования, он и занимается тестированием визуальной части интерфейса.

Есть два типа тестирования:

• Вручную
• Автотесты

С первым вариантом все понятно, кликаем пока мышка не сломается, и не выскочат кнопки из клавиатуры. Со вторым – немного сложнее…

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

Наши автотесты используют Selenium WebDriver. Мы разработали свой фреймворк для тестирования «морды», основанный на связке популярных и проверенных решений, позволяющий писать максимально чистые и прозрачные тесты, исключающий дублирование кода и загоняющий в жесткие рамки проектирования и построения фреймворка, благодаря которым достигается гибкость конечных тестов и простота поддержки их работоспособности.

Непосредственно само тестирование проходит в развернутой распределенной сети selenium grid, где запущенные машины с определенной ОС и набором версий браузеров ожидают своего часа (на деле конечно быстрее) славы. Запускаются тесты из TeamCity, часть – автоматически, смотрящие на свой триггер сборки, как, к примеру, смоук-тесты, запускающиеся после каждого деплоя тестового стенда, часть – вручную, по востребованию, например, более громоздкие тесты из набора тестов на регресс, позволяющие, выявить привнесенные баги. Кстати, о багах. Автотесты охватывают не только поверхностное тестирование GUI портала, большинство автотестов комплексные, и охватывают тестирование на уровне БД и веб-сервисов. Так что в случае падения автотеста, тестировщик получает не только скриншот с информацией «сломалось тут, смотри дальше сам», но и вменяемый отчет с информацией по полученным/ушедшим, к примеру, данным в БД.

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

Буду признателен замечаниям и комментариям по делу, для формирования следующих статей, где более подробно расскажем, как и что у нас устроено.