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

[Case]

Господа, интересует Ваше мнение на простую статью по определению критериев анализа средств автоматизации, с которой можно ознакомиться в лаборатории Тестера: Разработка критериев анализа систем автоматизации тестирования
Принимается критика, уточнения.

[el-step]

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

[Case]

Согласен, обзор технологий в самом результате исследования будет (есть для нескольких линеек), а вот в план разработки критериев я это не вставил - спасибо за уточнение.

[Олешка]

План.


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

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

[Олешка]

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

Наверное, тогда надо писать - "Поддерживаемые процессы жизненного цикла разработки ПО"?

Хотя мне кажется, что для систем автоматизированного тестирования важнее наличие интерфейса с системой управления требованиями, с системой bug tracking и другими, потому что иначе меняется объект рассмотрения статьи - анализируется уже не система автоматизированного тестирования, а система управления жизненным циклом ПО.

[Олешка]

В разделе "Поддерживаемые процессы тестирования" автор предлагает:

Для более полного анализа стоит разносить в процессе оценки инструменты разных типов, по разным категориям, одновременно расширяя набор критериев для узкоспециализированных инструментов.

но по какой-то причине мысль отложена и разделение не проведено.

[Олешка]

Если говорить о поддерживаемых процессах жизненного цикла, то есть предложение более четко сформировать такой список, руководствуясь не только собственными практическими наработками, но и существующими стандартами. Неплохая статья в качестве справочного материала:
Основы методологии проектирования ИС.
Также интересно взглянуть на критерии оценки и выбора CASE-средства:
Критерии оценки и выбора CASE-средства - там есть кое-что относительно поддержки процесса тестирования CASE-редством, так сказать, взгляд наоборот.

[Олешка]

Фраза:

Управление жизненным циклом (Lifecycle Management), как процесс тесно связанный с планированием этапов тестирования, как при «водопадной», так и при циклической модели разработки ПО. ресурсов этапов разработки / тестирования.

содержит предложение без начала (подчеркнуто в цитате)

[Олешка]

Управление изменениями (Change request management), как процесс специфичный для этапов тестирования, но интегрированный в процесс внесения изменений в программный код.

Выглядит туманно - я еще могу себе представить, как заявленные change requests добавляются в требования к системе, но как это должно быть интегрировано в процесс внесения изменений в коде? Можно пояснить? И еще - если управление изменениями должно быть интегрировано в процесс внесения изменений в код, почему нет того же самого в отношении процесса управления ошибками?

[Олешка]

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

Возможно ли найти такую систему, в которой все это будет автоматизировано?

[Case]

Наверное, тогда надо писать - "Поддерживаемые процессы жизненного цикла разработки ПО"?

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

[Олешка]

Наверное, тогда надо писать - "Поддерживаемые процессы жизненного цикла разработки ПО"?

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

Неа ;) - я как раз предлагаю сосредоточиться в статье на процессах тестирования.

[Case]

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

А зачем ещё нужен запрос на изменение как не для того, чтобы внести изменение в код???

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

А почему вы отрываете эти два процесса? Риквест, изменение, управление ошибками - как то вы их лихо размели по углам - получается действительно ерунда. У вас кстати довольно интересный стиль ведения полемики :)
Впрчем это известная в форумах политика - сначала сказать нет ты не прав, потому что (вставляетсЯ что-то чего аппонент не говорил), потом тут же опровергнуть его же словами :)
Олешка - я благодарен за критику - но если можно чуть более предметно.
Это кстати почему-то касается многих ваших постов в той же теме по обучению персонала и по сертификации системы качества - я к примеру упорно не уловливаю с первого прочтения суть вашего сообщения. Возможно не всегда виновать обьясняющий :), но всё же.

[Case]

Наверное, тогда надо писать - "Поддерживаемые процессы жизненного цикла разработки ПО"?

Тогда почему писать процессы разработки ПО? (в первой редакции статьи так и было написано, но потом я изменил и формулировку и абзац полностью)

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

[Олешка]

Возможно не всегда виновать обьясняющий :), но всё же.

Всегда-всегда :) Попробую более предметно.

[Case]

Если говорить о поддерживаемых процессах жизненного цикла

Да зачем говорить в статье о инструментах тестирования и критериях их оценки о жизненном цикле разщработки? Тестирование и так довольно сущетсвенно привязано к этапам разработки, так зачем же окончательно привязывать к ним ещё и анализ инстументов?
Никак не пойму.
Сначала нужно изменить формулировку, потом тут же есть набор материала по теме о которой я в статье не пишу :)
Олешка, если Вам не сложно, набросайте свои идеи письмом, что ли?

[Олешка]

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

Я как раз удивилась, почему они разнесены в статье, а вовсе не отрываю их друг от друга. Они же там указаны, как отдельные процессы.

[Case]

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

Возможно ли найти такую систему, в которой все это будет автоматизировано?

Да почему найти? :)
Выбрать инструмент который позвлит такоую систему в том или ином приближении построить!

[Олешка]

Да зачем говорить в статье о инструментах тестирования и критериях их оценки о жизненном цикле разщработки? Тестирование и так довольно сущетсвенно привязано к этапам разработки, так зачем же окончательно привязывать к ним ещё и анализ инстументов?

А я про что? Только это же не мой текст:

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

Не чувствуется несогласованности?

[Case]

Акцент сделан на технологиях, и он же выведен в критерий, с оговоркой о жизненном цикле как о фоне на котором мы работаем.

Что тут чётко не так?