Приводим доклад khroliz Игоря Хрола, компания Wargaming, Минск, с конференции SQA Days 15.

Видео доклада:
vimeo.com/93944414

Презентация:
www.slideshare.net/slideshow/embed_code/33725306#

Я 8 лет работаю в этой отрасли, и я считаю, что у нас есть проблемы )

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




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

В первую очередь, я призываю вас вспомнить: Кто мы? Software testing engineer. Инженеры. То есть мы не называемся тестерами, тестировщиками и проч., мы — инженеры. И я считаю, что ситуацию как раз могут менять инженеры своими техническими навыками, своими подходами.

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

Название играет роль.
• Автоматизация тестирования (мы что-то делаем руками, и мы это автоматизируем)
• Автоматическое тестирование (что он нас хочет бизнес? чтобы тестирование шло как-то само, автоматом, а мы там логи смотрели и проч. Цель — не автоматизировать тестирование, а сделать тестирование автоматическим)
• Эффективное автоматическое тестирование

Рассмотрим абстрактный проект в вакууме.
Это — модель, она описывает жизненную ситуацию в какой-то мере приближения.
У нас есть 5 модулей. В первом надо протестировать 5 вариантов, во втором — 8, а третьем — 2 варианта и т.д. Всего надо провести 800 тестов, чтобы убедиться, что все работает.



Меняем цифры на V: V1 * V2* V3*...*Vn В итоге Vn — средняя сложность модуля. Что такое Vn? Математическая сложность и экспонента. Все строится на том, что задача, имеющая такую сложность решается очень плохо.
Экспоненциальная сложность. См график.



Зеленый график, который долгое время держится ниже других, но в какой-то момент уходит стремительно вверх. И когда мы тестируем методом черного ящика, когда мы пытаемся перебрать все варианты, у нас получается, что черный ящик (сложность такого тестирования) — это экспоненциальная сложность. У нас появляется много автотестов, которые работают часами, что мы дальше делаем? Запускаем их параллельно. Мы делим эту сложность на константу. У нас та же экспонента, но чуть-чуть уменьшенная константа. То есть это не решает проблему.



Разделяй и властвуй

Давайте посмотрим на нашу задачу с другой стороны.
У нас было 26 тестов (если тестировать каждый модуль по-отдельности). Но вы скажете, что надо убедиться, что все это вместе работает. Хорошо, давайте протестируем отдельным тест-кейсом каждую связь и прогоним какой-нибудь сквозной сценарий. Получился 31 тест. В итоге, мы экспоненциальную сложность меняем на линейную. И задача становится эффективно решаема. То есть если мы плохо тестировали, и наняли еще 10 тестировщиков, то мы просто распараллелили на 10, а если мы поменяли саму сложность задачи, то не надо так сильно увеличивать ресурсы, требуемые для тестирования.

Если у нас есть некая абстрактная система, которая имеет по одному варианту, а в конце — 10, если перемножим, то у нас 10 тест-кейсов, а суммарно — 14. А плюс еще связи проверить — 19. Но тесты стали проще. Вместо одного длинного теста, мы пишем 10 маленьких. То есть по факту сложность тестов все равно упрощается.



“Пирамида” автоматизации.

Если мы не будем строить наши тесты на этой “пирамиде”, мы получим экспоненциальную сложность нашей задачи, нашего тестирования. Самый мелкий модуль декомпозиции задач — это отдельные классы, отдельные методы. Главное — это декомпозиция задач. Если она — односложна, то мы получаем умножение, если нет, то мы получаем сложение, и в долгосрочной перспективе это будет лучше.

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



Проект из жизни.
Siebel, Oracle — жесткое enterprise решение, это был проект по кастомизации, по внедрению мобильного оператору решений на основе технологий Siebel. До того как я присоединился к проекту, тесты писались на QTP. Они представляли из себя такую структуру: там был внутренний API, и тесты ходят, кликают на кнопочки, в середине — черный ящик, и снизу база данных. Достаточно типовая картина.



Как результат: тесты долгие, тесты нестабильные. Пришла задача: оптимизировать предусловия, которые делаются часами.

Я написал на java скриптик, который отправляет GET запрос, парсит XML, смотрит XML, отправляет еще один GET запрос и т.д. Тесты стали работать 20 минут и стали хорошо параллелиться.

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

Вопрос “не видно” решился как в старом анекдоте: “Вам шашечки или ехать?” Вам на тесты смотреть, или надо тестирование проводить? Т.е. тут вопрос: мы хотим автоматическое тестирование или автоматизировать тестирование?

Структура решения: Java + TestNG + Maven + HttpClient. Положить несколько уровней абстракций, чтобы не работать напрямую, запросы не писать, а работать с сущностями, которые специфичны для Siebel’а.



Но оказалось, что от браузера не уйти, и часть логики оказалась реализована в самом браузере. Т.е. часть логики была на сервере, а часть логики — в браузере. Поэтому появился Selenium. Но зная о том, что браузер — это долго, нестабильно и непрочно, мы это делали аккуратно. Запускали только тогда, когда реально нужен браузер, когда в тест-кейсе появляется логика, которая реализована в браузере, и которую мы хотим проверить (около 3% сценариев). Также реиспользуется headless-сессия с безбраузерного взаимодействия.

Дальше декомпозируем эту задачу на какие-то кусочки. Оказалось, что верстка браузера генерируется самим Siebel’ом. И нам не важно, чтобы нажатие на кнопку было реальным, потому что это уже разработано в Siebel’е, это протестировано в Siebel’е, нам надо просто отбросить лишнее и тестировать только то, что мы делали.
Оказалось, что для разработки браузерной логики есть API (оф. документация Oracle): хочешь что-то сделать в UI — вызови вот тот метод.



База данных.
Это — самый быстрый способ работать с системой, но лучше туда напрямую не писать (но это была специфика нашего проекта). Какие-то изменения в базе мы делали через специальные выверенные stored procedures, и это хорошо подходит для проверок.

Web-сервисы
JAX-WS — это протокол в Java для работы с web-сервисом. Вместо того чтобы тестировать наш Siebel в контексте всех других систем, мы заглушили все внешние взаимодействия, и когда нам надо было проверить, что из Siebel’а что-то уходит, мы смотрели это не на каких-то внешних системах, а на заглушках. Также мы отправляли java запросы на web-сервисы для проверки исходящей информации.

Наш сервер состоит из двух частей: Web-сервер и Application-сервер. Web-сервер отвечает за верстку и отсылку ответов, а Application-сервер за логику приложения. И есть доступ к логике через Java Data Bean.И через нее мы получили полный программный интерфейс для создания логики приложений в Siebel’е из Java.

Тесты производительности.
Т.к. наши тесты пишутся на java, т.к. они хорошо параллелятся, мы можем просто “натравить” на JMeter наши тесты, и по сути нагрузить систему функциональными тестами. Также тесты суппортились вместе с поддержкой функциональных тестов. Т.е. если для нового билда нужны были новые версии скриптов, мы все равно для проведения функциональных тестов эти скрипты обновляем.



Мы разобрались, как работает наш стек технологий, поняли варианты взаимодействий, и мы понимали, что чем ниже мы опускаемся, тем более быстро и надежно.
В результате мы получили:
• быстрые тесты
• предсказуемые результаты которые легко масштабируются
• возможность взаимодействия с Siebel на любом уровне

Мне бы не хотелось, чтобы мой доклад воспринимался как инструкция: “Как работать с Siebel “. Мне бы хотелось, чтобы вы глянули на свой стек технологий и посмотрели, что там “под капотом”, т.к. это делает нашу работу качественней и интересней.
Взгляд на тестирование со стороны реализации системы позволяет:
• уменьшить сложность самой задачи тестирования
• уменьшить сложность и длину сценариев
• увеличить скорость и стабильность работы
• найти новые области применения автотестов