Qualitative battle for the quantity final
•Transferir como PPTX, PDF•
0 gostou•1,164 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Roman Ivliev
Mais de Roman Ivliev (15)
Qualitative battle for the quantity final
- 1. Качественная борьба за количество Роман Ивлиев
- 2. О чем это я... Качество и риски Поля для деятельности Что делать?
- 4. Качество и риски Финансовые риски
- 5. Качество и риски Финансовые риски Временные риски
- 6. Качество и риски Финансовые риски Временные риски Функциональные риски
- 8. Что там было про количество?
- 9. Два типа функционала Тот, что обязательно тестируем
- 10. Два типа функционала Тот, что обязательно тестируем Если хватит сил и времени
- 11. Цель Уменьшить количество затрат на тестирование Увеличить качество продукта
- 12. Поле для деятельности-1 Функционал
- 13. Поле для деятельности-1 Функционал Устойчивость
- 14. Поле для деятельности-1 Функционал Устойчивость Производительность
- 15. Поле для деятельности-1 Функционал Устойчивость Производительность Удобство использования
- 16. Поле для деятельности-1 Функционал Устойчивость Производительность Удобство использования
- 17. Поле для деятельности-1 Функционал Устойчивость Производительность Удобство использования Работа с данными
- 18. Поле для деятельности-1 Функционал Устойчивость Производительность Удобство использования Работа с данными Взаимодействие со смежными системами
- 19. Что делать?
- 21. Уменьшить количество Как? Расставить приоритеты Сопоставить время рискам Сопоставить ресурсы рискам Сопоставить финансы рискам
- 22. Прикинуть приоритетность Комплексные приоритеты Серьезность Приоритет Вероятность
- 23. Смотреть вглубь в вширь Маленькие проекты Побольше Совсем большие
- 24. Эмпирический метод Собрали в кучу функуионал; Прикинули для ниго ситуации; Поставили приоритет; Сопоставили с рисками; Обсудили список с остальными; Отсортировали по убыванию.
- 25. ISO 9126 Функционал? Надежность? Юзабилити? Эффективность? Производительность? Удобство поддержки?
- 26. FMEA Failure Mode and Effects Analysis метод анализа видов ошибок и их влияния
- 27. Каждому свое «Слова вы услышали; поиск пути за вами» Уильямс Деминг
- 28. Спасибо за внимание! Я: Роман Ивлиев E-почта:Roman.ivliev@mail.ru ICQ UIN: 73034738 Skype: roman.ivliyev LJ: http://dumtest.livejournal.com
Notas do Editor
- Представим обычную для наших дней ситуацию. Проект. Бюджет. Все как обычно. Надо строить систему тестирования. Будем честны перед собой. В современных условиях рынка, когда гонка за клиентом достигла небывалых высот, тестировнию уделяется время, но, как обычно совсем не то, которое хочется. Я бы не был столь категоричен, если бы практически все современные вендоры программного обеспечения через пару месяцев после выпуска продукта на рынок, не шлепали пакет заплаток. Кто-то не скромничает и называет Critical Fix, кто-то Service Pack, кто-то пряча глаза в пол: Update. Не мне вам рассказывать, что проверить все практически не реально, а в условиях бюджетирования и сжатости сроков – это к сожалению факт. Куда вкладывать силы, бюджет, какой части системы уделить наибольшее внимание? Об этом и хотелось бы поговорить.Я не специалист в части оценки рисков, так как это написано в умных книжках, поэому более приземленно.Итак наша задача, минимальными средствами получить максимальное качество для наибольшего количества «частей» продукта.
- Уже страшно? На самом деле эти слова я я сюда прикрутил осознанно, т.к. именно они являются причиной всех бед. Никто не знает что это, не умеет пользоваться, но все хотят снизить риски и увеличить качество:)Программисты и прочия айтишная братия сейчас являются прямыми рабами бизнеса. Меркетологи решают, какие фичи нужны клиенту, финансисты заранее планируют полученную то продажи софта прибыль, менеджеры не имеют права голоса. Им только остается попинывать рабов, чтобы дело шло. Поглядим на два случая:Если есть требования и система им польностью или с допустимым отклонением соответствует – отлично. У нас качественная система. Но, ситуация когда требования есть, они строго формализованы, проанализированы, если хотите протестированы – большая редкость. В общем ситуация с наличием таких требований – мечта любого члена команды, от тестера до менеджера. Как показывает практика, в случае с формализованными требованиями обычно система выходит практически стабильная. За примером ходить далеко не надо: авиаиндустрия. Время, которое там выделяется на разработку требований, тестирование и анализ оных, на тестирование и обкатку софта – мечта тестера. Пока самый последний баг не описан, изучен и исправлен (есть конечно исключения) – фиг вам, а не деплой на борт.Если требования к системе есть, но их состав оставляет желать лучшего - А вот таких случаев большинство. Современная гонка софта приводит к тому, что конторы более охотно, а главное с высоким приоритетом, шлепают новый функционал, при этом баги новые – по возможности чинятся, баги с предыдущих версий – опционально. Гонка привела к тому, что выход т.н. критикалфикса к предыдущей версии часто осуществляется после выхода следующей. Этим грешат многие производители «сезонного» софта. Антивири, браузеры, офисные приложения. Сколько раз в месяц к винде выходят заплатки? Не сосчитать. Сколько ваш любимый антивирь качает апдейтов? Много, причем это далеко не всегда вирусные базы Как же тут быть? А вот как.Безусловно, в такой ситуации определить степень качественности продукта сложнее. В принципе, если продукт получился пригодным для использования, если его покупают, устанавливают и пользуются – можно сказать, что качество приемлемое. Можно ещё так: если количество довольных пользователей при использовании продукта больше, чем недовольных. Это не обобщенное утверждение. Если системой автопилотирования после использования будут недовольны духи пилотов, то о каком качестве может идти речь
- Где могут возникнуть проблемы?1) Финансовые – их все боятсяА будет ли прибыль черт её побери Или енежки уйдут туда, где висят такие картинки?
- Тут скорее в ход идет репутация и престиж компании. Современный рынок строго следит за тем, чтобы анонсы выходя софта совпадали с реалиями. Иначе журналюги очень быстро все раскапывают и сами знаете что Впишется ли в установленные временные рамки, на каком этапе будут проблемы со временем и т.д. Ах если бы я мог остановить время....
- Это скорее внутренняя кухня, но все же аффектит товар на рынке, его карму и отношение пользователей.А есть ли шансы построить вообще не то, что хотелось изначально? Может ли результатом творчества явиться потеря изначально запланированного функционала? Да вообще что получится то? А я уже заявил, что эта фича будет в продукте....А её не видно за алертами
- Собственно за него и воюем. Только не стоит тут воспринимать качество буквально. Ведь качество это не только соответствие формальным документам и процессам, но и степень удовлетворенности пользователя.
- Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
- Сколько реально функций запланировано в релиз
- Чуть что – сразу в синьку, никаких обработок эксепшеной и т.д.
- Все хорошо, все работает, но ацки тормозит даже на можных машинах
- Все действия призодится делать через не то место
- Чуть пошатнуло – данные к черту. Либо корраптятся, либо просто теряются
- Чуть возросла нагрузка на операционку, чуть пояилось побольше процесов – приложение в ауте. Вообще в ращных книжках умные дядьки типа Рекса Блека, Кема Канера, Питера Ньюмана приводят примеры сотен и сотен софтверных ошибок. Любой толковый тестер с легкостью прикинет для желающих огромное количество умопомрачительны тестовых сценариев для обыкновенного блокнота, НО. Как обычно не хватает ни времени, ни денег. Что же призодится делать?
- Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
- Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
- Вдруг повезет
- Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
- Немного покрупнее. Тут уже просто так не получится. Надо думать. Но сам подход феерический.По этим группам характеристик ИСО требует (он же стандарт, потому и требует), чтобы все заинтересованные лица (тут каждый может составить свой список, плюс добавить список от клиентов), предложили более детальные характеристики.Ну например, а может ну её эту функциональность? Кривовата, отложим на следующюю версию. Или хочу, чтобы обязательно прогружалось все быстро на главной странице, дальше хоть ползком. Тестер может стрясти такие решения от заказчика. Они сильно сужают область поиска ошибок, а главное они конкретизируют фиговые требования. Главное донести смысл такого рода вопросов
- Метод достаточно сложный, основан на определении потенциальных проблем, оценки их влияния, а затем выполнении классификации по серьезности, приоритетности и вероятности возникновения дефекта.В классическом исполнении предполагается оценка потенциальных ошибок по четырем критериям: серьезность, вероятность, приоритетность и обнаружаемость, причем каждый критерий может варьироваться в различных диапазонах для увеличения или уменьшения точности. Таким образом, вероятность может оцениваться по шкале начинающейся с 1 (наибольшая вероятность) и заканчивающейся Х (наименьшая вероятность). Промежуточные значения и их количество определяются исходя из требуемой точности для конкретного проекта. В итоге получается для каждого типа ошибок четыре числовых значения. Их произведение дает приоритет риска, который может принимать значение от 1 до Y. После этого определяются рекомендуемые действия по снижению рисков. Общая шкала значений делится на количество выделенных категорий, в результате каждой ошибке сопоставляется то или иное действие для уменьшения её эффекта. В общем это не для слабонервных, а в условиях, когда надо занижать, а не увеличивать, вообще может не подойти.