YuP

Спасибо за столь подробный ответ.

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

Хотя.. наверное все-таки по другому не получится поступить. Попробуем обобщить удачный опыт собственных прошлых разработок.

Еще раз спасибо.

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

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

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

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

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

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

Расскажите поподробнее. Какого рода программа? Какая у нее у функциональность? Какие были объемы тестирования в чел*часах? Имеются ли выделенные регрессионные тесты? Автоматизированные это тесты или ручные?

А как зовут тестировщицу и ее телефончик не надо сообщить?

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

Какие черные ящики ? Какие неизменившиеся части? Какая добавленная функциональность? Ничего не изменилось в версии программы с момента предыдущего тестрования. С какой целью с предыдущей версией сравнивать?
Новое обрудование - это окружение тестируемой программы, внешнее по отношению к ней... о каких "входах" речь? В жизни бы так все просто: взял входы, подал на них входные данные.. Если что-то подать на "вход" тестируемой программы (т.е. реализовать "драйвер", пользуясь нашей профессиональной терминологией), то этим мы заменим данные, которые реально выдает новое внешнее окружение. А именно работу с ним и надо протестировать. Так что не подходит такое предложение..

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

Добрый день.

С тестированием так и быть - тестировать эту же версию на новом окружении. Да, появится другой результат не отличный, а дополняющий предыдущий. Все может быть иным, прежней останется только версия. Ведь она не менялась же?

Будут новые баги, значит их надо будет фиксить, будут новые выводы - значит их надо будет принимать к сведению.

По-моему все достаточно прозрачно.

Спасибо.

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

Но мне кажется, что по своей сути такое тестирование можно выделить в отдельный вид . Т.к. в отличие от других видов оно выполняется не после стадии разработки, (когда версия-претендент на релиз либо становится релизом, либо отдается программерам на ремонт), а перед разработкой следующей версии приложения. Релиз уже состоялся, програма работает у клиентов и менять предыдущую версию x.y.z на новую с таким же номером конечно никто не будет. А по результатам тестирования в лучшем случае новая версия выпущена не будет - если проблем с новой техникой не возникнет, а в худшем новая версия появится. Причем ее функциональность останется без изменений, а только будут исправлены ошибки совместимости с новым оборудованием.
Такое тестирование как бы изначально уже принадлежит следующей версии программы, с него начинается разработка новой версии (точнее, может начаться). Рассматриваемое тестирование инициирует разработку, определяя новые задачи программистам, оно направлено на формирование требований к программе, которые необходимо будет реализвать в ходе стадии разработки, а потом проверить реализацию на завершающей стадии тестирования и исправления багов.
Как видим, в данном случае меняется общий цикл разработки софта. Здесь он начинается с тестирования и заканчивается тестрованием .
Можно конечно сказать, что цикл разработки не изменился и первым по прежнему выполняется стадия разработки требований.. Но точно изменились требуемые на стадиях роли. Теперь на первой стадии нужен не маркетолог, а тестровщик.

Что скажете?