Data-driven подход: серебряная пуля или старые грабли на новый лад?

Advantages of Data-Driven testing

Data-Driven offer many advantages some of them are:

1. Allows to test application with multiple sets of data values during Regression testing
2. Test data and verification data can be organized in just one file, and it is separate from the test case logic.
3. Base on the tool, it is possible to have the test scripts in a single repository. This makes the texts easy to understand, maintain and manage.
4. Actions and Functions can be reused in different tests.
5. Some tools generate test data automatically. This is useful when large volumes of random test data are necessary, which helps to save the time.
6. Data-driven testing can perform any phase of the development. A data-driven test cares are generally merged in the single process. However, it can be used in multiple test cases.
7. Allows developers and testers to have clear separation for the logic of their test cases/scripts from the test data.
8. The same test cases can be executed several times which helps to reduce test case and scripts.
9. Any changes in the test script do not effect the test data

Data-Gathering Procedures: Best Practices

Now that you’ve planned how to use your data, it’s time to conduct tests to gather the hard numbers you need. Below, we’ll discuss the process of planning for a UX research experiment.

Creating a Hypothesis

In the previous section, we spoke about establishing goals for your project (what will your data eventually be used for?). Once you’ve done this, you can turn your attention to developing a hypothesis.

Creating a hypothesis for a UX experiment is much like creating one for a science experiment. Many of the same rules apply.

The biology department at California State University, Bakersfield, has this to say about hypotheses (emphasis theirs):

“A useful hypothesis is a testable statement, which may include a prediction. A hypothesis should not be confused with a theory. Theories are general explanations based on a large amount of data.”

They go on to give the following example of a “formalized hypothesis”:

“If skin cancer is related to ultraviolet light, then people with a high exposure to UV light will have a higher frequency of skin cancer.”

The statement has two parts: If X condition is met, then Y result will occur. It refers to a cause-and-effect relationship between two factors.

When creating a UX hypothesis, however, it’s necessary to go a little bit further. Beyond just discussing the cause and effect, we need to explain which users our hypothesis applies to, and why we think the result will occur.

An example of a formalized hypothesis for a UX research project can be seen below:

If the color red creates a sense of urgency in users, then making the “checkout” button on our website red will increase conversions among users browsing our product pages.

As you can see, the UX hypothesis is slightly longer than a scientific hypothesis. It contains all the information we need to test and answer the question.

Ensuring a Sufficient Sample Size

Once you’ve created a hypothesis, you’re ready to begin your experiment.

When conducting an experiment, there are certain best practices to keep in mind. One is that you need a sufficient sample size to ensure results are significant. If your sample size is too small, the value of any data you gather will be questionable. For this reason, it’s important to ensure that your organization has a method of finding and incentivizing UX testers to participate in the experiment.

Eliminating Confounding Variables

You’ll want to eliminate confounding variables as much as possible when planning your experiment.

For instance, in the above “red button” example, it might not be a good idea to redesign your entire website, then test the old version of the website with the former button color and the new version with the red button.

In that case, users might be tempted to purchase because the new overall design makes the website look more trustworthy—the results could have nothing to do with button color.

Service Monitoring

Any web-based service can and should be monitored for

• crashes and other serious errors
• server load, server outages and internal server problems
• server traffic, including traffic to particular pages, percentage of mobile and non-English users, etc.
• specific monitoring for the services you are offering, e.g. in the case of DataCite number of DOIs registered (broken down by data center), number of DOIs with specific metadata (e.g. ORCID identifiers for creators and funding information), and number of DOI resolutions (tricky because there is no easy way to filter out bots)
• user-generated feedback (see section product development)

Definition

Data-Driven Development and related terms are in use in several contexts, in particular economics, and programming. The term sounds similar to test-driven development and behavior-driven development, two related software development processes. Business intelligence and data science are of course closely related. My definition is as follows:

This shouldn’t come as a surprise as DataCite’s mission is Helping you to find, access and reuse data. And my last job at the Open Access publisher PLOS was all about collecting and presenting data about the reuse of scholarly articles (citations, downloads, social media mentions, etc.). But here I mean data in a much broader sense.

Кейсы компаний, которые реализуют Data Driven-подход

Управление

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

Внедрение Data Driven-подхода позволило открыть доступ к 80% ранее скрытой информации, сотрудники начали самостоятельно проверять гипотезы на данных, составлять интерактивные дашборды. С помощью бизнес-симуляторов компания начала моделировать различные ситуации на рынке и рассчитывать целесообразность инвестиций или запуска новых продуктов.

Разработка маркетинговых продуктов

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

MDD — Model Driven Development

В последнее время много внимания в публикациях отводится теме архитектуры и разработке на основе моделей MDA (Model Driven Architecture) и MDD (Model Driven Development). Не вдаваясь в подробности, выделим только ключевые моменты.

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

Основная цель MDD — минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам. Ведь основная бизнес-логика содержится в диаграммах и не сковывает нас рамками выбора языка программирования и инструментов разработки.

Давайте немного отвлечемся и вспомним про компилятор. Он преобразует язык программирования высокого уровня в эквивалентную реализацию на машинном языке. Моделью в этом случае является программа, написанная на языке высокого уровня, которая скрывает несущественные детали о ее реализации. В MDD наши диаграммы — это еще один уровень абстракции, который не позволяет нам увязнуть в деталях разработки, а посмотреть на картину в целом.

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

Идея MDD не нова ‑ она использовались с переменным успехом и раньше. Причиной возросшего внимания к ним в настоящее время является то, что автоматизации поддается значительно больше процессов, чем раньше. Это развитие отражается в появлении MDD-стандартов, что ведет к унификации соответствующих средств. Одним из таких стандартов является пересмотренная версия Unified Modeling Language – UML 2.0.

По стандартам Object Management Group (OMG) создание приложения состоит из следующих шагов:

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

Классический пример применения MDD, который используется уже давно, — моделирование баз данных. На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД.

Какие преимущества мы получаем:

• ускоряется вывод минимального жизнеспособного продукта (Minimum Viable Product) на рынок;
• сокращается время на: генерацию каркаса приложения, модели классов, базы данных;
• постоянно обновляемая документация;
• для участников проекта диаграммы намного нагляднее кода.

Минусы:

• для внедрение MMD потребуется использовать специальные программные решения, такие как Rational Software Architect, Simulink или Sirius;
• от программистов требуются внушительные знания проектирования диаграмм;
• значительные финансовые затраты на интеграцию данной методологии.

Пример из жизни

Расскажу вам о двух клиентах нашего агентства.

«Птица Синица» (blue-pottery.ru) — небольшой монобрендовый магазин польской керамической посуды. 2 офлайн-магазина: в Москве и Санкт-Петербурге. ZV.Digital оказывает Птице Синице услуги комплескного интернет-маркетинга.

Kant.ru — крупный мультибрендовый магазин спортивных товаров. 15 офлайн-магазинов. ZV.Digital оказывает «Канту» услуги веб-аналитики (автоматизация отчётов, настройка сквозной аналитики, ad hoc отчёты).

Инфраструктура аналитики и объёмы данных разные.

Для «Птицы Синицы» мы используем данные из Google Analytics с простой (не расширенной) электронной торговлей.

Для «Канта» мы настроили большое количество автоматически обновляемых отчётов для отслеживания эффективности рекламы. Ежедневный отчёт позволяет мониторить работоспособность платных каналов и быстро реагировать на отклонения и причины. Отчёты за неделю и за месяц дают понимание о приоритетных каналах по важным KPI. На основе этого корректируются бюджеты. Отчёт за год — база для прогноза на следующий год.

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

С проектом «Птица Синица» мы даже рассматривали вопрос о полной остановке всех маркетинговых и рекламных активностей на пару месяцев или до прояснения ситуации, что повлекло бы за собой серьёзные убытки. К счастью, этого не произошло.

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

В начале апреля для «Птицы Синицы» мы приняли решение совместно с владельцем бизнеса не просто не останавливать рекламу, а, наоборот, увеличить бюджет на наиболее эффективные по данным GA кампании. Рекламный бюджет в Яндекс.Директе в итоге был увеличен почти в 3 раза. Это привело к значительному росту дохода из этого источника.

На графике показана динамика расходов на рекламу и дохода из Яндекс.Директа. Данные из Google Analytics с января по июнь 2020 года.

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

Результат

На графике показана динамика коэффициента транзакций для этого канала трафика. Значительный рост конверсии в середине мая связан с сезонным спросом на одну из категорий товаров. Но на большем периоде виден стабильно более высокий уровень этого показателя.

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

«Птица Синица», не поддавшись панике и приняв решение на основе данных, в одночасье выросла в 2 раза. Это повлекло за собой необходимость набрать новых сотрудников, изменить стратегии закупок, расширить число поставщиков и многое другое.

Сотрудники компании «Кант» были очень воодушевлены, увидев реальный потенциал ecommerce. Данные аналитики давали уверенность в принятии решений. Проверив в боевых условиях подход к работе, компания расширила число автоматических отчётов и разовых отчётов по дизайну и интерфейсу сайта. Компания сосредоточила усилия на настройке сквозной и Ropo-аналитики.

Каждая из этих компаний находится на своём уровне зрелости аналитической культуры и развивает её своими темпами. Вопросы аутсорсинга отдельных компонентов аналитической культуры — тема для отдельной статьи. Но как они к этому пришли и с чего начинали?

Что такое рекрутинг и зачем рекрутеру метрики

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

Подписывайтесь на рассылку статей для HR и рекрутеров! Будьте в тренде с Hurma

*

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

Вы подписаны!

Зачем рекрутеру метрики

Рекрутинговые метрики выполняют две основные функции:

• определение эффективности процесса найма;
• определение эффективности работы рекрутера. 

Кроме того, метрики по рекрутингу помогают найти ответы на следующие вопросы:

1. Насколько хорошо мы находим подходящих кандидатов и сколько времени нам нужно, чтобы нанять их? (С этой информацией можно спланировать личную нагрузку, а бизнесу – планировать свои процессы).
2. Сколько квалифицированных кандидатов нужно найти, чтобы закрыть вакансию? Как быстро мы переходим с одного рекрутингового этапа на другой?
3. Насколько эффективно мы привлекаем лучших кандидатов и убеждаем их принять оффер?
4. Сколько денег мы тратим на наем и как наши расходы меняются в зависимости от позиции, на которую мы ищем людей?
5. Насколько, в целом, эффективен наш процесс найма и какие шаги (этапы) наименее оптимизированы?

Юлия Кескин поделилась информацией о том, какие метрики отслеживаются в её агентстве VeryBusy Recruiting: что они анализируют, когда ведут поиск и зачем. 

Подписывайтесь на рассылку статей для HR и рекрутеров! Будьте в тренде с Hurma

*

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

Вы подписаны!

Funnel-based аналитика (метрики, которые мы получаем из воронки рекрутинга). Измеряются базовые метрики, которые заложены в воронку рекрутинга:

• скольким кандидатам мы предложили позицию;
• сколько кандидатов ответили на наше предложение;
• сколько кандидатов из ответивших заинтересовались предложением;
• сколько кандидатов мы  отправили на ревью клиенту;
• сколько кандидатов прошло техническое интервью;
• скольких кандидатов мы наняли.

Для оценки эффективности используются следующие показатели:

Sourced/Relevant candidates – сколько кандидатов из найденных являются релевантными для позиции.

Relevant/Attracted candidates – сколько релевантных кандидатов приняли оффер.

Sales метрики:

• Response rate –отношение количества ответивших кандидатов к количеству отправленных писем.
• Sourcing channels effectiveness – определение эффективности каналов поиска.

Календарные метрики:

Time to hire – время на закрытие позиции.

• Time in hiring process steps – время между каждым из этапов найма.
• Cost of hire – стоимость найма.

Candidate experience метрики:

• Refusal reasons – причины отказов.
• Offer acceptance rate – соотношение отправленных офферов к принятым. 

Characteristics of a data driven culture

A data driven organization is one that prioritizes the best practices and uses of analytics in culture and operating habits. When you look at well known data driving organizations, such as Google and Apple, you can see that the influence starts at the very top of the company and is felt in every position.

Not all organizations have employees that are quite as data savvy. One of the main obstacles in data driven strategic planning for a whole organization is in getting all of the staff members to buy into and use the protocols effectively. This is a major commitment for all personnel because not every member of staff will have a background in data science.

Data driven strategy consulting can help companies develop a data driven culture and aid the executives and management in finding ways to bring all employees on board. This type of culture will allow employees to grow more secure in their data analytics tools and analysis.

Training options for these types of functions can be time consuming but it will also mean greater skill sets for employees, more employee loyalty, and a better overall company culture. Once the organization has reached a place where all aspects of the culture are data driven, decisions and projections are far more efficient and accurate. Productivity and profitability are higher in a data driven organization, as well.

Шаг 1: База данных

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

Мысль!

Отслеживать в компании можно практически что угодно, но не все отслеживать нужно!

Поймите, какие компоненты действительно влияют на результат, а какие — нет.

Отслеживать можно и SMM, и офлайн активности. Существуют QR коды, метки, промокоды и призывы к действию. Тратя время и деньги на продвижение, всегда закладывайте возможность отслеживания результатов

A Textbook Example Of Good Data-Driven Design

To better understand how to focus on empirical data, both qualitative and quantitative, let’s look at a hypothetical problem for a content-oriented website.

Let’s suppose you run an online periodical or research website. Keeping visitors engaged is a big goal! You’ve been asked to make design and content changes that will help retain visitors. Where do you start?

You could log into your analytics account and check exit and bounce rates. For our purposes, we can define these as follows:

• Exit rate. The number of times a visitor leaves your domain from a page, divided by that page’s total views. Generally expressed as a percentage.
• Bounce rate. The number of times a visitor enters a domain on a page but leaves before viewing any other page in the domain, divided by the total number of views of that page. Also generally expressed as a percentage.

Upon sorting all of your pages by exit rate and then bounce rate, you find that two pages have much higher rates than the website’s averages. Based on this quantitative data, you look up the pages. One page contains a prominent link to a sister website — this means you’re intentionally sending people someplace else. You’re not as concerned, then, by the high exit and bounce rates on that page, because that page is designed to be an exit point. But the other page contains a long, important article and no direct, intentional reason to leave.

Why are visitors bouncing and exiting so often, then? Time to turn to qualitative data! “My favorite thing to do is combine observational research (watching somebody use a site) with in-context, self-reported data asking people about their presence,” says Yeats:

Yeats is right! This is a great opportunity for user testing. And because you’ve narrowed down your efforts to a single page (maybe a couple for additional context), testing becomes more practical. You’ll also be able to determine whether any design changes you make are working, because you’ve identified specific, empirical metrics that quantify success: exit and bounce rates.

С чего можно начать?

Если мой “нудный PR”  проектирования на основе предметной области (DDD) вас до сих пор не утомил, то думаю нам стоит продолжить, если же иначе, то посмотрите хотя бы ссылки на материалы.

Есть так же несколько хороших презентаций Эрика Ивенса (Eric Evans), с которых можно начать:

В этой книге вы найдете практические примеры:

1) Как проходит процесс проектирования и разработки, от определения требований, до написания кода

2) Как организовывать архитектурные слои в своих решениях

3) Как применять шаблоны и практики DDD

4) Как построить небольшой каркас для DDD

5) Как изолировать домен предметной области от модели

6) Современные паттерны представления данных и взаимодействия с ними (Model-View-ViewModel) в такой среде как WPF (так же применимы к Silverlight) в практики.

Вся концепция книги построена на 3 книгах-столпах DDD:

1. PoEAA Мартина Фаулера
2. DDD Эрика Ивенса

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

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

Некоторые реализации шаблонов DDD на Ruby On Rails:

How to create a Data Driven Automation Framework

Consider you want to Test Login functionality of an application.

Step 1) Identify the Test Cases

• Input Correct username and password – Login Success
• Input incorrect username and correct password – Login Failure
• Input correct username and incorrect password – Login Failure

Step 2) Create detailed est Steps for above 3 Test Cases

Step 3) Create Test Script

If you observe the Test Steps Remain common through the 3 Test Steps. You need to create a Test Script to execute these steps

// This is Pseudo Code 

// Test Step 1: Launch Application 
driver.get("URL of the Application");  

// Test Step 2: Enter Username 
txtbox_username.sendKeys("valid"); 

// Test Step 3: Enter Password 
txtbox_password.sendKeys("invalid"); 

// Test Step 4: Check Results 
If (Next Screen) print success else Fail

Step 4) Create an excel/csv with the Input Test Data

Step 5) Step Modify the Scrip to Loop over Input Test Data. The input commands should also be parameterized

// This is Pseudo Code
// Loop 3 Times
for (i = 0; i & lt; = 3; i++) {
    // Read data from Excel and store into variables
    int input_1 = ReadExcel(i, 0);
    int input_2 = ReadExcel(i, 1);

    // Test Step 1: Launch Application
    driver.get("URL of the Application");

    // Test Step 2: Enter Username
    txtbox_username.sendKeys(input_1);
    // Test Step 3: Enter Password

    txtbox_password.sendKeys(input_2);
    // Test Step 4: Check Results
    If(Next Screen) print success
    else Fail
}

Above are just 3 test cases. The test script can be used to loop over following test cases just by appending test data values to Excel

• Input incorrect username and incorrect password – Login Fail
• Input correct username and password blank – Login Fail
• Input blank username and blank password– Login Fail

And so on

Как понять, когда нужно создавать DDT

• Если Вы увидели, как какой-то компонент системы описать с помощью входных параметров и выходного состояния или результата – можно создавать DDT. По опыту автора, требуется определённое время, чтобы разработчики начали замечать, как ввести DDT на проект. Притом очень часто без явного напоминания или толчка со стороны люди продолжают полагаться или на мануальное тестирование, или пишут много похожих юнит тестов. На проекте примера 4 так и было.
• Приходилось участвовать в ситуациях, когда DDT становился спасением проекта из-за накопленной внутренней сложности, когда небольшое изменение может повалить всю систему. Смотрите пример 6.
• Если входные параметры представляют собой сложный набор данных, или когда нужно тщательно проверять взаимозависимости входных параметров, делать валидацию с большим количеством ошибочных вариантов, а также, когда количество результирующих состояний системы неограниченно.
  • Используется свой DSL (domain specific language). Смотрите пример 3.
  • Покрываемая система расширяема – плагины, скрипты. Смотрите пример 4.
  • В базе данных происходят сложные калькуляции или присутствуют сложные связи. Смотрите пример 6.
• DDT можно применять для стабилизации системы, в которой случаются трудно-поправимые баги, и для организации грамотного регрессионного тестирования (Смотрите примеры 3 и 5).
• Также, если в юнит тестах вы видите copy pasting на уровне test методов, стоит подумать над вынесением этого в DDT (значительно сокращается объём кода для тестов).

Недостатки Data Driven-подхода

1. Расходы на инфраструктуру. Чтобы собирать данные о клиентах, нужно внедрять новые инструменты. Действия в интернете, например, просмотры страниц, время на сайте, клики и переходы можно отслеживать с помощью классических сервисов Google Analytics или Яндекс.Метрика. Но иногда их функционала не хватает и приходится покупать дополнительные сервисы.

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

1. Затраты ресурсов на очистку данных. Для корректных результатов данные на входе должны быть чистыми, то есть не содержать ошибочной информации, устаревшей или неактуальной для компании. Очистка данных — трудоемкий процесс, который может отнимать до 80% времени.

Как планируем доработать систему

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

Пример гугл-таблицы с дополнительными параметрами для отчетов

Идеально в будущем было бы закрыть часть из этой мануальной работы возможностями SendPulse. Например, добавить поля utm-меток для каждого письма в авторассылках и навешивать их автоматически на все ссылки в шаблоне, а затем отдавать их через API. Тогда отчетность станет проще и точнее.

Похожие записи:

Инструкция как пользоваться спарк ар студией Соревнование ironman: супергероями не рождаются, а ими становятся Cert-gib Как работать с блогерами: инструкция по применению Как составить контент-план для инстаграм: шаблоны и инструкция Интернет-банк «альфа-бизнес онлайн»