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

Английский для тестировщиков
онлайн, начало 7 декабря
Chrome DevTools: Инструменты тестировщика
онлайн, начало 10 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря
Фотография

Повторное тестирование старой версии программы


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

#21 YuP

YuP

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

  • Members
  • Pip
  • 38 сообщений
  • Город:Питер

Отправлено 18 декабря 2007 - 20:05

Определение maintenance testing для железа к софту нельзя отнести. У аппаратуры и у программы разные жизненные циклы. В аппаратуре дефекты появляются со временем, поэтому нужна периодическая диагностика (можно ее и тестированием назвать). А в ПО все дефекты закладываются при разработке и со временем их число не увеличивается, только возрастает число известных. Если периодически запускать один и тот же набор тестов, то новые баги мы не найдем.

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

2 Case. Действительно, можно сказать, что начинается цикл разработки опять с требований. Они изменились: теперь добавлено требование по поддежке нового оборудования. Мне вот только кажется странной возможность следующей ситуации: требования к новой версии сформулированы, а сама новая версия не появится, т.к. прежняя версия, оказалось, этим требованям удовлетворяет. За что заказчик платить должен? :) Второй раз за одну и ту же версию?
  • 0

#22 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 18 декабря 2007 - 21:48

2 Case. Действительно, можно сказать, что начинается цикл разработки опять с требований. Они изменились: теперь добавлено требование по поддежке нового оборудования. Мне вот только кажется странной возможность следующей ситуации: требования к новой версии сформулированы, а сама новая версия не появится, т.к. прежняя версия, оказалось, этим требованям удовлетворяет. За что заказчик платить должен? :) Второй раз за одну и ту же версию?

Заказчик платит за то исследование, которое вы проведете. Это раз. Два - за ту гарантию, которую дает ваша компания заказчику. Иначе - можно вас не тревожить и попытаться эксплуатировать ПО на обородувании, на котором не проводилось тестирование. А это уже риск для заказчика. Следовательно, он платит за уменьшение своих рисков. Вполне возможно, что у заказчика на это ПО есть потенциальные клиенты - следовательно он платит за возможное раширение своего бизнеса.
  • 0
Regards,
Alexey

#23 Darkus

Darkus

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

  • Members
  • PipPipPipPip
  • 424 сообщений
  • Город:Казахстан, г.Астана

Отправлено 19 декабря 2007 - 03:42

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


Уф. Спасибо Славе, что избавил от необходимости длинного поста.
Акцент сделан правильно. Есть новые Требования, которые должны быть проверены.
Собственно, как и проверены старые требования на предмет поддержки в новом окружении.

А с другой стороны есть такой тип тестирования, под названием Конфигурационное тестирование - "специальный вид тестирования, направленный на проверку совместимости объекта тестирования с различным аппаратным и программным обеспечением."
Там как раз и должны сидеть "спецательные" тесты на новый тип оборудования (в соотв. см. с требованиями).

Поэтому, на мой взгляд я бы вначале провёл:
1. Конфигурационное тестирование, целью которого прямо убедиться, что реализация соответствует новым требованиям (ограниченное число специализированных тестов).
2. Exploratory тестирование - чтобы попробовать найти специфические\случайные\особенные баги.
3. С учётом найденных ошибок п.1, п.2 - поправить список основных тестов(если в этом есть необходимость) и провести регресионное тестирование.
  • 0

#24 Nadya Kochetova

Nadya Kochetova

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

  • Members
  • Pip
  • 66 сообщений
  • ФИО:Kochetova Nadya
  • Город:London, UK

Отправлено 19 декабря 2007 - 06:25

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

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

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

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

#25 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 19 декабря 2007 - 08:29

Сорри, что снова влезаю, просто хочу повторить еще раз, то что писал до этого уже 2 раза:
Не надо ничего усложнять, все прозрачно!!!

Слава правильно писал:

Чем это не обычный раунд тестирования


ИМХО, Это и есть очередной раунд тестирования...

YuP,
Скажите честно, вам нужен тест план?
или
Нужно объяснить заказчику куда уходят деньги?
или
что-то другое?
  • 0
Алексей Булат
Про Тестинг

#26 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 19 декабря 2007 - 08:37

maintenance testing: Testing the changes to an operational system or the impact of a
changed environment to an operational system. Источник: Standard glossary of terms used in Software Testing
Version 1.3 (dd. May, 31st 2007)
Produced by the ‘Glossary Working Party’
International Software Testing Qualifications Board.

ИМХО, ISTQB продолжает множить фигню :) Уже как-то разбирали в форуме какие-то траблы с материалами ISTQB - дошли до первоисточника, который как оказалось не совсем авторитетен в данной области. Не удивлюсь если это его же творение.

Собственно вся деятельность ISTQB - я сужу по России и Украине, хотя это, скорее всего, отображдение общей стратегии ISTQB как организации - напоминает странные шатания по рынку с просьбой к самим игрокам рынка дать материалы, которые ISTQB "сертифицирует" (повесит свой логотип) и будет продавать под своей маркой, при этом как я вижу по качеству материалов, которые просачиваются из ISTQB наружу - материалы либо совсем не рецензируются сколь-угодно компетентными в вопросах тестирования людьми, либо рецензируются теми же, кто эти материалы в ISTQB "скармливает".
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#27 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 19 декабря 2007 - 08:43

А с другой стороны есть такой тип тестирования, под названием Конфигурационное тестирование - "специальный вид тестирования, направленный на проверку совместимости объекта тестирования с различным аппаратным и программным обеспечением."
Там как раз и должны сидеть "спецательные" тесты на новый тип оборудования (в соотв. см. с требованиями).

Совершенно верно! Тип тестирования - "конфигурационное", раунд - самый обычный, что в него включать - зависит от приложенияи требований к окружению эксплуатации.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#28 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 19 декабря 2007 - 09:07

Сорри, что снова влезаю, просто хочу повторить еще раз, то что писал до этого уже 2 раза:
Не надо ничего усложнять, все прозрачно!!!

...


ИМХО, Это и есть очередной раунд тестирования...

+1.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#29 YuP

YuP

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

  • Members
  • Pip
  • 38 сообщений
  • Город:Питер

Отправлено 19 декабря 2007 - 09:17

YuP,
Скажите честно, вам нужен тест план?
или
Нужно объяснить заказчику куда уходят деньги?
или
что-то другое?


Отвечаю честно. Меня в данном случае интересует чисто формальная теория, для общего развития. Обосновать заказчику место, куда уходят деньги - не проблема :). И с тест-планами тоже вопросов нет. Почти ;).

Просто сначала показалось, что при тестировании совместимости с новым окружением уже выпущенного релиза нарушается установленный цикл разработки софта. Теперь все вернулось на круги своя. Я так понял, что рассматриваемое тестирование нельзя отнести ни к предыдущей версии продукта, ни к следующей. Это отдельная исследовательская активность, по результатам которой могут быть сформированы новые требования к следующей версии: "Реализовать поддержку такого-то оборудования..".
  • 0

#30 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 26 января 2008 - 16:05

maintenance testing: Testing the changes to an operational system or the impact of a
changed environment to an operational system. Источник: Standard glossary of terms used in Software Testing
Version 1.3 (dd. May, 31st 2007)
Produced by the ‘Glossary Working Party’
International Software Testing Qualifications Board.

ИМХО, ISTQB продолжает множить фигню :) Уже как-то разбирали в форуме какие-то траблы с материалами ISTQB - дошли до первоисточника, который как оказалось не совсем авторитетен в данной области.

Решил сделать небольшой follow-up в рамках рекламной компании SWEBOK:

------------------

5.2.2.11.Configuration testing [Kan99:c8; Pfl01:c9s8.3]

In cases where software is built to serve different users, configuration testing analyzes the software under the various specified configurations.

------------------

In chapter 6 "Maintenance"
6.2.1.2. Testing [Art88:c9; Pfl01:c11s11.3]

The cost of repeating full testing on a major piece of software can be significant in terms of time and money. Regression testing, the selective retesting of a software or component to verify that the modifications have not caused unintended effects, is important to maintenance. As well, finding time to test is often difficult. There is also the challenge of coordinating tests when different members of the maintenance team are working on different problems at the same time. [Plf01] When software performs critical functions, it may be impossible to bring it offline to test. The Software Testing KA provides additional information and references on the matter in its sub-topic 2.2.6Regression testing.

------------------
  • 0


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



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

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

Яндекс.Метрика
Реклама на портале