Идеальное время для ad-hoc тестирования — после проведения всех формальных тестов. Не стоит также забывать и о Security Testing, использование которого глобально не отличается от других сфер. Также стоит упомянуть работу с DRM системами (Denuvo и т.д.) и Anti-Cheat программами (Easy Anti-Cheat и т.п.). Прежде чем тратить время и усилия на тестирование с помощью Monkey Testing или Gorilla Testing, обязательно попробуйте BrowserStack, чтобы избежать любых “обезьяньих дел” в последнюю минуту. Независимо от того, предпочитаете ли вы ручное тестирование приложений или автоматизированное, ваши команды разработчиков и тестировщиков могут выбрать App Live или App Automate в зависимости от общих потребностей тестирования. Тестировщик, также известный как тупая обезьяна в этом тестировании, понятия не имеет о потоке работы или необходимых данных, которые должны быть переданы приложению в идеальной среде.
Следующие best practices гарантируют, что время на тестирование будет потрачено с умом, а шансы на успех будут максимальными. Проверив основные идеи, просто стала тыкать туда-сюда, отключив мозг и думая о чем-то своем. Да-да, создается робот, который просто тыкает во все подряд. Генерирует кучу случайных значений и пихает во все доступные поля.
Прерывание работы
Как Monkey Testing, так и Ad-hoc Testing – это типы случайного тестирования, которое проводится после того, как было выполнено его программирование, но обычно перед началом интенсивного и сложного тестирования. Чуть выше кто-то где-то упомянул персонажей/уровни/предметы и т.п.? Мы начинаем говорить о Visual Components Testing группе, куда можно внести тестирование 3D моделей/сцен, 2D (спрайты) и 2.5D. В отличие от эмуляторов или симуляторов, вы можете получить доступ к облаку реальных устройств для тестирования в реальных условиях.
- Введение случайных входных данных повышает вероятность обнаружения таких ошибок.
- При тестировании на обезьянах, когда тестировщик ничего не знает о программном обеспечении или функциях, функциях, поведении и начинает тестирование приложения случайным образом, это называется методом тестирования на тупых обезьян.
- Monkey Testing — это метод тестирования черного ящика, в котором тестер вводит случайные данные и применяет действия в программном приложении для проверки поведения системы.
- Обычно это тестирование не имеет четкого плана, а тестировщики не придерживаются никаких особых методик создания тест-кейсов.
Если тестировщик не знаком с приложением, рекомендуется определить области программы, где вероятность ошибок выше всего, и начать тестирование с них. QA-специалист, проводящий ad-hoc тестирование, должен хорошо знать тестируемое приложение и его основные функции. Только благодаря этому он сможет «угадывать», где скрываются ошибки и баги. Поскольку такое тестирование предполагает отсутствие заранее подготовленных или задокументированных тест-кейсов, трудно предугадать, сколько сил, времени и ресурсов потребуется на проведение тестов.
Жизнь – это движение! А тестирование – это жизнь 🙂
Знание механик, трендов и игр в целом помогает проводить анализ найденных ошибок и создания комплекса ивентов для предотвращения появления их в будущем или возможности найти их на самых ранних стадиях. Важно держать во внимании, что кроме ваших собственных стандартов качества к игре, свои стандарты есть у платформодержателей. Часто такие проверки называются Technical Requirements Checklist или TRC, а проверяются они в рамках Compliance testing и, часто, не вашей командой, а командой QA на стороне платформодержателя. В рамках данного тестирования вы можете также проверить внутриигровые покупки, достижения (Achievements), подписки (subscriptions), если они у вас есть, а также поддержку фич стриминговых сервисов. Часто для таких нужд “отпочковывается” отдельный билд, который доводят до ума и не аффектят его изменениями основной билд. Такие хитрости как замены хай поли на лоу поли моделей или даже на Импостеров, баланс и скорость отображения полигонов на загруженных сценах, обработка эффектов и т.п.
Но, вместе с тем, воспроизвести это тестирование сложно, поскольку нет ни написанных тест-кейсов, ни документации. Это также проводится случайным образом, без какого-либо планирования или подготовки. По этой причине многие программисты относят Monkey Testing к типу Adhoc Testing.
Monkey testing
Adhoc Тестирование выполняется без какого-либо планирования или подготовки. После того, как программа заработает, программист или тестер будут тестировать программное обеспечение, используя свои знания о программе. Он, как правило, проверяет основы системы, чтобы убедиться, что они работают и система не падает. Этот тип тестирования выполняется без использования тестового примера. Ад-хок тестирование (Ad hoc testing) — это тестирование, выполняемое как бы “неформально” и “рандомно”, часто после того как завершено “формальное” тестирование. Цель ad hoc тестирования — найти баги в системе “случайным образом”, наугад.
А еще бывает такое, что приложение тупо падает от манки-тестирования. То есть после хаотичного тыкания во все подряд (особенно актуально для мобильных приложений). Или памяти не хватает, или вы случайно задействуете комбинацию, которая все разваливает, или еще что.
Тестирование Dumb Monkey
Иногда ad hoc называют обезьяньим тестированием — и это не является большой ошибкой. Ад-хок тестирование не проводят упорядоченным monkey testing это образом, или по какой-то устоявшейся методологии. Поэтому ад-хок типологически относят к “неупорядоченному” тестированию.
Здесь входными данными могут быть данные, введенные в приложение, или нажатие кнопки для следующего действия, или нажатие ссылки для перехода на другую страницу. Часто интуитивное тестирование путают с исследовательским. Если говорить об ad-hoc testing и исследовательском тестировании. Ad-hoc testing — это более интуитивное и беспорядочное тестирование, когда тестировщик просто идет и проверяет, что ему хочется. У него нет определенной цели, структуры тестов в голове, какой-то системы.
Преимущества тестирования на обезьянах:
Monkey testing и Gorilla testing – термины, с которыми мы сталкиваемся в цикле тестирования при разработке программного обеспечения. Обе эти техники похожи, но в то же время отличаются друг от друга при тестировании приложений и имеют свои преимущества и варианты использования. Основная цель обоих методов – выявить критические ошибки в системе и сообщить о них. О том, как каждый метод достигает этой цели, мы расскажем в этой статье. Здесь тестировщики знают, что они тестируют, где они тестируют и к чему это приведет.
Каковы инструменты, используемые для тестирования на обезьянах?
Чтобы найти одну ошибку, может понадобиться как несколько минут, так и несколько часов. Также ad-hoc тестирование не гарантирует, что все ошибки будут найдены. Успех этого тестирования вообще очень зависит от знаний и навыков тестировщика. Кроме того, если у тестировщика нет предварительных знаний о функционале тестируемого приложения, ad-hoc тестирование будет бесполезным, оно не выявит никаких ошибок.