Сообщений в теме: 29

[YuP]

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

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

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

[LeshaL]

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

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

[Darkus]

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

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

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

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

[Nadya Kochetova]

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

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

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

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

[Boltick]

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

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

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

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

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

[Case]

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 "скармливает".

[Case]

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

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

[Case]

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

...


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

+1.

[YuP]

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

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

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

[a66at]

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.

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