'

Взгляд на QA чужими глазами. QA from not QA’s perspective

Понравилась презентация – покажи это...





Слайд 0

Взгляд на QA чужими глазами. QA from not QA’s perspective Моя личная точка зрения или доклад тролля... Калугин Александр, Ph.D, PMP Mercury Development, LLC alex.kalouguine@gmail.com


Слайд 1

2 QA about QA Мы можем делать не Quality Assurance, а только Quality Control Не только мы отвечаем за качество Программ без багов не бывает. «Телепаты в отпуске» Нас спрашивают слишком поздно...


Слайд 2

3 QA about QA Requirements Artifacts (Software Product) QC Defects Recommendations


Слайд 3

Идеальный тестировщик Может проанализировать спецификацию Переводит спецификацию в тестовый сценарий (т.е. документ, полностью подчиненный спецификации) Умеет быстро и надежно воспроизводить баги по описанию и корректно описывать условия воспроизведения. Умеет оптимизировать собственный труд, вырабатывая автоматизированные процедуры. и т.д. формализм 4


Слайд 4

К чему приводит (проблема) Смещение фокуса – основной упор делается оптимизации процессов контроля качества (автоматизированные тесты, нагрузочные тесты, скрипты, и т.д.) Выработка дополнительный процедур, суть которых – тот же контроль качества. Контроль качества работы «кодеров» Отчетность «в багах»... 5


Слайд 5

Возможные причины Раз все баги не перефиксить – пусть лучше о них мы будем меньше знать. В конце концов значение имеют баги, которые найдет заказчик, а не мы. Тестирование -- «отрицательная» деятельность, которая лишь направлена на выявление недостатков – если хорошо разрабатывать – QC не нужны. Чтобы оправдать затраты – деятельность QC должна быть измерима и не вызывать сомнений, что делается «какая-то фигня». 6


Слайд 6

«Фатальные» проблемы качества: Не нравится заказчику – Ну не нравится и всё тут! Несоответствие продукта – бизнес-цели – не приносит денег Несоответствие продукта ожиданиям конечных пользователей – неудобно пользоваться Сложность освоения – сразу непонятно, как пользоваться, непохоже на остальное. Не вписывается в toolset – продукт – сам по себе, не связан с OS или другими продуктами. Продукт стабилен только в рамках определенных сценариев использования, шаг влево-вправо – «Тормозит и валится». Продукт тяжело расширять или добавлять новые фичи 7


Слайд 7

«Фатальные» проблемы качества: Не являются следствием недостатков процесса разработки или неследования этому процессу. Не являются ошибками кодеров. Практически невозможно выявить в процессе формальной проверки соответствия продукта функциональным требованиям. Очень сложно выявить в рамках формализованных процессов и процедур. 8


Слайд 8

Задачи-максимум QA (моя мечта ?) Обеспечить беспроблемную приемку проекта заказчику. Гарантировать успешность продукта Гарантировать удобство и интуитивность пользования продуктом, его стабильность, производительность и расширяемость Минимизировать затраты на процессы QC и разработку Минимизировать риски проекта. 9


Слайд 9

Задачи-максимум QA (моя мечта ?) 10


Слайд 10

11 Может быть как-нибудь можно? Requirements Artifacts (Software Product) QC Risk Inventory Architectural Patterns Historical Records OS Guidelines Competitive Products Business Goals Constraints and Priorities


Слайд 11

12 Может быть как-нибудь можно? Requirements Defects QC Risk Inventory Historical Records Usability Analysis Architecture Analysis


Слайд 12

Может быть как-нибудь можно? Участие на всех стадиях включая Pre-sale Взаимодействие со всеми ролями в проекте Вовлеченность и ответственность за результат Смена приоритетов 13


Слайд 13

14 Типа усё... Калугин Александр, Ph.D, PMP Mercury Development, LLC alex.kalouguine@gmail.com


×

HTML:





Ссылка: