PPTX, PDF67 views

Can we have some more quality - Russian version

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

Technology◦

Can we have some more quality - Russian version

1.
Can we havesome more... Quality? A. Pushkarev 2016
2.
Trailer
3.
Обычный проект
4.
Куча багов впроде БЛДЖАД!!!!11
5.
Нужно больше качества!!!11
6.
Давайте познакомимся
7.
Кто я? Alex Pushkarev •~ 10 лет в IT • Разработчик [в тестировании] • Java, .Net, Python • "Context driven" школа тестирования (open certification hater) http://aqaguy.blogspot.com https://www.linkedin.com/in/alexpushkarev/ https://twitter.com/aqaguy
8.
Часть 1. Качество.
9.
Что такое Качество •Баги [Много/Мало] • Параметры производительности • Функционал [Много/Мало] • Функционал vs. ЦА • Удобство использования • Документация [Много/Мало]
10.
Мысленный эксперимент Продукт содержиттолько 10 минорных багов (опечаток) Является ли качество продукта приемлимым? • Пользовательская документация отсутствует • Средняя задержка реакции на действия пользователя ~ 2 секунды
11.
Мысленный эксперимент Продукт содержиттолько 1 багов, который приводит к "падению" приложения. Вероятность встретить баг ~1% Является ли качество продукта приемлимым? • Клиент для новой online игры • Автопилот Airbus 320
12.
Мысленный эксперимент VS
13.
Цена качества Сколько этобаг весит в граммах стоит в деньгах? [ROI] • Оправда (экономически) но ли фиксировать этот баг в Jira? • Оправдано (экономически) ли обращать на него внимание? • Оправдано (экономически) ли фиксить этот баг?
14.
Качество Качество === Fitfor purpose
15.
Больше качества? Знай свое[целевое] качество
16.
Приемлимый уровень качества Shippable/Acceptablequality. Уровень качества (уверенности в качестве), достаточный для того, чтобы принять решение о релизе.
17.
Часть 2. Тестирование.
18.
Тестирование. Кто отвечает закачество на проекте?
19.
Нужно больше качества!!!11
20.
Нужно лучше тестить!
21.
Лучше тестить!!!!!1
22.
[все еще] Кучабагов в проде БЛДЖАД!!!!11
23.
Чето вы долготестируете
24.
[все еще] Кучабагов в проде БЛДЖАД!!!!11
25.
Даешь качество!
26.
Тестирование, что это? QA!= QC != Testing • Тестирование не контролирует качество (контролировать - значит иметь возможность изменить) • Тестирование - это эмпирический сбор информации о продукте • Тестирование не обеспечивает качество
27.
Качество, при оценкеконечного продукта Module Bug Investigation and Reporting (time spent on tests that find bugs) Test Design and Execution (time spent on tests that don’t find bugs) Total Tests A 0 minutes (no bugs found) 90 minutes (45 tests) 45 B 10 minutes (1 test, 1 bug) 80 minutes (40 tests) 41 C 80 minutes (8 tests, 8 bugs) 10 minutes (5 tests) 13 http://www.developsense.com/blog/2009/11/why-is- testing-taking-so-long-part-1/
28.
Качество, при оценкеконечного продукта http://www.developsense.com/blog/2009/11/why-is- testing-taking-so-long-part-1/ "Lots of bugs means reduced coverage, or slower testing, or both." "Finding bugs today means verifying fixes later, which means even less coverage or even slower testing, or both."
29.
Качество, при оценкеконечного продукта
30.
Качество, при оценкепроцесса
31.
14 Deming points 1.Adoptthe new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change. 2.Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
32.
Производственная система Тойота "Theright process will produce the right results"
33.
Производственная система Тойота "Theright process will produce the right results" ...Build a culture of stopping to fix problems, to get quality right from the first...
34.
Где взять большекачества? Качество создается на этапе разработки
35.
Элементы разработки, влияющиена качество
36.
Правильная пирамида тестирования ручные Тормознутые Медленные Тесты А.Солнцев, Эффективный процесс тестирования
37.
Качество, при оценкеконечного продукта Module Bug Investigation and Reporting (time spent on tests that find bugs) Test Design and Execution (time spent on tests that don’t find bugs) Total Tests A 0 minutes (no bugs found) 90 minutes (45 tests) 45 B 10 minutes (1 test, 1 bug) 80 minutes (40 tests) 41 C 80 minutes (8 tests, 8 bugs) 10 minutes (5 tests) 13 http://www.developsense.com/blog/2009/11/why-is- testing-taking-so-long-part-1/
38.
Производственная система Тойота "Theright process will produce the right results" ...Build a culture of stopping to fix problems, to get quality right from the first...
39.
Чето вы долготестируете
40.
Чето вы долготестируете
41.
Мифы о тестирующихдевелоперах "Девелоперы не умеют тестировать" При должном коучинге разработчике вполне способны справится с acceptance story и регрессионным тестированием. А с написанием unit тестов и подавно "Нельзя тестировать свой код" Может быть. Предложите разработчику тестировать код товарища. А через 6 месяцев и свой код уже не свой "Я девелопер, мое дело писать код!" Ты - девелопер, твое дело создавать рабочий продукт. Код не в продакшне - это не рабочий продукт.
42.
А где жетут тестеры? All That Testing is Getting in the Way of Quality, StarWest 2011 Why software is better? • Automatic updates/cloud deployment • Crash recovery • Reduction of dependencies through standards • Continuous build/integration/release/test • Initial code quality • Convergence of the user and test community
43.
А где жетут тестеры? GTAC 2011 Opening Keynote "Test is dead" • The key takeaway was test is dead as a phase. • Testing has to occur, but where and when it occurs has changed.
44.
Причины для беспокойства •Тестировщики больше не монополисты тестирования • [Относительное] Качество улучшилось не благодоря не только благодаря тестированию • Есть другие способы выявить риски, которые обычно выявлялись с помощью тестирования. • Есть много компаний, в которых нет тестировщиков, но которые почему-то не разоряются и деливерят классный, востребованный софт
45.
Элементы разработки, влияющиена качество
46.
Тестировщики не нужны?
47.
Тестировщики должны изменится, вчера •Индустрия меняется, но тестирование "lags behind" …."Test is dead, let us kill test zombies..."
48.
Должен ли тестировщикуметь кодить?
49.
Должен ли тестировщикуметь кодить? Возможно тестировщик и не обязан уметь кодить, но это точно не повредит Может автоматизировать тесты (включая unit) Может фокусировать тесты, основываясь на реальных изменениях, а не методиках тестирования 30-ти летней давности Может помочь девелоперам, если они зашиваются "Ты - девелопер [scrum признает лишь одну роль], твое дело создавать рабочий продукт. Тесты - это не рабочий продукт."
50.
Agile testing manifesto
51.
[Scrum] команда -это Командос
52.
Подведем итоги • Качество- это многомерная величина • Не всегда нужно "больше" качества • Тестировщики не владеют качеством • Контроль результатов процеса [чаще всего] менее эффективен контроля самого процесса • Мы должны изменится

Editor's Notes

#4 Представим обычный, сферический в вакууме проект. У нас есть какая-то (к примеру, скрам) команда. Девелоперы делают свою работу, Тестеры - свою, менеджеры - менеджат, занимаются qpf и pdp. Стори закрываются, тесты зеленые, все при деле и счастливы. Ну и тут Внезапно!!!
#5 Мы задеплоили что-то в прод, и там вылез один критичный баг, или много мажорных багов. Были эскалации, раздачи люлей, поиски виноватых и куча митингов.
#6 И следующее, что может произойти, это появится вот такой вот злобный чел, и скажет нам, что на проекте есть проблемы с качеством, и надо их решать
#10 Качество это сложное понятие, которое включает, в том числе, и примеры, представленные на слайде. Можно придумать еще много характеристик, так или иначе относящиеся к качеству продукта. Самое главное, что ни один из критериев, сам по себе и вне контекста не является достаточным для того, чтобы оценить качество продукта Давайте попробуем такой мысленный эксперимент
#11 Какой из представленных продуктов является качественным? (суждение на одном факторе)
#12 Какой из представленных продуктов является качественным? (суждение вне контекста)
#13 Какой из представленных продуктов является качественным? С моей точки зрения, оба продукта обладают примерно одинаковым качеством (если под качеством понимать fit for purpose) В зависимости от ЦА понятие качество может координально менятся, к примеру в офисе у нас две кофеварки. В одной, если открыть отсек для кофейных зерен двигатель зернодробилки автоматически выключается, а у другой нет. Это достаточно филосовский вопрос, в какой из них баг. С точки зрения баристо, возможность начать молотить зерно до того, как закрыта крышка это дополнительные несколько секунд форы, которые важны в случае аншлага в кофейни. С моей точки зрения, с точки зрения отца двоих детей, я уже представляю кофе из детских пальчиков. Качество не только многомерно, но и субъективно.
#14 Качество не является бесплатным. Мы часто агитируем за более высокое качество, но является ли это экономически оправданым?
#15 Если попробовать выразить, что я считаю качеством, я бы сказал, что качество это Fit for purpose. Или еще говорят Value Т.е. насколько продукт отвечает возложеным на него ожиданиям, своему предназначению. (к примеру, в советских инструкциях часто можно прочитать "товар преднозначен для" Предназначения могут быть: Повысить долю компании на рынке Поддерживать человеческую жизнь с помощью регулировки сердцебиения (кардиостимулятор) Если продукт соответствует своему предназначению, значит с качеством все в порядке. Например
#16 Если попробовать выразить, что я считаю качеством, я бы сказал, что качество это Fit for purpose. Или еще говорят Value Т.е. насколько продукт отвечает возложеным на него ожиданиям, своему предназначению. (к примеру, в советских инструкциях часто можно прочитать "товар преднозначен для" Предназначения могут быть: Повысить долю компании на рынке Поддерживать человеческую жизнь с помощью регулировки сердцебиения (кардиостимулятор) Если продукт соответствует своему предназначению, значит с качеством все в порядке. Например
#17 Давайте поговорим, что такое тестирование. В данной презентации я буду придерживаться имено этого определения тестирования. Ни для кого не секрет, что есть некая путаница между QA, QC, Testing. Вопрос залу - "кто отвечает за качество на проекте"? Тестирование не обеспечивает качество, не контроллирует его, а обеспечиват "посмертное" вскрытие. И зачастую, люди с должностью "тестировщик" занимаются имено этим. Они "вступают" в игру в самом конце, может даже в последний день итерации, и гоняют продукт в хвост и гриву, с тест кейсами или без. А потом делают такой репортик с кучей "пассед" и "фейлед". Я конечно надеюсь что все мы делаем еще кое-что из области качества кроме этого, но львиную долю нашей работы составляет имено такая.
#20 И следующее, что может произойти, это появится вот такой вот злобный чел, и скажет нам, что на проекте есть проблемы с качеством, и надо их решать
#22 В последний день спринта, тот "кто отвечает за качество" сидит до поздна и гарантирует это качество,
#23 И что происходит - много багов в продакшне. Кто надо получил своих люлей. "Ты мол плохо тестишь"
#24 И что происходит - много багов в продакшне. Кто надо получил своих люлей. "Ты мол плохо тестишь"
#25 И что происходит - много багов в продакшне. Кто надо получил своих люлей. "Ты мол плохо тестишь"
#26 Ну или, начинает нервничать. И нифига это не помогает конечно. Не надо этого делать. Встает вопрос, а что надо.
#27 Давайте поговорим, что такое тестирование. В данной презентации я буду придерживаться имено этого определения тестирования. Ни для кого не секрет, что есть некая путаница между QA, QC, Testing. Вопрос залу - "кто отвечает за качество на проекте"? Тестирование не обеспечивает качество, не контроллирует его, а обеспечиват "посмертное" вскрытие. И зачастую, люди с должностью "тестировщик" занимаются имено этим. Они "вступают" в игру в самом конце, может даже в последний день итерации, и гоняют продукт в хвост и гриву, с тест кейсами или без. А потом делают такой репортик с кучей "пассед" и "фейлед". Я конечно надеюсь что все мы делаем еще кое-что из области качества кроме этого, но львиную долю нашей работы составляет имено такая.
#28 The morning session is taken up with Module A, from Development Team A. These people are amazing, hyper-competent. They use test-first programming, and test-driven design. They work closely with us, the testers, to design challenging unit checks, scriptable interfaces, and log files. They use pair programming, and they review and critique each other’s work in an egoless way. They refactor mercilessly, and run suites of automated checks before checking in code. They brush their teeth and floss after every meal; they’re wonderful. We test their work diligently, but it’s really a formality because they’ve been testing and we’ve been helping them test all along. In our 90-minute testing session, we don’t find any problems. That means that we’ve performed 45 micro-sessions, and have therefore obtained 45 units of test coverage. The first thing after lunch, we have a look at Team B’s module. These people are very diligent indeed. Most organizations would be delighted to have them on board. Like Team A, they use test-first programming and TDD, they review carefully, they pair, and they collaborate with testers. But they’re human. When we test their stuff, we find a bug very occasionally; let’s say once per session. The test that finds the bug takes two minutes; investigation and reporting of it takes a further eight minutes. That’s ten minutes altogether. The rest of the time, we don’t find any problems, so that leaves us 80 minutes in which we can run 40 tests. Let’s compare that with this morning’s results. After the afternoon coffee break, we move on to Team C’s module. Frankly, it’s a mess. Team C is made up of nice people with the best of intentions, but sadly they’re not very capable. They don’t work with us at all, and they don’t test their stuff on their own, either. There’s no pairing, no review, in Team C. To Team C, if it compiles, it’s ready for the testers. The module is a dog’s breakfast, and we find bugs practically everywhere. Let’s say we find eight in our 90-minute session. Each test that finds a problem costs us 10 minutes, so we spent 80 minutes on those eight bugs. Every now and again, we happen to run a test that doesn’t find a problem. (Hey, even dBase IV occasionally did something right.) Our results for the day now look like this:
#29 After the afternoon coffee break, we move on to Team C’s module. Frankly, it’s a mess. Team C is made up of nice people with the best of intentions, but sadly they’re not very capable. They don’t work with us at all, and they don’t test their stuff on their own, either. There’s no pairing, no review, in Team C. To Team C, if it compiles, it’s ready for the testers. The module is a dog’s breakfast, and we find bugs practically everywhere. Let’s say we find eight in our 90-minute session. Each test that finds a problem costs us 10 minutes, so we spent 80 minutes on those eight bugs. Every now and again, we happen to run a test that doesn’t find a problem. (Hey, even dBase IV occasionally did something right.) Our results for the day now look like this:
#30 Тестирование законченого продутка и в фичи, это как пытаться из готового автомобиля, который и должен был быть тойотой пытаться собрать, задокументировать и сделать все импрувменты, чтоб из жигуля сделать тойоту. Поздно батюшка пить боржоми!
#31 И вот, никому неизвестная компания Тойота, в середине 20 века столкнулась с проблемой качества. В это время в США, в детройте, был дядька Дэминг, который придумал цикл Дэминга (Plan Do Check Act), который предложил идею управление качеством через управление процессом производства. Наверняка вы слышали про Канбан и Lean. Главным инструментом обеспечения качества на Тойоте является обеспечение качества всего процесса. Делать, к примеру, автомобиль, качественным, после того, как он собран дорого. Это waste. Зато контроллировать качество на протяжении всего цикла разработки и дешево, и, ВНЕЗАПНО, обеспечивает высокий результат качества конечного продукта (Кто сказал unit-тесты?)
#32 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли
#33 Качество создается не тестированием, а правильном процессом разработки
#34 Качество создается не тестированием, а правильном процессом разработки
#35 Качество создается не тестированием, а правильном процессом разработки
#36 Код ревью Парное программирование TDD/ATDD
#37 Качество создается не тестированием, а правильном процессом разработки
#38 The morning session is taken up with Module A, from Development Team A. These people are amazing, hyper-competent. They use test-first programming, and test-driven design. They work closely with us, the testers, to design challenging unit checks, scriptable interfaces, and log files. They use pair programming, and they review and critique each other’s work in an egoless way. They refactor mercilessly, and run suites of automated checks before checking in code. They brush their teeth and floss after every meal; they’re wonderful. We test their work diligently, but it’s really a formality because they’ve been testing and we’ve been helping them test all along. In our 90-minute testing session, we don’t find any problems. That means that we’ve performed 45 micro-sessions, and have therefore obtained 45 units of test coverage. The first thing after lunch, we have a look at Team B’s module. These people are very diligent indeed. Most organizations would be delighted to have them on board. Like Team A, they use test-first programming and TDD, they review carefully, they pair, and they collaborate with testers. But they’re human. When we test their stuff, we find a bug very occasionally; let’s say once per session. The test that finds the bug takes two minutes; investigation and reporting of it takes a further eight minutes. That’s ten minutes altogether. The rest of the time, we don’t find any problems, so that leaves us 80 minutes in which we can run 40 tests. Let’s compare that with this morning’s results. After the afternoon coffee break, we move on to Team C’s module. Frankly, it’s a mess. Team C is made up of nice people with the best of intentions, but sadly they’re not very capable. They don’t work with us at all, and they don’t test their stuff on their own, either. There’s no pairing, no review, in Team C. To Team C, if it compiles, it’s ready for the testers. The module is a dog’s breakfast, and we find bugs practically everywhere. Let’s say we find eight in our 90-minute session. Each test that finds a problem costs us 10 minutes, so we spent 80 minutes on those eight bugs. Every now and again, we happen to run a test that doesn’t find a problem. (Hey, even dBase IV occasionally did something right.) Our results for the day now look like this:
#39 Качество создается не тестированием, а правильном процессом разработки
#40 Давайте посмотрим еще раз на слайд. Что здесь не так? Вэлью не добавлено, У нас есть куча дуболомов с тайтлом дев, на одну дев стори, тест команда зашивается, на выходе результат ноль. Что делать в такой ситуации? Может помочь тест команде? "Тестирование дело не пацанское" да? Или еще "Девелоперы не умеют тестить..."
#41 Давайте посмотрим еще раз на слайд. Что здесь не так? Вэлью не добавлено, У нас есть куча дуболомов с тайтлом дев, на одну дев стори, тест команда зашивается, на выходе результат ноль. Что делать в такой ситуации? Может помочь тест команде? "Тестирование дело не пацанское" да? Или еще "Девелоперы не умеют тестить..."
#42 И вот, никому неизвестная компания Тойота, в середине 20 века столкнулась с проблемой качества. В это время в США, в детройте, был дядька Дэминг, который придумал цикл Дэминга (Plan Do Check Act), который предложил идею управление качеством через управление процессом производства. Наверняка вы слышали про Канбан и Lean. Главным инструментом обеспечения качества на Тойоте является обеспечение качества всего процесса. Делать, к примеру, автомобиль, качественным, после того, как он собран дорого. Это waste. Зато контроллировать качество на протяжении всего цикла разработки и дешево, и, ВНЕЗАПНО, обеспечивает высокий результат качества конечного продукта (Кто сказал unit-тесты?)
#43 Во многом, воспринимаемое качество софта вырасло не потому что его больше тестят, а потому что снизилась цена бага, и снизились технологические предпосылки для возникновения багов. Тестеры потеряли свое первенство в борьбе за качество. Для того, что бы быть ценными нам пора менятся!
#44 И вот, никому неизвестная компания Тойота, в середине 20 века столкнулась с проблемой качества. В это время в США, в детройте, был дядька Дэминг, который придумал цикл Дэминга (Plan Do Check Act), который предложил идею управление качеством через управление процессом производства. Наверняка вы слышали про Канбан и Lean. Главным инструментом обеспечения качества на Тойоте является обеспечение качества всего процесса. Делать, к примеру, автомобиль, качественным, после того, как он собран дорого. Это waste. Зато контроллировать качество на протяжении всего цикла разработки и дешево, и, ВНЕЗАПНО, обеспечивает высокий результат качества конечного продукта (Кто сказал unit-тесты?)
#45 И вот, никому неизвестная компания Тойота, в середине 20 века столкнулась с проблемой качества. В это время в США, в детройте, был дядька Дэминг, который придумал цикл Дэминга (Plan Do Check Act), который предложил идею управление качеством через управление процессом производства. Наверняка вы слышали про Канбан и Lean. Главным инструментом обеспечения качества на Тойоте является обеспечение качества всего процесса. Делать, к примеру, автомобиль, качественным, после того, как он собран дорого. Это waste. Зато контроллировать качество на протяжении всего цикла разработки и дешево, и, ВНЕЗАПНО, обеспечивает высокий результат качества конечного продукта (Кто сказал unit-тесты?)
#46 Код ревью Парное программирование TDD/ATDD
#47 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли
#48 И вот, никому неизвестная компания Тойота, в середине 20 века столкнулась с проблемой качества. В это время в США, в детройте, был дядька Дэминг, который придумал цикл Дэминга (Plan Do Check Act), который предложил идею управление качеством через управление процессом производства. Наверняка вы слышали про Канбан и Lean. Главным инструментом обеспечения качества на Тойоте является обеспечение качества всего процесса. Делать, к примеру, автомобиль, качественным, после того, как он собран дорого. Это waste. Зато контроллировать качество на протяжении всего цикла разработки и дешево, и, ВНЕЗАПНО, обеспечивает высокий результат качества конечного продукта (Кто сказал unit-тесты?)
#49 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли
#50 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли
#51 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли
#52 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли
#53 Тестировщикам необходимо изменится. Создается впечатление, что мы "внедрили" agile, а "обновить" тестирование забыли

Can we have some more quality - Russian version

More Related Content

What's hot

Similar to Can we have some more quality - Russian version

Can we have some more quality - Russian version

Editor's Notes