Самый известный тип тестирования, ведь все начинают с него )))
Просто берем... И тестируем! Без цели, без плана. Просто тыкаемся везде с намерением что-то сломать. Как обезьянка.
Между прочим, метод работает! Мы можем влететь на такую ошибку, которую сами бы никогда не нашли. Просто не догадались бы, что это другой класс эквивалетности. Всякое бывает...
А еще бывает такое, что приложение тупо падает от манки-тестирования. То есть после хаотичного тыкания во все подряд (особенно актуально для мобильных приложений). Или памяти не хватает, или вы случайно задействуете комбинацию, которая все разваливает, или еще что.
Есть даже автоматизация манки-тестинга! Да-да, создается робот, который просто тыкает во все подряд. Генерирует кучу случайных значений и пихает во все доступные поля. И снова ходит и тыкает, тыкает, тыкает...
Вот почему я вспомнила про мобильные — именно для них и пишутся такие роботы. Можно и для простого ПО написать, но в мобилках это популярнее и профита больше. Написал робота, ушел домой. А он всю ночь тыкает, тыкает. Пришел утром — все зависло / упало. Дальше локализуем.
Вот тут и возникает проблема — как понять причину ошибки, если ты бессистемно тыкал во все подряд?
Когда я работала на первой работе и тестировала игры на мобильных, у меня было несколько таких случаев. Когда баг воспроизводился «по наитию». Тогда то я еще не знала о существовании классов эквивалентности и всякого такого. Очень тяжело было воспроизводить!
*****************************************
Цикл в бильярде
Сделали игрушку — бильярд. Сижу, тестирую... Дело было поздним вечером, я проверяла уже N-ный телефон. Проверив основные идеи, просто стала тыкать туда-сюда, отключив мозг и думая о чем-то своем.
И тут я бью по мячу, а он ударяется об один борт, потом о другой, третий... И не останавливается! Обычно же бьешь сильно, но инерция проходит и он катится все медленнее и медленнее... А тут нет! Что-то где-то не сработало и мячик не снижал скорости. И в лунку так и не влетел, катался по квадрату между стенками. 5 минут, 10...
Сначала я завороженно смотрела на это. Потом мимо прохошел генеральный директор — зашел к нам в настольный теннис поиграть. Показала ему, похвастаться, что нашла. Похвалил, ушел играть)))
А я остановила игру и стала пытаться воспроизвести ошибку. Вся раслабленность и «мысли о своем» испарились, теперь я была сосредоточена на игре. Но... Воспроизвести почти случайную последовательность силы и направления удара?
Мне так и не удалось... Если бы были средства записи экрана, возможно, разработчик даже смог бы исправить баг. Правда, как такое проверять, я не представляю. Только на уровне кода или автотеста!
Тем не менее тот найденный манки-тестингом баг до сих пор помню... 10 лет прошло, но засело в голове, ведь так и не смогла локализовать ошибку...
Линии
Игрушка, в которой ты рисуешь линии, а потом по ним катится человечек на санках. Задача — чтобы он катился как можно дольше.
Там тоже однажды нашла баг чисто случайно. Мозги отключились и я просто тыкала игрушку. Тык-тык-тык, о, баг! Сразу оживилась, круто же, там картинки накладываются друг на друга. Сейчааааас как покажу разработчику!
Пытаюсь воспроизвести — не получается! Оооо, как я мучилась тогда с этим багом, весь вечер корячила. И все пыталась вспомнить, что же я делала, ну что?! Вот бы мне тогда видео-запись моих действий...
Баг, кстати, воспроизвела. И если бы знала про классы эквивалентности, тестовые туры и прочее, могла бы и раньше воспроизвести. Насколько я помню, там надо было выйти в меню и отменить какое-то действие, и вот тогдаааа!
В общем, часа 3 я убила на попытки вспомнить, что же я нажимала во время манки-тестинга... Так что учтите, баги такое тестирование найти найдет, а вам их потом воспроизводить придется!
*****************************************
Если вы оставляете манки-робота на ночь, обязательно включите запись видео действий. Иначе единственная надежда будет на то, что разработчик по стеку ошибки поймет, где косяк в коде. А если не поймет — воспроизводите как хотите.
Перезапуск робота тут не поможет, ведь вся его фишка — в рандомности. Запустили один раз, он тыкался в одни места, вводил одни значения. Запустили второй — он не повторит тот же маршрут. А, значит, если он случайно попал на комбинацию, приводящую к багу — ее надо или самим искать, или надеяться, что робот сможет ее повторить за ночь.
Ну и бредовая статья, как вы ещё преподаёте курсы по тестированию? Вам следует получить ИТ образование и рассказывать людям, как нужно тестировать в 21 веке, ваши подходы уже не работают, девушка тестировщик)
ОтветитьУдалитьГде в статье написано, что это "мой подход"?
УдалитьЧто подразумевается по IT образование? Можно чуть больше конкретики?
Удалитьздорово, такой подход тоже нужно брать на вооружение.
ОтветитьУдалитьтоже был случай с хитроумным багом, который воспроизводился один раз и только при определенной фазе луны :)
так и не удалось потом выловить его
Эх, да, у меня тоже такое было, что так и не воспроизвелось :(
УдалитьЛюбопытный взгляд на описание Monkey Tester'а. А что насчет exploratory(исследовательское) тестирование? Разница получаетс только в том, что человек знает что он делает и зачем? Интересно Ваше мнение. :)
ОтветитьУдалитьДа, исследовательское тестирование осмысленное
УдалитьСложно на 100% согласиться т.к. человек в отличие от ботов разумен и если у него есть хоть какой-то опыт взаимодействия с похожими приложениями, то и ожидаемый результаты в голове уже будут. И ещё мне кажется любой человек в любом случае будет склонен воспроизводить некоторый сценарий использования, даже если приложение видит первый раз в жизни и дали его со словами "На, потести". Я не люблю понятие "манки тестинг" т.к. могу отнести его в основном только к ботам которые реально не понимают контекста приложения. Человек в любом случае поймёт что-то. Но термин "манки тестинг" очень любят использовать недалёкие разработчики, которые считают что мануальщики это манки тестеры, а автоматизаторы молодцы. В общем, на мой взгляд, вредный термин.
ОтветитьУдалить