среда, 7 марта 2012 г.

Тестировщик как ревизор кода или минусы "черного ящика"

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


Не выходя за рамки процесса тестирования можно констатрировать минус "черного ящика", который заключается в риске пропустить подобный "архитектурный" баг. Этот риск тем больше, чем несовершениее процесс управления изменениями в конторе.
То есть, очевидна, польза в просмотре кода тестировщиками: если бы разработчик с самого начала расплодил код вызова в по всей системе, то тестировщик, проверяя все сценарии и, не находя в них ошибок, так никогда бы и не узнал о том, как неоптимально и взрывоопасно все реализовано. А при добавлении нового сценария с вызовом F через некоторое время получили бы проблему "невызова f" с большой долей вероятности.

p.s.
Читайте код, если есть возможность :)

8 комментариев:

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

    ОтветитьУдалить
    Ответы
    1. Кроме того "мораль" здесь не в том, что кто-то выделенный, а кто-то совмещенный, и не в длине цепочки , а в том, что иногда, не глядя в код, тестировщику невозможно выявить действительно серьезную проблему.

      Удалить
    2. В ряде случаев чтение кода можно заменить плотным взаимодействием с разработчиками на всех стадиях. Правда это уже ставит определенные условия на всю команду.

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

    ОтветитьУдалить
  3. А как такой баг был пропущен на Code Review? Как его пропустили unit-тесты? И зачем вообще разработчики придумали себе столько всяких инженерных практик, если в код должен еще и тестировщик лезть?
    Если тестировщик обладает настолько высококлассными знаниями языка программирования, что может провести качественное код-ревью и показать места с "неоптимальной" реализацией, то зачем конторе держать разработчика?

    ОтветитьУдалить
  4. >А как такой баг был пропущен на Code Review?
    Такое случается )

    >Как его пропустили unit-тесты?
    Вы удивитесь, но в наше время еще не все разработчики пишут unit-тесты. Да и сами по себе unit-тесты еще надо так написать, чтобы они отловили баг. Это инструмент , а не волшебная палочка гарри поттера )

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

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

    >Если тестировщик обладает настолько
    >высококлассными знаниями языка программирования,
    >что может провести качественное код-ревью и
    >показать места с "неоптимальной" реализацией, то >зачем конторе держать разработчика?

    Это самый интересный момент Вашего замечания) Вы, похоже, частично мыслите старыми категориями. В наше время порой тестировщик обладает гораздо более богатыми навыками ,чем рядовой кодер. И, кстати, получает зарплату соответствующую.
    Ответ на вопрос "зачем держать разработчика" очевиден - "Разрабатывать" )

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

    Спасибо за вопросы)

    ОтветитьУдалить
  5. Мне только кажется, или это:
    "Вы удивитесь, но в наше время еще не все разработчики пишут unit-тесты."
    и это:
    "Вы, похоже, частично мыслите старыми категориями."
    слегка противоречат друг другу? Таки это я мыслю старыми категориями, или все же "но в наше время"?

    А вот это:
    "Инерция, штука такая, знаете ли." - вообще не оправдание, знаете ли ))) Если программисты привыкли выдавать нагора говнокод, то почему ответственным за это должен быть тестировщик?
    Некоторые вообще вот активно пропагандируют отсутствие роли тестировщика в команде. На кого в таком случае такому программисту валить вину за собственную некомпетентность?

    ОтветитьУдалить
  6. )) Прошу, не обижайтесь, но противоречия нет... Вы вырвали из разных абзацев. Один - про разработчиков, которые тоже подвержены инцерции.. Более того, иногда они хотят работать по-другому, но не могут. В силу разных причин.

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

    >Если программисты привыкли выдавать нагора говнокод
    >На кого в таком случае такому программисту валить
    Тут речь не идет,что кто-то на кого-то валит.. Речь о том, что реальные процессы в РЕАЛЬНЫХ компаниях не всегда "КАК В КНИЖКЕ" и в таких ситуациях от тестировщика требуется не только тыкать в кнопки и сверять со спецификацией... В ЧАСТНОСТИ читать код может быть ОЧЕНЬ и ОЧЕНЬ полезно..

    Еще раз спасибо за вопросы :)

    ОтветитьУдалить