Перейти к содержимому

Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 6

#1 Liv

Liv

    Активный участник

  • Members
  • PipPip
  • 75 сообщений
  • ФИО:Ольга
  • Город:Москва


Отправлено 29 ноября 2010 - 16:12

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

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

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

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

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

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

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

#2 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 29 ноября 2010 - 16:43

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

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

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

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

#3 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 29 ноября 2010 - 16:47

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


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

#4 stmark

stmark

    Опытный участник

  • Members
  • PipPipPipPip
  • 404 сообщений
  • ФИО:Докучаев Сергей
  • Город:Ярославль


Отправлено 29 ноября 2010 - 20:06

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

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

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

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

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

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

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

#5 stmark

stmark

    Опытный участник

  • Members
  • PipPipPipPip
  • 404 сообщений
  • ФИО:Докучаев Сергей
  • Город:Ярославль


Отправлено 29 ноября 2010 - 20:25

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

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

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


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

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


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


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


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

#6 contestar

contestar

    Новый участник

  • Members
  • Pip
  • 36 сообщений
  • ФИО:Алексей

Отправлено 30 ноября 2010 - 08:44

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

#7 Undi

Undi

    Активный участник

  • Members
  • PipPip
  • 134 сообщений
  • Город:Kiev

Отправлено 02 декабря 2010 - 09:13

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


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

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


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных