Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Не увидел определения качеству. Есть «диалектические» признаки, но может я невнимательно прочел, не увидел ISO-шного качества как «уровня соответствия результата заявленным требованиям».
По моей практике, в том числе и исошной возни, которая куда-то канула и слава богу отсюда (у 1с-франчайзи может так и застряла в бытие), качество это распределение дефектов (при должном покрытии при тестировании) по критичности. Продукт признают качественным при приемке, если критичных дефектов нет, а низкокритичных мало и они устранимы в дальнейшем.
Выглядит банальщиной, но этого достаточно при наличии всевозможных тестирований. Собственно работа с качеством это не столько работа с продуктом, а работа с процессом обеспечния качества (PMBoK впитал в себя куски ISO). Вот обеспечение всестороннего тестирования (не только конечного продукта, но и промежуточных артефактов) — собственно и есть обеспечение качества в разработке ПО.
По моей практике, в том числе и исошной возни, которая куда-то канула и слава богу отсюда (у 1с-франчайзи может так и застряла в бытие), качество это распределение дефектов (при должном покрытии при тестировании) по критичности. Продукт признают качественным при приемке, если критичных дефектов нет, а низкокритичных мало и они устранимы в дальнейшем.
Выглядит банальщиной, но этого достаточно при наличии всевозможных тестирований. Собственно работа с качеством это не столько работа с продуктом, а работа с процессом обеспечния качества (PMBoK впитал в себя куски ISO). Вот обеспечение всестороннего тестирования (не только конечного продукта, но и промежуточных артефактов) — собственно и есть обеспечение качества в разработке ПО.
Спасибо за грамотный комментарий и я не вижу противоречий…
В соответствии с моим подходом, качество — это удовлетворение конечного потребителя лучше конкурентов. C учетом неполных требований, сжатых сроков и других цирков с конями.
Я выработала свою стратегию на основе многих практик, стандартов, в том числе ISO, и личного опыта. И теперь представляю ее критике (тестированию).
Все что я хочу рассказать здесь, что качество индивидуально, его можно определить в любых условиях и есть обоснования сдерживать свое личное качество.
Про контроль и обеспечение качества, как процессы, уже не в этот раз
В соответствии с моим подходом, качество — это удовлетворение конечного потребителя лучше конкурентов. C учетом неполных требований, сжатых сроков и других цирков с конями.
Я выработала свою стратегию на основе многих практик, стандартов, в том числе ISO, и личного опыта. И теперь представляю ее критике (тестированию).
Все что я хочу рассказать здесь, что качество индивидуально, его можно определить в любых условиях и есть обоснования сдерживать свое личное качество.
Про контроль и обеспечение качества, как процессы, уже не в этот раз
качество индивидуально
Да, за этот момент спасибо. Обычно такой взгляд в корпоративных практиках не присутствует, или присутствует максимум на уровне опросника «поставьте оценку качеству от 1 до 10».
Когда количество переходит в качество, ему (качеству) становится проблематично дать точную количественную оценку.
не уверена, что правильно вас поняла… а именно свойство количества переходить в качество. Я думаю, такого не бывает. Ну или уточните пожалуйста.
предполагаю, вы говорите о том, что не все можно посчитать, чтобы оценить и это действительно так.
Посчитать можно не все, удобство использования не вычисляется цифрами, но качественная норма (оценка) тоже норма. Брендбуки, гайдлайны, своды правил в области юзабити, персонализированные для бренда/ проекта/продукта, могут быть мерой между «качественно/некачественно». Инициировать их может кто-угодно, в т.ч. QA.
А вот эффективность, может исчисляться только цифрами. Никакие какчественные «быстро»-«медленно» тут неприемлемы. Сколько тестировщиков ломали голову над такими багами «Эта функция работала слишком медленно, мы пофиксили» — как было, как стало, никто не знает. Что-то сделали, проверьте.
предполагаю, вы говорите о том, что не все можно посчитать, чтобы оценить и это действительно так.
Посчитать можно не все, удобство использования не вычисляется цифрами, но качественная норма (оценка) тоже норма. Брендбуки, гайдлайны, своды правил в области юзабити, персонализированные для бренда/ проекта/продукта, могут быть мерой между «качественно/некачественно». Инициировать их может кто-угодно, в т.ч. QA.
А вот эффективность, может исчисляться только цифрами. Никакие какчественные «быстро»-«медленно» тут неприемлемы. Сколько тестировщиков ломали голову над такими багами «Эта функция работала слишком медленно, мы пофиксили» — как было, как стало, никто не знает. Что-то сделали, проверьте.
С Демингом, вы, конечно, загнули. Он не работал непосредственно на заводах Тойоты, тем более в 80 годах (https://deming.org/deming-the-man/timeline). Термины «ублажение потребителя», боюсь, тоже не из его репертуара
Ублажение потребителя — это емкое словосочетание, которое в его риторике действительно не фигурирует. Но его 14 принципов направлены именно на это. В долгосрочной перспективе вы сэкономите время и сделаете ваш продукт более успешным, если научитесь слышать своего «потребителя» (внутреннего и конечного). И сильно облегчите себе жизнь, если научите этому своего «поставщика».
В статье я хочу рассказать не о Деминге, хотя не скрою, его книга «Выход из кризиса. Новая парадигма управления людьми, системами и процессами», сильно утвердила лично мои взгляды. Я хочу сказать, что «качество» начинается с определения своего потребителя и понимания, что именно вы ему даете и каким образом. Поставщика, что хотите от него получать, в каком виде.
Я отвечаю за тестирование, поэтому пример про тестирование. Что производят ручные тестировщики? На низком уровне, для внутренних потребителей они не производят ничего, кроме отчетов (о дефектах, о состоянии релиза, о рисках). Очевидно, эти отчеты, должны быть понятными, достоверными и своевременными. Для кого? Для разработчиков, руководителей проекта, саппорта. А если нет? В лучшем случае они будут приходить за уточнением и тем самым тратить время (и ваше и свое), которое могли бы не тратить. В худшем принимать неправильные решения, которые негативно повлияют на конечно потребителя.
Конечному потребителю нужен хороший продукт. Основная сложность в том, чтобы понять, что именно он идентифицирует, как «хороший». Декомпозировать такую крупную задачу мне помог стандарт ISO.
ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.
В статье я хочу рассказать не о Деминге, хотя не скрою, его книга «Выход из кризиса. Новая парадигма управления людьми, системами и процессами», сильно утвердила лично мои взгляды. Я хочу сказать, что «качество» начинается с определения своего потребителя и понимания, что именно вы ему даете и каким образом. Поставщика, что хотите от него получать, в каком виде.
Я отвечаю за тестирование, поэтому пример про тестирование. Что производят ручные тестировщики? На низком уровне, для внутренних потребителей они не производят ничего, кроме отчетов (о дефектах, о состоянии релиза, о рисках). Очевидно, эти отчеты, должны быть понятными, достоверными и своевременными. Для кого? Для разработчиков, руководителей проекта, саппорта. А если нет? В лучшем случае они будут приходить за уточнением и тем самым тратить время (и ваше и свое), которое могли бы не тратить. В худшем принимать неправильные решения, которые негативно повлияют на конечно потребителя.
Конечному потребителю нужен хороший продукт. Основная сложность в том, чтобы понять, что именно он идентифицирует, как «хороший». Декомпозировать такую крупную задачу мне помог стандарт ISO.
Он не работал непосредственно на заводах Тойоты, тем более в 80 годах
ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.
Он не работал непосредственно на заводах Тойоты, тем более в 80 годах
ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.
в соответствии со статьей от центра сертификации и лицензирования прорыв заводов Toyota был назван Японским чудом и случилось оно на основе трудов Деминга.
в соответствии со статьей от ассоциации Деминга император Хирохито вручил ученому «Орден священного сокровища второй степени» в 1960г. Полагаю этот год можно считать официальным признанием его работы.
Итак, с годом, вы правы, я борщенула. Сбил с толку год публикации книги, нужно было проверить.
Про качество хорошо написано в статье google https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html?m=1
Качество определяется метриками проекта. А влиять на него при росте проекта нужно путем автоматизации процессов релизного цикла.
При этом не стоит выкидывать из процесса общение с заказчиком, потому что проблемы в этой области так же влияют на результат. Неправильно проработанные требования, например.
Статья очень похожа на краткое изложение книги «Как тестируют в Google». Я даже удивлена что там нет прямой ссылки. Очень рекомендую ее к прочтению, там куда больше занимательного. Тем более, что книга уже несколько лет выпускается в русском переводе.
И все таки, она не про качество, а про процессы контроля и обеспечения качества. Попробую объяснить разницу
метрики сами по себе не определяются, их должен кто-то определить. Кто? Допустим вы QA и взяли на себя эту задачу. Как это сделать, чтобы не строить башню из слоновой кости и не занизить планку? Структурировать эту задачу и определить для каждого пункта границы между «качественно» и «некачетсвенно». Как? Попыталась описать в своей статье.
А процессы… Они же не перенимаются по шаблону, их выстраивают на основе многих условий, первые из которых Ваш потребитель и Ваш продукт. Тему процессов попробую раскрыть в следующей статье.
И все таки, она не про качество, а про процессы контроля и обеспечения качества. Попробую объяснить разницу
Качество определяется метриками проекта. А влиять на него при росте проекта нужно путем автоматизации процессов релизного цикла.
метрики сами по себе не определяются, их должен кто-то определить. Кто? Допустим вы QA и взяли на себя эту задачу. Как это сделать, чтобы не строить башню из слоновой кости и не занизить планку? Структурировать эту задачу и определить для каждого пункта границы между «качественно» и «некачетсвенно». Как? Попыталась описать в своей статье.
А процессы… Они же не перенимаются по шаблону, их выстраивают на основе многих условий, первые из которых Ваш потребитель и Ваш продукт. Тему процессов попробую раскрыть в следующей статье.
есть прекрасная книга «дзен или искусство ухода за мотоциклом». там тоже все началось с вопроса что такое «качество»)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Качество, что за зверь и как его обнаружить