Итерационное тестирование

Тестирую доработку по меньшей мере 30-й раз.

В первый раз отношение к функционалу было очень ответственным, было много мыслей о том, какие тесты можно провести, какие настройки сделать и т.д.
Но увы... первое же тестирование выявило ошибки: каждый мой тест-кейс закончился неудачей.

Разработчик исправлял свои ошибки 2 дня. При этом он "протестировал" сам...
Наступило второе тестирование. Результат ничем не отличался от первого - столько же ошибок (старых и новых).

И теперь решили, что разработчик исправляет найденные ошибки прямо в тесте. Но вот беда: если он исправляет что-то в одном месте, то парочка ошибок возникает в других местах функционала.
Я уже не помню, что работает, а что нет.
Складывается впечатление, что мы собираем конструктор. Причем после каждой сборки постоянно несколько деталей остаются лишними, а некоторые прикручены совсем не в тех местах.

Я уже не верю, что когда-нибудь функционал заработает.

И мне интересно, сколько раз должен тестировщик проверять систему? После нескольких дней проверок, мне уже не хочется проводить операции, ставшими для меня стандартными, в очередной раз.

Как мне себя мотивировать на выполнение рутинных операций (если я предполагаю, что это будет длиться еще долго)?

И мне интересно, сколько раз должен тестировщик проверять систему? После нескольких дней проверок, мне уже не хочется проводить операции, ставшими для меня стандартными, в очередной раз.

может, пора подумать об автоматизации? :)

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

если при каждом прогоне находится куча багов, то..
1) а не пропустили ли вы их при предыдущем тестировании?
2) если это все новые, то проблемы есть как в конкретном разработчике, так и в процессе разработки вообще.

И мне интересно, сколько раз должен тестировщик проверять систему? После нескольких дней проверок, мне уже не хочется проводить операции, ставшими для меня стандартными, в очередной раз.

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

От ручного тестирования никуда не денешься, а регрессионное тестирование порой бывает утомительным, мне помогают такие вещи:

1. Автоматизация. И это не обязательно должны быть тестовые фреймворки, студии и прочее. Можно писать простенькие скрипты.
Например есть у нас один сложный визард, куча тестов для него, часть автоматизированы, часть прогоняются вручную. Для того что бы облегчить работу - написал скрипт прохождения по всему визарду, а далее просто останавливал выполнение скрипта там, где нужно, выполнял тест, а далее скрипт завершал свое исполнение.

2. Cause-effect maps - почему-то редко обсуждаемое средство уменьшения регрессионных тестов, часто использую вместе со смоук тестами. Порой тестирование превращается в настоящую магию, когда лишь прочитав условия задачи можешь рассказать о том, какие баги и где будут обнаружены. :)

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

4. Любимая музыка. Кому как, но мне при выполнении монотонной работы нравится иногда слушать музыку. Причём больше всего почему-то транс и chillout, хотя обычно выбираю совсем иной жанр. Коллега программист во время рутины слушает выступления КВН :)

5. Совершенствование тестов. Когда постоянно одни и те же тесты повторяешь, то на ум приходит более аккуратные формулировки шагов(тест-кейсы)\пунктов (чек-листы), находишь шаги, которые охватывают больший функционал. В результате получаем материал, по которому тестировать одно удовольствие, а не рутина и тягомотина.

6. Анализ багов. Баги можно и нужно анализировать. Это полезно и может доставлять большое удовольствие. Открыл для себя то, что этой радостью можно делиться даже с программистами и вместе бурно обсуждать. Причём разработчиков стоит слушать внимательно, они знают о причинах бага много больше чем тестировщики. Не стоит только полагать, что дырявый софт доставляет удовольствие - это в корне не верно. Мне безумно нравится, когда программа работает так, как и было задумано, когда ею пользоваться удобно. Баги в радость, когда они найдены тобой, т.е. не пропущены к пользователям. Для анализа багов существует множество методов начиная с простой локализации, заканчивая статистическими выкладками, применяемыми к сотням исправленных ошибок.

Тестирую доработку по меньшей мере 30-й раз.

...каждый мой тест-кейс закончился неудачей.

...Результат ничем не отличался от первого - столько же ошибок (старых и новых).

Создайте смоук-тесты и договоритесь\объясните начальству и программистам, что если проваливаются смоук-тесты, то дальнейшее тестирование - бесполезная трата времени\сил\денег. Таким образом каждый виток итерации будет отнимать минимум сил на регрессионные тесты.

И теперь решили, что разработчик исправляет найденные ошибки прямо в тесте. Но вот беда: если он исправляет что-то в одном месте, то парочка ошибок возникает в других местах функционала.

Если имеется в виду, что программа\сайт обновляются во время выполнения тестирования, то это очень плохо, более того эффективность тестирования падает в разы. Думаю Вам и так понятно почему. Нужно опять же популярно объяснить почему так делать плохо и к каким результатам это может привести.

И мне интересно, сколько раз должен тестировщик проверять систему? После нескольких дней проверок, мне уже не хочется проводить операции, ставшими для меня стандартными, в очередной раз.

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

Как мне кажется, в данной ситуации необходимо всё взять в свои руки. Я имею ввиду собраться на стендап и обговорить проблемы, расставить приоритеты в связке PM-dev-test. Разделить функционал на несколько частей и начать заниматься одной из них. Доработать одну часть - протестировать, взяться за вторую и т.д. А bug-fixing всего и сразу не даст результата. Здесь важно расставить приоритеты. Соглашусь с предыдущим комментарием. От вас в первую очередь требуется smoke testing - набор кейсов, при падении хотя бы одного из них продукт не может быть отдан в тестирование. Эти кейсы желательно автоматизировать и дать возможность прогонять их на новом билде самими девелоперами до передачи билда. Этот момент нужно обговорить как с dev командой, так и со своим менеджером, чтобы каждый знал свою роль и ответственность в проекте. Успехов.

И теперь решили, что разработчик исправляет найденные ошибки прямо в тесте. Но вот беда: если он исправляет что-то в одном месте, то парочка ошибок возникает в других местах функционала.
Я уже не помню, что работает, а что нет.

Вот это главная Ваша ошибка!
Нельзя соглашаться ни под каким предлогом на исправление ошибок "прямо в тесте".
Разработка - отдельно, тестирование - отдельно.
Собрали версию для тестирования, дали ей номер, передали в тестирование.
Далеее Вы проводите смоук-тесты.
Если тесты завалились, отдаете версию обратно на доработку.
Если тесты пройдены успешно, тестируете дальше.

Получить качественный продукт без фиксированных версий невозможно в принципе.