Поощрение руководства отказаться от ручных тестов и делать все правильно - PullRequest
3 голосов
/ 03 февраля 2010

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

В любом случае, это означает, что все тестирование выполняется вручную, поскольку документация является конечным результатом - это означает, что страдает реальный технический дизайн, реализация и тестирование сайта (мы разработчики или авторы документов? Что мы пытаемся сделать здесь? вопросы, которые приходят на ум). Сайт довольно большой и сложный (не в масштабах Facebook или чего-то подобного), но проведение ручных тестов в соответствии с инструкциями (несмотря на мои предупреждения) говорит мне, что это не высококачественное тестирование и, следовательно, не высококачественный продукт для выйди из этого.

Какие преимущества я могу предложить соответствующим людям для поощрения автоматизированного тестирования (которое, как они знают, я могу реализовать)? Я знаю, что можно изменить разрешение с помощью cmd с помощью стороннего приложения для Windows, так что все это может быть частью автоматической сборки. Вместо этого мне, вероятно, придется вручную просматривать все эти варианты браузеров, разрешений экрана и размеров окон. Кроме того, куда попадают записанные тесты? Они ломаются, когда окна свернуты? Большая проблема с этим заключается в том, что я выполняю работу по мониторингу теста, а ПК не выполняет ВСЕ работы, что является моей работой (заставьте ПК выполнять всю работу). И из-за нехватки ресурсов это забивает блок разработки - да, используется для разработки, а затем для тестирования. Намного лучше автоматизировать это для ночной пробежки, когда коробка свободна.

Спасибо

Ответы [ 5 ]

2 голосов
/ 04 февраля 2010

Говоря о деньгах, обычно это лучший способ привлечь внимание руководства, поэтому вот несколько предложений:

  • Оцените, сколько времени вам потребуется на текущее ручное тестирование.
  • Получите список критических ошибок, которые были обнаружены клиентами - в идеале, с учетом стоимости воздействия (исправление ошибки после выпуска всегда намного дороже, чем раньше), но обычно достаточно просто, чтобы описать одну или две особенности плохие ошибки Ваше ручное тестирование не выявило этих ошибок клиентов, так что это хороший способ продемонстрировать, что ваше ручное тестирование неадекватно.
  • Придумайте пилотный проект, в котором вы автоматизируете тестирование определенной области продукта, в которой были обнаружены ошибки в процессе производства. Оцените стоимость пилотного проекта - выполнение пилотного проекта с ограничениями имеет преимущества в том, что его легче охватить и оценить. Затем сравните текущую стоимость многократного запуска автоматизации с тестированием каждого выпуска вручную; после нескольких выпусков вы должны оценить стоимость инструмента автоматизации и разработки тестов. Будьте осторожны при выборе области автоматизации - старайтесь избегать областей, таких как сложный пользовательский интерфейс, который может значительно измениться между выпусками и, следовательно, потребовать много времени для обновления автоматических тестов.
1 голос
/ 03 февраля 2010

Удачи тебе.Я кричал на все это, и я работаю на компанию с миллиардом +.Мы все еще проводим ручное тестирование (включая регрессионное тестирование).Автоматизированные тесты, наконец, начались, потому что некоторые разработчики вышли и получили демонстрации некоторого программного обеспечения, которое вы описываете, и начали настраивать фреймворк.документированное сравнение между работой с продуктом и работой без продукта, чтобы однозначно доказать руководству, ответственному за трату денег, и разработку процессов, которые окупаются не только там, но и людьми, которым необходимо выполнить тестирование и / или изменить свои существующие процессына самом деле их работа будет немного легче.

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

0 голосов
/ 10 февраля 2010

Пытался сделать подобное в моем текущем проекте ... Могу сказать, что есть еще один фактор - время. Существует кривая обучения по автоматизированным инструментам и разработке автоматизированных тестов. Первый выпуск, который тестируется с помощью автоматизированных инструментов, не будет тестироваться так же быстро, как это было вручную, потому что тестеры изучают инструменты в дополнение к выполнению тестов. Второй выпуск будет намного быстрее, и каждый выпуск после этого будет еще быстрее - но первый будет хитом по расписанию, если не по стоимости.

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

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

0 голосов
/ 09 февраля 2010

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

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

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

0 голосов
/ 03 февраля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...