tag:blogger.com,1999:blog-2877410536371661916.post5855536933825920242..comments2023-10-23T17:22:38.832+02:00Comments on Про Тестинг: Обеспечение качества. Контроль качества. ТестированиеАлексей Булатhttp://www.blogger.com/profile/03409061843239194158noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-2877410536371661916.post-65352172189790041412013-05-16T11:15:37.309+02:002013-05-16T11:15:37.309+02:00идея про ложку гениальнаидея про ложку гениальнаналивнойhttp://charoitbud.com/noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-57375877657166019232008-08-20T20:52:00.000+02:002008-08-20T20:52:00.000+02:00Алексей, то что у каждого своя точка зрения - это ...Алексей, то что у каждого своя точка зрения - это абсолютно нормально :)<BR/>Благодаря этому QA и дает столь ценный результат.<BR/>Проблема не в том что "Мы говорим практически об одних и тех же вещах...", а в том что мы понимаем их по-разному. Многие могут похвастаться знанием формального RUP и бесконечно долго говорить о нем, но на практике у всех получаются разные результаты. Мое мнение таково, что уже время не просто обобщать теоретические знания, а анализировать и систематизировать практический опыт нарабатывая так называемые "Best Practices", которые позволили бы отобразить RUP на реальные проблемы, с которыми сталкиваются современные проекты.<BR/><BR/>Что же касается пунктов, возможно я был недостаточно точен опустив ряд пояснений которые считаю для себя сами собой разумеющимися.<BR/>Поэтому вернусь к пунктам еще раз:<BR/><BR/>1. Здесь я абсолютно того же мнения, но хотел подчеркнуть связь между составляющими, и именно такую, как я указал.<BR/><BR/>2. Боюсь, вы путаете разработку тестов с управлением тестами. На практике действительно разработку тестов называют частью планирования, с чем я в целом <BR/>не спорю. Но управление тестами - никогда. Это систематические мероприятия, которые суть - есть часть самого процесса контролируемого QA. Они неизменны и регулярны в рамках проекта, поэтому нет необходимости описывать их регламент в тестплане.<BR/>Достаточно их однажды регламентировать в документах описывающих ваш формальный процесс.<BR/>Иначе так, чего доброго, можно будет назвать все действия формального процесса частью планирования только потому, что они там упоминаются. <BR/><BR/>3. Здесь я имел ввиду как раз противоположное :) а именно, насколько важно планирование и для тестирования, и для QC, и для QA, и какие задачи оно решает именно для них. И уделил специально для для этого особое место перечислению этих задач, чтоб показать, насколько тесно они связаны в тестплане. Если принадлежность какой-либо задачи какому-то из понятий не очевидна - <BR/>это, возможно, мое упущение.<BR/><BR/>4. Может вам покажется странным, но это скорее я смотрю на задачу QA шире чем вы.<BR/>То, о чем говорите вы:<BR/> - взаимодействие между командами<BR/> - планирование выполняемых работ<BR/> - разработка шаблонов <BR/> - и многое-многое другое о чем еще можно упомянуть...<BR/>скорее точки воздействия на процесс для достижения конечной цели, но не сами цели.<BR/>Однако не зная конечной цели, вы не можете знать как нужно эффективно воздействовать на процесс.<BR/>Приглядитесь, все 3 пункта что вы назвали, так или иначе способны внести свой вклад в дело сокращения стоимости <BR/>исправления дефектов:<BR/> - взаимодействие между командами - быстрый и прозрачный обмен информацией, четкие формулировки, свободное и четко <BR/>регламентированное общение, минимум шума в информации позволят быстро идентифицировать дефекты и находить их причины<BR/> - планирование выполняемых работ - и так все ясно, планируйте наиболее трудоемкие и рискованные задачи на более ранние этапы, ставьте задачам на исправление критических дефектов максимальный приоритет, и т.д.<BR/> - разработка шаблонов - если речь идет о шаблонах документов - выносите место для наиболее важной информации вперед, предоставьте удобный способ описания деталей.<BR/>Так ваши воздействия приобретут направленный вектор подчиненный единой цели, что и обеспечит эффективность воздействия.<BR/>Есть такая поговорка: "О чем бы не говорилось - это всегда о деньгах". Возможно это и банально звучит, но бюджет коммерческого проекта не будет тратиться на то, что не помогает получить<BR/>прибыль или сэкономить деньги. поскольку коммерческие проекты тратят деньги на QA (и даже больше чем некоммерческие), то стоит предположить, что заслугу QA можно <BR/>оценить в денежном эквиваленте. Ответьте сначала на такие вопросы, прежде чем размышлять об этом дальше:<BR/> - Что в вашем понимании есть "качество" (самоцель или инструмент для достижения другой цели)? Если инструмент, то достижению какой цели он служит?<BR/> - Как вы измеряете качество в общем? <BR/> - Как вы оцениваете суммарную эффективность своих методов достижения качества?<BR/>Что, озадачил?...<BR/>Так вот, на Западе есть такое понятие: "Удельная Стоимость Дефекта". Чем раньше дефекты обнаруживаются и исправляются, тем затраты на их исправление меньше, а значит меньше и удельная стоимость этих затрат. Чем меньше удельная стоимость, тем эффективнее, считается, QA в проекте.<BR/>Как можно измерить затраты на исправление? - если дефект повлиял на сроки проекта, что повлекло дополнительные затраты на продление проекта, или, еще хуже, понизил имидж проекта будучи обнаруженным после релиза, что привело к потерям продаж,<BR/>то очевидно, что стоимость его исправления обошлась в эти дополнительные затраты и непредвиденные убытки; любой другой дефект обошелся в суммарные (и запланированные) человекочасы тех инженеров, которые были задействованы при его обнаружении и исправлении, чем они меньше - тем затраты меньше (и тем больше запланированных человекочасов у нас осталось для выполнения других задач проекта, в том числе, и не связанных с QC и QA вовсе). Как вы думаете, здесь связь с показателем успешности проекта в целом не прослеживается?...<BR/>Может это сразу и не очевидно, но связь между удельной стоимостью дефекта и эффективностью QA прямая.<BR/>Как? - примерно вот так:<BR/>Чего мы ждем от QA? <BR/>Качества выполнения всех этапов необходимых для получения конечного конкурентноспособного продукта в сроки, установленные проектным планом.<BR/>Что нам дает качество?<BR/>Гарантию того, что вероятность обнаружения недопустимых дефектов после релиза или сдвига сроков <BR/>релиза ввиду обнаружения недопустимых дефектов в предрелизный период будет минимальной.<BR/>Отсюда, чем меньше удельная стоимость дефекта, тем надежнее эта гарантия.<BR/>Зачем нам нужна такая гарантия?<BR/>Мы рассчитываем получить ожидаемую прибыль от продажи продукта и не получить неожиданных потерь этой прибыли.<BR/>По сути, это показатель успешности проекта.<BR/>Скажите, кто-нибудь станет заявлять что в успешном проекте неэффективный QA? - никогда.<BR/><BR/>5. В предыдущем комментарии зашла речь о том, что на практике Тестирование и QC совмещаются - я лишь отметил что на самом <BR/>деле все зависит от размеров департамента QA и в своей практике частенько наблюдал иное, о чем и написал.<BR/>А то, о чем говорите вы - это не совмещение в 1м тестере и QC и QA. Это полное отсутствие QA. Опять таки, исхожу из своего опыта и информации получаемой о QA в разных компаниях. Я частенько общаюсь с тестерами других компаний и знаю специфику <BR/>работы тестера-одиночки.<BR/><BR/>6. Тоже было высказывание в предыдущем комментарии. Я категорически не согласен что роль QC и QA можно совмещать. <BR/>Это не только вредно для QA, но еще и практически невозможно охватить одному человеку при грамотном QA. Это я тоже <BR/>заявляю исходя из своей практики.<BR/><BR/>---------<BR/>И по поводу экспертной оценки тоже...<BR/>Представьте, что бизнес требованием было создать ложку.<BR/>А конечным продуктом стал некий совершенно новый инструмент размером с обычный столовый прибор способный перемещать неоднородные жидкие среды любого объема в пространстве на любые расстояния с любой скоростью, но это не "ложка".<BR/>Ваши тестеры прекрасно научились есть суп при помощи этого инструмента во время тестирования. Вся функциональность работает.<BR/>Требования соблюдены.<BR/>А за время разработки вашей ложки появились ложки нового поколения, которые универсальны и подходят и для чая и для супа, и включаются в интегрированный столовый прибор содержащий также вилку, нож, авторучку, часы... и т.д.<BR/>Можно ли при этом оценить успешен проект или нет и приступить к изготовлению промышленных образцов?!<BR/><BR/>Как вы это сделаете без экспертной оценки представителей целевой группы пользователей?<BR/>А теперь, представьте, что продукт гораздо более сложен и специфичен и ваши тестеры вообще не эксперты в предметной области, и что целевых групп пользователей несколько, они перекрываются, и специфика их задач очень различна в рамках предметной области, а ваши тестеры де-факто не попадают ни в одну из них, кроме того ваш продукт предназначен не для всех групп пользователей в рамках предметной области...<BR/>Вы все еще считаете что экспертная оценка всего лишь моя прихоть?...<BR/>Я вам больше скажу, у ваших тестеров не будет достаточно знаний даже для того чтобы выполнить те формальные RUPовские<BR/>типы тестирования, что вы назвали (которые кстати, едва покрывают треть поднятых мною проблем):<BR/>- Requirements Testing - покрывают качество описания самих ребований, но не полноту согласно бизнес требованиям, это вообще делается <BR/>не формальным тестированием, а аналитикой, а часто Requirements Testing на практике вообще не применяется, потому что сами требования изначально не выдерживают никакой критики или просто отсутствуют, а оценить потенциальную конкурентноспособность продукта все равно надо.<BR/>- Business Cycle Testing - часто выполняются именно третьей стороной (экспертами, заказчиком, бэта тестерами) на ее оборудовании, включают набор use-case'ов, которые обеспечиваются функциональностью продукта, выполняются в течении длительного времени со съемом <BR/>множества метрик включая контроль стабильности, а так же Capacity (или по RUPовски Volume) базы данных если речь идет о клиент-серверной системе, могут быть частично автоматизированы. Но при этом сама полнота набора use-case'ов согласно RUP никак не оценивается, что опять таки - минус.<BR/>- User Interface Testing / Usability Testing - эти 2 понятия вообще недопустимо смешивать. Это разные вещи. Usability не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе равно как и на многих других возможных компонентах продукта, но тип тестирования и тесткейсы совсем другие, и не всегда человек не разбирающийся в предметной области<BR/>способен провести его самостоятельно, а тем более написать к нему тесты. Здесь речь также об удобстве использования невизуальных компонентов,<BR/>если таковые имеются и администрирования, например, распределенного клиент-серверного продукта и т.д. А удобство пользовательского интерфейса -<BR/>лишь часть этого типа тестирования. А теперь представьте что вам нужно протестировать Usability стратегического бомбардировщика...<BR/>Все тестируйте: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки, и т.д. Сильно это будет связано с User Interface Testing??? А без эксперта в выполнении тестов только Usability вы сами справитесь? А сколько экспертов вам понадобятся?<BR/><BR/>Так вот, исходя из вышеизложенного, как вы считаете, попадают ли в область ответственности QA взаимодействия со структурами внешними по отношению к проекту, такими как например, бэта тестеры, представители заказчика (если таковые имеются), ваш собственный техсаппорт? <BR/>Отвечу сам - ДА!<BR/>Это как то имеет отношение к Quality Control?<BR/>Тоже отвечу сам - напрямую - вообще никак, ведь продукт и проект продолжают в этом случае изменяться и получать новые задания даже тогда, когда все требования по Quality Control формально уже соблюдены.<BR/><BR/>Это я и имел ввиду говоря об экспертной оценке.<BR/><BR/>Спасибо за внимание.nikodenhttps://www.blogger.com/profile/00249929914310913085noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-58782597262079090222008-08-13T10:43:00.000+02:002008-08-13T10:43:00.000+02:00У каждого своя точка зрения на все на свете... Мы ...У каждого своя точка зрения на все на свете... Мы говорим практически об одних и тех же вещах, но почему-то вы перефразируете то о чем мы говорили до этого. А теперь по пунктам:<BR/><BR/>1. "готовность Продукта к выпуску" может и связана с "Соответствия зафиксированным требованиям" и "Соответствия заявленному уровню качества продукта", но это никак не одно и тоже, а одни из его составляющих.<BR/><BR/>2. Тест менеджмент и планирование это по существу одно и тоже, если включить в понятие планирования то что вы написали, а именно: <BR/>- контроль качества тестов, <BR/>- оценку достаточности покрытия тестами тестируемой области, <BR/>- контроль версий тестов, <BR/>- контроль документирования результатов тестирования <BR/>и т.д.<BR/>Все эти активности должны быть спланированы!!! А вот QA уже должно убедиться в том, что это было сделано :) Так что я упорно продолжаю разделять тест менеджмент и QA.<BR/><BR/>3. Ну если для вас тестинг это просто кликинг, то вы можете не включать планирование в него... А по поводу тест плана у меня вопросов нет и быть не может - это другая тема, которую можно начать в моей статье по планированию тестирования.<BR/><BR/>4. Вы говорите только о деньгах и дефектах, но QA смотрит на все намного шире. В круг ее обязанностей входят не только процессы связанные с разработкой и тестированием, но и взаимодействием между командами, планированием выполняемых работ, разработкой шаблонов и т.д. Точнее все, чтобы обеспечить качественное выполнение поставленных задач на всех уровнях.<BR/><BR/>5. Да не важно кто все это делает. В маленьких конторах есть 1 тестер, который и QC и QA одновременно. Да и вообще мы не конкретизируем здесь, а смотрим на вопрос в общем.<BR/><BR/>6. без комментариев, опять конкретика...<BR/><BR/>-----------<BR/>И теперь по поводу экспертной оценки.<BR/>Все что вы говорите подпадает под определенны виды тестирования:<BR/>- Requirements Testing<BR/>- Business Cycle Testing<BR/>- User Interface Testing / Usability Testing<BR/>А это уже тестирование, и значит тестировщики этим должны заниматься.<BR/><BR/>А по поводу экспертной оценки, хотите ее получить, наймите людей со стороны :)<BR/><BR/>Вот.<BR/><BR/>Спасибо за ваши комментарии.<BR/>Алексей.А.Б.https://www.blogger.com/profile/15946082367048034861noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-39094333930132927812008-07-03T16:04:00.000+02:002008-07-03T16:04:00.000+02:00В целом я согласен и с материалом статьи, и с пред...В целом я согласен и с материалом статьи, и с предыдущим комментарием.<BR/>Но у меня есть некоторые замечания, которые я и хочу изложить:<BR/>1. В определении QC, на мой взгляд,"готовность Продукта к выпуску" как раз и определяется на основании "Соответствия зафиксированным требованиям" и "Соответствия заявленному уровню качества продукта".<BR/>2. Не согласен с тем что Test Management есть планирование тестирования и является частью Testing. Планирование тестирования - это планирование тестирования, и ни что иное и в мировой практике зовется как Software Test Planning (STP). А Test Management - скорее часть QA поскольку включает и контроль качества самих тестов, и оценку достаточности покрытия тестами тестируемой области (соответствие тестплану), и контроль версий тестов, а также контроль документирования результатов тестирования (фиксирование статуса выполнения отдельно взятого теста).<BR/>3. Не согласен с формулировкой о том, что планирование тестирования "может быть" частью тестирования и частью QA. Скорее хошее планирование тестирования позволяет решить и задачи тестирования, и задачи QC и QA. Поясню. Тестплан, это не просто статический документ написанный один раз перед тем как начать тестирование и после этого благополучно забытый. К ранее написанным тестпланам возвращаешься и в процессе тестирования и после рализа. Пока тестирование не закончено, тестплан может изменяться. <BR/> Грамотно составленный тестплан позволяет:<BR/>- провести анализ дизайна продукта (в глобальном смысле, а не GUI) с точки зрения того что уже воплощено, что еще предстоит воплотить и какие проблемы возникли уже на данном этапе, при этом оценить вероятность появления изменений к требованиям и, по возможности, сами эти изменения, обсудить эти изменения с разработчиками и продуктменеджером (это нужно продолжать делать и тогда, когда тестирование уже идет полным ходом, давая новую пищу для анализа);<BR/>- оценить проектные риски с точки зрения качества в момент когда разработка уже начата, а значит когда уже появилась динамика рисков; <BR/>- определить интеграционные моменты смежных продуктов или компонентов которые требуется учесть при тестировании, а значит и методы и степень взаимодействия смежных подразделений внутри проекта и за его пределами; <BR/>- определить методы и подходы к тестированию; <BR/>- предъявить требования к минимальному покрытию тестами;<BR/>- предъявить требования к лабораторному оборудованию, необходимому для тестирования;<BR/>- определить критерии готовности продукта к выпуску, включая требования к уровню качества.<BR/>- определить сроки тестирования.<BR/>4. Далее, цитата: "QA, это превентивные действия, попытка недопустить появление дефектов." - Красиво и наивно. Попробуйте недопустить нашествие саранчи... Будьте готовы к тому, что дефекты так или иначе будут.<BR/> Скорее задача QA состоит в следующем:<BR/>- сократить разницу во времени между началом разработки и началом тестирования<BR/>- сократить время обнаружения дефектов<BR/>- сократить время исправления дефектов<BR/>- минимизировать количество ложных обнаружений дефектов и сократить время идентификации таких ложных дефектов<BR/>а в нескольких словах: сократить стоимость исправления дефектов (чем раньше дефект найден - тем дешевле он нам обошелся) и как следствие - суммарную стоимость проекта!<BR/>5. В больших и средних проектах разница между QC и Testing проявляется в том, что трекинг готовности продукта осуществляют не те кто его непосредственно тестирует, а их менеджеры, опираясь на отчеты о готовности отдельных фич, приемочного тестирования и прочие критерии готовности продукта, такие, например, как допустимый процент неисправленных дефектов, отсутствие дефектов блокирующих релиз.<BR/>6. Цитата: "Еще я склонен согласится с тем, что все три роли могут быть объеденены в одну." - Очень неблагодарное допущение. Точно так же как не стоит доверять контроль качества продукта программисту, не стоит доверять и контроль качества тестирования продукта инженеру, выполняющему тестирование. А в сколь-нибудь большом проекте это просто невозможно.<BR/><BR/>А еще, я не нашел явного упоминания об одной, жизненно важной для продукта роли QA, которую не осуществить средствами одного QC.<BR/>Это экспертная оценка продукта силами департамента QA или независимыми экспертами (хотя-бы бэта тестерами, но так или иначе квалифицированный департпмент QA принимает в этом участие с самого начала разработки).<BR/>Что имеется ввиду? - Неформальная оценка способности продукта решить те бизнес задачи, которые на него возлагает отдел маркетинга или заказчик.<BR/>Она на, мой взгляд, должна включать, как минимум:<BR/>- оценку качества технических требований к продукту и их соответствие бизнес требованиям (осуществляется до начала разработки);<BR/>- оценку способности продукта обеспечить те бизнес процессы потенциального покупателя или заказчика которые достаточны для того, чтоб продукт был востребованным и конкурентноспособным;<BR/>- оценку удобства использования продукта для целевой группы пользователей (равно как и оценку правильности выбора целевой группы).nikodenhttps://www.blogger.com/profile/00249929914310913085noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-24998630226948395022008-01-23T07:52:00.000+01:002008-01-23T07:52:00.000+01:00Алексейя прочитал обе статьи. Считаю что данные оп...Алексей<BR/><BR/>я прочитал обе статьи. Считаю что данные определения вполне пригодны. Хороший шаг для определения собственой "системы координат", в отношение которой в дальнейшем можно строить теории или практики. Мне кажется, что нельзя дать единственно правильного и неоспоримого определения для этих терминов. Почему? Приведу аналогию с физическими системами измерений. Нельзя сказать, что измерять длину в метрах правильно, а в дюймах нет. И даже если вдруг получится сформулировать "идеальное" определение того что такое тестирование, QA итд., вовсе не факт, что оно будет принято и пониматься всеми одинаково.<BR/>Подавляющее большинство людей работающих в ИТ считают, что QA==Testing. Это все-равно, что говорить что системный архитектор и программист - одно и тоже. Еще это показатель общей безграмотности кадров, работающих в ИТ. Причем такие люди зачастую занимают руководящие посты в разных компаниях. Ужас. Так что проблемы с образованием не только в области обеспечения качества.<BR/><BR/>Мое мнение, что та или иная специализация, может характеризоваться обязанностями и действиями. Но, к сожалению, а может быть и к счастью, в области обеспечения качества некоторые активности могут относится к нескольким специализациям. Например, такая активность, как планирование тестирования, может быть как частью тестирования(IEEE Std 829 - Test Plan), так и частью QA(IEEE Std 730 - Software QA Plan). Но есть и такие, которые нельзя попутать, например, формализацию процесса работы с дефект-трекером - к активностям тестирования отнести сложно.<BR/><BR/>Я полностью согласен с картинкой из первой статьи. Где QA включает QC включает Testing. Это логически понятно из самих названий. Рассуждения таковы: чтобы обеспечивать качество продукта, нужно постоянно контролировать это качество (например от билда к билду, от версии к версии). В свою очередь для того чтобы проконтролировать качество, нужно сделать какие-то акции, провести эксперименты.<BR/><BR/>Теперь попробую дать определения так, как я это вижу в своей "системе координат".<BR/><BR/>Обеспечение качества - совокупность мероприятий, сервисов и действий направленных на постоянное улучшение качества выпускаемого продукта путем улучшения процессов и систематического контроля как за соблюдением этих процессов так и за качеством выпускаемого продукта.<BR/><BR/>Контроль качества - систематические действия, направленные на определение текущего качества выпускаемого продукта, определение относительного изменения этого качества по отношению к предыдущему состоянию продукта и выявление тенденций в отношении улучшения или ухудшения качества в следующем состоянии продукта.<BR/><BR/>Тестирование - набор целенаправленных действий дающих понятие о текущем качестве продукта, подтверждающих то, что разрабатываемый продукт имеет заранее спланированное поведение и характеристики и не имеет незапланированных характеристик и поведения (т.е. дефектов).<BR/><BR/>Основные различия:<BR/>QA, это превентивные действия, попытка недопустить появление дефектов. Понижение рисков появления неисправностей.<BR/>Тестирование - действия направленые на поиск неисправностей которые уже допущены, либо подтверждение того, что их нет.<BR/>Контроль качества - действия направленные на оценку текущего состояния продукта. По сути близко к тетсированию. На практике редко (на моей памяти ни разу) выделяется отдельно от тестирования. Т.е. по результатм тестирования у нас есть данные - прошел тест или нет, найдены дефекты или нет. По результатам контроля качества, мы можем вынести вердикт о функциональности продукта - годна она к релизу или нет.<BR/><BR/>Как-то вот так.<BR/><BR/>Еще я склонен согласится с тем, что все три роли могут быть объеденены в одну. Хотя бы потому что я сейчас сижу на всех трех стульях - я тестирую (провожу эксперименты), я контролирую качество (оцениваю, что билд номер N - есть релиз, т.к. он удовлетворяет критериям) и обеспечиваю качество (формализую процессы, участвую в обсуждениях архитектуры проекта). Конечно, хотелось бы больше сосредоточиться на последних двух областях, но...Anonymousnoreply@blogger.com