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

[barancev]

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

Статья посвящена рекомендациям по наиболее безболезненному варианту внедрения автоматизации тестирования на уровне проекта в случае, если это направление в целом не развито в компании – производителе ПО.

Читать дальше...

[KaNoN]

Как систематизация знаний - материал неплохой.

Не понравилось дополнительное акцентирование внимания на Keyword-Driven подходе.

Во-первых, описание преимуществ подходов несколько выходит за рамки основной темы. Более того, есть множество других подходов и людям лучше изначально предоставить выбор, какой из таких подходов использовать. К тому же есть и более гибкие решения, чем Keyword-Driven
Во-вторых, при всех описанных преимуществах (которыми не факт, что удастся воспользоваться) у данного подхода своих недостатков вагон и полная тележка
В-третьих, данный подход не везде применим или целесообразен (не забываем, что автоматизация тестирования уровнем UI не ограничивается)

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

[barancev]

В-третьих, данный подход не везде применим или целесообразен (не забываем, что автоматизация тестирования уровнем UI не ограничивается)

На других уровнях keyword-driven тоже применим, вообще-то.
Да, применимость, конечно, ограничена, но дело не в уровне, а в чём-то другом.

[KaNoN]

В-третьих, данный подход не везде применим или целесообразен (не забываем, что автоматизация тестирования уровнем UI не ограничивается)

На других уровнях keyword-driven тоже применим, вообще-то.
Да, применимость, конечно, ограничена, но дело не в уровне, а в чём-то другом.

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

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

[SALar]

Несомненно, автоматизация тестирования имеет много неоспоримых преимуществ,

Но ни одно не приведено.

Цель – повысить эффективность тестирования проекта

1. что это означает? Найти больше ошибок при той же стоимости тестирования? - Нет, это малореально.
2. Найти более критичные ошибки нежели при ручном тестировании? - Практически невыполнимо.
3. Снизить бюджет разработки? - даже если и получится, эта сумма находится в рамках погрешности. Т.е. не измеримо. А вот потери от внедрения автоматизации они вполне ощутимы. Т.е. здесь скорее от внедрения автоматизации следует ожидать вреда.

[Natalya Rukol]

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

Тогда врядли кто-то внедрит автоматизацию :))

На сегодняшний день KeyWord Driven фреймворки это наиболее технологически продвинутое решение по соотношению цена / трудозатраты / эффективность.

Приведённые плюсы - это плюсы любого параметризированного подхода. Аргументов чем лучше всех конкретно кейворд (оно и логично, т.к. выбор подхода зависит от контекста) - нет.

Короче, недопродуманный пеар.

[chezar]

Всем привет! :)
Писал статью мой коллега по моей просьбе, поэтому позволю себе дать некоторые пояснения по статье.
Во-первых всем спасибо за отзывы по статье и критику, особенно за критику, т.к. будет работа над ошибками :).

Статья на самом деле не имеет целью открыть что-то новое для специалистов области. Статья ориентирована в первую очередь на компании, уровень зрелости ИТ процессов которых достиг до уровня возможности внедрения автоматизации, но в то же время нет понимания, как это сделать с наименьшими потерями и тревожит риск зря потраченного времени без получения положительного результата.

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

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

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

Да, keyword-driven не универсален, нельзя применить везде где ни попадя и вообще универсального решения/средства/методологии до сих пор, на сколько знаю, не придумали :). Но, как написано в статье "в большинстве случаев, мы рекомендуем.....". Никто не говорил про бездумное ориентирование на одно решение. В таких проектах всегда есть этап исследования, в рамках которого выбирается инструмент, оценивается инфраструктура заказчика, уровень подготовки специалистов, .... Все эти данные перевариваются, и только после этого предлагается решение. Заказчик, после этапа исследования и выданных предложений по внедрению, может посчитать плюсы и минусы, опять таки бабки (не факт, что будет возможность применить бесплатное средство автоматизации или то, на которое у заказчика по каким-то счастливым обстоятельствам могут оказаться лицензии), и в конечном итоге подумать "а оно мне надо или я смогу прожить и дальше без автоматизации?".

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

Еще раз всем спасибо за отзывы и критику :).
Удачного дня!