Кто такой хороший QA?


    Начнем с того, что в народе всех quality assurance инженеров (“по-нашенски”, инженеров отдела качества) обзывают тестировщиками. Это не совсем правильно, в реальности тестирование — это только часть задач QA, но кого бы это волновало. Поэтому пойдем в общем тренде и будем использовать привычное всем погоняло.

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

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

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

    Из него видно, что к ПО есть конкретные требования, и надо, чтобы они выполнялись. Если тестировщик ломал программу вместо того, чтобы проверить, выполняет ли она вообще возложенные на нее функции, в итоге он может получить стабильную, но не нужную заказчику фигню.

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

    Тестирование и не только


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

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

    Вы уже понимаете, что история на этом не кончается.

    Тестировщик попытался объяснить пользователю, в чем тот не прав, нарвавшись на порцию негатива и негодования. Пользователь усадил его рядом и открыл требования, на основе которых писались спецификации. Одно из этих требований почти дословно гласило следующее: ”Атрибут должен отображаться на каждом экране”. Одно предложение, а сколько смысла! Затем он открыл приложение и начал рандомно навигироваться на разные экраны, приговаривая: “И где же этот атрибут?”. Понятное дело, что пользователь откровенно издевался, но формально он имел на это право. Беда в том, что дальше пошла эскалация, и в процесс обсуждения проблемы вовлекалось все больше народу. Под конец пользователя убеждали, кроме самого тестировщика, несколько ПМов и толпа аналитиков, а тот был непреклонен и требовал уже невозможного.

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

    Без фанатизма



    Идем дальше, весьма иронично, сам процесс тестирования характеризуется бородатым анекдотом:

    Заходит однажды тестировщик в бар.
    Забегает в бар.
    Пролезает в бар.
    Танцуя, проникает в бар.
    Крадется в бар.
    Врывается в бар.
    Прыгает в бар.

    Заказывает:
    кружку пива,
    2 кружки пива,
    0 кружек пива,
    999999999 кружек пива,
    ящерицу в стакане,
    –1 кружку пива,
    qwerty кружек пива.

    Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают.

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

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

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

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

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

    Язык мой — враг мой



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

    Что это все за собой влечет? Тут ответ и ежу понятен, но на примерах, конечно, интереснее.

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

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

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

    Личное пространство



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

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

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

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

    Организационные моменты



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

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

    Однажды тестировщика поставили на новый проект. Поскольку он его плохо знал, ему дали задание разобраться и записать наблюдения. Так как это было нечто неформальное, договорились, что писать будет в гуглдоке. Человек начал выполнять задание, через неделю это задание было проверено, тестировщика похлопали по плечу и он продолжил работу. Шли месяцы, у начальства появилось беспокойство, почему в багтрекере нет тикетов и ничего на проекте не делается. Начали разбираться, оказалось, что человек продолжает писать в том самом гуглдоке. Никто же не сказал “Горшочек, не вари” и не остановил тестировщика, а он исправно продолжал разбираться и записывать наблюдения, при этом никак не давая о себе знать. Баги есть, и он их нашел, но никому не сказал, а лишь записал в файлик, о котором спустя неделю уже все забыли.

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

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

    Заключение


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

    А если человек ответственно и со здравым смыслом подходит к своей работе, то ему удастся избежать большинство проблем на своем пути, не только в профессии QA.
    Haulmont
    Создаем современные корпоративные системы

    Комментарии 40

      +1
      Статья отличная!, последний пример про гуглодок вообще сюрреализм какой-то) Тестировщик должен прежде всего уметь общаться со всей командой.
      Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет. И вот он пытается на этапе обсуждения требований заказчика что-то свое предложить, но его не слушают, пытается объяснить разработчику, как будет удобнее для пользователя сделать кнопку, форму и т.д. — разработчик говорит — этого нет в ТЗ. Рассказывает в никуда про автоматизацию и юнит тесты. В общем пытается сделать качество продукта более высоким, но безрезультатно.
      Что делать вот в такой ситуации? Увольняться? Давить? Писать предложения руководству? Забить и плыть по течению?
      Поделитесь, пожалуйста, опытом, сталкивались ли вы с чем-то подобным и есть ли какие-то универсальные решения?
        0
        Увольняться?

        This

          +1
          Увольнение не всегда может быть хорошим вариантом. Можно попробовать обойтись без крайних мер, но придется запастись терпением. Любые свои замечание нужно будет оформлять в виде тикетов и доводить до команды о их существовании. Команда, в свою очередь, может принять решение ничего по ним не делать. В таком случае ответственность за проблемы после релиза будет уже не на тестировщике, а на тех кто принимал решение не исправлять проблему. После череды событий из разряда «Я же говорил...», команда невольно начнет прислушиваться.
            +1
            Плюсую.
            Faenor Нужно набрать себе репутацию. Когда ты найдешь несколько раз неочевидные вещи, которые окажутся на деле критическими — с твоим мнением начнут считаться. Но последнее слово все равно за лидом.
            Ну и нужно общаться с разработчиками, чтобы понимать их классификацию проблем и критичности.

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

            Рассказывает в никуда про автоматизацию и юнит тесты
            Tогда и такие темы будут не просто так рассказываться. Ты попробуешь написать сам какой нибудь юнит-тест, начнешь ковырять Jenkins, пилить автоматизацию приемочного тестирования, и т.д. Только сделать и показать. А говорить и надеяться, что кто-то вдохновится речью на какие-то телодвижения — ну это только в фильмах бывает.
            Но если ты это сделаешь — как взлетит твоя репутация, ты будешь «хранителем тайного знания».

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

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

            Короче, нужно брать все в свои руки. Изменить процессы можно только изнутри. Своими руками. У нас было несколько таких, кто приходил на должность типа «коуча», вещал умные вещи про то как надо, но ни пальцем не притронулся к проекту. Не сделал ничего для продукта. Для меня теперь это быстрый тест на эффективность человека в новой должности. Если «марает» руки — будет толк, если нет — не будет.

            Люблю цитировать Ларри Уолла: «Три высших добродетели программиста — лень, нетерпение и спесь». И когда я только вливался в среду, я почувствовал это все на себе. Со временем я адаптировался, вырос. Характер разработчиков так и не изменился, но изменился я. И отношения у нас замечательные.
            0

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


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

              0
              Ребят, всем спасибо за ответы, буду думать...)
              0
              Статья отличная!, последний пример про гуглодок вообще сюрреализм какой-то) Тестировщик должен прежде всего уметь общаться со всей командой.


              Нет не должен. А вот к Тим Лиду большой вопрос, что за бардак у него в рабочей группе.

              Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет.


              Хорошо бы понимать что есть QA и должность не обязательна должна быть.
              Может быть и роль.
              Кстати мало людей фанатеют от гостов и стандартов. А для QA они основа в работе…

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


              Не занимаются QA удобством продукта для пользователя.
              Более того если этого нет в ТЗ именно QA первый скажет стопе. Вносите в ТЗ, вот тогда и будем разговарить, нет процесса на измение тз? Ок, счас будуте.

              QA — это в первую очередь нацеленность на бизнес и на процессы.

                0
                Не занимаются QA удобством продукта для пользователя

                Занимаются
                Этот вид тестирования называется usability

                  0
                  Нет, QA специалисты не занимаются QC, а уж тем более тестированием.
                  Если у вас в компании так, то тогда у меня для вас плохие новости :)

                  Есть такой фасет в нефункционально тестировании. И?
                  Да есть тестировщики специализирующиеся на нем, но именно тестировщики, они обычно одновременно юзабилити занимаются. Но это не то чем занимается QA
                    +3
                    Нет, QA специалисты не занимаются QC, а уж тем более тестированием.
                    Если у вас в компании так, то тогда у меня для вас плохие новости :)

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

                      0
                      ISO 9000:2005 п.3.2.11 — quality assurance
                      part of quality management (3.2.8) focused on providing confidence that quality requirements will be fulfilled

                      Такая активность как QА направлена на стандартизацию процессов с целью обеспечить гарантию того, что установленные для ПО требования будут удовлетворены.

                      Перевожу: QA инженеры (По сути, эту роль можно возложить на любого человека, который знает стандарты и отраслевые, и стандарты внутренние) занимаются превентивной деятельностью. Они налаживают процессы разработки, тестирования и внедрения ПО таким образом, чтобы минимализировать шанс его несоответствия требованиям и стандартам. Для этого пользуются внедрением разнообразных метрик качества продукта и способов их проверки (что и называется QC, которое выполняется уже, как правило, отдельными людьми).
                      Тестирование же — это просто деятельность, направленная на ОБНАРУЖЕНИЕ несоответствий ПО требованиям, т.е инструмент для такого процесса как QC.

                      Хотя, в современных «шлеп-шлеп и в продакшн» конторах, конечно же, никто и не пытается поинтересоваться что с чем едят и, как минимум, попытаться отличить говно от нутеллыодно от другого и немного формализовать процессы, что печалит…
                        0
                        Я гляжу, что не все до конца понимают о чем говорят…
                        На самом деле есть русская версия ISO: www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:ru:term:3.2.11

                        Выдержки:
                        — 3.2.11
                        обеспечение качества
                        quality assurance
                        часть менеджмента качества (3.2.8), направленная на создание уверенности в том, что требования (3.1.2) к качеству будут выполнены
                        — 3.2.10
                        управление качеством
                        quality control
                        часть менеджмента качества (3.2.8), направленная на выполнение требований (3.1.2) к качеству
                        — 3.2.8
                        менеджмент качества
                        quality management
                        скоординированная деятельность по руководству и управлению организацией (3.3.1) применительно к качеству (3.1.1)
                        Примечание 1 к записи: Руководство и управление применительно к качеству обычно включает разработку политики в области качества (3.2.4) и целей в области качества (3.2.5), планирование качества (3.2.9), управление качеством (3.2.10), обеспечение качества (3.2.11) и улучшение качества (3.2.12).
                        Первое — определение процесса обеспечения качества, второе — процесс управления качеством. Все это является состовляющей менеджмента качества, также как и планирование и многое другое. Это не определение должности человека.
                        В большинстве компаний есть отдел качества, который занимается как раз Менеджментом этого самого качества. Т.е. те же самые люди, что настроили процесс, могут заниматься и тестированием. Может действительно отдельную статью об этом написать…
                          0
                          Я и попытался разъяснить, что стоит за каждым из этих пунктов.

                          В одном с вами не соглашусь. Не знаю компаний (конечно, я не утверждаю, что их нет в принципе), где одна и та же команда выполняла бы и QA, и QC. QA — это все-таки про стандарты (при чем тех самых процессов тоже), их разработку и внедрение. Если речь идет о QC и тестировании — согласен, изучили стандарты, построили процессы, наладили коммуникации — и вперед тестировать. А роль QA на практике в большинстве компаний ложится на плечи архитектам и всяким там R&D менеджерам и иже с ними, которые уже внедряют метрики, описывают стандарты, соглашения, проводят код ревью т.д.

                          Интересно было бы узнать названия хотя бы некоторых из этого вашего большинства компаний, где те люди, которые тестируют ПО, занимаются так же разработкой стандартов или ХОТЯ БЫ участвуют в код-ревью девелопмента) Да, несомненно, они могут принимать участие в этих процессах косвенно или факультативно, но они не являются главными инфлюэнсерами.

                          По поводу написания статьи — согласен, иногда чувствуется острая необходимость прояснить и трактовать все понятия, объяснить их применение на практике, но тем, кто и не хочет разбираться в тонкостях — вряд ли поможет.
                            0
                            Большинство имеет отдел качества. Не в каждой это именно QA отдел, хоть и называется так. Я видел конторы в которых вообще нет тестировщиков и их обязанности принимают другие отделы. Мне, будучи сотрудником QA отдела, приходилось фиксы делать вместо разработчиков. Это все лирика. Да, в природе есть компании, в которых отдел QA — это QA. И даже есть в которых код ревью делают, все зависит от подхода. Важно понимать, что QA — занимается тестированием, просто по сравнению с QC у сотрудников больше полномочий и обязанностей. Ну я уж не буду пояснять, что внутри отдела тоже есть иерархия и обязанности могут быть разделены.
                              0
                              Все, я уловил вашу мысль. Мы обсуждали одну и ту же иерархию в разных направлениях) Вы говорили о возможности такого подхода, когда QA занимаются тестированием, а я говорил о том, что тестировщики (без нужной квалификации, а именно такие работают на большинстве галер) не могут заниматься QA активностями, по этому этот скоуп ложится на плечи иных людей. Тут одно другому не мешает)

                              В целом, приятно пообщаться с человеком, который понимает чем он занимается
                          0

                          Я же написал: "общепризнанного". Вы можете сколько угодно ссылаться на всяческие стандарты но пока люди вокруг реально не начнут поголовно использовать именно это определение — это именно вы будете вне сообщества, а не наоборот. Толку то от того что вы будете применять труъ определение если вас никто не поймет. А уж если начать говорить о понимании людей не связанных со всем этим напрямую — руководством например, то там все совсем плохо.

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

                  Заводить дефект на положение кнопки это не дело тестировщика, он максимум может вынести этот вопрос на обсуждение с дизайнером
                    0
                    Почему? Чтобы вынести вопрос он должен завести тикет, а дизайнер в том же тикете отпишет свою точку зрения. Это тестирование usability или UI/UX.
                      0

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

                        0
                        Согласен, процессы могут быть разные, но такого рода обсуждения важно логировать, чтобы потом было на что ссылаться. Если все будет устно, потом могут концов и не найти.
                          0

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

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

                              Да, с такой формулировкой я полностью согласен.

                        0
                        Не согласен. Когда новые кнопки выбиваются из ряда и ломают процесс работы в программе — он именно что должен завести тикет.
                        А то было когда на задачу «добавить две кнопки в форму» разработчик открыл форму, растянул, кинул внизу две стандартных кнопки, навесил функционал и закрыл баг. Нужно объяснять, что все прочие кнопки стояли в других местах и имели идею в своём расположении, в отличие от?
                        0
                        Спасибо за статью!:)
                          +1

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

                            +1
                            Спасибо за развернутый комментарий, я намерено не стал вдаваться в подробности о том, что такое Тестирование, QC и QA. Т.к. это тема обширная, которая годится для отдельной статьи. Я лишь указал, что QA в большинстве компаний так и зовут тестировщиками, хоть это и неправильно. И да, бывает и обратная ситуация, когда тестировщиков зовут QA.
                              0

                              Абсолютно согласен. Это мы еще с вами не задели тему, как QA пересекается с DevOps. Это все вместе уже на цикл статей тянет.

                            0
                            «Если тестировщик ломал программу вместо того, чтобы проверить, выполняет ли она вообще возложенные на нее функции, в итоге он может получить стабильную, но не нужную заказчику фигню.»
                            «QA — это, по сути, адвокат пользователя.»

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

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

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

                                  0
                                  Какая-то инфантильная статья, и она даже не про тестировщика, а тем более не про QA.
                                    0
                                    Полностью согласен. Сборник бессмысленных анекдотов без всякой морали. Может забыли тэг «Юмор»?
                                    +1
                                    >>хороший тестировщик никогда не остановится, найдя первый попавшийся баг
                                    Даже самый плохонький тестировщик не должен так делать. Первое что нужно объяснить новорожденному тестировщику — твоя задача не найти мильон багов. Твоя задача — проверить что программа выполняет свои функции. И только когда есть уверенность что выполняет — можно переходить к 9999999 кружкам и запятым в About.
                                      0
                                      > Твоя задача — проверить что программа выполняет свои функции
                                      Это положительные кейсы. Да, тестировщик обязан это проделать первым же делом. Но далее он обязан проверить и негативные кейсы. Да, все их перебрать нереально, но основные негативные кейсы проверить ему тоже необходимо.

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

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