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

[Ashker]

Доброго времени суток!
Не мог бы кто подсказать, как именно заказчик может убедиться в том, что стадия тестирования программного продукта выполнена надлежащим образом и продукт качественен?
На текущий момент разработчик мутит - уже найдены расхождения с ТЗ, ответить как они тестировали (и тестировали ли вообще) они не могут.
Какай необходимо запросить перечень документов, и что в них должно быть?

[DrVal]

1. Для этого могу предложить 3 способа - аудит процесса и артефактов тестирования у разработчика, независимое тестирование или тестировать самим.

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

Доброго времени суток!
Не мог бы кто подсказать, как именно заказчик может убедиться в том, что стадия тестирования программного продукта выполнена надлежащим образом и продукт качественен?
На текущий момент разработчик мутит - уже найдены расхождения с ТЗ, ответить как они тестировали (и тестировали ли вообще) они не могут.
Какай необходимо запросить перечень документов, и что в них должно быть?

[Ashker]

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

Документов у них точно нет (они сами говорили об этом в личной беседе).
Проблема в том, что они уверяют, что тестировать не надо, ибо и так всё работает :)
Очевидно, не хотят ничего делать и вводят в заблуждение заказчика... (

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

[Clauster]

Можно попробовать заставить провести acceptance testing и запросить отчет. Вкратце это приемочное тестирование на соответствие ТЗ и юзкейсам.

[SALar]

Проводите acceptance testing по правилам проведения аудита. Если очень надо поставить фирму разработчика на место, то при наличии хороших требований можно и за день сделать. Но брать на такой аудит нужно очень опытного тестировщика, который селезенкой знает, где программа будет падать. Из серии:

- Проверьте здесь.
- Необработанный эксепшен и остановка сервера
- Теперь здесь
- Полбазы снесло
- Сделайте расчет на таких данных
- Не сходится
- Ну все, три теста сделали, три критических ошибки поймали. Уже достаточно.

[Ashker]

Хорошо, всем спасибо за ответы!

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

[DrVal]

Вы не обидитесь, если я Вас отошлю к стандартам IEEE?

829-1998 - Software Test Documentation
730-2002 - Standard For Software Quality Assurance Plans

А вообще проектная документация (в т.ч. и касательно тестированию) - это часть контракта. Т.е. если в договоре не написано, какую документацию должен предоставить разработчик, то можно и ничего не получить.

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

Хорошо, всем спасибо за ответы!

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

[Ashker]

DrVal Спасибо! Вопрос с контрактом я выясню.

IEEE 829-1998 это походу это:
ieee 829 1998

А вот второй не могу найти..

[Darkus]

Требуйте от разработчиков ПМИ.
В качестве ГОСТа предложите оформление по "РД 50-34.698-90 - АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ " (см. п. 2.14. Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем))
В приложении должны быть приёмо-сдаточные тесты. Внимательно читайте их, т.к. по ним будет приниматься система.

[Toxa]

ПМИ - это хорошо, но если его будет писать сам разработчика, то такое ПМИ никогда не найдет ошибки. Из него просто все сценарии находящие ошибки будут удалены (при этом он будет 100% покрывать все требования). Что бы избежать этого, лучше всего написать ПМИ самим, а для этого, как говорил SALar, наймите опытного тестировщика.

[Nemo]

Программа и методика испытаний - оптимальное, на мой взгляд, решение в данном случае. Документ описывает приемо-сдаточные тесты и сам процесс тестирования. У нас, правда, тесты состаляются на основании ТЗ и направлены на проверку того, что все пункты ТЗ реализованы в должном виде. Процесс приемки согласовывается при составлении договора. Там прописывается, кто готовит ПМИ, порядок согласования-подписания ПМИ и т.д. Затем во время разработки продукта одна из сторон (как правило мы - разработчики) составляет ПМИ готовит приемо-сдаточные тесты, затем эти документы подписываются обеими сторонами и акт приемки подписывается только в случае успешного проведения испытаний (критерии, по которым определяется успешность, также прописываются в ПМИ).
В Вашем случае в договоре это не оговаривается, но приемка продукта все равно должна в какой-то форме проводиться. Вы можете предложить разработчикам этот вариант.
Сам документ и тесты лучше, вероятно, либо составить самим, либо привлечь специалистов, так как разработчикам Вы, судя по всему, не слишком доверяете.
Ну и наконец, в случае аварии эти документы, как мне кажется, для прокуратуры будут что-то значить только в том случае, если та конкретная ситуация, которая привела к аварии будет в тестах. Поэтому, если требования к качеству продукта предъявяются высокие, и Вы хотите продстраховаться, лучше всего провести тестирование самим или отдать на аутсорсинг компании, специализирующейся на тестировании чужого ПО.

[Ashker]

На данный момент ПМИ есть. Я, к сожалению, сейчас не располагаю инфой, кто составлял и согласовывал (и согласовывал ли вообще) данную методику испытаний.
Но проблема в том, что эта ПМИ для комплекса в целом (программная и аппаратная составляющие) и направлена только на то, чтобы показать, что мол всё сделано , а не на то, чтобы показать, что всё работает надёжно (надёжность - основное требование). Никакие внештатные ситуации не моделируются и не прогоняются.

К самой программе множество замечаний (как я уже говорил, есть и не соответствия с ТЗ) что наводит на мысль о небрежной реализации и наличии серьёзных багов в коде. А Разработчик отказывается предоставлять подтверждение этапа тестирования.

Завалить их - проблем нет, а вот заставить работать....

Такие вот дела.

[Фрося]

Требуйте от разработчиков ПМИ.
В качестве ГОСТа предложите оформление по "РД 50-34.698-90 - АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ " (см. п. 2.14. Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем))
В приложении должны быть приёмо-сдаточные тесты. Внимательно читайте их, т.к. по ним будет приниматься система.

Немножко уточню.
Какие именно документы на программное обеспечение(например, ПМИ) должен предоставить исполнитель , и в соответствии с какими ГОСТами созданными ( или в соответствии с корпоративными стандартами, например...) , должно быть прописано в ТЗ на разработку.
Ежели не прописано - то требовать можно, но вряд ли дадут.....
И не обязательно по ГОСТу (ежели Вы, как заказчик, не являетесь госучреждением... или представителем Минобороны... - то ГОСТ не обязателен...)

[Фрося]

Хорошо, всем спасибо за ответы!

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

Про контракт - здесь очень правильно написали.
Я бы еще добавила.
Есть ГОСТ Р 51904 (и не только...)
Объем документации, который должен быть разработан, привязывается к уровню ПО. Т.е оценивается, как отказ ПО влияет на безопасность, а уже исходя из этого - определяется объем документации..
И если просмотреть объем документации -- то... документация по приемо-сдаточному тестированию - это далеко не все, что необходимо..