Жила-была маленькая тестировщица, и по неопытности своей считала, что белый ящик - для программистов, а черный - Мекка для тестировщиков.
Но однажды наступил момент, когда ей в Jira подключили FishEye, и она смогла видеть то, каким образом был пофикшен тот или иной баг, или каким образом был заимплеменчен тот или иной функционал. По началу все изменения выглядели как наскальная живопись - было понятно о чем речь лишь по мутным и примитивным очертаниям. Тогда она стянула себе из системы контроля версий репозиторий, и очертания стали больше напоминать то,что они значили, ибо в IDE можно было перемещаться по классам и методам, чтобы понимать, что происходит. И тогда коммиты стали понятней, и несмотря на практику код ревью, принятую в команде, маленькая тестировщица все равно заглядывала в новый код посредством FishEye.
Это привело к тому, что отныне делать impact анализ можно было основываясь не только на словах разработчика и собственных предположениях, но и на том, что она сама видела. И оказалось, что, как правило, изменения затрагивали гораздо больше того, что было сказано разработчиком, и тестов нужно было сделать гораздо больше, чтобы убедиться в правильности имплементации. Чек листы стали более полными, что позволяло отловить больше багов.
А маленькая тестировщица теперь при получении тикета в Jira первым делом открывает вкладку Source и смотрит изменения в файлах, а уж потом приступает к тестированию. А в случае, если на нее ассайнят тикет, где такая вкладка для нее отсутствует, она брезгливо морщится и тяжело вздыхает.
Не стоит брезговать выпрашивать открыть код любыми доступными способами и смотреть реализацию методов. Это поможет лучше понимать, у каких кейсов реально есть шанс отловить ошибки, а какие делаются просто для того, чтобы "погладить кота по шерсти" и убедиться, что все работает в тепличных условиях. Можно сколько угодно долго рассуждать о классах эквивалентности, граничных значениях и тому подобных вещах,
но это не имеет никакого смысла до тех пор, пока нет доступа к коду.
Имеет смысл. Бо "классы" и "граничные" - это детский сад тестировщика, это только начало. И все это нацелено на исследование феномена, в код которого не смотрят.
ReplyDeleteНе смотрят по очень многим причинам.
Например, по каким?
DeleteПри том что "классы" и "граничные" это тезхники лучше всего работающие на уровне unit тестов. Но некомпетентных к коду лучше не подпускать, да.
DeleteReadonly Доступ тестера к исходному коду, безусловно , штука больше полезная. Если тестировщик квалифицирован достаточно, чтобы делать обоснованные выводы , глядя в код, то это очень даже может помочь : в более быстрой диагностике, более полном понимании нутра и как следствие более адекватному тестированию.. Это если квалифицирован. А если, он только думает, что он квалифицирован в кодировании , в понимании кода? )) В этой сиутации можно ждать необоснованных предложений, выводов, замечаний багов , тестов , которые нагородил тестер исходя из своего неправильного понимания прочитанного кода..
ReplyDeleteТо есть, в целом, совершенно необязательно, что этот код должен быть тестеровщику предоставлен. Это опция, которая есть не везде и полезна не всем.
Более того, даже квалифицированному тестировщику, который читает код как книгу , досконально зная нутро приложения, не стоит забывать , что на ПО он прежде всего должен смотреть со стороны пользователя.
Доводилось работать в проектах, где код от тестеров был спрятан и показывать его или нет - даже не обсуждалось. Как правило, это был классчиеский или почти классический "водопад".
Но также доводилось работать в условиях , когда можно было разработчику патч прислать. Мне лично, конечно, комфортнее во втором случае, когда процес более гибок и прозрачен.
И в целом лично я очень приветствую, когда тестировщик понимает код и имеет возможность его анализировать. Но я не берусь утверждать, что в первом случае качество продукта было хуже , чем во втором.
А вообще, тема интересна для обсуждения.
Но ведь всегда можно проводить ревью чеклистов\тестов\чего угодно, чтобы избежать "тестов , которые нагородил тестер исходя из своего неправильного понимания прочитанного кода" и подобных вещей. Либо принять какие-то другие меры для того, чтобы подобных выводов было меньше.
DeleteИ перед огромными голубыми глазами той маленькой тестировщицы (анимешная картинка. девушка смотрящая в даль) – открылся новый мир. Мир, в котором за каждым фиксом стояли строки кода. Мир, в котором лампочка загорается из-за разности потенциалов, а не только потому, что ее включили в розетку.
ReplyDeleteТестировщица сделала первый шаг. А затем еще один и еще один…
:)
Если лампочки загораются, значит это кому-либо нужно ? ))
DeleteСпасибо за соблюдение как идеи, так и стиля повествования :)
Deleteкогда код представляет из себя тонны текста, при этом в целом приложение работает исправно - тратить силы и кучу времени на прочтение и анализ кода не оправдано.
ReplyDeleteВ Agile - на здоровье, опять же, если есть время. в крупном проекте где сотни разработчиков читать код почти бессмысленно. Те же клаасы эквивалентности найдут баги быстрее.
Да,я работаю в agile.
DeleteИ, как по мне, если на тестирование сразу приходит "тонна текста от сотни разработчиков" - это уже проблема.
Особенно, если именно "текста", а не кода.