Тестировщик — больше, чем профессия

    За время своей работы в сфере тестирования, у меня сложилось своё, особое мнение об этой области, начиная с позиции младшего тестировщика (junior tester) до руководителя отдела тестирования (test manager). И, в целом, это мнение достаточно критичное с долей любви и обожания к этой замечательной профессии.





    В качестве вступления



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

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

    Обо всём об этом я узнал на первом своём месте в качестве тестировщика с неугасшими амбициями разработчика. В первую очередь, меня очаровала возможность получения доступа к управлению продуктом, власть, на которую я не особо рассчитывал. Это было здорово, что-то особенное, выше написания очередной функциональности. Во-вторых, тестировщики в силу особенностей профессии имеют большее представление о процессах и целях продукта, отчасти транслируют бизнес цели разработчикам, а результат разработчиков —руководителям. К сожалению, в мире и, тем более, в России, представление о роли тестировщика весьма сумбурное, и её значение сильно преуменьшается. А те компании, которые всё-таки находятся в тренде, стараются развить направления тестирования и управления качеством, хотя и ставят несколько завышенные цели: «найти все ошибки, снизить до минимума стоимость разработки через тестирование».

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

    Тезис №1: Тестировщик — не обезьяна





    В Android SDK входит замечательный инструмент под названием MonkeyRunner, который позволяет автоматизировать процесс тестирования Android приложений в идеале без исходного кода, без особых знаний языков программирования (лишь общего представления о скриптовых языках достаточно) и, главное — имитировать любое поведение настоящего пользователя. В итоге получается эдакая скриптовая обезьяна, которая тыкает, печатает, читает приложение. Самое то, что можно «отдать на аутсорс» машине. Для меня такое понимание тестирования в порядке вещей. Но, к моему удивлению, когда я искал работу в первый раз после своей первой должности в роли тестировщика, выяснилось, что на рынке существуют (и по сей день!) странное разделение на «ручных» и «автоматических» тестировщиков, более того, лестница грейдов и вовсе столь смешана и растянута, что диву даёшься. Не говоря уже о том, что от компании к компании одни и те же должности подразумевают разные должностные обязанности, особенно это актуально для старших должностей.

    В мои должностные обязанности входило: составление тест-дизайна, тест-кейсов, стратегии тестирования (если это был назначенный на меня проект), репорт багов, проверка документации и создание тестовой документации. Это было само собой разумеющимся для меня, хотя несколько удивляло, что у западных коллег эти обязанности были разделены. На рынке же оказалось, что вполне обычным явлением считается, что дизайн пишется с помощью CTE/UML (в лучшем случае) Test Lead/Senior Tester/Test Designer. Тест кейсы (разнообразные стратегии проверки границ, интерфейсное тестирование, нагрузочное, стендовые кейсы) — Senior Tester’ы. И, наконец, существуют низшие должности «исполнителей» — Tester. В некоторых компаниях и отделах их число может доходить до 20 и более человек! Другими словами, в штате проекта числились обезьяны, в лучшем случае, обладающие навыками пользователя компьютером и каким-то продуктом.

    На деле же это… несколько неправильно. Потому что тестировщик не обезьяна. Если это не так, то либо вы, как компания, выпускаете разные продукты в короткий срок, без последующей поддержки и качества, прогоняя формальные smoke-тесты, либо, что более вероятно, ваш менеджер/архитектор — баран.


    Затраты на автоматизацию тестирования окупаются далеко не сразу.

    Для знакомых с теорией тестирования (коих, как показывает практика, не так уж и много), вполне очевидно, что необходимость автоматизации сильно зависит от специфики проекта (его сроков, поддержки, повторяемости, и пр.). В некоторых случаях куда предпочтительнее обойтись smoke тестами и пользовательским бета-тестированием и выполнять приёмку через product owner'a, чем усложнять процессы. Так же должно быть чёткое понимание приёмки продукта: верхнеуровневая и низкоуровневая. В первом случае, внутри проекта, можно определить роли и принять продукт владельцу продукта, во втором возможно ограничиться, если допускают это требования, приёмкой самими инженерами-разработчиками с выпуском release notes. В случае, когда тестирование требуется всё-таки отдельное, то куда проще и эффективнее иметь поставленный менеджментом процесс жизненного цикла продукта и человека или команду инженеров, способных самостоятельно покрыть задачи развёртывания и тестирования продукта, т. е. людей, которые априори знают область, инструменты и методы, а не стадо обезьян, которых повесили на разработчиков или одного руководителя проекта.

    Ремарка №1
    Как ни удивительно, но этот простой тезис зачастую сознательно нарушается. Например, для аутсорсинговых компаний это хороший способ получить дополнительные FTE. В плане бизнеса попросту выгоднее продать побольше, что-то, имеющее низкую себестоимость. В опыте моей работы на Auriga, где заказчикам предоставлялись на почасовую оплату соответствующие ресурсы в количестве десятков человек — не единичный случай. Более того, такой план хорошо покрывает цели стаффирования проекта для клиента при минимальных затратах. Несмотря на то, что нагрузка на менеджера проектов значительно возрастает, при грамотном руководстве это пусть к созданию «кузницы кадров» за счёт проекта, привязки кадров к компании (обучение и рост навыка) при сравнительно большей цене покупке специалиста с рынка, и последующая перепродажа, ротация персонала на более требовательные проекты.

    Ещё одной причиной такой стратегии является возможность покупки нецелевых кадров для клиента. Так уж получается, что требования к кадрам ваших работодателей или клиентов иногда бывают недальновидны (о чём речь пойдёт ниже), и меньшими затратами для компании (по деньгам и времени) является возможность покупки фиктивных кадров. Скажем, покупка такого рода «обезьян» на проект с параметром «20 лет стажа» (но, возможно будучи весьма посредственным специалистом). Это особо актуально в системе грейдов Junior/Standard/Senior многих компаний, особенно за пределами России, где требования к стажу и реалии немного иные.

    Следующей, и, на мой взгляд, главной причиной, являются риски. Постановка задач на проекте для тестирования — это покрытие определённой функциональности и действий. Зачастую процессы можно автоматизировать, особенно в отношении регулярных активностей, регрессионного тестирования, т. е. в процессе тестирования создать ферму, процесс и инфраструктуру, часто масштабируемую, портируемую и переносимую на другие продукты и проекты с минимальными издержками. Сокращение «непосредственной» работы на проекте для тестировщика ведёт к двум следующим следствиям:
    • Тестировщик становится тестировщиком-автоматизатором или он получает новые сферы ответственности и новую нагрузку. В таком случае, его рыночная цена и спрос на него растут, что вызывает риск его ухода или повышение зарплатных притязаний, а это может быть большой проблемой в рамках одного проекта и невозможностью масштабировать и ротировать в компании.
    • Риск перехода системы на сторону заказчика или аутсорса. В случае, аутсорсинговой компании — это риск потери FTE вплоть до потери проекта. Такие риски редко вносятся в риск-планы проектов, хотя косвенным образом управляются через миссию компании и давление топ-менеджмента.


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


    Тезис №2: Тестировщик — это инженерная профессия



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

    На мой взгляд, любой тестировщик должен обладать техническими знаниями, уверенным владением и хотя бы базовыми навыками администрирования прикладных программ и популярных ОС. Кроме того, тестировщик должен иметь хотя бы базовое представление о языках программирования, уметь читать код хотя бы на интуитивном уровне, а также быстро адаптироваться к новым языкам и программам/средам. Вообще, главные особенности тестировщика — это гибкость и обучаемость. Поэтому, имея опыт в программировании и общее представление о скриптовых языках и языках высокого уровня, человек сможет обучиться и адаптироваться без особых проблем. В идеале требуется знание скриптового языка и основ языка разработки, на котором и базируется проект.

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

    Несмотря на то, что я в подавляющем большинстве случаев слышу мнение, что процесс ревью кода, отладки (дебаггинг) и юнит-тестирования — прерогатива исключительно разработчиков, возьму на себя смелость утверждать, что это неправильный подход. Проблема исходит из недостаточной квалификации тестировщиков и неверного управления жизненным циклом ПО. Возможно, этот подход хорошо работает в маленьких проектах по TDD, но главная сила и возможность обеспечить высокое качество продукта — разбить сферы влияния, ответственности, обеспечить принцип раздельности (dissimilarity).Это сделает процесс разработки более прозрачным, отслеживаемым и позволит скомпенсировать «эффект замыленности глаза» у разработчиков, избежать «трюков» с их стороны.



    Ремарка №2
    В компании Liebherr Aerospace жёстко выстроены процессы и роли в компании. Чёткое следование специфичным для отрасли итеративным моделям. Тем не менее, инженерное крыло, инженерные должности называются для всех одинаково — Software Engineer. Акцент делается на том, что сотрудник в компании в первую очередь — специалист, инженер в области ПО. Значит, сотрудник должен разбираться в инженерных процессах, процессе разработки, тестирования, схемотехники и т.д. Тем не менее, среди инженеров присутствует обязательное разделение на специализацию: in Test, in Development, in Requirements, и пр.

    Так как компания следует жёстко инженерным процессам с целью соблюдения высочайшего качества, каждая часть процесса разделена на независимых участников. На практике это означает, что каждый уровень требований пишется отдельным человеком (группой), дизайн другими, код пишется третьими, юнит-тестирование четвёртыми, функциональное тестирование — пятыми и так далее. При этом, чтобы не дать «заскучать» и «увязнуть» в рутине, людей в проекте стараются вращать по функциям, и, вполне возможно, даже на одном проекте, в разных итерациях инженер, по мере своих возможностей будет покрывать разные обязанности, и охватит различные этапы разработки ПО.

    То, что каждый из этапов и типов разработки и тестирования должен покрывать разные люди следует из требований международных стандартов, таких как DO-178B (для авиации), EN 50128 (для железнодорожного транспорта) или ГОСТ Р МЭК 60880 (для атомных электростанций), и обеспечивает, в конечном итоге высочайшую отказоустойчивость на уровне процессов и в том числе в части тестирования ПО.


    Тезис №3: Метрики — ерунда, если нет работы в команде



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

    На практике это означает, что бесполезно считать количество разработанных тестов (это метрика прогресса), найденных багов (в худшем случае) показателем эффективности команды тестирования, даже рейт регрессий, даже синтетических метрик на проекте (с использованием критериев важности и трудоймкости), не говоря уж о идиотских (но по-прежнему применяемых и для команды тестирования KSLOC\hour). Для менеджера проекта, возможно, будет неплохой метрикой CPI/SPI как KPI проекта, которая может базироваться на всех обозначенных и собранных тест-менеджером метриках. То есть, достаточно абстрактная и высокоуровневая оценка в зависимости от затраченных усилий и полученного результата. Но при условии, что команды работают как единый организм.

    Для тестировщиков это означает, что они связующее, ведущее колесо процесса, которое сделает программное обеспечение работоспособным и соответствующим требованиям. В процессе тестирования это означает как само тестирование, так и предоставление теста повторяемости, документируемости, возможных проблем и решений проблемы (если это видно со стороны тестирования, если хватает квалификации), а так же перепроверку тестирования (VoV). Другими словами, задачей тестирования является как перепрогон и перепроверка всех возможных состояний, так и (в необходимом и достаточном случае) покрытие полной тест-стратегии и тест-плана (по крайней мере то, что обозначено в Quality Gates), вынесение багов и их разрешение через разработчиков ПО и спецификации. Т. е., с момента проверки и обнаружения бага ответственность на нём не «перекидывается» на разработчика, а сопровождается тестировщиком до его разрешения. Грубо говоря, тестировщик отвечает за баги, а разработчик — за фичи.

    Тут мы подошли к ключевым различиям между тестировщиком и разработчиком, кои в моей статье получаются очень близки и похожи. Тем не менее, по стилю работы разработчики обычно либо перфекционисты, либо «фичеделы» (которые любят кодить ради кода, функциональности и алгоритмов); тестировщики же — либо педанты, либо автоматизаторы (стремящиеся автоматизировать автоматизацию). Поэтому в проекте тестировщик знает, как правильно сделать, а разработчик — как именно.

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

    Ремарка №3
    Несмотря на то, что описанная мною модель говорит о единстве и взаимосвязанности всех этапов процессов, сегодня тестировщиков правильнее классифицировать всё-таки на разработчиков самих тестов (акцентирующих силы и знания на методологии тестирования) и devops инженеров, обслуживающих инфраструктуру. Сегрегация функций имеет свои плюсы при достаточно большом размере проекта и хорошем финансировании, когда развитие, поддержку и тестирование инфраструктуры можно разнести между инженерами, в идеале — между экспертами-специалистами. Важным моментом является то, что тест-инженер всё-таки в первую очередь инженер, разработчик в тестировании, способный использовать различные инструменты для разрешения поставленной задачи. И только во вторую очередь — эксперт в какой-то определённом инструменте и программе. Знатоков инструментария, возможностей фреймворков правильнее классифицировать как отдельных инженеров, инженеров-инструменталистов (tool engineer).


    Тезис №4: Тестировщик — центр процесса разработки ПО




    В V-модели разработки ПО наглядно видно, что тестировщик участвует на всех этапах жизненного цикла.

    Схожесть разработчика и тестировщика, размазанность границ области при наличии хорошей квалификации — главный показатель интереса в работе тестировщика. Конечно, можно утверждать, что причастность к продукту и его качеству в случае тестирования чёрного ящика является мотивационным фактором, но, на мой взгляд, человек, пришедший в техническую, инженерную область сделал это осознанно, с желанием развиваться и работать над собой. Поэтому возможность расширять свой кругозор, влиять на качество продукта, (пусть даже небольших вещей), проявлять активность, а также накладывать вето на выпуск продукта у тестировщика, по моему мнению, более весомые аргументы за профессию. А раз так, раз хороший тестировщик — не обезьяна, а инженер-исследователь, знаток, принимающий участие на почти на всех этапах жизненного цикла по (в отличие от ролей аналитиков, дизайнеров, разработчиков, и технических писателей), ответственный за качество продукта (не процесса, это к QA, так что под «качеством продукта» будем подразумевать соответствие заявленным и утверждённым требованиям и стандартам, чеклистам и прочая), то для поднятия качества продукта и развития себя, как специалиста, тест-инженер должен проявлять активную позицию. Он знает, как улучшить продукт. Знает, что такое «достаточно хорош», и как его, продукт или процесс, таким сделать, инициировать движение как инженера-разработчика, так и других команд и даже компаний. Например, в любых проектах бывают моменты простоя, который может быть допустим со стороны руководства. Обычно в это время сотрудники решают личные проблемы или занимаются самообразованием. В отношении работы разработчик может заняться рефакторингом, поизучать алгоритмы и перенести на свои проекты. А что делать тестировщику? Осваивать новые средства тестирования? Он-то ничего не делает без изначального пакета от разработчиков/аналитиков. В действительности, он может заняться автоматизацией своей деятельности или улучшением продуктов, им используемых, даже если он далёк от инфраструктуры и devops.

    Ремарка №3
    В Liebherr Aerospace жёсткий процесс резко ограничивал использование любых инструментов и жёстко формализовал процесс разработки и тестирования, т. е. простора для автоматизации оставалось не так много — даже вмешательство в багтрекер было запрещено. Тем не менее, такой процесс, как подготовка документации, был в такие периоды автоматизирован, пусть и с использованием не находящегося под запретом VBA для MS Office. А для процесса код ревью можно было улучшить статические анализаторы кода. Они не совсем удовлетворяли стандартам на проекте и порождали лишние сообщения, которые не фильтровались даже элементарным grep. Тем не менее, чтобы уменьшить время на ручное ревью кода, в рамках простоя мы работали на перспективу, улучшая сторонний продукт, такой как статический анализатор, подготавливая набор кейсов для него для имплементации нужных нам проверок.


    Тезис №5: Тестирование — не место для фиксации на ключевых словах



    Последней и самой странной темой, на мой взгляд, является весьма смутное представление о тестировании (даже о теории, не говоря о практике). Во многих компаниях отделы тестирования не оправдывают надежд, в некоторых даже дискредитировали себя и функционируют на малую часть от своей потенциальной эффективности по ряду факторов. Проблема проистекает как из-за отсутствия школы, так и из-за некомпетентности менеджмента. Ситуация весьма плачевная в отраслях, отдалённых от IT, даже где «деньги — не проблема» — там задачи ставятся по принципу «повысить качество продукта». Даже в IT-компаниях, где есть общее представление о процессах, есть целый ряд проблем, связанных с фиксацией на определённых ролях или инструментах, хотя к тестированию, повторюсь, такой подход плохо применим.

    В одном из крупных инвестиционных банков, в котором у меня проходило собеседование, было схожее требование на позицию тест-менеджера: «повысить качество и уменьшить брак». Любую задачу можно решить. Хотя под покровом задач скрывается координация отделов по ряду различных продуктов, составление планов тестирования, организация тестирования, работа с разработчиками, составление базы кейсов и прочая. В действительности, ответственность за качество продуктов в компании логично взять на себя какому-нибудь «директору по качеству», оно же QA Director, а не просто руководителю отдела тестирования. Однако тут дело упирается в полномочия, которых на этой позиции нет, и в отсутствие группы, которая не планировалась вовсе (которая могла бы помочь тому-тому тому-то). То есть в компанию нужен человек-оркестр без команды. Разгадка тут простая: менеджмент ищет по ключевым словам, и считая качество в аббревиатуре QA панацеей от всех проблем, хотя она лежит в сфере стратегического топ-менеджмента и процессов, которые нужно спускать сверху с соответсвующими полномочиями и ресурсами.


    В идеале управление качеством (QA) и тестирование две непересекающиеся сущности.

    Проблема системная, т. к. весьма неплохо, когда HR ищут по ключевым словам вроде «нагрузочное тестирование», «функциональное». Но когда в процессе рассмотрения делается акцент не на навыки тестирования, не на активность и гибкость кандидата, а на конкретный инструмент — это уже проблема, особенно когда никакого тестирования нет в помине (есть обезьянничество), и не факт, что требуемый инструмент эффективнее того, который знает соискатель. Проблема в том, что знание мелкого нюанса или инструмента, на освоение которого уйдёт несколько часов, ставится во главе угла, выше знания языков программирования или теории. В одном из интервью было достаточно смешно было отвечать на вопросы: «назовите какую-нибудь книгу по тестированию» и, ответив про Сэма Канера, услышать: «мы такого не знаем, а про жизненный цикл бага что-нибудь читали?». Это было бы смешно, если бы не было так грустно. Грустно, когда HR сообщает об отказе из-за отсутствия опыта у кандидата, хотя дело к неправильном расставлении акцентов.

    Найти хорошего тестировщика — большая проблема, т. к. инженер-тестировщик — это, в идеале, человек, который разрешает технические проблемы, связанные с разработкой ПО, эдакий problem solver. Такому человеку, помимо технических навыков очень важно иметь внимательность, пытливый ум, быть активным и уметь донести мысль и отстоять свою точку зрения на любом уровне.В каком-то роде, тестировщики — это исследователи из мира разработки ПО. Поэтому в руках инженера-тестировщика легко узнаваемый символ — лупа (линза), наблюдающая за жучками. Как нельзя лучше характеризует она работу тестировщика: используется как по прямому назначению для выявления дефектов, так и для «прожигания дырочек», с её помощью можно добывать огонь и даже, имея целую систему линз, наблюдать за звёздами. Главное — уметь это делать.

    Ремарка №5
    В компании Intel главенствует подход, в котором инструменты выбираются из предпочтений сотрудников на проекте. Это означает, что, в целом, неважно, какой инструмент и язык выбрать для решения задачи, главное — её решить. Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо, если проблема решается, решается эффективно и накладные расходы на поддержку разумны, а процесс документируется. Кроме того, многие используемые инструменты являются бесплатными, open-source или собственной разработки. На сегодняшний день существует огромное количество инструментов, с помощью которых возможно решать разнообразные задачи, и выбор инструментов не должен ограничивать возможности инженера. Однако, если для задачи действительно требуется использовать какой-то инструмент, отличный от свободно доступного, то при наличии чёткого понимания и обоснования, можно купить и использовать его. Это опять-таки соответствует целям бизнеса — не забивать гвозди микроскопом, не работать эффективно, выжимая максимум из инструментов, если квалификация инженеров позволяет обойтись «малыми потерями». Хорошей альтернативой является также участие в открытых проектах и инвестиции в них для последующего использования для собственных нужд. Такой подход убивает двух зайцев (свои нужды) и задачи и создаёт инструменты для всего общества в свободном использовании.


    Вместо выводов



    Тестировщик — это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех посильными и эффективными средствами. Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании в отношении этого продукта, и в то же время глубоки внутри компании в роли исследователя. А раз так, то главные его качества — это энергия, знания и гибкость. Но в тоже время работа тестировщика – это не всеобщее знание и ответственность за качество продукта и качество услуг. У тестирования есть границы: с одной стороны ограниченные проектом и требованиями в нём (менеджмент проекта и установленный жизненный цикл программы), и с другой – процессами, за которые отвечает QA. Но о различия QA от тестирования совсем другой разговор.
    Поделиться публикацией
    Комментарии 46
      +1
      Спасибо. ИМХО, полезный пост. Настоящий тестировщик — это летчик-испытатель.
        +1
        Настоящий тестировщик — это летчик-испытатель.

        Несколько преувеличено, имхо.
          0
          Донести бы эту мысль до наших бизнесов… Ибо зачастую на пост-советском пространстве софт (и веб) делаются по принципу «Запустилось? Отдаем заказчику!»
            +1
            Это обычно лежит на совести стратегического менеджмента, который сам не может, но при этом не стремится внедрять с помощью других управление (контроль) качеством. Вот когда будут ясные цели и критерии качества внутри компании, либо когда их будет транслировать заказчик (хотя как показывает практика, даже топовые компании «хотят», чтобы им поставщик услуг поставлял и средства измерения и процессы), то тогда и будут критерии для тестировщиков и поставки. В данной ситуации можно конечно вступать в конфликт и двигать идею снизу вверх или блокировать\саботировать процесс, но это несколько рисковано и накладно.

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

            Так что, суть моей статьи скорее не совсем побуждение доносить до бизнеса идею (там много нюансов слишком), сколько побуждение инженеров выбирать разумно компанию, чтобы не увязнуть в болоте и знать свою и роль в ней, и цену.
              0
              хо-хо, расскажите это людям, постоянно разрабатывающим какой-то софт, да их продуктом потом пользоваться никто не будет
            +5
            … это больше, чем профессия. Это образ проактивной жизни и стремления эту жизнь сделать лучше для всех

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

              При этом есть категория юниоров, готовых впитывать знания. Так что если искать, то через институт интернатуры или тех людей, которые энергичные и интересные на собеседованиях. При этом, в зависимости от ваших требований, не факт, что вам нужен perfect grade of ISTQB тестировщик, вполне возможно «компьютерных дел мастер», «системный администратор» или программист из НИИ вам подойдёт, если вы ему развяжете руки.

              Тут главное увидеть в человеке огонёк и жилку, карму и развязать ему руки в проекте. В случае если его не пугает ответственность (хотя, кончено её будет нести ПМ\ТМ в случае чего), если он хочет влиять на ход проекта — это только на руку будет.
                +1
                с чего на Ваш взгляд нужно начать, чтобы стать хорошим тестирощиком? понимаю, что вопрос банальный, но думаю, что Вы сможете дать хороший совет, так сказать определить направление движения. Дальше уже двигаться буду на силе желания…
                  0
                  С ответа на вопрос, кем вы хотите стать (и в каких условиях) через пять лет и что вам интересно. Чтобы стать хорошим тестировщиком нужно хорошее понимание жизненного цикла разработки по, жизненного цикла дефекта, а так же личная гибкость и готовность постоянно обучаться и не привязываться к тому или иному инструменту или техники решения проблем\поиска уязвимостей. По большому счёту всё, что нужно — это гибкость ума, много терпения, готовности к рутине (как у старателей), и системный, несколько смещённый взгляд на вещи… что-то вроде анализа FMEA.

                  По поводу базы — замечательный курс есть на Intuit.

                  Подробнее ответил в личку.
              +6
              Тестировщик это карма. Лично у меня всегда все не так. То ни с того не с сего Visual Studio упадет, то именно у меня Google Chrome закроется. То стул всегда был хорошим, но именно у меня он сломается. Меня уже порою из показов в команде выгоняют, дабы «бозоны» не принес
                +5
                Эффект Паули же.
                Однажды Паули решили разыграть, соединив настенные часы в зале, где он должен был читать лекцию, с входной дверью с помощью реле, чтобы при открытии двери часы остановились. Однако этого не произошло — когда Паули вошёл, неожиданно отказало реле.
                +1
                График затрат на ручное и автоматизированное тестирование не корректен и создает ложное впечатление.
                Первоначальная разработка автоматических скриптов для тестирования в разы дороже ручного тестирования — до пересечения со стоимостью ручного тестирования там ой как не близко.
                И ровной полки там не может быть в принципе — поддержка эти скриптов тоже обходится не дешево.
                Сама статья очень хорошо написана — мне только этот график не понравился.
                  0
                  Справедливо. График я брал из интернета.
                  1) Там не ровная полка, а растущая кривая, если приглядеться
                  2) По поводу «в разы» я с вами не соглашусь, т.к. всё зависит от специфики. На одном из моих проектов, основывающемся на регрессионном и перфоманс-тестировании для 20+ конфигураций в ежедневном режиме автоматизированное тестирование окупило себя через 2,5 месяца. При проекте длиной в 2а года — это большие деньги и сэкономленное время.
                  Естественно, для поддержания скриптов и вообще автоматической CIT системы нужны люди с хорошей квалификацией, но, в целом, это посыл моей статьи — на больших интервалах, в стратегическом плане для IT компании-собственника это работает в разы лучше, чем держать и стаффировать десятками кликеров (зачастую не знающих и теории покрытии и методологий тестирования).
                    +1
                    Согласен насчет регрессионного автоматического тестирования на Х конфигурациях — я тоже работал в компании с такой ситуацией, и там это было безусловно оправдано (хотя разработка и наладка всего этого хозяйства стоила кучу денег, но там все было сложно — разные юниксы и даже майнфреймы).

                    В случае типового веб-проекта, в котором UI на продакшене меняется быстрее, чем его успевают проектировать :-) поддержка авто-скриптов превратится в непрерывную параллельную разработку. Разве что если возложить ответственность за скрипты на самих разработчиков.
                      0
                      Перекладывать на разработчиков в условиях постоянно меняющегося UI — это просто издевательство над ними будет :)
                      Критерии автоматизации — самый частый вопрос на собеседованиях и на пресейлах. На всякий случай ещё раз напишу тут:
                      1) Повторяемость тестов
                      2) Изменяемость требований
                      3) Затраты на разработку и поддержание теста, инструменты
                      4) Размер данных
                      5) Время выполнения
                      6) Время внедрения (не слишком раннее и не слишком позднее)
                      7) Вариативность (нечеткость критерия успеха)
                +3
                Опять эти тестировщики поют себе гимны… Дворник — это больше, чем дворник… Сантехник — это больше, чем сантехник… Пылесос — это больше, чем пылесос. Да так вообще про всё сказать можно )
                  0
                  У Вас не правильное понимание роли тестирования.
                  * Разработчик создает то что продается;
                  * Тестировщик создает ситуации при которых пользователь не потребует денег обратно и вполне возможно придет за покупкой update;

                  Пользователю глубоко фиалетово какие паттерны знает разработчики и какие были применены в продукте, который он купил. Ему наплевать как много и упорно оптимизировал\рефакторил разработчик свой продукт. Но стоит пользователю увидеть багу, которая мешает ему выполнять его задачи, то разработчику очень сильно повезет если на рынке нет конкурентов, иначе он потерял пользователя.
                    +1
                    Да, теоретически всё верно ) Только на практике всё обстоит несколько иначе. Вот например я, как пользовался глючным твиттером, глючной виндой, глючным линуксом, глючным скайпом, глючным андройдом, так и пользуюсь ) Если хотите продвинуть продукт — не нанимайте тестировщиков, нанимайте маркетологов ;)
                      0
                      Понимаете, есть продукты-монополисты или без которых нельзя обойтись, а есть те что имеют конкурентов или без которых в принципе можно обойтись.
                      Приведу пример, недавно в Android-версии сервиса LingvaLeo нашел багу «Очень тихо, почти не слышно озвучиваются слова, даже если громкость телефона на самый максимум». После обращения в саппорт получил ответ через 2 дня на уровне «А вы телефон включили?». После моего второго письма ответа так и нет, прошла неделя! Как Вы думаете буду ли я покупать второй раз ихний «Золотой статус»? Нет, не факт! Проблема не в том что саппорт молчит, хотя и это плохо, а в том что проверить громкость озвучки не больше 1 мин. Видимо они проверили у себя в офисе и им наверное в голову не пришло что люди могут ездить в электричках, метро и боже упаси в тролейбусах.

                      Т.е. разработчик не до тестировал, что привело к тому что пользователь врядли еще раз заплатит ему денег
                        +2
                        Обратите внимание, что в данной ситуации раздражение вызывает некачественная поддержка, а не недостаточное тестирование ;) Так что, поддержка — больше чем профессия?
                        +1
                        Это не теоретически — это практически!
                        Приведу ситуацию в которой я не до тестировал. Наша компания выпускает софт full-версию которого мы посылаем в виде ссылки пользователю. Где-то год назад произошла ситуация когда на один из наших билдов ругался антивирус от Symantec. Некоторые пользователи не только отказались ставить наш продукт, но и потребовали денег обратно! Наш продукт стоит 995$.

                        Да, разработчики сделали продукт, его можно продавать. Но, я не протестировал на Symantec и понадеялся что хватит Dr.Web и Kaspersky. А ведь несколько раз умножить на 995 это 2-3 зарплаты тем же разработчикам!
                          0
                          это психология русскоговорящих пользователей, остальные чуть что — сразу звонят в поддержку, если они заплатили хотя бы 5 долларов
                          +1
                          Обеспечение качества продукта — всегда командная задача, иначе быть беде. Каждый делает свою часть работы, которую не могут сделать другие. Крутые тестировщики продукту, который пишут посредственные программисты, не сильно помогут.
                            +1
                            Где-то недавно пробегала фраза (по памяти цитирую): отсутствие или неумелое тестирование может загубить хороший проект, но супер-отличное тестирование не спасет изначально плохой проект.
                              0
                              Не совсем правильное видение процесса тестирования. Изначально плохой проект может и не появиться! Дело в том что многие тестируют ПОСЛЕ создания, а надо ДО создания уже включаться. Другими словами, как начали с командой обсуждать задачу от Product-owner, то тестировщик уже может начать задавать свои «глупые вопросы»:
                              * А как должна работать прога в demo-версии?
                              * А что если я подам неправильный серийный номер?
                              * А если пользователь уже имеет аккаунт?
                              и др.

                              Ответы на вопросы тестировщика могут дать новую пищу для ума команде и это дает понимание того что что-то не такое простое как кажется и на него следует больше человеко-часов выделить и возможно пересмотреть его приоритет. И т.д. и т.п.
                                0
                                О, да!

                                Могу порекомендовать пару софтверных лавок, где вам за ваши вопросы похлопают, покивают, а потом забьют на них и на вас. Да ещё и поговорят в духе «Ко мне опять этот умник приходил, парил про неправильные серийные номера».
                                А дальше хоть утестируйтесь. Даю волю вашей фантазии и «правильному видению процесса тестирования».

                                И ещё подумайте на тему работы над приложением, которое никому не нужно.
                                  0
                                  Сразу вижу, разработчик, который далее своей IDE ни разу не выглядывал :))) По некоторым багам, которые открывал на своей работе я не мало раз откладывал релиз на 1-2 дня. Было и не раз, когда был в отпуске и выдавали релиз, а потом в последствии во внутренней переписке Product-owner на чуть более культурном языке чем матерный выражал свое мнение по поводу пропущенных баг. Очень, очень радует Product-owner-ов слова вида «А никто и не задавался подобным вопросом?» или вида «А никто и не проверял». Хотя Разработчику, который далее своей IDE никуда не заглядывал врядли это возможно понять.
                                  Также скажу что у меня есть опыт ведения проектов, за свои собственные деньги, так сказать «домашние проекты», на которых зарабатываю пусть не на BMW, но на хлеб хватает. Скажу что Вы даже не представляете какое бывает ощущение, осознать что половину работы можно было бы и не делать, если Бы во время кто-то обратил внимание на один из нюансов!

                                  Но у Вас похоже опыт работы в «софтверных лавках», ну чтож. Похвальный опыт! Но такие виды компаний всегда обходил и обхожу стороною, я денюжку люблю и очень, как вывод надо работать хорошо, а не через ж…
                                    0
                                    Извините, конечно, но речь и в статье и в моих коментах вовсе не о вас. Вряд ли кому-то тут интересен ваш опыт.

                                    А то, что вы напридумывали про меня. Вы ошиблись во всём. Ну что ж. Живите в мире своих иллюзий, но меня, пожалуйста туда не тащите.

                                    На сём закончу непродуктивный разговор.
                        +1
                        Сосуществование трёх разных тест инженеров, пишущих на трёх разных языках вполне допустимо


                        Не ради спора пишу, а чтобы своим опытом поделиться. Работал в компании ||, занимался автоматизацией. Я единственный писал автоматизацию на C#, остальные в общей массе писали на РНР, был кусок на Java, где-то использовался LISP и еще куча всего уже и не вспомню.

                        Когда был 2008 год (кризисный) многих сотрудников просили покинуть компанию. Мне предложили закрыть весь мой C# проект и написать все заново на РНР. Причем codebase был взят с другого продукта, codebase был написан на РНР. Объяснялось это так — основная масса програмистов в компании пишет на РНР. Тесты на C# ты пишешь один. Если нужно будт тебя заменить (сам уволюсь, уволят, камень на голову упадет), то придется искать человека на мое место со знанием C#. Во-первых, такого тестировщика будет трудно искать. Во-вторых, наверняка он будет с непомерными амбициями :) Ну т.е. для комании это невыгодно. Выгодно было иметь единый codebase для тестов и продукта, чтобы человека если что можно было заменить. И, например, при желании программиста могли не уволить, а перевести в отдел тестирования, где бы он писал тесты.
                        Мне было грустно и печально расставаться со своим проектом, в который я вложил 2 года трудов. Но в дальнейшем я понял, что решение принятое менеджментом было верным и правильным. Наконец-то удалось к моему проекту подключить и других людей, мы смогли за пол года все переделать на РНР, покрыть тестами и другие области продукта, не только мою ответственность, интегрироваться с другими внутрикорпоративными системами, работать одной РНР командой, делать ревью кода и прокачать скилы.

                        И через 2 года я смог со спокойной душой уволиться :)

                        P.S. Статья понравилась, вспомнил свою тестерскую молодость :)
                          +1
                          «И, например, при желании программиста могли не уволить, а перевести в отдел тестирования, где бы он писал тесты.»

                          Вот одна из причин из-за которой о тестировщиках плохое мнение или суждение как о людях непрофессиональных. Программиста, которого отторгли другие программисты ни в коем случае нельзя пускать в тестирование. Скорее всего это человек некомпетентный, не склонный к развитию и безотвественный. Более того он уже не умеет тестировать.
                            0
                            Лично я не вижу тут связи с тем, что сказал автор предыдущего коммента.
                            Дело в выгоде для компании, что бы не увольнять человека из-за кризисной ситуации, не сажать его сидеть бездельничать. А вовсе не потому, что он не профессионал. Другое дело, что писать тесты может быть для разработчика скучно, но опять-таки как для бизнес-потребностей, так и для компании, где программист не только кодер, и где тестировщик не просто обезьяна — это вполне нормальное и хорошее для всех решение.
                              +1
                              Автор brutalko всё верно написал про единый code base.

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

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

                              Резюмируя. Только программист, сам захотевший работать в тестировании будет работать полезно. А вот держать в команде человека, спасающийся от увольнения в кризис перейдя на «менее пыльную» работёнку — не завидую команде и начальнику.
                                0
                                Тут я с вами соглашусь. Статистически, хороших специалистов из программирование в тестирование переходят доли процента (не на время, а навсегда). У меня не очень большая выборка, но знаю только одного человека, который променял написание математического софта для нужд геологоразведки на тестирование ПО, и то при близкой работе с кодом.

                                Со временными, проектными переходами всё обстоит гораздо лучше, но это на срок в несколько месяцев. Увы.

                                Как мне кажется, это связано больше с незрелостью области и нечёткому пониманию руководства места тестирования в процессе разработки ПО. Особенно в России\СНГ. Как минимум мой опыт собеседований в компаниях и русские и зарубежные говорит об этом.
                                  +1
                                  Я видел только удачные переходы из программистов в QA manager. Это были действительно достойные люди. Про переход в тестеры я с вами согласен. Ниже я упомянул про найм в компанию Microsoft. Люди с желанием шли в крутую контору на позицию SDET, хотя раньше кодили. Но опять же как дальше у них судьба складывалась — я уже не слышал. Думаю дальнейшее зависит от человека, от его упорства и амбиций :)
                                  +1
                                  Все верно, дело было в выгоде для компании. На самом деле и работу тогда найти новую сложно было, у меня тогда не получилось. Везде шли сокращения, так что можно сказать, что программистам компания пошла на встречу, ну а слабых тестировщиков немного кинули :)

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

                                  И я слышал много историй как русским программистам предлагали позиции SDET в Microsoft. Многие с удовольствием соглашались. Как там у них дальше судьба складывалась — уже не слышал :) Может им было скучно.
                                  0
                                  Как я понимаю тестирование — это больше управление качеством продукта. Научить программиста писать тесты — не сложно, когда уже есть готовый фрейворк. Пройти подготовленный тест план — ерунда, любой сможет (ИМХО), хотя мне реально всегда было скучно это делать.

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

                                  И, кстати, в той компании, где я работал пытались убедить, что тестер должен быть более квалифицированным, чем программист. Программист просто пишет свой кусочек кода, отвечает за свою область. А тестер обычно должен понимать как устроен весь продукт, т.к. он может столкнуться с проблемой в любом месте и должен уметь с ней разобраться. Ну т.е. понять баг это или фича :)
                                    0
                                    Не с чем поспорить.

                                    Но обычно «подготовленный тест план» либо вообще отсутствует, либо пишется тестировщиками, а не спускается откуда-то сверху. А вот его подготовить, знать как проверять границы, покрытие — это уже несколько сложнее. Во всяком случае на всех проектах, где я работал программисты наступали всегда на одни и те же грабли, считая многие условия «невозможными» и тратить время на написание какого-то гварда бессмысленным. Поэтому несколько опасно, во всяком случае без всеобщего чеклиста и стандартов отдавать программистам тестирование, во всяком случае без VoV.

                                    Ну и по поводу квалификации в Вашем примере, возможно, это тоже перегиб небольшой :) А то в таком случае получается не разработчик уже, а кодер :) Нужен баланс в команде, на самом деле. Программист круто знает алгоритмы и знает как рефакторить и оптимизировать, а тестировщик смотрит сквозь это, даже на распрекрасный алгоритм, доставая корявое преобразование типов, например.
                                      +1
                                      Первая часть — согласен, уметь составить качественный тест-план не всякий сможет.

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

                                      Конечно по моим рассказам получается, что очень квалифицированный тестер может стать архитектором. Это как бы полностью перечеркивает то, что я написал выше. Он же уже не тестер. Так что и тут можно с Вами согласиться, есть небольшой перегиб :)
                                +1
                                Очень противоречивая статья, хотя и интересная.

                                С одной стороны есть много хороших и правильных замечаний, например про метрики. С другой — какие-то тестировщики-обезъяны накладывающие право вето на выпуск продукта.

                                С одной стороны правильные слова про HR и глупый поиск на соотвествие и знание инструмента. С другой — никому не нужные сравнения/противопоставления QA и тестирования, свойственные начинающим тестировщикам. Кто-нибудь где-нибудь в своей жизни видел отдел QA (или SEPG) который бы занимался только процессами и при этом, в лучшем случае, не мешал бы работать людям? Утопия.

                                С одной стороны совершенно точное замечание про несовершенные, неумелые отделы тестирования, которые дискредитируют сами себя. С другой — какой-то мифический QA Director, который должен «взять отвественность за качество» на себя, отобрав его у простого руководителя отдела тестирования. Где вы таких директоров видели? Если такой есть — то имхо, это должен быть первый кандидат на увольнение. В худшем случае он будет мешать процессу «деливери», стоя во главе банды обезъян и не давая поставить главную печать на продукт. Ну а в лучшем случае на него все забьют.

                                Ну а вообще статья занятная. Было бы любопытно по всей этой тематике круглый стол устроить где-нить на SQA Days или другой конференции.
                                  0
                                  Спасибо. Я ждал этого комментария.
                                  Давайте по порядку.
                                  1) Сравнение QA/SEPG и тестирования — это тема, пожалуй, следующей статьи. Но отвечая на ваш вопрос — да, существует. Есть критерий применимости, где в небольших компаниях или в рамках одного-единственного проекта вряд ли нужен такой отдел. С другой стороны, в больших, зачастую распределённых компаниях, выпускающих мощный или критически важный софт наличие такого механизма необходимо. Да и Ваше замечание о том, что такой отдел «мешает» людям — это странно, т.к. деятельность его как раз таки направлена на то, чтобы эту жизнь улучшать.
                                  2) QA менеджер, во-первых в мире существует, во вторых руководитель отдела тестирования и он — это два совершенно разных человека, которые занимаются совершенно разными вещами. Грубо говоря, только наличие QA и процессов, качество которых он курирует является залогом качества. А вовсе не хаотичная деятельность тестировщиков и разработчиков. Ради любопытства, если не читали, то почитайте мои первые статьи о том, как разрабатывается софт для авионики. Приплетать такого человека для тестирования сайта-визитки в рамках камерной «студии веб-дизайна», конечно же глупо.
                                  3) Право вето среди отдела тестирования и у QA в мире существует, и оно не просто «мешает процессу деливери», а обеспечивает качество. Лучше затянуть поставку на два года (как в случае Boeing 787), чем выпустить потенциально опасный продукт на рынок. Но, опять-таки, все в рамках и масштабах проектов и установленных критериев качества (qulity gates), чтобы никто в проекте не стрелял по воробьям из пушки.
                                    +1
                                    Сравнение QA/SEPG и тестирования — это тема, пожалуй, следующей статьи.

                                    Позвольте дать совет. Сохраните свое время. Напишите лучше о чём-нибудь другом.

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

                                    Ничего странного. Как вы правильно заметили, такой отдел нужен когда несколько проектов. Но нужен ли? Обычно этим занимаются люди ничего не понимающие в каждом конкретном проекте. Не понимающие команду, не понимающие текущие сложности. Они стараются применить ко всем одинаковые практики, считать неработающие метрики.
                                    Видел на практике две крайности. Отдел есть, что-то делает и никому от этого ни жарко ни холодно.
                                    Вторая — отдел есть и наделён сильными полномочиями менять процесс, не взирая на то, что каждое следующее «улучшение» добавляет головной боли программистам, тестировщикам и другим людям нацеленным на «деливери».

                                    Это конечно холиварная тема, именно поэтому и было бы интересно сделать круглый стол на эту тему на конференции.
                                      0
                                      Я не против, приглашайте, наверняка смогу найти время :)

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

                                      Опять-таки, их моего опыта:
                                      1) В области авионики люди, занимающие должности в QA проходили путь в десяток лет от через SW Engineer, и то, что они курировали, они обычно знали изнутри, и вполне могли дать совет, выходящий за рамки их должностных обязанностей. Вывод: качеством должны управлять эксперты, а не блюстители бюрократии и процессов.
                                      2) Блюстители бюрократии и процессов так же могут приносить пользу. Так, например в моём опыте аутсорса это прекрасно работало для медицинских проектов (например било по рукам и направляло новые команды в новых проектов, используя как требования к процессам так и опыт предыдущих шишек, набитых за 20 лет работы), но совершенно не работало для всех остальных проектов и либо приносило головную боль, либо делалось для галочки, т.к. будучи несколько не самыми большими экспертами даже в абстрактных и высокоуровневых вещах, совершенно не адаптировалось.
                                      +1
                                      По поводу (2) и (3) думаю что спорить бесполезно. Наверное вы правы.
                                      Я не работал над авиоционным или медицинским софтом, не знаю как там устроено.

                                      Но мне сложно поверить, что некий человек, который не вовлечён в проект может быть главным отвественным за качество продукта.
                                      Хотелось бы верить, что в вышеперечисленных областях все участники процесса разработки прекрасно понимают цену ошибки.
                                    +1
                                    Спасибо за статью, интересно было почитать!

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

                                    V-модель — далеко не единственный подход к процессу разработки, и из приведенной картинки вообще-то не следует, что тестировщик участвует на ВСЕХ этапах жизненного цикла, начиная с формализации или формулирования требований заказчика и заканчивая выводом ПО из эксплуатации.

                                    Право «вето» звучит, конечно, круто, но я ни разу в своей практике не встречал, чтобы инженер по тестированию мог не дать руководителю проекта выпустить релиз. Убедить, наверное, можно, но не запретить.
                                      0
                                      Я, если честно, не совсем понимаю, что такое «центром разработки должно быть как раз ПО», т.к. это самое ПО пишут и поддерживают реальные люди. Людям же свойственно ошибаться — на этапе оценок, составления требований, дизайна, кодирования, тестирования и развёртывания. Для обеспечения установленного качества и проверки критериев соответствия требованиям, стандартам, процессу и привлекаются тестировщики + QA, если он есть. В какой момент привлекать тестирование — по V-модели, по которой тестирование производится для всех этапов, либо по водопаду, где лишь после написания кода, либо использовать Agile/TDD — это дело выбора менеджера проекта.

                                      О «вето»:
                                      Право вето среди отдела тестирования и у QA в мире существует, и оно не просто «мешает процессу деливери», а обеспечивает качество. Лучше затянуть поставку на два года (как в случае Boeing 787), чем выпустить потенциально опасный продукт на рынок. Но, опять-таки, все в рамках и масштабах проектов и установленных критериев качества (qulity gates), чтобы никто в проекте не стрелял по воробьям из пушки.

                                      Для того, чтобы оно работало, PM и QA должны установить «правила игры», в которых будет прописано, какией критерии будут блокирующими и mitigation plan для них.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое