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

управление
#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 участников

3 лайка
#2

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

1 лайк
#3

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

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

#4

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

2 лайка