Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Проблемы автоматизации и способы спасения автоматизации на проекте

management
Теги: #<Tag:0x00007f7b674179d8>

(Михаил Братухин) #1

Добрый день!
Я тут на досуге решил посмотреть доклады с последнего Selenium Camp’а (2017-го) и увидел много интересных докладов, даже выше уровнем, чем на SQA Days’е, хотя с меньшим разнообразием выступающих (возможно, в этом тоже причина). И вот, например, один из интересных с моей точки зрения докладов:
5 top pain points of test automation (Mikalai Alimenkou, Ukraine)

По сути там, конечно, вода, но видно, что есть много здравых рассуждений (хотя и субъективных). Само выступление бодренькое. Вообще, у Микалая, по всей видимости, уже богатый опыт выступлений и это дает о себе знать.

Так вот интересно насколько объективны те или иные способы “угробить” свою автоматизацию. Кто и сколько насчитал баллов у себя на проекте. И что самое важное - какие вы знаете способы “спасения” автоматизации на проекте. Есть ли у кого опыт спасения автоматизации на “безуспешных” и “утопающих” проектах. Интересно послушать о best practices (silver bullet не предлагать! :slight_smile:). Ну, и может есть еще какие-то способы “успешно похоронить” свою автоматизацию.

Сколько из перечисленных способов “угробить” автоматизацию применяется у вас на проекте?

  • 0
  • 1
  • 2
  • 3
  • 4
  • 5
  • больше 5

0 участников


(Sergey Pirogov) #2

А смысл спасать? Дайте галере успешно утонуть и постройте новую


(Михаил Братухин) #3

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

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


(Valentin Buryakov) #4

Да как позывает практика, когда уже больше 3х поинтов на проекте, то уже вряд ли можно помочь, а причина в основом как раз в тех главных менеджеров и начальников отделов автоматизации и создателей своих собственных “фреймворков”, которые и насаждали эти принципы долгое время и которые будут всячески препятствовать этому, т.к. если будут изменения, то они могут оказаться не нужны или могут потерять свою власть и свою незаменяемость.