Почему падают авто-тесты?

Летним ветром навеяло:
Почему падают авто-тесты, какие типовые причины и вообще - доколе? Я бы выделил четыре группы причин:
1. "Битая" функциональность, т.е. таки изъян в тестируемой системе;
2. "Поломанные" тесты - кто-то что-то улучшил, изменились локаторы, поменялась логика работы системы ... ;
3. Что-то нездоровое было с окружением: сеть(задержки-огнестены-впн-ы и т.д.), драйверы, электропитание, админы празднуют Новый Год ... ;
4. НЁХ - "неведомое ёлочное художество". Упали потому что упали, жалко что ли?

ИИ всё ближе / 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/

"Нагенячить"... .

"Нагенячить" - глаг., от существительного "гений".

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

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

А хочется же как? Запустил-забыл-вспомнил-посмотрел отчёт.

Можно завести себе удалённую машину, поднять там Луниевский сервер, гонять тесты через него и т.д. . Можно и виртуалку поднять с аналогичной начинкой. Или виртуалку, но в облаке.

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

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

1. Установить Селеноид ("Грузчик" и прочее тоже);

2. Настроить (укажите один браузер для начала);

3. Запустить всё это докерное чудо;

4. Указать http://127.0.0.1:4444/wd/hub в качестве урла удалённого сервака Линия;

5. Запустить тесты;

6. Наслаждаться.

В итоге - ничего не мельтешит, всё по-модному в Докере, ещё и в куче браузеров можно запускать. Лепота.

Ссылки:

https://hackernoon.com/selenium-testing-a-new-hope-7fa87a501ee9#.64hdyki27

https://hackernoon.com/selenium-testing-a-new-hope-a00649cdb100#.7u1pq8hz1

https://habrahabr.ru/post/322742/

https://habrahabr.ru/company/wrike/blog/324418/

https://github.com/aandryashin/selenoid

https://github.com/aandryashin/ggr

http://aerokube.com/

Надумалось по поводу нагрузочных тестов и когда начинать всё то.

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

Рекламное немного.

 Контора "КостыльТехРеш" в сжатые сроки преодолеет любые технические трудности заказчика использую многовековые наработки в области самобытных и маловремязатратных решений.

О вежливости и эффективности в переписке, Н-2.

Ещё один совет из области рабочего общения: 

http://neprivet.ru

Коротко:

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

A short translation for language impaired ones:

"Do NOT  IM like

- You: Hello

- Your colleague: Hello

- You: Would you be able to .... .

---

DO it  like:

- You: Hello. Would you be able to ... ."

Just save the time.

Синдромное и зажратоитэшное.

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

Eng. - be strong and think about others.

Senior engineers!  Just a note - at the very moment you are about to code-up your next shiny, glamorous test automation framework  - think about those middles who will  support and maintain the fruit of your creativity.  Be kind, leave at least couple of notes  on how that "wonderwaffle" is supposed to work!

О наступании на горло собственной песни.

Синьоры!  Когда вы собираетесь замутить что-нибудь такое-этакое в своем очередном каркасе для авто-тестов, помните - вот это вот потом поддерживать мидлам. Пожалейте их мозг  и осталяйте хоть какие-то описания как эта вундервафля предположительно работает.