TestNG, skipped tests and "why" related information.

 As usually there are passed, failed and skipped tests. TestNG map skip tests due to failures in
precondition steps (i.e. somewhere inside all those @BeforeSuite/Group/Method routines). In such a case there is no quick-human-readable
explanation why a test was skipped. That is a pity, so what about the following:
1. Go to TestListenerAdapter#onTestSkipped(ITestResult result);
2. Check Throwable of that ITestResult;
3. If null then get skipped configurations - result.getTestContext().getSkippedConfigurations();
4. I haven't found a straight way to link skipped configuration and skipped test, but one could try to do that via TestContext/TestClass:
check whether skippedConfig.getTestClass().equals(result.getTestClass()))
5. If there is skipped config caused the test to be skipped then use result.setThrowable() to transfer throwable to ITestResult;
6. No guarantees but seems to work.

ИИ всё ближе / AI is closing.

Разум изнурённый борьбой с постоянными падениями на СИ, протухаущими данными и прочими прелестями "взрослого проекта с длинной историей" начинает требовать внедрения ИИ в тесты - "что оно как-то там само разруливала мелкие падения и вопросы типа 'откуда брать кошерные данные прямо вот сейчас'". Главное чтоб потом код тестов не стал на порядок сложнее кода тестируемого приложения.

-------------

All those failing tests and suddenly became invalid data are so frustrating that engineer's mind strats to demand an AI in the test automation solution - just to decide-on-the-fly what-to-do and where-to-go if something went wrong in runtime. The main concern - test automation code should not be more complex than AUT's one.

Актуальная банальность (е.н. Прописная истина) / Actuality.

Если нет стабильных тестовых окружений, то количество отличных тестов в наборе это просто цифра.

-------------------
If you do not have stable environments then it does not really matter how many excellent tests you have in the suite.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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/