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

[YuP]

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

Но появилось новое оборудование, которое так же, как и старое должно корректно поддерживаться программой.

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

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

[Boltick]

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

Но появилось новое оборудование, которое так же, как и старое должно корректно поддерживаться программой.

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

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

Добрый день.

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

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

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

Спасибо.

[Galina]

Я бы начала с:
1. Full Regression Testing
2. Critical parts/path Testing
3. Exploratory Testing
По результатам более глубое тестирование частей...

Если есть время, то я бы повторила полный цикл тестирования, как он проводился в первом случае...

Как то вот так...

[Nadya Kochetova]

Я бы начала с:
1. Full Regression Testing
2. Critical parts/path Testing
3. Exploratory Testing
По результатам более глубое тестирование частей...

Если есть время, то я бы повторила полный цикл тестирования, как он проводился в первом случае...

Как то вот так...

Галина, вы собираетесь вначале запускать регрешн сюит. На каком окружении? На старом или новом? Вы же знаете, что новое окружение может потребовать (читай потребует ) новых тестов. возможно нового подхода к тестированию. Новое оборудование может поддерживать NetApps, использовать Ctirix и пр.. ваш регрешн сюит даже может не запуститься на новом оборудовании

Вы по результатам эксплорер тестинга собираетесь проводить глубокое тестирование частей?
и что такое "глубокое тестирование частей"?

И если у вас есть время, то вы бы повторили полный цикл тестирования - интересно, полный цикл тестирования это что? это снова регрешн тестинг, критикал пас и эксплоритори тестинг? и в таком порядке?

с уважением и небольшим недоумением,
Надя

[dimasoft]

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

Но появилось новое оборудование, которое так же, как и старое должно корректно поддерживаться программой.

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

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

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

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

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

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

С уважением,
Дмитрий Мугтасимов.

[Galina]

Галина, вы собираетесь вначале запускать регрешн сюит. На каком окружении? На старом или новом? Вы же знаете, что новое окружение может потребовать (читай потребует ) новых тестов. возможно нового подхода к тестированию. Новое оборудование может поддерживать NetApps, использовать Ctirix и пр.. ваш регрешн сюит даже может не запуститься на новом оборудовании

Вы по результатам эксплорер тестинга собираетесь проводить глубокое тестирование частей?
и что такое "глубокое тестирование частей"?

И если у вас есть время, то вы бы повторили полный цикл тестирования - интересно, полный цикл тестирования это что? это снова регрешн тестинг, критикал пас и эксплоритори тестинг? и в таком порядке?

с уважением и небольшим недоумением,
Надя

Уточняю, имелось в виду, что
1. Тестирование использовалось только ручное.
2. Функциональность перенесена полностью.
3. Тестирование, естественно, на новом окружение. Как работает старое мы и так знаем.
4. По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности.
5. Полный цикл - это то, как мы тестировали выводя в жизнь ту, милую, работающую версию с учётом полученного опыта. Что именно и как именно тестировалось - надо узнать у автора.
6. Что касаемо автоматизации и автотестов - это отдельная песня. Всё-таки автоматизация - это помощь в тестирование, а не полная замена.

Надеюсь, удалось рассеять Ваше недоумение! Если нет - могу попробовать ещё.

[Nadya Kochetova]

Уточняю, имелось в виду, что
1. Тестирование использовалось только ручное.
2. Функциональность перенесена полностью.
3. Тестирование, естественно, на новом окружение. Как работает старое мы и так знаем.
4. По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности.
5. Полный цикл - это то, как мы тестировали выводя в жизнь ту, милую, работающую версию с учётом полученного опыта. Что именно и как именно тестировалось - надо узнать у автора.
6. Что касаемо автоматизации и автотестов - это отдельная песня. Всё-таки автоматизация - это помощь в тестирование, а не полная замена.

Надеюсь, удалось рассеять Ваше недоумение! Если нет - могу попробовать ещё.

Галина, читайте по строкам:
Вопрос 1: вы действительно бы тестировали старый функционал на новом окружении в таком порядке как вы описали?
Вопрос 2: вы считаете что старое окружение теперь тестировать не надо?
Вопрос 3: "По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности." - после (по результатам )регрессионного тестирования, критикал пас и эксплоритори тестирования вы собираетесь еще гонять все тесты которые у вас были?
Вопрос 4: полный цикл - это то, как вы тестировали? т.е. цикл тестирования для вас - это "как я тестировала" ?
Вопрос 5: об автоматизации речь не идет. идет речь о подходе к тестированию старого функционала на новой платформе - т.е. многим известный maintenance testing.

не пытайтесь найти в вопросах подвоха. просто ответьте да, где это возможно или нет. я пытаюсь понять вас.

[YuP]

Добрый день.

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

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

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

Спасибо.

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

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

Что скажете?

[YuP]

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

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

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

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

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

[LeshaL]

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

Привет!
Тут вы совершенно правы. И рад за вас, если вам все с подходом к тестированию понятно, успехов Честно говоря, у меня так очень редко бывает - иногда тестируемое ПО ломается там где не ожидал никто...
Есть "Но". Если вы найдете проблему в ПО при работе на новом оборудовании и если вы решите, что надо делать патч(апдейт, maintenance) релиз - то вам скорее всего придется тестировать и на старых конфигурациях тоже.
Следует учитывать:
1. Будет ли такая конфигурация поддерживаться в следующей версии или нет.
2. Сколько было найдено проблем при попытке использовать ПО на новом оборудовании. Их важность.
3. Насколько такая конфигурация приоритетна в будущем.
4. Не нашлись ли на новом оборудовании проблемы, не найденые ранее и которые могут проявиться и в других конфигурациях.
5. Если проблемы найдены, будете делать патч только для новой конфигурации или же для всех предыдущих тоже.

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

Да, вот уже выделили:
http://en.wikipedia....ibility_testing
http://www.aptest.co...patibility.html

Что касается всего остального - то это не так. Т.е. в этом нет ничего удивительного. Такие вещи так или иначе делаются всегда, особенно для версии >1. Проводится ананлиз, насколько сложно будет что-либо сделать. Анализ может проводится как тестерами, так и девелоперами, или кем-то еще. По результатам, выносится вердикт, будем делать или нет и сколько будет стоить.
Простой пример. Есть программа на джаве, допустим версии 2. Разрабатывалась и тестировалась только под виндами. Возникает у инвесторов желание поддержать и линукс тоже в версии 3. Вроде бы ничего сверхсложного, это ведь джава, должна легко работать - думает инвестор!. Тестеры пытаются прогнать те же тесты на линухе - все работает плохо. Разработчики смотрят в код - находят кучу мест, где привязка к виндам и надо чинить для линуха. Плюс к этому - есть несколько фич, которые работать не будут 100% (например, использование dll-ок от майкрософта, для связи с мсофисом). Дальше - люди будут думать, а надо ли тратить силы, время и деньги на поддержку операционки, где по прогнозам бизнес-аналитиков этой программой будет пользоваться, ну..0.5% от всех пользователей.

[LeshaL]

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

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

Зачем же вы так, коллега вам помочь хочет...
А насчет телефончика, любопытно конечно

[LeshaL]

Извините, леди, можно я встряну - есть небольшой вопрос к Надежде:

Вопрос 5: об автоматизации речь не идет. идет речь о подходе к тестированию старого функционала на новой платформе - т.е. многим известный maintenance testing.

Если честно - первый раз слышу о maintenance testing. Могу представить такое тестирование для hardware, но не для ПО. Проясните пожалуйста, что скрывается за этим термином, применительно к софтверным продуктам. Есть ли это просто тестирование maintenance рилиза?
Спасибо.

[Galina]

Галина, читайте по строкам:
Вопрос 1: вы действительно бы тестировали старый функционал на новом окружении в таком порядке как вы описали?
Вопрос 2: вы считаете что старое окружение теперь тестировать не надо?
Вопрос 3: "По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности." - после (по результатам )регрессионного тестирования, критикал пас и эксплоритори тестирования вы собираетесь еще гонять все тесты которые у вас были?
Вопрос 4: полный цикл - это то, как вы тестировали? т.е. цикл тестирования для вас - это "как я тестировала" ?
Вопрос 5: об автоматизации речь не идет. идет речь о подходе к тестированию старого функционала на новой платформе - т.е. многим известный maintenance testing.

не пытайтесь найти в вопросах подвоха. просто ответьте да, где это возможно или нет. я пытаюсь понять вас.

"Галина, читайте по строкам:" - Надежда, прежде всего чуть больше уважения к другим людям. Если вы не согласны с моей точкой зрения, в этом нет ничего зазорного, просим описание вашего подхода . Пока я только вижу "недоумение" и попытку наезда :) "Типа вы написали чушь, ужас" :)
Вопрос 1: вы действительно бы тестировали старый функционал на новом окружении в таком порядке как вы описали?
- Да, если интересует почему - могу написать.
Вопрос 2: вы считаете что старое окружение теперь тестировать не надо?
- Встречный вопрос - зачем? Вам поступил заказ на то, чтобы существующая программа поддерживала новое окружение. Просьба к вам ответить на вопрос - зачем тестировать старое окружение?
Вопрос 3: "По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности." - после (по результатам )регрессионного тестирования, критикал пас и эксплоритори тестирования вы собираетесь еще гонять все тесты которые у вас были?
- А что вас собственно смущает? В моей, подчёркиваю, моей, что НИ ЕСТЬ ИСТИНА В ПЕРВОЙ ИНСТАНЦИИ, а просто проверено на конкретном проекте, тест-кейзы по функционалу включают гораздо больше всего того, что есть в регрессии и в критикал пас. Однако каждый проект уникален, каждый процесс уникален. Всё-таки цель форума, ИМХО, обмен опытом, а не попытка взять "готовый рецепт" и бездумно его применить.
Вопрос 4: полный цикл - это то, как вы тестировали? т.е. цикл тестирования для вас - это "как я тестировала" ?
- Полный цикл тестирования обычно описывается либо в стратегии на релиз, либо в плане, кто как привык. Естественно полностью шаг в шаг повторять неразумно, т.к. опыт выпуска предыдущей версии есть и его нужно использовать. Но в общем подход будет тот же.
Вопрос 5: об автоматизации речь не идет. идет речь о подходе к тестированию старого функционала на новой платформе - т.е. многим известный maintenance testing.
- Простите, не уловила в чём собственно вопрос?

С огромным Уважением!

P.S. Если не секрет - сколько лет вы занимаетесь тестирование, сколько проектов (не релизов) - успешных?

[Galina]

Извините, леди, можно я встряну - есть небольшой вопрос к Надежде:

Вопрос 5: об автоматизации речь не идет. идет речь о подходе к тестированию старого функционала на новой платформе - т.е. многим известный maintenance testing.

Если честно - первый раз слышу о maintenance testing. Могу представить такое тестирование для hardware, но не для ПО. Проясните пожалуйста, что скрывается за этим термином, применительно к софтверным продуктам. Есть ли это просто тестирование maintenance рилиза?
Спасибо.

Моно-моно, НУНО :)

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.


В общем-то в моей практике я пока встречала только проекты Software Maintenance.
maintenance: Modification of a software product after delivery to correct defects, to improve
performance or other attributes, or to adapt the product to a modified environment. [IEEE
1219]

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

Это моё мнение - осталось услышать мнение Надежды.

[dimasoft]

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

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

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

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

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

Видимо Вам, коллега, для начала нужно научиться разговаривать и перестать считать себя самым умным. Успехов!

С уважением,
Дмитрий Мугтасимов.

[Boltick]

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

Что скажете?

Красиво, но есть противоречия.
Как я понял, версия уже стоит в продакшине. И теперь добавилось новое окружение?

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

Это звучит странно! Если поменялась версия, то я так думаю, что надо будет перетестировать все окружения... так могут образоваться регрессии

Как видим, в данном случае меняется общий цикл разработки софта. Здесь он начинается с тестирования и заканчивается тестрованием .
Можно конечно сказать, что цикл разработки не изменился и первым по прежнему выполняется стадия разработки требований.. Но точно изменились требуемые на стадиях роли. Теперь на первой стадии нужен не маркетолог, а тестровщик.

Не согласен...
Вот что я могу предложить.
Версия уже есть в продакшине или отправлена кастомеру. ВСЕ ОНА УЖЕ СОСТОЯЛАСЬ.
Далее появляется новое окружение. Что мы делаем. Команда тестирования проводит полное тестирование версии на новом окружении.
Причем, если багов нет, то мы можем сообщить, что имеющаяся версия, также прошла тестирование на новом окружении и готова с ним работать.
Если баги были, то тут немного сложнее. Тестирование придется проводить как на новом, так и на стром окружении... Так как фиксы могли не только починить но и сломать, уже работавший ранее, функционал.
В результате полного цикла разработки мы имеем новую версию, которая работает на всех окружениях прошедших тестирование.

И нечего тут усложнять... все просто...

ИМХО

[Nadya Kochetova]

Можно просто Надя.
Сейчас попытаюсь на все ответить. Если что-то пропущу - напишите.


Вот что в моей компании понимают под термином maintenance testing: это тип выполняемой тестерами работы, которая производится каждый раз при внесении каких либо изменений в саму систему ( например, после change requests) либо при изменении окружения, в котором работает эта система.

Вот пример:
Мы поставляем клиентам продукт, который отслеживает изменения в Excel файлах. До марта 2007 года продукт работал только c обрабатываемыми Excel 2003 файловыми форматами. Вышел новый 2007 офис. Наша задача: проверить, как работает наш продукт с xlsx, xlsm,xlsb и пр.форматами поддерживаемыми Excel 2007. Плюс у нас есть заказчик, который работает на Citrix. Готовим к выходу новый релиз

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

То, чем тестеры занимаются в этом случае – есть maintenance testing. Можно оспорить термин. Более того, в других компаниях возможно это называют по-другому.

Алгоритм действий (грубый):

1. Анализ изменений в Excel 2007 по сравнению с предыдущими версиями. Анализ принципа работы Сitrix окружения

2. Анализ «затронутых» изменениями в Excel 2007 функциональностей в нашей системе. Сitrix пока пропустим

3. Полный цикл тестирования не поддерживаемых ранее функциональностей. Например, таблицы (не путайте со сводными). Их не было до 2007 офиса. Если система не обрабатывает некоторые фичи нового офиса , например, игнорирует сводные таблицы – убедиться в том, что система их по прежнему игнорирует

4. Проверить удаленные и не поддерживаемые в новой версии офиса функциональности (например, не поддерживаемые старые форматы).

5. Протестировать основную фукциональность. Не только использовать critical path.

6. Протестировать процесс апгрейда системы (если предполагается), установки системы на новое окружение и пр.

6. Протестировать наличие обоих версий систем и обоих версий офиса на одной машине одновременно (если такое поддерживается)

7. Запускать регрессионный тестинг кусками. Анализировать результаты, заводить баги, если имеются, фиксить, тестировать, до тех пор пока критерий окончания тестирования для отдельных кусков функциональности не будет достигнут.

8. нефункцильнальное тестирование

9. Полный регрессионый тестинг.

далее по списку.. остальные виды деятельности команды тестировщиков не относящиеся к данному топику

Как вы будете тестировать, кто будет тестировать и сколько вы будете тестировать – это все зависит от продукта, рисков, сложности , ресурсов и пр. факторов.

Цикл тестирования – это последовательность этапов тестирования (вкл. Анализ, проектирование и пр). Не важно где цикл описывается, главное, какие этапы в него входят и чем занимаются люди на этих этапах. И цели, которые преследуют люди, проводя тот или иной вид тестирования.

Выполнение полного регрессионного тестирования на начальном этапе в примере описанном выше считаю неразумным. Но вот на случае с Citrix – это хороший шаг. Мы запустили весь регрессионный тестинг на Citrix сразу. Да, свалилось много скриптов. Причины ошибок были быстро устранены. Так как изменения произошли в окружении, а не в системе. Поэтому, прежде чем запускать весь цикл регрессионного тестирования – стоит всегда оценить то, что вам это даст.

Галина, я не пыталась на вас наезжать. Я просто спросила, действительно ли вы в таком порядке хотите проводть тестирования. Я нигде не сказала , это хорошо или плохо. Я нигде не критиковала вас. Иногда люди перечисляют что бы то ни было в разной последовательности. Ваша последовательность видов тестирования показалась мне интересной. Я попросила вас подтвердить. И только лишь. Не ищите подвоха.

По поводу того, надо ли тестированить старое окружение.
Но где-то было это написано. Если в случае рождения ребенка в семье, в системе поле «число детей» должно увеличиться на количество рожденных деток, обычный тестер проверит – выросло ли количество детей на 1 после того, как он «добавил» одного ребенка. Но хороший тестер проверит, не «уменьшилось» ли при этом количество детей в другом месте. Поэтому мы всегда тестируем и старое окружение. Это не обязательно, наверное. Но мы так делаем. Прежде чем выпустить релиз или хотфикс мы проверяем все предыдущие версии.

Учитывая количество ошибок, которое возникает в коде при любой его поправке и сколько по статистике ошибок возникает в процессе управления кодом (имею в виду source control, можно и плохо изъяснилась), если вам позволяют ресурсы, время, и пр – лучше перепроверить и оттестировать старое окружение.

Галина, я не сомневаюсь, что вы опытный тестер. Очень даже возможно, что опытней меня. Я никогда это не оспаривала . Но мне очень инетерсно иногда читать ваши комментарии. Иногда я могу промолчать, иногда нет. Но вам не стоит воспринимать все так критично.

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

Надеюсь, ответила на все вопросы

[Galina]

Галина, я не пыталась на вас наезжать. Я просто спросила, действительно ли вы в таком порядке хотите проводть тестирования. Я нигде не сказала , это хорошо или плохо. Я нигде не критиковала вас. Иногда люди перечисляют что бы то ни было в разной последовательности. Ваша последовательность видов тестирования показалась мне интересной. Я попросила вас подтвердить. И только лишь. Не ищите подвоха.

И мне показалось :)

Галина, я не сомневаюсь, что вы опытный тестер. Очень даже возможно, что опытней меня. Я никогда это не оспаривала . Но мне очень инетерсно иногда читать ваши комментарии. Иногда я могу промолчать, иногда нет. Но вам не стоит воспринимать все так критично.

Опыт вещь относительная... Я только за встречные и "несогласные " комментарии! Ибо, ИМХО, любое мнение имеет право на существование!

Автору и всем, сорри за небольшой оффтоп!

Надя, спасибо за описание вашего подхода!

[LeshaL]

Надеюсь, ответила на все вопросы

Спасибо.
Как я и предположил - получается, это просто вариант тестирования maintenance версии продукта. Под maintenance версией мы похоже понимаем одно и тоже:
Либо багфикс релиз, либо версия для поддержки новой конфигурации\окружения итп. Т.е. релиз без добавления нового функционала.

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

А под термином maintenance тестирование я понимаю следующее - техобслуживание оборудования. Например, медицинский прибор, котрый лечит ультразвуком. Его надо планово тестировать на предмет того, что интенсивность звука соотвествует параметрам.
Правда, подумав и почитав этот тред, вероятно есть случаи майтененс тестирования сложных софтверных систем. Например, провести тестирование на целостность данных в базе, после восстановления после сбоя у заказчика. Ну или что-то в этом духе.
Вообщем, что-то типа того, что тут написано http://en.wikipedia....tenance_testing - хотя как-то криво описано.

К сожалению :) я сейчас в отпуске и мне лень залазить на работу, чтобы посмотреть, что говорят умные люди написавшие IEEE Std 610.12, по поводу maintenance testing-a и maintenance релиза.
Хотя, похоже, Галина привела цитату именно из этого источника. Название похоже - сомнение в дате - неужели у них был апдейт от 31 мая сего года?

[Case]

Вот что в моей компании понимают под термином maintenance testing: это тип выполняемой тестерами работы, которая производится каждый раз при внесении каких либо изменений в саму систему ( например, после change requests) либо при изменении окружения, в котором работает эта система.

"Не множте сущностей без необходимости" как сказал не так давно один мой коллега.

Сам термин maintenance никаким местом к тому что вы описали отношения не имеет даже просто по смыслу. Мaintenance по сути - поддержка. "Тестирование поддержки" мне не совсем понятно и как я вижу не мне одному. Я бы побоялся вводить термин и отстаивать его, если основной мотив "у нас в компании так называется". У нас в компании одна очень умная штука "байдой" называется - что ж теперь :)

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