Some obvious ideas about back-end and BD autotests.

Some "C.O"-like ideas about back-end and BigData(ETL) test automation:
1. Conceptually the back-end testing approach may look like:

2. In case of BigData ETL(Extract-Transform-Load) application:

There is no huge difference but:
а. your tests interact with some schedulers and other "auxiliarry" tools now.
b. there is no direct response from the system-under-test(requests-response-check turns into request for launch-wait-check output data).
c. test data approach (in terms of libraries to use) - is quite similar.
d. since there is no direct interaction with SUT there are more libraries in your test automation project.
e. Output data checks often contain "does look like truth?"-like checks.

How-to adapt test Data-pool.

 There is such a thing  - Test Data-Pool. Seems to be usefull and there are usage examples but still it is not absolutely clear how-to start.

Given there are tests based on Java+testNG+maven + something else. Let's start:

1. Add maven dependency

 com.griddynamics.qa.datapool

 data-pool

 1.0.1

Specify actual version of course.

2. Greate/find entities package. Add a new entity class

package ru.test.automation.entities;

import com.griddynamics.qa.datapool.DataTypeFactory;

import com.griddynamics.qa.datapool.datatype.IDataType;

/**

 * Represents a BitBucketUser entity.

 */

public interface BitBucketUser extends IDataType {

    static BitBucketUser newUser(){

        return DataTypeFactory.create(BitBucketUser.class);

    }

    Integer getId();

    String getLogin();

    String getPassword();

}

Field set could be different.

3. Greate/find  /resources/data directory and add the data-file

!DataTypeKey 'interface ru.test.automation.entities.BitBucketUser':

- !IDataType {id: 1, login: Uzvr_Odin, password: Klu4slovo}

- !IDataType {id: 2, login: uzvr-Dva, password: derParrollen}

- !IDataType {id: 3, login: uzvr-Tri, password: AEtoKto?}

Let's name the file as ls.yml

4. Highly likely there is a BaseTest so add the following to it

import ru.test.automation.entities.BitBucketUser;

import com.griddynamics.qa.datapool.DataPool;

import static com.griddynamics.qa.datapool.FilterCriterion.by;

import static com.griddynamics.qa.datapool.matchers.StandardMatchers.CONTAINS;

...

@BeforeSuite

protected void loadData() {

    ClassLoader classLoader = getClass().getClassLoader();

    DataPool.load(Paths.get(classLoader.getResource("data/ls.yml").getPath()));

    // TODO: Switch to the approach below when Data-pool 1.0.2 is released.// DataPool.load("data/ls.yml");

}

//TODO: Think about moving into a separate data-access class.

protected BitBucketUser getUserByLogin(String partOfLoginName) {

    return DataPool.find(BitBucketUser.class, by("login", CONTAINS, partOfLoginName)).get(0);

}

5. And finally, within a test

BitBucketUser usr = getUserByLogin("Uzvr_Odin");

loginPage().login(usr.getLogin(), usr.getPassword());

Что бы такого учесть при оценке трудозатрат на АТ.

Классический вопрос обоснования необходимости автоматизации тестирования(и не только) -
"Что мы с этого будем иметь? Сколько сэкономим, сколько заработаем, скольких уволим и сколько можно будет перевести в премии?". И как всегда есть очевидные, известные и не очень вещи. Обычно пишут об эффективности автоматизации функционального тестирования как некоей загадочной величине пропорциональной отношению затрат на ручное тестирование к затратам на автоматизированное. И что включать в каждый вид затрат - тут каждый сам себе художник и научрук.

 На мой выпуклый военно-морской в затратах на автоматизацию следует в том числе учитывать:

- людей: кто, когда, с какой мотивацией и под какой стимуляцией будет всё это делать, развивать и поддерживать;

- документированность: насколько быстро можно получить ответы на внезапные вопросы,

нужно ли разрабатывать сценарии или использовать готовые и проверенные тестослучаи для ручного тестирования, каков вообще порог вхождения в проект(в месяцах). Здесь же можно упомянуть и общую зрелость проекта — если всё работает «не-так», то автоматизация вряд ли будет быстрой и эффективной;

- архитектуру и структуру. Проистекает из вопроса "что покрываем?". Навскидку:

 а. микросервисы или монолит;

 б. сервисы на основе бинарных протоколов или РЕСТ какой-нибудь;

 в. нужно воздействовать на одну систему или несколько.

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

- технологии тестового решения. Например использовать Селениум или Сикули это две большие разницы в затратах и на разработку и на поддержку;

- данные: стабы, моки или живые данные? Как генерировать и валидировать тестовые данные(особенно в случае критических систем(медицина, авиация))? Если моки-стабы, то есть ли что-то готовое или нужно будет писать своё?

- безопасников - дадут ли доступ и добро на манипуляции с системой, тестовые сборки с "дополнительными"(отладочными) функциями?

- среды: всяко-разные, начиная от где это запускать и где разворачивать тестируемое. Далеко не всегда можно получить стенды вот так сразу, возможно придётся подождать годик-два;

- СИ: строить с ноля или интегрироваться в существующее решение?

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

Вышеперечисленное конечно же требует творческого расширения, углубления и всяческого дополнения. На то она и затравка.

Ссылки россыпью:

http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727

https://pikabu.ru/story/post_2_yeffektivnost_avtomatizatsii_testirovaniya_3974390

http://www.a1qa.ru/blog/otsenka-effektivnosti-avtomatizatsii-testirovaniya/