Данный доклад является логическим продолжением доклада с предыдущей конференции SQA Days 27. В предыдущем докладе мы с вами рассмотрели историю, узнали базовую теорию, а также, на словах обсудили некоторые баги данных и даже отловили их “на бумаге”.

Пришло время практики. Гладко было на бумаге, да забыли про овраги? Давайте посмотрим.

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

В мире компьютерных технологий вы можете встретить данные повсеместно. Это могут быть хорошо всем знакомые записи баз данных, реляционных и NoSQL; содержимое потоков данных; топики в очередях и файлы в локальных и распределенных файловых системах. Данные подготавливаются как людьми, так и программами. Потребителями данных также могут быть как люди, так и программы. На основе данных делаются прогнозы, планируются какие-то действия.

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

Давайте рассмотрим методы, которые помогут нам быть уверенными в данных - как попадающих в нашу систему, так и произведенными ей.

Последнее время все чаще слышны разговоры про проекты в области Больших Данных или как мы говорим в простонародье - БигДата проекты (BigData projects).

Работая в оутсорсинге я вижу всё больший спрос на специалистов в по контролю качества в таких проектах.

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

Некоторое время назад я рассказывал о сложностях в управлении тестовыми данными.

Я упоминал одно из возможных решений, которое было применено на одном из наших проектов,  под названием Data Pools.

Прошло время и этот подход стал публично доступен и воплотился в общедоступную java-библиотеку.
https://github.com/griddynamics/test-data-pool

О чем, собственно, будет рассказ:

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

- объяснение каким образом подход с использовангием Data Pools приносит результаты;

- как воспользоваться библиотекой при написании автоматизированных тестов:

- каким образом данный инструмент применим при мануальном тестировании.

Доклад начался с простого на первый взгляд вопроса, заданного мне на прошлой конференции SQA Days: “А как понять принесёт ли нам пользу автоматизация?”. “Ну”, - начал я и понял, что ответа-то у меня и нет. И вообще, что лучше собрать мысли воедино и вместо беседы в кулуарах конференции сделать публичный доклад. Мне, человеку, занимающемуся автоматизацией в тестировании последние лет 12, непонятно, как можно тестировать, ничего не автоматизируя, и какие сомнения есть у людей. Поэтому работа над докладом была продолжена на встрече сообщества тестировщиков, где мы устроили мозгоштурм и сбор информации. Далее были опрошены люди, у которых как бы есть автоматизация, но нет понимания, работает она или нет. По результатам и получился данный доклад, цель которого - дать набор вопросов, которые необходимо проработать и получить в итоге ДА или НЕТ в пользу или против автоматизации в тестировании.

"- Эй, тестировщики, какое покрытие тестами вы обеспечили?
- Огурец.
- Что "огурец"?
- А что "покрытие"?"
(c) Табличка “Сарказм” (https://twitter.com/glorphindale)

Помните мой доклад годичной давности "Визуализация покрытия автоматизированными UI тестами" (http://sqadays.com/ru/talk/26051)? В нем я рассказывал про нашу идею и реализацию измерения покрытия UI тестами. А еще обещал сделать универсальную версию и выложить в открытый доступ.
Сказал - сделал: https://github.com/budabum/uicov.
Цель этого блиц-доклада - ознакомить вас с инструментом, который вы можете использовать для анализа покрытия вашими UI-тестами. Кроссплатформенно и языконезависимо.

План такой:
1) Рассказать общий принцип работы uicov.

2) Показать, что он умеет.
Всё.

А еще зададимся вопросом, почему многие неправильно используют PageObject.

Наиболее ресурсоёмкая часть тестирования - это подготовка тестовых данных. Они зависят от типа и цели тестирования, стадии разработки проекта и много от чего ещё.

Писать ли тест генератор или создавать синтетический набор данных. Искать ли данные в копии боевой базы или делать поднабор этих данных? Рандомизировать или фиксировать? И другие подобные вопросы будут затронуты.

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

Ну и конечно вопрос: а как вы понимаете какие данные реально использовались при тестировании?

Время от времени руководитель тестирования, менеджер проекта или заказчик интересуются - а на сколько же хороши наши автоматизированные тесты? Как хорошо они покрывают функциональность проекта? Открою секрет, зачастую, это интересно и самим инженерам автоматизаторам. Но точного ответа обычно нет. И если для “низкоуровнего” тестирования есть известные механизмы оценки покрытия, например code coverage, то для автоматизированных Web и Mobile UI тестов нет наработанной методики. “Model-based-testing” - скажут одни. “Сложно и скучно” - скажут другие. “Можно!” - скажу я и расскажу о простой методике, как используя opensource технологию [http://plantuml.sourceforge.net](http://plantuml.sourceforge.net) и не используя классический MBT оценить покрытие вашего приложения автоматизированными UI тестами. При этом останутся довольны как любители эффектных картинок, так и суровые, ascii-тичные инженеры-тестировщики.

Здравствуй, коллега! Знаешь ли ты, что нас, тестировщиков, считают дилетантами? С этим, порою, трудно поспорить. А иногда называют непрофессионалами? Ты стараешься, работаешь и непрофессионал, wtf? А может этому есть причины... Как более старший товарищ хочу рассказать тебе о том, что для того, чтобы быть профессионалом недостаточно быть хорошим специалистом. А для того, чтобы вести себя профессионально не нужен опыт, стаж и седина. Конфуций говорил, что “Три пути есть у тестировщика, чтобы вести себя профессионально: первый, самый благородный, - размышление; второй, самый легкий, - подражание; третий, самый горький, - опыт”. Я хочу дать тебе пищу для размышлений, чтобы в каждый момент времени ты знал какой путь выбрать, чтобы ты понимал кому стоит подражать и когда, и чтобы третий твой путь оказался менее горьким. Редкая книга или курс говорят об этом. Я же покажу тебе что есть путь профессионала и что есть самый большой грех тестировщика. Итак, слушай...