Аллюр и Пружина, разошлись в аспектах ткачества.

  

IT life is the endless learning, you know. Just bear that.

Жизнь в ИТ это бесконечное, нескончаемое обучение. Это надо просто принять.

The better you rest the better you test!

 Just out of the blue I either "invented" or recalled that phrase about "work-life balance":

The better you rest, the  better you test!

https://www.youtube.com/watch?v=vK7-yV2dKAk  

Опережающее смягчение рисков.

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

[Импортозамещение] О прокрастинации.

 Прокрастинация, прокрастинация... называйте честно - отлыньтяйство! Тогда томный и загадочный прокрастинатор становится обыкновенным отлыньтяем безо всякого налёта заумной грусти.

В ту же степь - отлынь.

Автоматизация тестирования, какой язык лучше учить?

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

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

 А вот если рядом никого и кругом Антарктида, то во-первых: так ли нужна автоматизация тестирования? Во-вторых: берите первый язык в списке самых популярных и учите для начала до уровня "смог написать калькулятор и модульные тесты к нему". Потом второй по популярности, потом ... найдите работу автоматизатором, хотя бы даже и интерном.

Удачи!

Портрет автоматизатора

 

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.

Мысли вслух о разнице между автотестами на ПИП и для Большеданных приложений

Просто наблюдение "внимательного индейца Джо":
1. На уровне "квадратиков" подход к авто-тестированию тылового междумордия( ПИП) выглядит так:

2. А вот в случае всяких большеданных приложений типа "Взять-Преобразовать-Выдать":

Великой разницы нет, почти те же самые тесты на междумордий, однако:
а. работать приходится не с самим приложением, а с некими дополнительными приспособами которые запускают уже само приложение и т.д.
б. непосредственного ответа от тестируемого приложения может и не быть ("запрос - ответ - проверка что там в ответе пришло" меняется на "запрос на запуск - ожидание - проверка данных в выдаче")
в. работа со входными-выходными данными (на уровне библиотек и вызовов) - практически такая же.
г. за счёт работы через "посредников" количество дополнительных библиотек в проекте возрастает.
д. Сами проверки выхлопа часто включают в себя "похоже ли на правду" ибо при больших объёмах жёстко сравнивать вход-выход может быть ооооочень дорого.

О работе с требованиями и общности ИТ с остальным миром.

Перекрёсток, нерегулируемый. Его(перекрёсток) переделывают в регулируемый, Канавы, знаки, светофоры... . Пешеходный переход на этом перекрёстке и пятеро(5-ро) мужиков машут руками, голосят, споря где/как/что тут  копать/штробить/цементировать. И тут один из них выдаёт робкую фразу “А как у нас по проекту должно быть?“. 
Оказывается не только лишь в ИТ так, не только лишь... .

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());