На собеседованиях я всегда спрашиваю, в чем смысел тестирования.
Определенного правильного ответа нет, он просто указывает на некий уровень развитости понимания обсуждаемой темы, не более. Однако ответ на этот вопрос говорит о многом.
Один из самых распространенных ответов таков:
«Тестирование повышает качество продукта».
Ну…
Вообще — нет, хотя… Да, с точки зрения рабоче-крестьянской логики, все именно так и происходит.
Я сам когда-то думал точно так же.
Я когда-то вообще думал только о том, как взять полууменьшенный минорный септаккорд от Ми, бо у Розенбаума оно получается, а у меня нет 🙂
Например, мое понимание смысела тестирования с годами ощутимо поменялось, и нынешнее свое понимание я совершенно не готов выбивать в мраморе на своем обелиске…
Однако попробуем уточнить, почему кандидат думает именно так (типичный диалог):
— А каким образом тестирование повышает качество?
— А таким, что если мы узнаем о багах, и асфиксим их (асфиксия — удушие, подразумевается планомерное удушение багов, гыгы), то качество продукта повышается.
— И в сравнении с чем оно повышается?
— Ну… В сравнении с тем, что было до тестирования, разумеется.
— Но ведь ожидалось, что продукт будет качественным, без багов. А тестирование показало, что продукт получился некачественным. Так в сравнении с чем качество смогло повысится после багфиксинга? Мне вот кажется, что после исправления дефектов продукт из некачественного просто стал качественным, а качество не повысилось, оно просто появилось.
— Ыыыыы… Ну так вот же — продукт стал качественным после исправления дефектов! И помогло в этом тестирование! Вот в этом и есть смысел тестирования — помогать делать продукт качественным!!! ©
И знаете что? Этот вопрос я задаю не только на собеседованиях. Примерно так же отвечают и менеджеры различных уровней, которые ответственны за процессы разработки ПО или за бизнес вообще.
Много народу в должности ПМ или вообще «клиент» убеждены в том, что
- если тестирование будет крутым,
- и если тестировщики будут крутыми,
- и если тестировщики будут «болеть за качество»,
то продукт будет отличным.
На самом деле, это вопрос и компетенция Product Manager.
Но считается, что «каждый должен заниматься своим делом» — программист программирует, тестировщик — тестирует, а то, что тестирование — занятие очень неоднозначное, и им занимаются вообще все те, кто вовлечен в проект, так «Вы мне это прекратите. Вы не в балагане, Привалов«.
После этого мы переходим к другим вопросам о тестировании. Например, к вопросам о том, как делают вино.
Есть в отрасли виноделия такие люди — виноградари. Они отвечают за условия, в которых виноград зреет.
Буквально — где когда и как сажать, как подвязывать, как чистить, как ухаживать…
Задача и вечное проклятие виноградарей — предоставить виноделам виноматериал, который соответствует определенным техническим характеристикам.
Характеристик этих множество, самыми понятными считаются соотношение влаги, сахара и кислотности в ягоде.
Характеристики виноматериала зависят не только от сорта винограда и и положения звезд в созвездии Свисток рака. Они даже поддаются какому-то тюнингу.
Например, если подержать виноград на лозе подольше нужного, он усыхает, жидкости в ягодах становится меньше, зато сахара больше. Если круто передержать, ягода превращается в будущий изюм, теряя влагу ко всем небесам.
В Венгрии придумали насылать на виноград специальный грибок «Ботритис» (одна тетка произносила «Бодритес»), затем выдерживают на лозе до начала высыхания, и получается ботритизированное вино, мощное, дорогое и сладкое.
Обычно же поражение Ботритисом такая же беда, как и прочие болезни винограда.
В некоторых странах виноград держат на лозе до наступления заморозков, и затем делают из иссушенных, подмороженных ягод вино под названием «ice-wine» (ледяное вино); тоже прелесть в разделе десертных вин, сцуко, очень дорогое и немассовое.
В общем, винодел пытается получить от виноградаря заготовку с определенными параметрами, для того чтобы сделать вино с какими-то заранее предопределенными характеристиками (содержание сахара, спиртуозность, содержание тяжелых металлов и пестицидов, и много всякого).
Ближе к началу осени виноградарь начинает орать о том, что если виноград не снять вот прямо сейчас, то он снимает с себя всякую ответственность; а винодел орет о том, что если он сделает вино не такое-то, как того ожидают ритейлеры, им обоим будет нечего с себя снимать, поэтому снимать виноград ещё не надо…
На заднем плане в лаборатории среди реторт притаился лаборант — он будет проверять соответствие винограда, а затем и итогового вина техническим характеристикам. Лаборант вообще не волнуется. Разработка идёт как полагается — все орут.
Чувствуем совпадения с процессом разработки программного обеспечения, да? Насыпьте себе сухого кахетинского Форстериезуитенгартена (я легко могу это слово произнести без запинки), и продолжим.
Можно насыпать лед, бо жара в Киеве — нуеёнафиг…
На втором этаже сидит директор винзавода, и его тоже совершенно не волнует, получится ли вино качественным. Его волнует, получится ли вино вообще, бо вино такой зверёк, что или получается, или у вас будет простое «гаражное вино», стоимость которого вообще смешна, но является предметом личной гордости гаражного производителя.
В виноделии существуют законодательно предопределенные технические параметры качества производимого вина.
Вот бы софтописателям заполучить такие законодательные стандарты 🙂
Параметры готового изделия зависят от технических параметров исходного сырья (содержание сахара в ягодах, содержание воды в ягодах, содержания ягод в ягодах, условия роста ягод, общая сумма солнечных дней в году производства), и учитываются виноделом в процессе работы. Винодел заранее знает, каким вино должно получиться, если учесть то-то и сделать так-то…
Также винодел придерживается непременно повторяемой технологии производства вина, хотя имеет всю власть для проведения экспериментов.
В сумме это дает возможность рассчитать технические характеристики будущего продукта, и помогает сдать проект с выполнением определенных ожиданий заказчика.
В действительности вино — живой организм, и оно всегда получается «как получится». Но повторю сто раз, что есть возможность получить качество по ожидаемым параметрам, если:
- заранее подготовить (или купить) виноматериал определенного качества,
- строго и правильно выдерживать правильную технологию производства.
Для протокола: виноделы Европы уверенны в том, что создание вина — искусство, которое невозможно формализовать, алгоритмизировать, сделать техничным, все держится на чутье, таланте, и созвездии Свисток рака.
Короче, для них виноделие — состояние души.
Виноделы из Калифорнии это глупое заблуждение давно опровергли; они без чутья и таланта, только на основе копирования и взаимствования физико-химических показателей «от европейцев» из года в год делают чёткое и качественное вино, совершенно не страдая аллегоризмом. Все по-американски просто и прагматично.
Итоговая оценка качества вина производится по нескольким фронтам, самый известный из которых — органолептика (как выглядит, как пахнет, каково на вкус — обычное юзабилити тестирование), но основными являются физико-химические показатели.
Одно без другого не должно рассматриваться, но если говорить очень строго, то главными критериями качества вина являются измеримые физико-химические показатели.
Примеры физико-химических показателей для оценки качества вина:
- объемная доля этилового спирта, %;
- массовая концентрация сахара в пересчете на инвертный, г/100 см3;
- массовая концентрация титруемых кислот в пересчете на винную, г/дм3;
- массовая концентрация приведенного экстракта, г/дм3;
- давление в бутылках для вин, насыщенных СОг, кПа;
- органолептические показатели, баллы: прозрачность, цвет, букет, вкус, типичность (или для вин, насыщенных С02,- игристые и пенистые свойства);
- ассовая концентрация летучих кислот в пересчете на уксусную, г/дм3;
- массовая концентрация диоксида серы (общей и свободной), мг/дм3;
- массовая концентрация тяжелых металлов (железа, меди, свинца, олова), мг/дм3;
- содержание цианистых соединений;
- физико-химическая и микробиологическая стабильность, полнота налива и герметичность укупорки бутылок, гарантийный срок хранения готовой продукции;
Список скопирован с vinogradnik.org.ua, но вообще он предопределен в законодательствах и директивах отдельных стран.
Еще страшные цифры есть в реферате «Товароведная характеристика и оценка качества виноградного вина». Там рассказывается про то, как в производстве шампанского юзается рыбный клей и лимонная кислота 😉
Дык вот, примеры с циферками.
Если предоставленное нам для пробы вино не болеет (помутнение, окисление и прочие мерзости), и содержит спирта от 12 до 16%, а массовая концентрация Сахаров находится в диапазоне от 210 до 300 г/дм3 (и титруемых кислот там в пределах от 3 до 8 г/дм3), то согласно ГОСТ 7208-93, мы зрим ликерное вино, которое полностью соответствует российскому стандарту качества.
А если спирта около 12%, а содержание сахара стремится к нулю (полного нуля тут не бывает), то перед нами сухое столовое вино.
Если спирта будет менее 9%, то это, скорее всего, уже будет фляка, а не сухое вино.
Если спирта ноль, то перед нами компот обыкновенный, виноградный.
Итак,
- если все диапазоны соблюдены,
- если лабораторные пробы показывают правильность ожидаемых цифр,
Вопрос — это качественное вино?
Безусловно, да. Все то, что укладывается в заранее установленные параметры, является качественным.
Но вот…
Вкусное ли это вино?
«Вкусность» нельзя рассматривать с точки зрения циферок ТТХ.
«Вкусность» — уже дело третье, ведь заявленое качество полностью соблюдено, поэтому вино считается качественным.
Однако именно по «вкусности» качество вина и определяется конечным потребителем 🙂
Вино, которое всего лишь полностью соответствует параметрам ГОСТ, ничего необычного из себя не представляет. Его можно выпускать на рынок, тестирование оно проходит успешно, но страдать от счастья с этим вином не приходится.
Это простое, стандартное вино.
Проблематичность оценки заключается в факторе субъективности. Все мы «разбираемся в винах» (не забываем оттопыривать мизинец). И все мы когда-то попадаем в странную ситуацию: обычное, безусловно стандартное вино не воспринимается как качественное.
Под качественным вином нами почти всегда подразумевается ВЫСОКОкачественное вино.
Очевидна ли подмена понятий и ожиданий?
Это понятно, или это странно?
Трабла в том, что высококачественное вино в ГОСТ не описывается. Оно просто иногда «получается».
Иногда можно попытаться предсказать, что «вот это вино получится высококачественным, очень юзабельным, с приятным и долгим послевкусием«, патамушта оно было сделано из винограда с такими-то высокими показателями ТТХ. Но бывает, что ожидания не оправдываются.
Иногда марочное вино, заранее предназначенное для многолетнего выдерживания в бочках, может обещаться когда-нибудь быть ВЫСОКОкачественным, и зачастую оно таким становится.
А иногда — нет.
Не всякое вино можно выдерживать по 50 лет в бутылках.
Невозможно гарантировать эту высококачественность подходом типа «винодел болеет за мой продукт, он переживает за качество всего проекта, он встанет и скажет, что проект не готов к выходу, даже если давление (в том числе и с моей стороны) будет высоко«.
Да и вообще, что такое «высококачественное вино»? Баланс между содержанием танинов, кислотностью и ароматикой? Долго послевкусие? Новое послевкусие?
Грамотное послевкусие в ротовой полости должно ощущаться после каждого качественного вина. Это все тот же вкус, который ты ощущаешь после пробы, он устойчивый, явный, медленно исчезающий.
Но есть вина, которые поражают неожиданным финтом:
- понюхал — почуял что-то одно.
- попробовал — почуял что-то другое.
- подождал десяток секунд, и ВНЕЗАПНО чувствуешь во рту вообще третий вкус, совершенно неожиданный и невесть откуда взявшийся.
Это ОЧЕНЬ круто.
За такие ощущения стоит заплатить дорого.
Ординарные вина подобными эффектами не обладают в принципе.
Понятно, что под высококачественным подразумевается превышение ожиданий, и скорее всего, это будет не превышение физико-химических цифровых показателей. Это нечто априори субъективное.
У опытного винодела вино, вероятнее всего, получится качественным.
У опытного и талантливого винодела вино, вероятнее всего, получится качественным, а вероятно, и высококачественным.
Все это зависит от винодела, а не от его лаборанта.
Тестировщик — не винодел. Он не разрабатывает.
Хотя может знать технологию, и даже что-то ковыряет на личном участке земли под домом.
Тестировщик — не инстанция, которая делает что-то такое, что позволяет качество продукта повышать или понижать, сильно или слабо болея за разрабатываемый продукт.
Продукт — вот он, готов (пусть даже частично), пробуйте и оценивайте.
Тестировщик определяет готовность и качество продукта, и сообщает эту информацию тем, кому она важна, dixi.
То, что тестировщики «не болеют» за продукт, не является проблемой аутсорсинга тестирования.
Более того, это вообще свойственно не только тестировщикам, но и всем остальным участникам разработки.
Взваливать ответственность за качество продукта на тестировщиков правильно только с точки зрения принципов Quality School (знаете ведь про школы тестирования, да?). В остальном это неправильно и даже пагубно.
У винодела с оценкой качества дела обстоят бинарно — вино или получилось, или нет, это быстро определяет химлаборатория при заводе.
Фиксить баги винодел не может, продукт уже готов. Он может их только предвидеть и может принимать какие-то меры в процессе производства, не более.
Все то, что винодел мог сделать, он должен был сделать ДО того, как вино объявляется готовым.
В виноделии, в случае если «не получилось», вы просто идете домой и сосете себе палец до просветления. Невозможно что-нибудь исправить в вине, которое «не получилось» в принципе.
Выправлять в готовом продукте можно только какие-то частности, но это редкость, и требует шаманства.
Да шаманство и не поможет, если речь идет всего лишь об исправлении дефектов.
В софтостроении хорошо то, что если продукту присущи какие-то дефекты, то их почти всегда можно исправить.
Но исправление дефектов не повышает качество продукта.
Исправление дефектов только «лечит» продукт, там, где что-то прогибается в минус, и после починки просто поднимается до уровня «ноль», то есть — как и ожидалось.
Картинка для наглядности
…
На оси Х слева направо последовательно перечислены какие-то функции, для которых мы будем выяснять уровень качества воплощения. Уровень «0» это очень хорошо, это значит, что в частностях все получилось as expected.
На оси Y отображается в «минусе» важность дефектов, которые были найдены, а в «плюсе» — уровень сатисфакции той или иной фичей.
Для наглядности — функция №1 получилась отменной, и получила целый балл к карме.
Любо-дорого открывать сайт в принципе 🙂
Остальные функции отзываются как положено, ок.
Функция №17 выдала нам такой лажовый бэмц, что приоритет бага был объявлен критическим. Позже баг пофиксят, и функция придет в норму. В норму, в «ноль», а не в дальние высоты программерского искусства.
Идея понятна?
Теперь вот что получается.
Качественный продукт — это ноль по всем показателям. Простое соответствие ожиданиям.
Высококачественный продукт — это выше нуля по всем показателям.
Такое бывает?
Домашнее задание: поскорее найти в изложенных рассуждениях допущенную неточность, которая разрушает все мои логические построения.
[polldaddy poll=5240022]
Как-то не по человечески.
Вы еще скажите, что мы тут собрались деньги зарабатывать.
Аналогия с лаборантом хороша. Но есть нюанс. Лаборанту дали пробирку — он с ней работает.
Тестировщику обычно тоже сперва дают пробирку, но только потому как у них образ такой — «тестировщик ищет баги в программе», ага.
Но это как то неправильно, когда нетестировщики учат работать тестировщика.
Через несколько лет выясняется, что тестировать можно не только программу. А еще через несколько — что программу вообще тестировать почти не нужно и в последнюю очередь.
Работал как-то один сейл с одной прекрасной программисткой. Женился он на ней и стало меньше в продукте багов — на 4 критикал в месяц. Все просто. Она по пятницам допоздна работала, и, как правило, ломала то билды, то логику полуночным коммитом. Раньше.
При чем тут программа вообще?
Так и выходит.
Тестировщик ищет ошибки.
Тестировщик проверяет на соответствие.
Тестировщик недопускает появление ошибок.
Тестировщик понимает, что погорячился, и снова допускает ошибки, но не все, под запись и по паспортам.
Тестировщик вместе со всеми делает мир лучше.
Согласен на 90%. Основная мысль написана верно, качество продукта — это работа всех. Тестировщик всего-лишь проверяет получилось ли у них это сделать или нет.
Вижу, что есть ответ на мой пост о проблемах тестирования в аутсорсинге . Рад, что некоторые мысли «зацепили за живое» 🙂
Самое большое отличие, которое ты упустил (IMHO): Тестировщик в лабаратории не может повлиять на факторы созревания винограда (солнечные дни, болезни винограда, т.д.), а тестировщик в команде может. Он может менять процесс и факторы создания этой самой программы. Выйти и сказать, что Юнит-тесты не делают того, что должны, поэтому так много багов при изменениях.
Если же небрать во внимание такую возможность тестировщика (позиция «а я за это не отвечаю»), то пост на 100% прав 🙂
Не смог вывести весь материал за 1 раз =( Придется еще раз садится =)
Никаких крупных логических ляпов не нашёл (
Единственное, что царапнуло — «Но исправление дефектов не повышает качество продукта»
Про виноделие спасибо, интересно и познавательно )
Я эту идею особенно тщательно обдумал, бо она меня слегка напугала.
Специально картинку для наглядности сам себе нарисовал 🙂
Это нормально.
Повторюсь: при чтении сложных требований всё следует разбивать на короткие идеи.
Там за сложными оборотами обычно скрываются простые идеи, иногда иначе, чем сложно, выразиться не получается.
Сергей, весь этот текст — реакция на твой пост. Я поклонник идеи о том, что полемизировать надо статьями, а не в комментариях 🙂
Я тут попытался полновесно обосновать свое понимание ситуации, хотя можно было бы в нескольких предложениях все сформулировать так: априори ожидать от тестировщика способности влиять на процессы и факторы создания не следует, это ошибочно. И хотя иногда это происходит, это не показатель «правильного» тестировщика, технически говоря.
Наверное, это следствие того, что от тестировщика ожидают «to be QA», в то время как «тестирование» и «обеспечение качества» — это технически разные понятия («хирург и медсестра«).
Называть всех тестировщиков «обеспечивателями качества» некорректно, это приводит к неизбежному разочарованию вроде «Я думал, что тестировщики за качество отвечают, а они не отвечают, за мой продукт не болеют«.
К тому же, nobless oblige — я когда-то был назначен QA, и очень трепетно к этой должности относился. Я носился по офису и требовал изменить процессы разработки, требовал применять то и это так и эдак, и в итоге был выпилен из компании, хотя никто четко не мог сформулировать претензии к моей работе, да и сам я очень устал от сложившейся ситуации, и не жаждал разбираться, я жаждал уйти.
И редко бывает так, чтобы тестировщика награждали ответственностью, и в то же время давали рычаги для управления. Обычно дают только ответственность без полномочий, а это страшно.
Ну «царапнуло» — в смысле совсем не согласен ))
Тестирование — не повышает, да. А исправление — вполне повышает, как и любая работа по изменению продукта, а не по анализу оного.
ну а так конечно +100500 к “хирург и медсестра“, отлично сформулировано.
этот ньюанс рождает море проблем
ну тут вопрос терминологический
если рассуждать чётко, то тестирование служит для оценки качества. и повышать ничего не может. точка.
если рассуждать расплывчато, то результаты тестирования могут привести к
а) исправлению дефектов = повышению качества продукта — от отрицательного (с багами) до нейтрального (эз экспектед).
б) к пересмотру требований = повышению планки «нейтрального качества». т.е.
Мысли после прочтения:
1. Некоторые продукты перерождались из одного в другое, так что фраза «Качественный продукт – это простое соответствие ожиданиям(ноль по всем показателям), а высококачественный продукт – это выше нуля по всем показателям.» не совсем корректна, можно утверждать что качественный продукт в принципе может не вписываться в эту картинку.
2. «Под качественным вином нами почти всегда подразумевается ВЫСОКОкачественное вино.» ну как бы сказать — учитывая мой недавний обзор винных полок в магазинах, качественно — это то от чего не отравишься 🙂
3. Цитаты из пунктов 1 и 2 как то между собой слегка конфликтуют, по моему.
Согласен с тем что исправление багов не улучшает качество софта.
Порой все сказывается на производительности и на поведении связанных функционалов.
А самый главный косяк это то что во многих компаниях отсутствуют приемщики кодов, даже если они есть то они не так четко анализируют методы в кодах.
В свое время, команда из «хороших» тестеров смогут проверить код.
З/Ы: дайте эту работу инженерам тестировщикам. Пусть это будет дольше, но они сделают продукт качественным 🙂
Так в чем все-таки конечный «смысел» нашей работы?
Смысел — это как для приколу, так сказать рассчитанный шаг?
В предоставлении обратной связи об исследуемом софте.
Все остальное — наносное, но иногда кажется основным, и перетягивает на себя внимание.
Вот именно (хорошо сформулировано!).
Неоднозначность суждений и восприятия порождает путаницу.
Здравствуйте, Алексей. А скажите Вы в данном контексте отделяете (разделяете, дифференцируете) смысл и цель тестирования?
Смысл — предоставить обратную связь об тестируемом софте
Цель — обнаружить (обнаруживать) ошибки или иначе, постоянно доказывать, что система содержит ошибки. Т.е. цель осмысляется через предоставление обратной связи?
Нет.
Про цели можно говорить отдельно и тоже долго, бо их много.
Я тут рационализировал только смысл проведения тестирования, искал ответ на вопрос «Зачем вообще это нужно делать?» в свете ожиданий со стороны заказчика работ, которого описал Бережной.
Мне кажется, что корректнее будет сказать так:
смысл проведения тестирования — получение информации для последующего принятия решения.
цель проведения тестирования — предоставить обратную связь об тестируемом софте.
Обнаружение ошибок — это техническое последствие тестирования; но оно легко может стать целью и даже смыслом. Например, вас интересует конкретный ответ — есть ли в софте ошибки определенного рода, и тестировщику предлагается сосредоточиться на их поиске.
Или сам тестировщик из злостного спортивного интереса целенаправленно ищет ошибки, и находит их, и гордится этим. В каком-то смысле очень важно уметь испытывать эту злость и желание найти как можно больше ошибок — это стимулирует и тонизирует. Но видеть в этом смысл работы нельзя, фокус сбивается.
К тому же, сложно соревноваться с другими тестировщиками иначе, нежели количеством найденных багов 🙂
Не устану повторять «вы про QA или про QC?»
смысел QС — улучшение качества продукта
смысел QA — уменьшение цены качества продукта
P.S. Да, баги, найденные в процессе проверки, не улучшат качества (сами по себе). Но есть мнение, что без данной диагностики улучшение так же невозможно.
Правильное мнение.
Подскажите, если я что-то не так понял, но почему нельзя информацию о найденных багах включать в понятие качества? Таким образом каждый найденный баг немного бы его повышал. А каждый пофикшеный — повышал бы качество ощутимо.
Выскажу мнение как последователь Джеральда Вайнберга.
В изложенных рассуждениях, Вы, Алексей, намеренно поставили ловушку на
марксистовмаксималистов. Ну или абсолютистов. Меж тем, понятие качества категория абстрактная, глубоко субъективная. Более или менее успешно пытаться переводить его в цифры и графики можно только в фиксированном контексте. Ожидания (не «требования»), кстати говоря, тоже относительны и меняются с течением времени.Аналогия с вином мне очень понравилась. Позвольте своровать для своих примеров.
«Вот стоит потенциальный покупатель в магазине…
*) …или шикарном супермаркете, где ему предлагают капельку вина на пробу. Он пробует — глаза на лоб! Запах, вкус, послевкусие — просто божественно. Смотрит на цену — и грустнеет. Нет, не может он позволить себе такой продукт, даже по праздникам.»
*) …или, правильнее сказать, в сельпо деревни Гадюкино, и брезгливо морщится слушая объяснения про букет и выдержку. Какая разница, как пьется, выблевывается-то все равно одинаково. Ни запах, ни вкус, ни послевкусие значения не имеют, и на качество не влияют. Да и градус низковат.»
*) …и слушает объяснения продавца, который месяц назад обещал доставить просто таки уникальное вино. «Понимаете, у него действительно уникальный, божественный вкус. Но вот выявились сторонние эффекты: [На выбор: бесплодие, дисбактериоз, ускоренное привыкание, вдвое более долгое опьянение, отравляет в сочетании с оливками, и т.д. и т.п.]. К продаже пока не запретили, но вам решать..»
Моя добавка к Вашему определению.
Смысл проведения тестирования – получение информации для последующего принятия решения.
Цель проведения тестирования – предоставить обратную связь об тестируемом софте.
Зачастую, эта самая информация рассматривается как сугубо негативная (баги, дефекты), или отсутствие информации о найденных багах воспринимается как отсутствие информации вообще. Это порочная практика. Исследование продукта, т.е. тестирование, это органичный процесс выявления и накопления информации.
В результате исследования выявляются как недостатки, так и достоинства продукта, причем не всегда тестировщик может самостоятельно оценить важность полученной информации, да и не должен — на это есть хозяин продукта (он же главный заказчик тестирования).
Можно ее включать.
Каждый найденный баг приносит информацию о прогрессирующей степени поражения. Поэтому фикс багов — не повышение качества, а доставание этого самого качества из глубин, в которые оно упало; это выправление ситуации, а не повышение качества.
я так порадовался первому предолжению «Не устану повторять “вы про QA или про QC?”». Сам не устаю…
но вот дальше вижу странное:
как «контроль качества» (контроль!) может улучшать его? линейкой нельзя ничего удлинить (кроме случаев обмана).
с чего это вдруг процесс «обеспечение качества» должен быть направлен на минимизацию цены качества? цель в том, чтобы продукт был качественный, иначе если впереди паровоза ставить дешевизну, то будет как с юшкой — дешева рыбка, погана юшка.
а то, что цель должна достигаться минимумом усилий\ресурсов, так это уже вопрос эффективности _любого_ процесса.
Про вино не смог читать 😉 Остановился на этом:
«Мне вот кажется, что после исправления дефектов продукт из некачественного просто стал качественным, а качество не повысилось, оно просто появилось.»
После исправления дефектов продукт не становится качественным, но повышается его качество. Считайте меня неквалифицированным недотестировщиком, а я считаю, что вы тут недобросовестно лукавите 😉
Непоследовательное восприятие текста в данном случае может сыграть злую шутку, в частности — выдергивание идей из контекста уводит разговор в другие плоскости.
Однако вы остановились, и не развили соображение. Давайте до победного — в чем именно лукавство?
В чем именно лукавство? Ну скорее, моя реплика просто провокация.
Я просто по сермяжному уверен (специфический личный опыт в текущем проекте), не бывает такого, что качества не было и вот оно есть после успешных багфиксов. Качество может повыситься, улучшиться, возрасти с менее высокого уровня до более высокого. А сказать такое ли согласиться, что его не было и вот появилось, не могу. В общем, переливание из пустого в порожнее получается. Не хотелось бы разводить демагогию. Постараюсь может быть найти силы дочитать про вино 😉
Опять бездарно и провокационно флудану.;-) Вчера или позавчера узнал, что такое оксюморон. Денни де Вито сыграл неудачника препода литературы на армейских курсах, обясняющего grunts, что такое произведения Шекспира. Пример оксюморона это горькая радость — совмещение несовместимого. Так вы пишите, что багфикс это выправление ситуации, а не повышение качества. Это есть антиоксюморон! Ибо выправление ситуации это есть повышение качества. 😉 Усе, хватит, пойду работать. Извините если что.
Сермяжность и упертость на основании «личный опыт» у меня не допускается. У меня требуется логика, доводы, обоснования, и именно поэтому все мнения тут сводобно принимаемы и обсуждаемы.
Вы можете сформулировать более точно и емко:
— что такое качество?
— как его оценивать?
— в каких случаях оно повышается, понижается, наличествует или отсутствует?
Помнится, он там не только преподавал, но и играл монологи прямо перед носом ВНЕЗАПНО обалдевшего от силы искусства курсанта.
Я вижу, что мы дошли до более-менее адекватного различия в наших подходах. Но вы все еще не обосновываете свое мнение, поэтому даже не знаю, о чем тут дискутировать.
1) Что такое качество?
Качество — способность «объекта» выполнять предназначенную ему функцию.
2) Как оценивать качество?
Качество следует оценивать на основе сравнения требуемого и реального функционирования.
3) В каких случаях качество повышается, понижается, наличествует или отсутствует?
1) Что такое качество?
Качество – способность «объекта» выполнять предназначенную ему функцию.
Это далеко не то же самое, что «value for some person», не так ли? 🙂
Это определение полностью подходит под определение качества вина. Если укладывается в технические параметры, следовательно, оно качественное.
Предлагаю все-таки прочитать весь мой текст. Там говорится про то, что в действительности под качественным вином подразумевается высококачественное. И в отношении с ПО тут можно провести прямую параллель.
То есть, поднимается вопрос — насколько способность «объекта» выполнять предназначенную ему функцию идентично понятию качества?
2) Как оценивать качество?
Качество следует оценивать на основе сравнения требуемого и реального функционирования.
Вопрос — откуда оно повышается, если на предыдущем шаге оно отсутствовало?
«в действительности под качественным вином подразумевается высококачественное»
Если используются две несогласованные шкалы оценки, да. Если они согласованы, фактически, шкала оценки единственная, тогда нет.
«Насколько способность «объекта» выполнять предназначенную ему функцию идентична понятию качества?»
Согласно определению, на 100%.
«Что такое качество?
Качество – способность «объекта» выполнять предназначенную ему функцию.
Это далеко не то же самое, что “value for some person”, не так ли?»
Конечно, «to some person» подчеркивает субъективность оценки.
«способность «объекта» выполнять предназначенную ему функцию» не содержит персонификации. То есть, подразумевает договоренность 2 или более лиц, то есть объективная формулировка. 😉
«Выполнять функцию» и «решать проблему заказчика» — не одно и то же.
Если продукт не решает конкретную проблему конкретного заказчика — то он низкого (никакого) качества.
Если продукт конкретную проблему конкретного заказчика решает лишь частично — это существенно понижает качество продукта.
Если продукт не решает конкретную проблему конкретного заказчика в конкретных условиях, требуемых заказчиком — это существенно понижает качество продукта.
Если продукт для решения конкретной проблемы конкретного заказчика требует дополнительных расходов — это существенно понижает качество продукта.
Если продукт в процессе решения конкретной проблемы конкретного заказчика создает другие проблемы, которые заказчик вынужден будет решать — это существенно понижает качество продукта.
Если решение конкретной проблемы конкретного заказчика занимает столько времени, что результат начинает терять значение, — это существенно понижает качество продукта.
Если продукт не обладает свойством стабильно решать конкретную проблему конкретного заказчика в конкретных и стабильных условиях, требуемых заказчиком, — это существенно понижает качество продукта.
Если продукт удовлетворяет заказчика по всем вышеприведенным условиям, но имеется другой продукт, который решает те же проблемы с преимуществом, высоко ценимым заказчиком (например — лучше, быстрее, дешевле, надежнее) — это существенно понижает качество первого продукта.
PS. Заказчик, в некоторых случаях, заключает договора на создание продукта. Тем не менее, умный заказчик будет оговаривать какие проблемы и в каких условиях продукт должен решать; принимать решение какие именно функциональности нужны он оставит исполнителю.
«Выполнять функцию и решать проблему заказчика – не одно и то же.»
Не согласен. Такой продукт заказчику не нужен.
Развернувшаяся дискуссия о качестве и его измерении — прекрасная иллюстрация того, что тестировщику желательно иметь вышее техническое образование (не диплом, а образование).
Эрвин Шрёдингер уже давно, прекрасно и чётко всё проиллюстрировал.
Пожалуйста, познакомьтесь с его котом.
В оригинале — с кошкой.
Однако же:
Так дискуссии не дискутируются. Это уровень сериала ‘The Big Bang Theory’.
А о чём можно дискутировать, если Ваша изначальная позиция заключается в том, что самого качества не существует до его измерения (сиречь тестирования)?
Извините, я — пас.
Ну что тут непонятного?
«Вам шашечки или ехать?» — как раз про то самое. Вот такси — раскрашено как надо (т.е. соответствует требованиям), имеет техническую возможность везти пассажира с багажом (т.е. выполнение функции в порядке), однако — не везет в аэропорт / не берет с лыжами / не принимает теньге / — т.е. конкретную проблему конкретного заказчика не решает. А потому — в глазах конкретного заказчика — данный сервис некачественный — не обладает нужным качеством, и все тут.
Коль скоро речь зашла о высшем техническом образовании, полезно будет вспомнить теорию систем и кибернетику — и тогда будет совершенно ясно, что такое абстрактное понятие как «качество» вообще не существует само по себе, и уж тем более никак не измеряется, а оценивается сравнительно.
Кошмар!
По-видимому, мы с Вами изучали разную кибернетику.
В «моей» версии этой науки качество сигнала не являлось абстракцией и прекрасно измерялось и вычислялось.
Как Вы умудрились изучать кибернетику, не изучая помехи, достоверность сигналов, фильтрацию и т.д. + колоссальный матаппарат для обработки и вычисления всего этого — для меня загадка.
ЗЫ. И пусть она ею и остаётся. Не стоит тратить на меня время, доказывая , что Земля плоская. Это — бесперспективно.
Александр, регулярность Ваших ответов таки доказывает, что во внимании Вы нуждаетесь, я же свое время трачу не только для Вас. Сколько еще таких «технарей» с окостеневшими мозгами и категоричными суждениями пошагово пишут скрипты и «измеряют» качество в багах? Наша с Вами дискуссия показательна и полезна.
Итак, разберем пару предложений.
качество сигнала
«Качество», изначально абстрактное, будучи приложено к категории «сигнал» начинает обретать некий смысл. Однако «сигнал» — это всего лишь пакет, контейнер, значение имеет информация, которую он несет. Получаем — «качество пакета информации». Это все еще абстракция — потому что сигнал не воспринят.
«Качество пакета информации для реципиента» — вот это уже становится более конкретным. Однако, контекст еще не определен.
В каких условиях передается информация? Какой способ восприятия у реципиента? В каких условиях находится реципиент? Как он(о) обрабатывает полученную информацию? Все эти вопросы и явились причиной разработки развесистого матаппарата, дабы суметь описать поведение в конкретном контексте.
К сожалению, теория оторвалась от практики, стала абстрактной. Но теоретиков
надо душитьнадо тыкать носом в контекст.Программами пользуются реальные живые люди; некачественные программы причиняют потерю денег, времени, удовольствия, репутации, а иногда — человеческой жизни.
Нам, технарям с окостеневшими мозгами смешно читать бред фрондирующей школоты, которая даже про приёмник Котельникова не слышала. Значит так оно и должно быть.
Хе-хе. А я ведь не зря писал: «не диплом, а образование».
Вот так и получается: люди, не имеющие знаний и не умеющие их получать, идут в тестирование. В результате, через пару-тройку лет левых «поделок», такой практик-самородок начинает рассуждать о качестве, даже не прочитав ISO9126.
Ох, долго ещё в России тестирование останется на уровне написания скриптов без понимания сути.
Коллеги, а вы заметили, что ушли от сути в скандирование общеизвестных истин и бессмысленную пикировку?
Таков уровень дискурса в России?
;-))
Заметили.
Alexander забанен.
Последний коммент Alexander’a насквозь троллиный. А жаль — начинал нелохо, шансы были..
Он на форуме software-testing.ru той же ерундой страдал.
Замечание принято, пара ссылок дабы повысить [и без того немалое] качество данного треда.
http://secretsofconsulting.blogspot.com/2011/01/universal-pattern-of-huge-software.html
В данной статье Джеральд Вайнберг приводит реальные примеры того, как незначительные изменения кода или даже только конфигурации могут повлечь за собой огромные потери. За примерами следуют подсказки, как подобные ситуации распознавать, и советы, как подобные сбои предотвращать.
http://secretsofconsulting.blogspot.com/2010/12/testing-without-testing.html
«The job of software testing, we know, is to provide information about the quality of a product. Many people, however, believe that the only way to get such information is to execute the software on computers, or at least review code. But such a belief is extremely limiting.» Gerald Weinberg
«Смысл тестирования как работы, известно, заключается в предоставлении информации о качестве продукта. Тем не менее, многие убеждены, что для получения данной информации необходимо выполнять программу на компьютере или, как минимум, просматривать код. Это крайне ограниченный подход».
— Читайте о мета-информации и мета-качестве.
Не соглашусь, что ноль — это «как и ожидалось». Как и ожидалось — это хорошо, это уже выше нуля. Я от большинства используемых продуктов (включая бытовую технику дома) была бы счастлива получить свое «как и ожидалось», меня бы это вполне устроило.
Какая-то ненулевая положительная планка — как и ожидалось, ниже — прогибы, в которых фичи не соответствуют ожиданиям, качество изначально какое-то есть. На приведенной картинке 17-я фича — в нуле могла бы быть.
Исправление дефекта повысит точку до «как и ожидалось», качество повысится с недостаточного до достаточного для удовлетворения заказчика или покупателя или иного решающего лица.
Странно читать, что низкое качество — это его полное отсутствие, коли уж ведется речь о каких-то количественных характеристиках.
Странно читать, что низкое качество – это его полное отсутствие, коли уж ведется речь о каких-то количественных характеристиках.
Я не говорил, что низкое качество — это его отсутствие. Я говорю про «отсутствие качества» вообще. Термин «низкое качество» так же двояк, как и «осетрина второй свежести», потому и.
Говорил я о том, что качество отсутствует вообще, если основные технические требования (которые весьма измеримы в цифрах) не достигнуты.
Если они достигнуты, то продукт безусловно качественен, безо всяких оговорок.
Проблема, указал я, в том, что под качественными продуктами человеческое восприятие подразумевает только высококачественные продукты. А формализовать человеческое восприятие в цифрах — дело пагубное и сложное. Отсюда и сложность с достижением качества с технической точки зрения.