YA
Потому что описание в стандартах ГОСТа ну какое-то такое
Size: a a a
2019 November 08
R(
Потому что описание в стандартах ГОСТа ну какое-то такое
Это ооочень интересный вопрос. Начало доклада Светланы Корневой на COMAQA Minsk 2019 было посвящено тому что единого определения нет, а есть разные.
R(
Начну с Болтона:
https://www.a1qa.com/blog/interview-with-michael-bolton-part-1/
My notion of quality comes from Jerry Weinberg: “quality is value to some person(s)” (Quality Software Management, Vol. 1: Systems Thinking; also available as two e-books, “How Software is Built” and “Why Software Gets in Trouble”). James Bach and I have added “who matters” to make explicit some of the things that Jerry presents in the book. When you think of quality as “value to some person who matters”, it should be absolutely clear that evaluating the quality of something starts with a decision about whose values matter.
Quality is always relative to some person. A product can have terrible problems in it, and yet still satisfy some people all of the time and most people most of the time. The idea of quantifying quality at all seems quite silly to me; what would it mean to have a 77% level of quality for a product? What would it mean to have a 100% level of quality? Until you can establish that, and until you can establish a scale that applies to widely differing people with widely differing sets of values, the number isn’t going to tell you anything meaningful. Numbers won’t do the trick there; you need a qualitative description.
What you can do, as a professional working in software testing outsourcing, is to identify important problems in the product that threaten its value such that the product owner (who is ultimately the person who makes decisions about quality on a project) might be unwilling to ship it. But that’s not usually a question of numbers to any serious degree. Instead, it’s a collection of qualitative criteria framed in terms of stories. Both testing and reporting problems are built on the idea of composing, editing, narrating, and justifying stories about our products. Sometimes the stories can be illustrated by numbers, but most of the time stories are about problems that would cause loss or harm or annoyance, loss of value, to somebody who matters. (See “Braiding the Stories (Test Reporting Part 2)”
https://www.a1qa.com/blog/interview-with-michael-bolton-part-1/
My notion of quality comes from Jerry Weinberg: “quality is value to some person(s)” (Quality Software Management, Vol. 1: Systems Thinking; also available as two e-books, “How Software is Built” and “Why Software Gets in Trouble”). James Bach and I have added “who matters” to make explicit some of the things that Jerry presents in the book. When you think of quality as “value to some person who matters”, it should be absolutely clear that evaluating the quality of something starts with a decision about whose values matter.
Quality is always relative to some person. A product can have terrible problems in it, and yet still satisfy some people all of the time and most people most of the time. The idea of quantifying quality at all seems quite silly to me; what would it mean to have a 77% level of quality for a product? What would it mean to have a 100% level of quality? Until you can establish that, and until you can establish a scale that applies to widely differing people with widely differing sets of values, the number isn’t going to tell you anything meaningful. Numbers won’t do the trick there; you need a qualitative description.
What you can do, as a professional working in software testing outsourcing, is to identify important problems in the product that threaten its value such that the product owner (who is ultimately the person who makes decisions about quality on a project) might be unwilling to ship it. But that’s not usually a question of numbers to any serious degree. Instead, it’s a collection of qualitative criteria framed in terms of stories. Both testing and reporting problems are built on the idea of composing, editing, narrating, and justifying stories about our products. Sometimes the stories can be illustrated by numbers, but most of the time stories are about problems that would cause loss or harm or annoyance, loss of value, to somebody who matters. (See “Braiding the Stories (Test Reporting Part 2)”
R(
Определение Вайнберга-Болтона скорее философское.
В качестве примера к нему следует тезис "представьте себе программу, которая совершенно без единого бага вычисляет гороскоп для человека который умер в 1993-м году — с одной стороны этот продукт не имеет багов, с другой он ни для кого не имеет ценности".
В качестве примера к нему следует тезис "представьте себе программу, которая совершенно без единого бага вычисляет гороскоп для человека который умер в 1993-м году — с одной стороны этот продукт не имеет багов, с другой он ни для кого не имеет ценности".
R(
Более подробные интересные рассуждения на этот счёт есть, опять же, в RST appendices:
YA
Ага
YA
Спс
R(
В дополнение приведу определение Майерса (Glenford J. Myers - The Art of Software Testing) , к которому я прибегал ранее:
That is, an error is clearly present if a program does not do what it is
supposed to do; but errors are also present if a program does what it is not
supposed to do.
Если программа НЕ делает того что она должа делать — это проблема.
Но также проблема если программа делает то что она НЕ должна делать (вешает девайс, крэшится и пр.).
Определение Баха в принципе включает определение проблем Майерса, но определение Майерса по-моему придаёт дополнительный вектор поиска проблем — "делает что она не должна делать" (забивает винт, выжирает память, вешает девайс, отправляет ваши данные куда не надо и пр.).
That is, an error is clearly present if a program does not do what it is
supposed to do; but errors are also present if a program does what it is not
supposed to do.
Если программа НЕ делает того что она должа делать — это проблема.
Но также проблема если программа делает то что она НЕ должна делать (вешает девайс, крэшится и пр.).
Определение Баха в принципе включает определение проблем Майерса, но определение Майерса по-моему придаёт дополнительный вектор поиска проблем — "делает что она не должна делать" (забивает винт, выжирает память, вешает девайс, отправляет ваши данные куда не надо и пр.).
R(
Также можно посмотреть:
https://en.wikipedia.org/wiki/List_of_system_quality_attributes
(тут их больше, некоторые включены в американские стандарты)
https://en.wikipedia.org/wiki/List_of_system_quality_attributes
(тут их больше, некоторые включены в американские стандарты)
R(
R(
(раздел Quality Criteria Categories) — там их перечислено меньше, но присутствуют некоторые описания.
S
пятница, вечер, а вы про работу
R(
пятница, вечер, а вы про работу
В кои-то веки процитирую Назину (Киселёву) : "Жизнь - это движение! А тестирование - это жизнь :)"
Мы про жизнь :)
Мы про жизнь :)
S
Ну ладно. Пятница, вечер, а вы про жизнь на трезвую
R(
Ктооооо на трезвую? Я на трезвую?!
"И снова будут совершенно неправы".
"И снова будут совершенно неправы".
DA
TIL: запрет на отправку стикеров в телеграме обрабатывается на стороне клиента
DA
R(
Пока ехал в Минск, посмотрел комедию про тестирование/испытания, и "планку бизнеса" как раз.
Вашему вниманию предлагается (я смотрел на английском, но есть русский перевод).
https://www.youtube.com/watch?v=SQJa3mOEz1k
Вашему вниманию предлагается (я смотрел на английском, но есть русский перевод).
https://www.youtube.com/watch?v=SQJa3mOEz1k
R(
Ещё раз к вопросу о том почему я считаю OTUS недобросовестными впаривателями и шарлатанами от маркетинга.
КР
Первое, с чего надо начинать любой курс о k8s - с заявления о том, что тянуть его в прод - испытывать многия скорби. Ну и рисковать всё уронить, может даже не по своей вине