OpenQuality.ru
Качество программного обеспечения
Добрый день.
Единственный способ определить границы возможного – выйти за эти границы (Артур Кларк).
Счастье тестировщика? Вот список из 62 пунктов: наш тяжелый изнуряющий труд не находит ни понимания, ни признания. Проклятые менеджеры и разработчики сводят на нет все наши усилия. Мы Дон Кихоты, бредущие по дорогам программных проектов и безуспешно сражающиеся с ветряными мельницами. Кто виноват?
Произво́дная в математике — функция, являющаяся результатом применения той или иной операции дифференцирования к исходной функции.
Нет исходной функции – нет производной. Тестирование программного обеспечения представляет собой сервис. Очень важный, ответственный, интеллектуальный сервис, без которого зачастую не обойтись. Но это производный сервис, надстройка над базисом. Разработчик может создать продукт без сучка и задоринки или же просто пренебречь шероховатостями, сделав акцент на ключевой функциональности приложения. Да, не все будет гладко, но продукт сможет найти признание у миллионов пользователей. Таким образом, тестировщик зачастую оказывается в двойственном положении. С одной стороны, QC-инженер осознает важность и полезность своего труда. С другой стороны, он видит, что его роль – второго плана. Что делать?
Казалось бы, ничего не остается, как опустить руки и принять неизбежное. Смириться со своим “производным” предназначением подобно рыбке-чистильщице, заплывающей в пасть бегемота и следящей за состоянием его зубов и десен. Выискивать мириады багов, бажков и бажочков в своих и сторонних продуктах, пытаясь убедить весь мир, к какой катастрофе он движется. Не самый плохой выбор. Полезная работа на благо продукта, разработчиков и пользователей. Важный винтик в скрипучем колесе проекта.
Скрипучем? Почему оно скрипит и что сделать, чтобы не скрипело? Каждый проект уникален. В каждом проекте своя специфика, свои слабые места и недоработки. Кто найдет их лучше чем тестировщик, знающий продукт вдоль и поперек? Быть может, тестировщик в состоянии не только увидеть просчеты, но и устранить их? Нет, это не новый виток спирали, не стародавний термин Quality Assurance (безусловно, серьезная активность, но достаточно размытая и неоднозначная). Речь идет о новых, дополнительных сферах деятельности, которые могут а) оказаться по силам тестировщику; б) обогатить его новым опытом; в) повысить значимость QC-инженера в проекте по созданию ПО.
В своих книгах об учении Дона Хуана писатель и антрополог Карлос Кастанеда призывает к перепросмотру – вспоминанию и “перепроживанию” всей своей жизни с целью высвобождения энергии. Порой книги Кастанеды вызывают недоверие, но сама мысль о перепросмотре, безусловно, важная и актуальная. Мы живем в плену устоявшихся убеждений, в прокрустовом ложе своих (не)умений и (не)удач:
Тестировщик, считающий поиск багов верхом своих возможностей, так и останется у своего корыта жалоб и причитаний, пыхтя как паровоз и требуя прибавки в зарплате за каждый найденный баг или каждый отработанный год. Тестировщик, не застрявший в своем развитии, способен пересмотреть свои взгляды, поднять планку своих возможностей и “заточить пилу” — овладеть новыми навыками и взять на себя новые задачи. Не в ущерб, а в дополнение к старым.
Вот три примера.
1. Задержать, нельзя выпустить? Задержать нельзя, выпустить?
Каждый программный продукт должен соответствовать набору критериев, заложенных на этапе подготовки спецификации. Безусловно, требования к продукту могут меняться в ходе разработки и тестирования приложения, но неизменной остается конечная цель – выпустить качественный продукт в сжатые сроки и с наименьшими затратами. Практически любой серьезный проект рано или поздно оказывается на критическом пути. Задачи на этом пути не имеют резерва времени выполнения – любая задержка в их реализации приводит к изменению сроков всего проекта либо к урезанию функциональности продукта. Помимо всего прочего, лихорадочное предрелизное кодирование отнюдь не способствует качеству приложения. Баги могут быть привнесены в самый последний момент, когда еще нет автотестов, а времени на вдумчивое тестирование уже не остается. Чем может помочь тестировщик в таких случаях?
Нет, нет, не стоит грудью бросаться на амбразуру: на создание классов, методов и объектов. Интересен стык “разработка/тестирование”. Например, при нахождении бага тестировщик может взломать черный ящик продукта и в открывшемся белом ящике найти причины возникновения бага. Тем самым можно высвободить время разработчика на исправление ошибки. Помимо всего прочего, QC-инженер получает более глубокие знания продукта, а значит и новую информацию для размышлений.
Дело за малым – овладеть соответствующими навыками. Рассмотрим процесс обучения ребенка катанию на велосипеде. Можно выделить четыре промежуточных состояния:
а) ребенок не знает о существовании велосипеда, и, соответственно, не может на нем кататься.
б) ребенок увидел велосипед у соседского мальчика, просит купить ему такой же, но кататься на нем не может.
в) велосипед куплен, ребенок делает на нем первые круги, а вы заботливо его подстраховываете.
г) ребенок освоил велосипед и свободно катается без вашей помощи.
То же самое с анализом бага. Поговорить с компетентным разработчиком. Выяснить, какие средства отладки он использует. WinDbg? Найти время и сделать первые шаги, вооружившись документацией. Выбрать интересный баг с падением приложения. Понаблюдать, как с этим багом справится разработчик и воспроизвести его действия в своей среде. Северный ветер создал викингов. Будет трудно. Помимо знания WinDbg, нужно понимать код: и синтаксис языка, и задумки разработчика. Но результат может превзойти все ожидания: баги на блюдечке с голубой каемочкой, с анализом и комментариями.
2. Good beginning is half of battle
Предотвратить баги гораздо важнее чем исправить. Понимает ли тестировщик рынок продукта? Знает о потребностях заказчика? Представляет среду, в которой будет работать продукт? “Видит” архитектуру разрабатываемого приложения? Даже при наличии выделенного аналитика (а зачастую по причине его бездействия) проект может оказаться в тупике. Конкурент решил задачу более эффективно. Ошибки при выборе сторонних библиотек. Неудачная структура приложения, нет возможностей для масштабирования и т.п. Это баги наивысшего приоритета, или, скорее, окончательный диагноз. Избежать таких последствий – чем не вызов, чем не почетная задача, которую трудно переоценить?
3. Где должен быть тестировщик? Впереди, на лихом коне!
Жизнь не стоит на месте. Развиваются проекты, рождаются новые технологии. Рано или поздно IT-инфраструктура компании перестает соответствовать бизнес-задачам. Что там говорят про облачные вычисления? Динамическое управление ресурсами? Что выбрать? Решения от VMware? Бесплатный ESXi или же стек ESX/vCenter/LabManager? А может быть, Eucalyptus? Как новые технологии смогут повысить эффективность процесса разработки? Как избежать лишних затрат?
Пассионарии – это “люди, обладающие врожденной способностью абсорбировать из внешней среды энергии больше, чем это требуется только для личного и видового самосохранения, и выдавать эту энергию в виде целенаправленной работы по видоизменению окружающей их среды” (Л.Н.Гумилев). Сможет ли тестировщик стать пассионарием в разработке программного обеспечения? Палочкой-выручалочкой в трудную минуту? Лучше зажечь одну свечу, чем проклинать темноту.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Pingback : OpenQuality.ru | Разработка ПО: что скрывает ложь? | November 3, 2009
[…] собой, достойно работать в круге своего влияния. И затачивать пилу. Всегда пригодится. Оставайтесь с […]