Подскажите, кто-нибудь использует протокол тестирования? Перечень процессов обязательных для проверки после обновления тестовой базы.
и Вообще стоит ли вводить такую процедуру прописывания протокола тестирования?
Я бы максимально детализированный разработал и "попросил" бы все службы его заполнять, но до конца не уверен будет ли профит...
Протокол тестирования после обновления ERP
Модераторы: m0p3e, edward_K, Модераторы
Протокол тестирования после обновления ERP
ВБР РУЛИТ)))ИС3
Re: Протокол тестирования после обновления ERP
p.s. у нас в it службе штат не большой и сами проверить весь функционал ERP не можем, потому проверка на плечах пользователей.
ВБР РУЛИТ)))ИС3
-
- Постоянный обитатель
- Сообщения: 135
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Москва Связьтранснефть
Re: Протокол тестирования после обновления ERP
У всех так (Связьтранснефть:)Mekhtiev писал(а):проверка на плечах пользователей.
С ув..
-
- Заслуженный деятель интернет-сообщества
- Сообщения: 5188
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: SPB galaxy spb
Re: Протокол тестирования после обновления ERP
Я бы посоветовал делать так.
1. Делаете тестовое обновление.
2. Рассылаете начальникам отделов о грядущей установке патчей с просьбой протестировать там то и там свои процессы и уведомить в таком то формате о возникших проблемах или ограничениях на установку(например сдача отчетности) до такого то числа(скажем даете дня 3 - все равно мало кто будет тестить).
3. Если уведомлений о проблемах не поступает, ставите патчи на рабочую базу.
Чтобы было поменьше стресов ставите раз в два месяца - тогда с одной стороны вы не получите вагон проблем скопом, с другой стороны и пользователям будет не особо напряжно.
Если же вы будете ждать визы каждого отдела, то патчи не поставите никогда.
Можно еще повозится с AQA - она для этого и предназначена.
Для этого вам нужно иметь эталлонную базу. Перед каждым запуском тестов ее нужно востанавливать из архива.
AQA сам умеет это делать, но делает он это ... очень долго, поэтому эту возможность следует там отключить(по умолчанию включена).
По сути это клавиатурный повторитель, но там можно проставить например контрольные точки. Скрипт можно потом подправить руками - я когда то давно использовал его для формировании оборотки по всем бухсчетам в отдельные файлы.
Из экзотики еще использовали для автоматизации выгрузки через стандартный экспорт(накладывались фильтры, помечали документы, формировался экспорт, проставлялись ВА, что выгрузка прошла).
1. Делаете тестовое обновление.
2. Рассылаете начальникам отделов о грядущей установке патчей с просьбой протестировать там то и там свои процессы и уведомить в таком то формате о возникших проблемах или ограничениях на установку(например сдача отчетности) до такого то числа(скажем даете дня 3 - все равно мало кто будет тестить).
3. Если уведомлений о проблемах не поступает, ставите патчи на рабочую базу.
Чтобы было поменьше стресов ставите раз в два месяца - тогда с одной стороны вы не получите вагон проблем скопом, с другой стороны и пользователям будет не особо напряжно.
Если же вы будете ждать визы каждого отдела, то патчи не поставите никогда.
Можно еще повозится с AQA - она для этого и предназначена.
Для этого вам нужно иметь эталлонную базу. Перед каждым запуском тестов ее нужно востанавливать из архива.
AQA сам умеет это делать, но делает он это ... очень долго, поэтому эту возможность следует там отключить(по умолчанию включена).
По сути это клавиатурный повторитель, но там можно проставить например контрольные точки. Скрипт можно потом подправить руками - я когда то давно использовал его для формировании оборотки по всем бухсчетам в отдельные файлы.
Из экзотики еще использовали для автоматизации выгрузки через стандартный экспорт(накладывались фильтры, помечали документы, формировался экспорт, проставлялись ВА, что выгрузка прошла).
Re: Протокол тестирования после обновления ERP
Добрый день! так и делаем, беда только в том что, все отписываются а по факту частично проверяют .. например бухгалтерия отписалась все "ОК", иду сам проверять наши доработки, а они требуют перекомпиляции, например из-за изменения структуры прототипа...edward_K писал(а):Я бы посоветовал делать так.
1. Делаете тестовое обновление.
2. Рассылаете начальникам отделов о грядущей установке патчей с просьбой протестировать там то и там свои процессы и уведомить в таком то формате о возникших проблемах или ограничениях на установку(например сдача отчетности) до такого то числа(скажем даете дня 3 - все равно мало кто будет тестить).
3. Если уведомлений о проблемах не поступает, ставите патчи на рабочую базу.
Чтобы было поменьше стресов ставите раз в два месяца - тогда с одной стороны вы не получите вагон проблем скопом, с другой стороны и пользователям будет не особо напряжно.
Если же вы будете ждать визы каждого отдела, то патчи не поставите никогда.
.
Чек лист так или иначе придется разработать...
Вопрос номер второй, заранее оговорюсь, что проблем сильных не доставляет, но раз уж я вернулся на форум, спрошу у коллег.
Почему слетает видимость пунктов меню у пользовательских групп?
ВБР РУЛИТ)))ИС3