Проще надо быть...

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

Казалось бы - ну зачем ещё нужны эти лишние потери времени, особенно когда лишнего времени и нет, ведь уже найден путь, как можно воспроизвести проблему? Так почему бы не описать его сразу именно в первоначальном виде? Изначально я стала заниматься упрощением полученного сценария воспроизведения проблемы из соображений гуманизма и эгоизма:

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

 - а во-вторых, я думала о себе, любимой, которой и сложную последовательность описывать лень, да и потом при проверке исправления (возможно, неоднократном) дольше возиться придётся. 

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

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

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

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

А ещё мне просто нравится докапываться до сути проблемы, спрятанной порой в пяти процентах всех сложных действий, приведших к обнаружению ошибки - ведь это интересно :)