Тестирование программ: «чёрный ящик» или доступ к исходникам?

>за и против предоставления тестерам доступа к исходникам тестируемой программы

А собственно зачем тестерам исходники? Это всеравно что обезьянам очки раздать. Тестер должен тестить юз-кейсы софтины. Исходники ему не нужны. Вот посмотрите на дистрибутив Федора. Он же бинарный, но тем неменее пользователи Федоры успешно справляются со своем прямой обязанностью - тестять то что скоро уйдет в RHEL.

>Тестер должен тестить юз-кейсы софтины. Исходники ему не нужны.

+100500

Я можт чего-то не понимаю, но программеры уже не занимаются отладкой? Мне пару раз попадались трудноуловимые баги, из-за которых приодилось сидеть часами с отладчиком. Тестер бы просто не смог внятно сказать из-за чего появилась проблема.

Тут исходники помогали.

> А собственно зачем тестерам исходники? Это всеравно что обезьянам очки раздать.

Если умеет ими пользоваться, почему бы и нет? Гориллы биноклями умеют.

Тестер должен тестить юз-кейсы софтины. Исходники ему не нужны.

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

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

Там-то исходники доступны. Иногда это помогает.

ололо ITT.

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

еще вопрос - если код всерьез покрыт unit-тестами, то скорее всего whitebox-тестирование не сильно повысит качество продукта, а вот разбазаривание казенных денег - запросто.

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

г-ди, надеюсь, вы не имеете отношения к разработке.

А собственно зачем тестерам исходники?

чтобы читать.

Тестер должен тестить юз-кейсы софтины.

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

Исходники ему не нужны.

Мне нужны.

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

Это всеравно что обезьянам очки раздать.

no comments

> тестировщик, способный разобраться в чужом коде и наваять свои тесты на его основе стоит дорого

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

> основной аргумент против whitebox тестирования - его стоимость

А ведь верно.

если код всерьез покрыт unit-тестами

В смысле? Большое число тест-кейсов, разработанных с учётом внутреннего строения программы и регулярно прогоняемых? Или разработанных без учёта внутреннего строения, но охватывающие всё, что доступно через интерфейс? Или что-то ещё? Требуется ли знать назначение каждой функции в каждом EXE и DLL, или достаточно полных спеков, что должен делать каждый DLL?

Как насчёт случая, когда тесты прогоняют нерегулярно? Будет ли эффективнее нанять одного специалиста или нескольких кнопконажимателей за те же деньги?

> Такие спецы стоят баснословных денег и в большинстве случаев просто не окупаются.

Можно пример, сколько такой человек реально получал?

>г-ди, надеюсь, вы не имеете отношения к разработке.

Ошибаешься. Имею.

чтобы читать.

Железная логика. Вот сейчас имею головную боль с одним проектом, так самое неприятное в нем - это читать мегабайты говнокода, написанного в стиле «полный паштет». Единсвенное о чем может сказать этот код - так это о вменяемости обезьяны его писавшей.

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

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

Мне нужны.

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

>но программеры уже не занимаются отладкой?

Отладка != QA или QC.

Тестер бы просто не смог внятно сказать из-за чего появилась проблема.

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

>В смысле? Большое число тест-кейсов, разработанных с учётом внутреннего строения программы и регулярно прогоняемых? Или разработанных без учёта внутреннего строения, но охватывающие всё, что доступно через интерфейс? Или что-то ещё? Требуется ли знать назначение каждой функции в каждом EXE и DLL, или достаточно полных спеков, что должен делать каждый DLL?

Вкратце unit-test'ы - написанные разработчиком тесты для всех написанных им методов. Пишутся вместе с кодом (а лучше до кода). То, про что вы говорите - автоматические тесты. Они с whitebox могут вообще не пересекаться, по поводу эффективности - зависит от продукта/технологии/методики разработки и еще сотни факторов. Обычно в штате просто имеется несколько хорошо прокачанных в автоматизации тестировщиков, остальные умеют какие-то базовые вещи из автоматизации.

>Можно пример, сколько такой человек реально получал?

В зависимости от языка - от 10 до 40 $/час. Но 40 - это действительно серьезный специалист, он нужен далеко не всем.

> еще вопрос - если код всерьез покрыт unit-тестами, то скорее всего whitebox-тестирование не сильно повысит качество продукта

А что, unit-тесты - это не whitebox-тестирование?

>Ошибаешься. Имею.

это печально

>Вот сейчас имею головную боль с одним проектом, так самое неприятное в нем - это читать мегабайты говнокода, написанного в стиле «полный паштет». Единсвенное о чем может сказать этот код - так это о вменяемости обезьяны его писавшей.

Проблемы говнокодеров - это проблемы говнокодеров. И иногда проблемы опрометчиво выбравших работу небыдлокодеров.

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

У вас извращенное понимание QA как студента-обезьянки за миску риса. Составление тест-кейсов, написание тест-планов, а иногда и спецификаций - задача тестировщика. Правильные тест-кейсы создаются на основе общения с заказчиком, спеки, юзкейсов, и вообще всей имеющейся информации. При необходимости - и исходного кода.

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

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

нет. unit-test - метод для проверки другого метода. whitebox-тестирование - тест-кейс/автоматический тест/что угодно для проверки метода. и в 90% случаев входные/выходные данные идут через UI приложения.

>Составление тест-кейсов, написание тест-планов, а иногда и спецификаций - задача тестировщика. Правильные тест-кейсы создаются на основе общения с заказчиком

Ололо. Тестер с завышенным ЧСВ детектед. Это с каких пор вас до общения с заказчиком допускать стали? Тебя послушать - так тестер чуть ли не самый главный человек в говнокодинге.

в приличном обществе вас окрестят лохом. http://www.google.com/search?hl=en&q=qa+engineer+вакансия grep'ать «обязанности» до полного просветления.

> unit-test - метод для проверки другого метода. whitebox-тестирование - тест-кейс/автоматический тест/что угодно для проверки метода

Даже по твоим словам, unit-тест - подмножество whitebox-теста.

и в 90% случаев входные/выходные данные идут через UI приложения.

Малозначащая техническая деталь.

Даже по твоим словам, unit-тест - подмножество whitebox-теста.

ну чисто теоретически - да.

а вообще отличия между ними не в реализации, а в целях. разработчик пишет unit test (в best practices он его пишет до кода ) чтобы самостоятельно проконтролировать, насколько правильно он реализует метод (какую-то часть приложения). а whitebox-тестер смотрит код для того, чтобы понять, какие данные нужно подать на вход всего приложения и какие результате на выходе всего приложения нужно получить.

>grep'ать «обязанности» до полного просветления.

Бегло просмотрев вакансии нашел «Общение с заказчиком» лишь на абстрактной должности «Офисный сотрудник». Но мы то знаем как пишутся требования к кандидату. Чтобы и жнец и швец и на трубе дудец и повар и водитель и технический директор и просто образованная и начитанная личность в одном лице. А на деле садят на банальную должность «пуговицы пришивать».

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

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

А банального просмотра API уже для этого недостаточно чтобы понять что нужно передавать и что получать _без влезания в детали реализации_? Вот возмет такой «тестер» и привяжется к неправильной реализации функции, которая потом поменяется...

> а whitebox-тестер смотрит код для того, чтобы понять, какие данные нужно подать на вход всего приложения и какие результате на выходе всего приложения нужно получить

Нормальные люди для этого читают требования к системе. А у вас вот оно как получается. Интересно, а если таким не дать сорцов, они будут таки читать требования или будут пытаться узнать «что подать, чтобы получить» изучая ассемблерный листинг, выданный декомпилятором?

>Бегло просмотрев вакансии нашел «Общение с заказчиком» лишь на абстрактной должности «Офисный сотрудник». Но мы то знаем как пишутся требования к кандидату. Чтобы и жнец и швец и на трубе дудец и повар и водитель и технический директор и просто образованная и начитанная личность в одном лице. А на деле садят на банальную должность «пуговицы пришивать».

http://forum.agiledev.ru/index.php?t=msg&goto=7649&

Обязанности: 
∙Анализ предметной области и функционала разрабатываемой системы для подготовки сценариев тестирования 
∙Планирование и организация тестовых сред и тестовых окружений. 
∙Подготовка плана тестирования, сценариев тестирования 
∙Проведение тестирования аналитических полуинтеллектуальных систем и систем искусственного интеллекта: 
∙Функциональное тестирование 
∙Регрессионное тестирование 
∙Модульное/интеграционное/системное тестирование 
∙Нагрузочное тестирование, 
∙Анализ проблемной ситуации и определение причин ее возникновения 
∙Ревью, систематизация и расстановка приоритетов в работе с дефектами, найденными при тестировании. 
∙Взаимодействие с заказчиком и командой разработчиков по вопросам обеспечения контроля качества, организации приемочного тестирования 
∙Автоматизация процесса регрессионного тестирования.

Я тоже на самом деле пуговицы пришиваю, а сюда ЧСВ прокачать вылез, да?

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

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

>что бы не наобещали «золотых гор» уже завтра, а потом не разводили руками, не то что тестеров...

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

>Нормальные люди для этого читают требования к системе. А у вас вот оно как получается.

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

>Интересно, а если таким не дать сорцов, они будут таки читать требования или будут пытаться узнать «что подать, чтобы получить» изучая ассемблерный листинг, выданный декомпилятором?

тут кто-то путает цели и средства.

> очень часто, для того, чтобы проверить все возможные варианты, которые вытекают из требований к системе, нужно перебрать порядка 100-150 вариантов. при этом, посмотрев исходник можно без потери качества отсечь ненужные варианты, а довольно часто увидеть те варианты, которые из спеки далеко не очевидны.

Скажи, какой продукт ты тестировал такими методами?

>А банального просмотра API уже для этого недостаточно чтобы понять что нужно передавать и что получать _без влезания в детали реализации_?

банального просмотра API - недостаточно.

>Вот возмет такой «тестер» и привяжется к неправильной реализации функции, которая потом поменяется

не понял претензии

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

>чтобы набрать более адекватных «простых кодеров», за которых не будет страшно, если им вдруг придется общаться с заказчиком?

Это невозможно хотя бы по двум причинам:

1. Бюджет 2. Будет анархия, один скажет я это вижу так, другой - так. Третий пошлет всех на и скажет заказчику, что ему это не нужно.

лично я? некоторые части приложения-аналога MS Project. На некоторые нормальную документацию в связи с недостатком времени не написали, на другие написали хреново.

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

>банального просмотра API - недостаточно.

О, неужели?!! Что тестеры кроме говнокода ничего больше читать уже не умеют? Хороших годных жабадоков с описанием того что должно происходить уже недостаточно?

не понял претензии

Судя твоей логике, написанный код - последняя инстанция в области того каким должен быть юз кейс. Но представь себе, что уже написанный код написан неравильно, кодер неправильно понял фичу и захардкодил лажу. Тестер в свою очередь тестирует лажу, лезет в код и строит ложные иллюзии, основанные на ложном представлении о том как должна работать система.... Тратит на эту чепуху время... Порождает целый виток бредовых идей и представлений, вместо просто того чтобы взять и прочитать тест план, написанный человеком, который _знает как должно быть_ без вникания в детали реализации.

я бы тоже. из моих знакомых никого, чьей основной деятельностью является whitebox-тестирование на языках, отличных от C#/Java/Ruby/Python нет.

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

+1. Особенно если там будет куча каких нибудь стейт машин, без визуальной картинки состояний и переходов или какая нибудь неоднозначная многопоточность. Нет, ну если он вундеркинд или человек-индиго, то тогда да... но что он в тестерах до сих пор делает с такими нечеловеческими способнастями до сих пор - непонятно...

> На некоторые нормальную документацию в связи с недостатком времени не написали, на другие написали хреново

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

О, неужели?!! Что тестеры кроме говнокода ничего больше читать уже не умеют? Хороших годных жабадоков с описанием того что должно происходить уже недостаточно?

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

Судя твоей логике, написанный код - последняя инстанция в области того каким должен быть юз кейс. Но представь себе, что уже написанный код написан неравильно, кодер неправильно понял фичу и захардкодил лажу. Тестер в свою очередь тестирует лажу, лезет в код и строит ложные иллюзии, основанные на ложном представлении о том как должна работать система.... Тратит на эту чепуху время... Порождает целый виток бредовых идей и представлений, вместо просто того чтобы взять и прочитать тест план, написанный человеком, который _знает как должно быть_ без вникания в детали реализации.

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

2. я по-моему уже рассказал, кто пишет тест-план и тест-кейс. и да, в тест-плане ни разу не написано, как должно быть :)

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

у вас какое-то странное понятие о адекватности.

Зависит от квалификации тестера:

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

> Только и денег они просят больше, и людей таких меньше.

Ключ к успеху команды в объединении людей разной квалификации.

я сам не против поработать в команде с крутым прошаренным парнем, но без крайней необходимости перекупать человека никто не станет. а Беларусь - не настолько большая страна, чтобы на проскилованных whitebox-тестеров не было дефицита.

> Тестер читает тест-кейсы, написанные человеком, которые _знает_ как должна правильно работать система

Обычно этот человек называется «старший тестер» :) А если он перегружен, подключается кто-то из нестарших.

> Его задача прочитать доку как должно быть, найти все оличия - и вбить их в багзилу

Тогда поясни, как понять в промежуточных внутренних альфах: фича не работает потому, что не написана, или потому, что написана с ошибкой? Мануал — в таком же состоянии, временнЫе сроки роадмапа соблюдаются с точностью плюс-минус месяц. Как избежать добавления кучи лишних багов в багзиллу? А то потом программист и тестер вынуждены вместо работы писать отписки: что в обилии багов нет вины программиста, а в обилии инвалидных багов — вины тестера :)

> от 10 до 40 $/час.

При 8-часовом рабочем дне получается зарплата 2-8 тестеров без опыта работы :) Они стольких стоят?

> Это с каких пор вас до общения с заказчиком допускать стали?

С тех пор как дали заказчикам право писать в багзиллу :)

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

А банального просмотра API уже для этого недостаточно чтобы понять что нужно передавать и что получать _без влезания в детали реализации_?

Для этого нужна актуальная документация на API :) Который может быть никому не нужен кроме самих программистов. Тоже они должны писать?

Вот возмет такой «тестер» и привяжется к неправильной реализации функции, которая потом поменяется...

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

> если таким не дать сорцов, они будут таки читать требования или будут пытаться узнать «что подать, чтобы получить» изучая ассемблерный листинг, выданный декомпилятором?

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

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