Доказательство того, что высшее руководство было выполнено правильно

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Как правило, представитель предприятия рассмотрит отчет об испытаниях и решит, считают ли они, что тестирования было достаточно. Обычно это компромисс.

Решения, которые получают из может быть что-то вроде:

Мы сделаем полное регрессивное тестирование на наиболее популярный браузер, но мы не будем делать это на других браузерах.

или

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

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

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

Answer 4

Для меня могут быть проблемы с окружающей средой. Иногда в моих предыдущих проектах было полезно подготовить инструкции по установке. Это помешало многим проблемам. Когда вы выполняете тесты в одной среде и выполняете несколько обновлений, вы можете забыть о том, что вы изменили, например, некоторые новые поля в базе данных, некоторые изменения в конфигурациях компьютера, браузера, некоторые библиотеки необходимо было установить и т. Д. Было бы здорово вы можете снова протестировать свою систему после установки в другую среду (например, тесты интеграции или приемки должны предоставляться в разных средах, например, вы проводили системные тесты). Если это невозможно, рассмотрите возможность построения системы во внутренней среде. Я имею в виду, что после того, как вы закончили тестирование, установите свою систему на другую среду и повторите тест (по крайней мере, регрессионные тесты).

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

Answer 5

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

Далее я бы сосредоточился. 1. Подготовка и параметризация данных испытаний. 2. Подготовка рабочей рамы. 3. Собственная интеграция с системой отчетов для извлечения сбоев вместе со скриншотами. 4. Достижение непрерывной интеграции с инструментами CI.

Я буду держать вас всех в курсе, если все будет так, как планировалось.

Еще раз благодарим всех вас за то, что вы дали мне ясность. ура !!!!!!!!!