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

Фотография

Тестирование отдельной задачи, баги.


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

#1 Aguero

Aguero

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

  • Members
  • Pip
  • 40 сообщений

Отправлено 30 января 2017 - 06:38

Добрый день! Вопрос, который у меня вызвал некоторые сомнения, как оптимально поступить.
При тестировании сборки с конкретной таской или решенной багой - тестировать только по самой таске или баге и еще дополнительно пробегаться по всему функционалу приложения? Так как бывают ситуации, пофиксили одно, а в сборке появилась бага в совершенно другом, несвязанным с этим фиксом месте)


  • 0

#2 baxatob

baxatob

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

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Юрий
  • Город:Riga

Отправлено 30 января 2017 - 07:17

Поэтому и полагается полный регресс делать после каждой поставки.


  • 0

#3 Molechka

Molechka

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

  • Members
  • PipPipPipPipPipPip
  • 1 224 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 30 января 2017 - 08:37

Когда вы тестируете исправление бага — проверьте:

 

1. Что исправлен сам баг (в первую очередь)

2. Что работает окололежащий функционал (не работала регистрация через твиттер? А простая? А через фейсбук?)

3. Что работает связанный функционал.

 

А уже перед выкаткой в прод — полная регрессия. Она нужна для того, чтобы обнаружить пункт 3 → вы могли даже не знать, что этот участок кода влиял на другой, "совершенно несвязанный", а теперь узнаете и пополните свои чек-листы :)


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#4 SALar

SALar

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

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 30 января 2017 - 09:07

Когда вы тестируете исправление бага — проверьте:

 

1. Что исправлен сам баг (в первую очередь)

2. Что работает окололежащий функционал (не работала регистрация через твиттер? А простая? А через фейсбук?)

3. Что работает связанный функционал.

 

А уже перед выкаткой в прод — полная регрессия. Она нужна для того, чтобы обнаружить пункт 3 → вы могли даже не знать, что этот участок кода влиял на другой, "совершенно несвязанный", а теперь узнаете и пополните свои чек-листы :)

Во-первых это невозможно для сколько-нибудь серьезных систем.

Вводная: у вас 12 000 юзкейсов; все они реализованы для десктоп, часть для мобильной и часть для интернет версии; в разных странах реализация юзкейсов разная; вы поставляете софт в дюжину стран; еще надо тестировать под разные версии Java, Win, DirctX, MSSQL, разрешшения экрана,...

Итого у вас примерно несколько миллионов тестов. На выполнение теста нужно пару минут (для автоматизированного тоже, т.к. система отвечает не быстро).

Считайте.

 

Во-вторых. Если вам нужна полная регрессия при каждом релизе, то вам уже конец.


  • 1

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#5 Molechka

Molechka

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

  • Members
  • PipPipPipPipPipPip
  • 1 224 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 30 января 2017 - 09:39

«Сколько-нибудь серьезных систем» — такое ощущение, что 90% тестируемого ПО — это миллиарды вариантов :-)

Но на самом деле проверить стандартный баг — от 5 до 30 минут, хотя у нас ПО тоже вполне серьезное. Но, конечно, без разных стран, мобильных версий, разных Java и вот это все.


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/


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

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