Тестирование черного ящика - это по существу "тестирование по факту". Приложение уже собрали и положили нам на блюдечко с голубой каемочкой. Нам остается лишь найти баги, которые в нем есть. Уверен, именно так и теструется большинство программных продуктов. Делается это вручную или автоматизированно - это уже не важно, так как это делается по факту выдачи программы, хотя и в тестовую, но все же в эксплуатацию.
- Да, с виду коробка прямоугольной формы, черного цвета, есть некоторые явные и видные невооруженным взглядом "дыры". Коробка может с легкостью выдержать большое давление (если на нее сесть) или удар (если её сбросить с большой высоты). Но вот что творится внутри неё, мы никогда не узнаем. А ведь могли бы, если бы знали как прочитать закорючки называемые "исходный код". Осталось немного - это выучить язык программирования и часто используемые новомодные фреймоврки.
И... Мы переходим на новый уровень! Уау - новые фичи, новые приемы.
Мы смотрим в код и уже видим не закорючки, а вполне понятные операторы, методы, класссы. Мы понимаем откуда все берется и куда кладется. Прокачивая свой уровень в программировании, нас может ждать два пути:
При этом основным бонусом будет не нахождение багов в готовом продукте, а предотвращение их появления в нем. Для этого существует большое количество статических техник, таких как: ревизия дизайна, кода, анализ причин ошибок. Либо автоматизированное тестирование на уровне модулей, объектов, систем перед сборкой приложения.
Конечно, работа по "предоплате" не удовлетворит все наши нужды на 100%, поэтому людям, занимающимся тестированием по факту, всегда будет место, но вот улов багов у них будет совершенно иной.
P.S. Навеяно требованиями к Software Engineer in Test в компании google
четверг, 15 апреля 2010 г.
Тестирование по факту или/и по предоплате
Подписаться на:
Комментарии к сообщению (Atom)
Сообщения
14 комментариев:
Но это же все называется обеспечение качества, и этим занимаются QA инженеры.
Хотя код ревью по ISTQB одна из техник статического тестирования.
Именно, что обеспечение качества!!!
Но многие не видят, не знают или просто не хотят замечать проблемы, скрытые внутри кода приложения, и которые можно найти только путем статических техник тестирования.
Алексей, не удержалась высказать то, что я надумала после прочтения вашей заметки, за что заранее прошу прощения :)
Пожалуй, в определённой степени понимание кода может быть полезным. Но мне кажется, что не стоит переоценивать это понимание для тестеров.
Конечно, есть определённые методы статического тестирования, работающие с самим кодом, но мне кажется, что большинство из них лучше всё-таки оставить разработчикам.
Ну, допустим, ревизии кода: это ж на каком уровне надо знать этот самый язык программирования, чтобы грамотно проводить ревизии кода? Полагаю, что ревизии самими разработчиками кода друг друга гораздо более эффективны, чем если этим начнут заниматься тестеры. А для тестера знание языка на уровне опытного разработчика - по-моему, утопия. Нельзя объять необъятное.
Ну или, допустим, выявления случаев значительной цикломатической сложности: опять же лучше это контролировать на уровне разработчиков, будет эффективнее. Но даже если разработчики и не захотят этим заниматься, то со стороны тестера это будет скорее использование каких-то спецсредств для определения этой самой сложности, а не просто чтение кода, так что опять же глубокое понимание кода вряд ли особо нужно.
Или возьмём проверки соответствия кода принятым стандартам: если соответствие стандартам не будет отслеживаться самими разработчиками, то что смогут сделать тестеры?
Насколько я понимаю, всё-таки если уж и проводить тестирование на уровне кода, то это должна быть отдельная специализация, а не совмещение всего в одном специалисте-тестере, который на все руки мастер.
Кстати, так и не смогла понять, что же в исходной заметке подразумевается под предотвращением появления багов в готовом продукте. Можно сколь угодно много анализировать написанный код, но он ведь уже написан, какое же это предотвращение?
Лично мне кажется, что гораздо более важным и эффективным со стороны тестеров по сравнению с ковырянием в коде может быть статическое тестирование требований, исходной документации. Вот где настоящее раздолье для предотвращения проблем до того, как код написан.
Лена, спасибо за комментарий.
Никто не говорит, что каждый тестер должен бежать и начинать читать исходный код. Тестирование черного ящика имеет свою нишу и никто его сбрасывать оттуда не собирается. Речь идет о переходе на новый уровень для тех, кто уже имеет серьезный бэкграунд в программировании. Это люди написавшие за свою карьеру не один фреймворк для тестирования, не один инструмент облегчающий повседневную работу - это и есть Software Engineers in Test!!!
Вы только посмотрите, как сейчас стало модно автоматизированное тестирование, сколько людей им занимается и хочет заниматься. А посмотрите назад на 10 лет, сколько автотестеров было тогда?
Мне кажется, что тенденции развития software development идут к тому, что задачи ревью/анализа/тестирования кода в скором будущем будут ставиться именно перед Software Engineers in Test, ответственными за качество исходного кода.
Estrella правильно подметила, что все это (от себя добавлю - тестирование/анализ/ревью спецификация, кода, готового приложения...) "называется обеспечение качества". Будут ли этим заниматься тестеры или разработчики - это уже не совсем важно. Важно что эта деятельность направлена на улучшение качества. К чему мы все и стремимся. :)
P.S.
> что же в исходной заметке подразумевается под предотвращением появления багов в готовом продукте.
Вовремя и грамотно написанный unit test может предотвратить появление баги в "собранном" готовом продукте.
Ну, если рассматривать всё это просто как возможность развития в данной области - то тут и спорить не о чем. Мне просто померещилось в ваших словах что-то вроде противопоставления: чёрный ящик - это ерунда, а вот белый ящик - это круто. Для меня это взаимодополняющие друг друга вещи, и скорее всего в большинстве случаев выполняемые разными людьми, как я и написала выше. Кстати, юниттесты - это уж точно дело разработчиков :)
А вот, кстати, мне интересно: наряду с этими самым гугловскими "Software Engineers in Test", есть ли у них тестеры в более привычном для нас смысле? Вы не в курсе?
Я думаю, что в Google есть все и мануал тестеры тоже :)
Однако судя по статье "Still Stuck in the 90s" (James A. Whittaker), тенденции к всеобщей автоматизации тестирования на лицо!!!
До тех пор, пока речь не идёт об искусственным интеллекте, который сможет заменить мыслительные процессы человека, автоматизация - это всё-таки только инструмент. Мощный, хороший, насколько хорошо его использование, но инструмент, который человеческую ручную деятельность в тестировании всё равно не заменит.
(Кстати, как-то незаметно в одну кучу свалились «белоящичное» тестирование и автоматизация тестирования вообще - разные вещи всё-таки)
Лена, я подписываюсь почти под каждым вашим словом. У нас мысли и взгляды словно совпадают... и это здорово :)
PS) меня раздражает фраза "тестировщик может прокачаться до разработчика" - как будто тестировщик это какой-то ущербный недо-программист. По-моему нужно понимать, что тестирование это совсем не путь в программисты, это совершенно самостоятельная интересная профессия, в которой очень приветствуются навыки программирования. А еже человек, обладающий этими навыками, сам в праве решить по какой дорожке ему идти - в тестирование или программирование.
Юрий, касательно вашего постскриптума: если вы про подобную фразу вообще, то согласна. Если же вы про слова Алексея, то полагаю, что он имел в виду всё-таки прокачивание умения программировать именно в первую очередь во благо и с целью использования его в тестировании :)
Юрий, Лена, умение программировать открывает перед вами двери и дает возможность расти разносторонне. Есть много примеров, когда, научившись программировать, тестировщики уходили в разработчики. В свое время я выбрал и перешел из разработки в тестирование. Так что выбор стоит только за нами, мы сами должны сделать свой выбор и понять, на какой позиции мы сможем быть полезнее, где мы будешь влиять на улучшение качества, разрабатываемого продукта.
Вот.
Лена, я не отрицаю полезность программирования в тестировании вообще - только ЗА! Бесспорно это очень полезно!
Похоже, что мы тут в целом все примерно сходимся во мнении о пользе программирования для тестера... :)
Алексей, а вы могли бы хотя бы кратко рассказать, почему вы перешли из разработки в тестирование?
Лена, работая девелопером за ЗП 180$, не задумываясь перейдешь в тестеры за 300$. Ну а дальше я понял, что не ошибся... :)
Вообще в жизни много чего перепробовал: проф. спортсмен, тренер по боксу, охранник на дискотеке, разработчик, тестер/автотестер и т.д.
А главное не известно где и кем я буду через лет 5-10 :)
Эх, а я-то надеялась на захватывающую историю с интересными и сложными побудительными мотивами!.. :)
Отправить комментарий