Тестирование "черного ящика" , пожалуй, наиболее распространенная практика верификации ПО.
У нее есть свои плюсы , минусы и область применения. Хочу привести пример (буквально по горячим следам), когда одного "черного ящика" явно недостаточно...
До доработки у системы N имелась функция F. Эта функция вызвается из разных "мест" системы. То есть, есть основной сценарий ее использования и более редкие - побочные.
Функция F дополнена функцией f. Эта новая ф-я f ДОЛЖНА выполняться ПРИ КАЖДОМ "вызове" F.
Тестировщик протестировал основной сценарий - все ок. Тест дизайнер, доверяя сисаркам, тем не менее попросил тестировщика провести дополнительные тесты , проверяя "побочные" сценарии использования F. При прверке первого же такого сценария тестировщик выявил то, что новая функция f не вызывается при вызове F. Разработчик исправил , тестировщик проверил. Все ок. Переходит к следующему "побочному" сценарию - там та же история.
Тест-дизайнер смотрит на все это , удивляется и лезет в changeset-ы и, не веря своим глазам, обнаруживает, что с каждым фиксом разработчик копипастит код вызова f и вставляет везде, где вызывается F.
В итоге , разработчику пришлось-таки сделать так, как он по идее был должен сделать с самого начала - убрать код вызова f в код F , тем самым исключив проблему отстутствия новой функциональности во всех сценариях использования.
Не выходя за рамки процесса тестирования можно констатрировать минус "черного ящика", который заключается в риске пропустить подобный "архитектурный" баг. Этот риск тем больше, чем несовершениее процесс управления изменениями в конторе.
То есть, очевидна, польза в просмотре кода тестировщиками: если бы разработчик с самого начала расплодил код вызова в по всей системе, то тестировщик, проверяя все сценарии и, не находя в них ошибок, так никогда бы и не узнал о том, как неоптимально и взрывоопасно все реализовано. А при добавлении нового сценария с вызовом F через некоторое время получили бы проблему "невызова f" с большой долей вероятности.
p.s.
Читайте код, если есть возможность :)
А выделенный тест дизайнер который тесты сам не прогоняет это специально чтобы цепоцка подлиннее была?
ОтветитьУдалитьКроме того "мораль" здесь не в том, что кто-то выделенный, а кто-то совмещенный, и не в длине цепочки , а в том, что иногда, не глядя в код, тестировщику невозможно выявить действительно серьезную проблему.
УдалитьВ ряде случаев чтение кода можно заменить плотным взаимодействием с разработчиками на всех стадиях. Правда это уже ставит определенные условия на всю команду.
УдалитьЭто специально, чтобы менее опытный тестировщик не пропустил нужные шаги при тестировании.
ОтветитьУдалитьА как такой баг был пропущен на Code Review? Как его пропустили unit-тесты? И зачем вообще разработчики придумали себе столько всяких инженерных практик, если в код должен еще и тестировщик лезть?
ОтветитьУдалитьЕсли тестировщик обладает настолько высококлассными знаниями языка программирования, что может провести качественное код-ревью и показать места с "неоптимальной" реализацией, то зачем конторе держать разработчика?
>А как такой баг был пропущен на Code Review?
ОтветитьУдалитьТакое случается )
>Как его пропустили unit-тесты?
Вы удивитесь, но в наше время еще не все разработчики пишут unit-тесты. Да и сами по себе unit-тесты еще надо так написать, чтобы они отловили баг. Это инструмент , а не волшебная палочка гарри поттера )
>И зачем вообще разработчики придумали себе столько всяких инженерных практик,если в код должен еще и тестировщик лезть?
Во-первых, практики придумывают не только разработчики) И та или иная практика не везде применима, а там ,где применима, наталкивается на инерцию.
Во-вторых не "должен" , а "может" , если есть возможность (доступ к репозиторию) и квалификация
В-третьих не "лезть", а "смотреть"
>Если тестировщик обладает настолько
>высококлассными знаниями языка программирования,
>что может провести качественное код-ревью и
>показать места с "неоптимальной" реализацией, то >зачем конторе держать разработчика?
Это самый интересный момент Вашего замечания) Вы, похоже, частично мыслите старыми категориями. В наше время порой тестировщик обладает гораздо более богатыми навыками ,чем рядовой кодер. И, кстати, получает зарплату соответствующую.
Ответ на вопрос "зачем держать разработчика" очевиден - "Разрабатывать" )
В общем в реальной жизни все несколько запутаннее чем в практиках , изложенных в статьях и книгах. Особенно все неоднозначно там, где процесс складывался годами. Инерция, штука такая, знаете ли..
Спасибо за вопросы)
Мне только кажется, или это:
ОтветитьУдалить"Вы удивитесь, но в наше время еще не все разработчики пишут unit-тесты."
и это:
"Вы, похоже, частично мыслите старыми категориями."
слегка противоречат друг другу? Таки это я мыслю старыми категориями, или все же "но в наше время"?
А вот это:
"Инерция, штука такая, знаете ли." - вообще не оправдание, знаете ли ))) Если программисты привыкли выдавать нагора говнокод, то почему ответственным за это должен быть тестировщик?
Некоторые вообще вот активно пропагандируют отсутствие роли тестировщика в команде. На кого в таком случае такому программисту валить вину за собственную некомпетентность?
)) Прошу, не обижайтесь, но противоречия нет... Вы вырвали из разных абзацев. Один - про разработчиков, которые тоже подвержены инцерции.. Более того, иногда они хотят работать по-другому, но не могут. В силу разных причин.
ОтветитьУдалитьКогда же я предположил о "ваших" старых категориях, то речь шла об отношении к современному тестировщику, как к человеку, который не должен обладать навыками программирования. Мое мнение - должен и порой, не худшими, чем у кодеров.
>Если программисты привыкли выдавать нагора говнокод
>На кого в таком случае такому программисту валить
Тут речь не идет,что кто-то на кого-то валит.. Речь о том, что реальные процессы в РЕАЛЬНЫХ компаниях не всегда "КАК В КНИЖКЕ" и в таких ситуациях от тестировщика требуется не только тыкать в кнопки и сверять со спецификацией... В ЧАСТНОСТИ читать код может быть ОЧЕНЬ и ОЧЕНЬ полезно..
Еще раз спасибо за вопросы :)