Совет по тестированию программного обеспечения?

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

Просто отметим, что мы передаем нашу разработку на аутсорсинг. К сожалению, предоставленный нам релиз редко тестируется разработчиками, и вот "отношения" у нас с ними последние 7 лет....

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


testing automated-tests functional-testing
person andreas    schedule 09.12.2010    source источник
comment
@JoseK: В проекте семилетней давности? Я так не думаю...   -  person Goran Jovic    schedule 09.12.2010
comment
@Горан: почему бы и нет? текущая модель не работает хорошо   -  person JoseK    schedule 09.12.2010
comment
@JoseK: Я согласен с тем, что agile почти всегда лучше, но у него есть некоторые предварительные условия, то есть архитектура программного обеспечения должна быть «дружественной к изменениям» с самого начала. Если это не так, Agile просто не работает. И я сомневаюсь, что писать его с нуля — вариант.   -  person Goran Jovic    schedule 09.12.2010

Ответы (4)


arrow_upward
2
arrow_downward

У вас есть два варианта:

  • Разделите код на независимые модули, чтобы исправление/изменение только в одном модуле означало, что вам нужно повторно протестировать этот модуль. Однако из-за зависимостей это эффективно только в очень ограниченной степени.
  • Внедрите автоматизированные тесты, чтобы повторное тестирование было не таким дорогим. Сначала потребуется немного больше работы, но она определенно окупится в вашем сценарии. Вам не нужно выполнять модульное тестирование или TDD — интеграционные тесты, основанные на инструментах захвата-воспроизведения, часто проще внедрить в ваш сценарий (установленный проект с процессом ручного тестирования).
person Michael Borgwardt    schedule 09.12.2010

arrow_upward
1
arrow_downward

Внедрите среду непрерывного тестирования, доступную вам и разработчикам. Что-то вроде CruiseControl.Net и NUnit для автоматизации функциональных тестов.

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

person Mark Mayo    schedule 09.12.2010

arrow_upward
0
arrow_downward

Определите «Quality SLA» — а именно, что все модульные тесты должны быть пройдены, весь новый код должен иметь определенный уровень охвата, весь новый код должен иметь определенный балл в какой-либо программе проверки статического анализа.

Конечно, все подобное можно обыграть, поэтому проводите регулярные отчеты после релиза, где вы обсуждаете проблемные области и создаете непредвиденные обстоятельства, чтобы избежать этого в будущем.

person PaulJWilliams    schedule 09.12.2010

arrow_upward
0
arrow_downward

Внедрите сервер GO с панелью инструментов и управляйте графическим интерфейсом агента GO с вашей стороны.

http://www.thoughtworks-studios.com/forms/form/go/downloadтекст ссылки

person NaV    schedule 22.12.2010