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

[rlabs]

Объясните, пожалуйста, как всё-таки правильно подготавливать тестирование.
Книжку Кэнера читал, "Автоматизированное тестирование" дочитываю, но всё равно как-то не получается.
Итак, имеется версия программного продукта и база ошибок, накопленная благодаря тестированию в режиме "свободного поиска". Хелп есть, спецификации нет, ТЗ нет, донимать распросами разработчиков - опасно для жизни. Ознакомительное тестирование можно считать проведенным - в "свободном поиске" моделируется масса мини-сценариев использования.

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

Может быть, кто-нибудь может "на пальцах" объяснить процесс поготовки? Читаю книгу - всё понятно, сажусь за тестируемое приложение - не понятно, с какой стороны подступиться.

[Mike]

Если нет ТЗ, и требований, то единственный вариант - писать требования и use cases самим (или с привлечением функционального аналитика если таковой имеется). Писать можно в любом виде, лишь бы они покрывали всю функциональность приложения. Далее - расставляете priorities каждого требования. К требованиям привязываете тесты (если они уже есть) или пишите новые (если нет) - очередность - в соответствии с priorities требований. Группируете тесты в тест сьюты, которым также назначаете приоритеты (Соответственно, на каждой итерации начинаете тестирование с самых важных сьютов и так далее, по очередности). Ну и вперёд :).

Если не хотите писать тесты по шагам (а это вполне понятно), и если тестировщики опытные, можно попробовать организовать ручное тестирование так, как это описанно тут. Только это не освобождает от написания тест плана и тестов - просто тестами тогда будут задания на test session.

И ещё один совет - почитайте RUP (Rational Unified Process) :) :) - хоть что-то пригодится. Это как раз об организации процесса разработки (и, в частности, тестирования).

[Stren]

Rational Unified Process - это конечно круто, только вот на руском было бы доступнее

[rlabs]

Если не хотите писать тесты по шагам (а это вполне понятно), и если тестировщики опытные, можно попробовать организовать ручное тестирование так, как это описанно тут. Только это не освобождает от написания тест плана и тестов - просто тестами тогда будут задания на test session.

Да, про session-based testing читал, пробуем внедрить, реально пока не очень получается. Собственно, затык в самом начале - на создании outline приложения :-)
Ну и метрики там не очень понятные, а как раз метрики сейчас представляют основной интерес.

И ещё один совет - почитайте RUP  (Rational Unified Process) :)  :)  -  хоть что-то пригодится. Это как раз об организации процесса разработки (и, в частности, тестирования).

Про RUP тоже очень интересно, разумеется. Можете посоветовать русскоязычную или переводную книжку? Знаю, они уже публикуются, но хочется какую-то рекомендацию по лучшему варианту.

[Green]

Может быть, кто-нибудь может "на пальцах" объяснить процесс поготовки? Читаю книгу - всё понятно, сажусь за тестируемое приложение - не понятно, с какой стороны подступиться.

В Вашей ситуации я бы поступил следующим образом:

1. Пообщался бы с разработчиками или руководителем проекта и ЗАПИСАЛ все возможные бизнес процессы, которые выполняет приложение. Каждому бизнес процессу проставьте два показателя (опять же совместно с руководителем проекта): важность и критичность. В результате получиться приоритетный список.

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

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

4. Выполняйте тест кейсы, относыщиеся к наиболее важным и критичным бизнес процессам. Постепенно Вы сможете закрыть каждый бизнес процесс.

При таком подходе Вы будете точно знать сколько Вы уже сделали и сколько еще предстоит сделать. Да, и начальству будет что показать.
:)

В дальнейшем на предложенный костяк могут быть "нарощены" любые методики или приемы по тестированию приложения.