Показаны сообщения с ярлыком мысли вслух. Показать все сообщения
Показаны сообщения с ярлыком мысли вслух. Показать все сообщения

2021-10-20

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

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

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

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

Удачи!

2018-05-18

Как оно, начинать.

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

2018-01-23

О бардаке с управлением и рулением.

"Никакого бардака с рулением нет, у нас спонтанно-динамическая стабилизация по всем каналам управления с элементами роевой самоорганизации."(а).

2018-01-09

О чайниках.

"Офисные хомячки"(тм) делятся на тех кто доливает чайник после использования и на тех кто нет.

2017-12-08

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

2017-12-05

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

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

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

2017-09-20

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

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

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

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

- архитектуру и структуру. Проистекает из вопроса "что покрываем?". Навскидку:
 а. микросервисы или монолит;
 б. сервисы на основе бинарных протоколов или РЕСТ какой-нибудь;
 в. нужно воздействовать на одну систему или несколько.

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

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

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

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

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

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

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


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

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