Контроль качества ошибки

Клинико-химические, как и все количественные измерения, принципиально отягощены возможностью ошибок. Весь процесс клинического исследования можно разделить на 4 этапа: взятие пробы, хранение пробы, анализ, оценка и выдача результата. Ошибки, возникающие на разных этапах работы, бывают внелабораторного и внутрилабораторного характера.

Внелабораторные ошибки

Существенным источником внелабораторных ошибок является трудность учета времени последнего приема пищи больным. Поэтому следует унифицировать время взятия крови и применять для исследования кровь, взятую натощак. Эмоциональное состояние пациента, время суток, положение тела больного оказывают влияние на количественные и качественные показатели крови.

Все указанные выше факторы погрешностей связаны с состоянием больного. Но нельзя недооценивать и ряд других факторов, которые также отражаются на качестве результатов: техника взятия крови, используемые при этом инструменты, сосуды, в которых хранится кровь. Иглы, применяемые для взятия крови, должны иметь достаточно большой диаметр, чтобы не возникало повреждения эритроцитов. Посуда и инструменты для взятия крови не должны содержать следов моющих средств, должны быть сухими.

Весьма существенной причиной возникновения погрешностей анализа является нарушение условий хранения проб. Уже одно более длительное стояние сыворотки над эритроцитами может привести к изменению концентраций компонентов. Сыворотка должна быть отделена от кровяного сгустка не позднее двух часов после взятия крови.

Упомянутые источники погрешностей не поддаются качественному и количественному контролю, их в большинстве случаев не очень легко распознать, исключить погрешности можно только тщательной и кропотливой работой. Следует добиться стандартизованных условий, обязательных при взятии проб крови. Необходимо регулярное инструктирование персонала клиник и амбулаторий о правилах и условиях сбора и хранения материала для различных клинико-диагностических исследований.

Внутрилабораторные ошибки

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

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

Наиболее распространена следующая классификация ошибок. Различают три основных вида ошибок: грубые, случайные и систематические.

Грубая ошибка — это одиночное значение исследуемого компонента, выходящее за пределы установленного для данного компонента области (за допустимые пределы погрешности). Причиной грубых ошибок является недостаточная тщательность в работе.

Случайная ошибка — одиночное значение, не выходящее за пределы установленной для данного компонента области. Случайными называются неопределенные по величине и знаку ошибки, в появлении каждой из которых не наблюдается какой-либо закономерности. Эти ошибки происходят при любом аналитическом определении. Наличие их сказывается в том, что повторные определения того или иного компонента в данном образце, выполненные одним и тем же методом, дают как правило несколько различающиеся между собой результаты. Случайные ошибки практически невозможно исключить совсем, они могут возникать из-за негомогенности пробы материала, недостаточно высокого качества оборудования, чаще случайные ошибки вызываются субъективными факторами. Этот вид ошибок можно значительно ограничить после оценки их размера, величина ошибки (разброс данных) является мерилом воспроизводимости лабораторных результатов. Чем меньше величина случайных ошибок, тем лучше воспроизводимость исследований. Распространенным способом характеристики воспроизводимости результатов является величина среднеквадратического отклонения.

Для суждения о правильности анализа совпадение или расхождение результатов параллельных проб не имеет значения. В этом случае на первый план выступают систематические ошибки.

Систематическими ошибками называют погрешности, одинаковые по знаку, имеющие определенную причину, влияющие на результат либо в сторону увеличения, либо в сторону уменьшения его. Систематические ошибки можно обычно предусмотреть или же ввести соответствующие поправки (ошибки методического характера). Систематические ошибки повторяются при каждом измерении, так как они вызываются постоянными причинами, влияют они на всю серию определений. В качестве причин могут выступать ошибки приборов (автоматические анализаторы, фотоэлектроколориметры) и неправильное приготовление реактивов, индивидуальные особенности работника (ошибочное восприятие окраски пробы). С введением биохимических анализаторов и автоматических дозаторов число случайных ошибок (ошибок манипуляций) уменьшается, но возрастает необходимость контроля за появлением систематических ошибок и увеличивается необходимость в контрольных материалах для их обнаружения. Величина систематической ошибки характеризует правильность результатов анализа.

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

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

Возникновению ошибок необходимо противопоставить постоянное измерение точности выполнения анализов, надежность работы лаборатории, т.е. контроль качества исследований.

Учимся на ошибках в организации контроля качества

Привет, Хабр! Меня зовут Илья Кудинов, и я работаю QA-инженером в компании Badoo. Три года назад я начал посещать различные IT-конференции и рассказывать о процессах и технологиях, применяемых нами при контроле качества. И конечно же, после каждого доклада я общался со слушателями, интересовался, как работают они. В этом деле меня всегда мотивировали отзывы вида «Раньше мы работали вот так, но, послушав твой доклад, мы увидели, как можно сделать лучше», а еще лучше — когда люди не копируют наши приемы, а придумывают что-то сами, иногда даже более интересные варианты. Таких историй у меня накопилось много, и я хочу поделиться с вами некоторыми из них (все имена и названия вымышлены, любые совпадения с реальными лицами являются случайностью). Может быть, что-то из этого поможет вам увидеть направление развития вашего собственного проекта — и это будет самой большой наградой для меня! Разумеется, буду рад после этого выслушать и ваши истории — в комментариях или личных сообщениях.

Прежде всего давайте оговорим два момента.
Первое: не для всех видов и масштабов разработки советы из этой статьи окажутся подходящими (для некоторых, я уверен, они будут даже очень вредными), поэтому для представителей разработчиков софта самолётов (а так же для тех гуру тестирования, кому мои советы кажутся очевидными) этот рассказ будет просто занимательным чтивом. Я в первую очередь ориентируюсь на быстроразвивающиеся продукты с плотным графиком релизов. Интереснее всего будет представителям тех компаний, где QA-отдел существует только в зародыше или пока не существует вообще.
Второе: нет, «грустные» истории не выдуманы. И нет, они, возможно, не так ужасны в действии, как я их описываю, но свое мнение я буду стараться всегда максимально аргументировать.

Визуализации мыслей и идей будут помогать вот эти три товарища, знакомьтесь:

Итак, давайте начнем с того, что определимся, кто же мы, собственно такие. QA-инженеры? Тестировщики? Тестеры?
Тестер — это такой прибор, использующийся для замера электрических характеристик цепи. Не надо нас так называть, мы обижаемся.
Тестировщик — специалист, занимающийся тестированием. Тестирование — важный и незаменимый процесс при разработке чего бы то ни было, но в него входит исключительно процесс помещения системы в различные ситуации с целью изучения ее поведения и верификации поставленных на тестирование задач.
QA-инженер — специалист, занимающийся контролем качества. В это понятие входят как тестирование, так и, например, последующий мониторинг, разработка и поддержка различных автотестов и прочих средств автоматизации и оптимизации процесса, релиз-инжиниринг.

Впрочем, с целью упрощения речи, «тестировщик» тоже сойдет, но только если вы говорите это с должным уважением.

Я гордо говорю, что я QA-инженер. Моя работа (и работа моих коллег как по компании, так и по сфере вообще) направлена на обеспечение максимально достижимого качества продукта — на то, в чем в любом случае заинтересованы все остальные участвующие в проекте стороны. Именно поэтому мне очень жаль, что во многих компаниях мои собратья зачастую рассматриваются как сугубо вспомогательный персонал, роль которого в проекте самая незначительная (уборщики хотя бы грязные кружки из-под кофе убирают за разработчиками).

На самом деле роль тестировщика в проекте в конечном счете является ничуть не менее важной, чем роль разработчика. Бьёрн Страуструп (дат. Bjarne Stroustrup) в своей книге «Язык программирования C++» писал: «Программа, которая не прошла тестирование, не работает». Зачем вам нужны программисты, продукты которых никогда не будут работать? Тестировщик — не раб разработчика, великодушно выдающего задачи типа «проверь, пока я раскладываю на прод». Наоборот, разработчик и тестировщик совместными усилиями достигают поставленной цели — выпустить продукт к назначенному сроку в максимально высоком качестве. Именно для этого и создается отдел контроля качества. Но… как его организовать?

QA-отдел

Итак, компания «ФОЛИАНТ ЛИЦ» решила заниматься разработкой программного обеспечения. Она подошла к этому делу основательно, даже отважилась на создание QA-отдела! Сколько нужно набрать туда людей, если у нас уже есть 12 разработчиков? Классический подход подсказывает, что приблизительное соотношение рабочей силы должно быть таким: 1 QA-инженер на 3-4 разработчиков. Сказано — сделано! Нанимаем трех инженеров и считаем себя большими молодцами.
Проект начинает развиваться, к QA-отделу предъявляются все новые и новые требования. Вот мы уже достаточно повзрослели, чтобы производить релизы не просто выкладкой gzip-архива на продакшен, а путем хорошо построенного и налаженного деплой-процесса. Кто будет этим заниматься? Отдадим это нашему специалисту в отдел контроля качества!
Функционала становится все больше — тестировать регрессию все сложнее. Один из наших тестировщиков имеет опыт разработки? Отлично! Пусть он теперь занимается разработкой автотестов! Хорошо мы придумали, да?
Что мы получили в итоге такого замечательного плана? Тестированием задач наших двенадцати разработчиков постоянно теперь занимается только один из QA-инженеров. Интересно, почему очередь на тестирование начала расти и наши отлично организованные релизы регулярно задерживаются?

Урок: рассчитывая количество специалистов для QA-отдела, нужно принимать во внимание все сферы деятельности, которыми они будут заниматься помимо непосредственного тестирования, и нанимать при необходимости новые кадры, а не распределять новые обязанности между имеющимися. Разве не это подсказывает здравый смысл? Практика показывает, что не всегда.

Смотрите, другая маленькая компания — «ЩЕБЕТАЛКА»! И у нее очень большие и серьезные планы. Начинают они с малого: четыре разработчика, пара менеджеров и один (очень гордый) тестировщик. Время проходит, бизнес идет в гору, количество заказов на разработку все увеличивается и увеличивается. Счастливые и довольные результатом руководители проекта объявляют расширение штата. Для начала наймем еще одного продакт-менеджера, пусть генерирует больше взрывных идей. Запросов на новые фичи становится все больше? Срочно набираем новых разработчиков!
Ого, больше пользователей? Больше прибыли? Ребята, мы идем верной дорогой — нанимаем еще разработчиков, пусть засыпят наш проект фичами! Как же это все здорово! Но что же это? Почему стало больше багов? Почему пользователи недовольны? Мы ведь наняли больше людей, почему мы отстаем от графиков? Ах, наш несчастный тестировщик, мы совсем про него забыли!

Урок: отдел контроля качества стоит развивать параллельно отделу разработки. Возможно, даже с опережением. Сложно бороться с конкурентами и доставлять пользователям новаторский функционал, если вы не можете обеспечить проекту должное качество.

А вот у компании «ТЫНДУКС» все процессы уже давно поставлены. У нее немаленький отдел разработки и вполне соответствующий ему отдел тестирования. Разработчики и QA-инженеры сидят в разных помещениях, разделенных большим холлом, и недобро переглядываются через щели приоткрытых дверей.
Завершив работу над задачей, разработчик со всей злостью, доступной при нажатии на кнопку Assign в Jira, кидает задачку на тестирование. Тестировщик недоверчиво смотрит на задачку, с отвращением открывает ее и спустя несколько секунд с достойной зависти яростью возвращает задачу на доработку с пояснением: «У вас опечатка в комментарии!» Казалось бы, при таком рвении к работе качество должно быть на высоте. Наверное, оно там и есть. Но мы этого никогда не узнаем, потому что при таком подходе задача доберется до продакшена примерно… никогда.

Урок: отделы тестирования и разработки — не враги друг другу. Они не должны сидеть по разные стороны укрепрайонов, стараясь при первой же возможности свалить работу друг на друга. Как я уже говорил, их совместная цель — релиз задачи в поставленный срок, и их обязанностью является объединение усилий для достижения этой цели. Это вовсе не значит, что нужно закрывать глаза на ошибки: просто после обнаружения незначительного дефекта не обязательно сразу же отправлять задачу на доработку, вполне можно записать ее в сторонку, проверить, насколько это возможно, и отправить уже с полным списком ошибок, чтобы сэкономить горы времени на постоянно повторяющихся этапах разработки и тестирования.

Здесь стоит заметить, что в некоторых случаях подобный подход все же уместен. В «промышленной» разработке (например, при поддержке софта использующегося на самолетах) качество и соответствие процессам может ставиться выше скорости, и это правильно. Наверное, я бы не хотел летать на самолетах, тестируемых и разрабатываемых работниками небольших «ультрасовременных и быстроразвивающихся» стартапов.

QA-процесс

И вот QA-отдел организован. Чем он будет заниматься? Правильно, контролем качества. Но как это процесс будет устроен?

Любые QA-процессы всегда строятся вокруг балансирования между качеством и скоростью. Абсолютное качество недостижимо (если вы со мной будете спорить — надеюсь, вы разрабатываете самолеты), тестировать задачи мгновенно тоже невозможно. Где же найти это равновесие? Здесь каждая команда может придумать свое решение. Для кого-то это Continious Integration, кто-то отдает предпочтение строго регламентированным и спланированным релизам — и нельзя просто подсмотреть процессы, поставленные вашими соседями по гаражу.

Как QA-процессы встраиваются в процессы развития проекта? Давайте поделим их на три этапа: продакт-дизайн, разработка и тестирование. Два молодых стартапа подошли к этому вопросу совершенно по-разному: компания «БОДУНЫ» плотно связала QA-инженеров с каждым из них, а «ПОЧТИ.РУ» оставила им только тестирование. Кто из них прав? Как говорится, истина может быть где-то посередине.
Что мы получаем с каждым новым этапом QA-процесса? Качество. Что мы при этом теряем? Скорость. Какими же этапами контроля качества можно жертвовать?

Тестированием? НЕТ.

Контролем качества при разработке? Звучит важно. Нет, конечно не нужно чтобы тестировщик сидел за плечом у разработчика и больно щипал его каждый раз, когда тот забывает поставить точку с запятой. Есть много других способов помочь разработчикам соблюдать определенный уровень качества. Удачно настроенная система контроля версий, различные хуки и скрипты для проверки корректности кода, написание юнит-тестов (здесь, правда, QA может выступать только в роли надзирателя с кнутом и пряником), удобная система code review — все это в области ответственности отдела контроля качества.

Контролем продакт-дизайна? Ну… В «промышленной» разработке существует целое направление контроля качества — тестирование и анализ ТЗ. Это помогает избежать логических и архитектурных ошибок на начальных этапах развития каждого проекта — и катастрофически отдаляет возможность начала разработки.
Наверное, в молодом стартапе это излишние предосторожности. Высокая интеграция различных отделов друг с другом позволит всем участникам проекта (и разработчикам, и тестировщикам) увидеть подробности проекта, определить шероховатости и донести до менеджмента полезные (и не очень) идеи. К тому же, в нашем мире динамичных проектов и Agile-методологий ТЗ зачастую изменяется уже во время разработки (и даже после релиза, в конце концов), так что имеет смысл позволить продакт-менеджерам выражать себя бесконтрольно и уже потом вносить свои предложения и поправки.

Урок: контроль качества на каждом этапе развития проекта положительно влияет на качество и катастрофически понижает скорость. Нужно строить процессы так, чтобы они соответствовали требованиям к вашему проекту, и не копировать бездумно чужие практики и статьи из книжек (и из Хабра, да-да).

Смотрите, разработчик компании «БУБЛ» отдал свою задачу на тестирование и абсолютно уверен, что увидит ее снова только в случае возврата на доработку. И что же, в этапе тестирования участвуют только QA-инженеры? Вовсе не обязательно. Конечно, при обнаружении каждой неясности можно сразу же возвращать задачку, но это вполне может оказаться обычным недопониманием, а задача при этом повиснет в каких-то промежуточных статусах. Поэтому (и не только поэтому, конечно) общение и взаимодействие в процессе тестирования — бесценно. В случае обнаружения странных и непонятных моментов всегда можно сесть вместе с разработчиком и попробовать разобраться. С одной стороны, если это поведение ошибкой не является, то можно разобраться в алгоритме и избежать всех задержек с переходом статуса. А если это оказывается неожиданной ошибкой, то подобное изучение может помочь разработчику решить проблему с ходу, а не добраться до переоткрытой задачи спустя несколько дней и пытаться с нуля сообразить, что же там происходило.

Урок: не стоит возвращать задачку при первом же непонятном моменте. Совместный с разработчиком дебаг — не только полезный и эффективный процесс, но и зачастую поучительное (оба участника могут глубже вникнуть в происходящее) и веселое занятие.

В компании «НАЛИНИИ» прекрасно построен процесс разработки. У разработчиков есть полный набор инструментов для оптимизации процессов разработки и упрощения распределения работы. Они пользуются системами проджект-менеджмента и системами контроля версий: никто друг другу не мешает и вся их работа всегда в целостности и сохранности.
А вот у их отдела контроля качества все давно не так безоблачно. Исторически сложилось так, что релизы на тестирование отправлялись им в качестве архивов, вложенных в почту. Ну, кто-то когда-то так придумал, и все привыкли. Они пишут свою документацию на бессчетных бумажках, разбросанных по всему отделу (некоторые особо хитрые инженеры завели самый настоящий совместный Google Doc, но очень боятся, что их рано или поздно поймают и заставят все переписать на бумажки). Очень жаль, что никто не может проявить инициативу и попробовать объединить используемые технические средства!
Ведь можно было бы использовать общие репозитории, общие базы знаний, интегрировать друг в друга системы баг-трекинга, сборки приложений и сделать все таким красивым, автоматизированным и целостным… Но нет, к сожалению, разработчикам пришлось бы для этого отвыкать от привычного flow и даже (!) разрабатывать и настраивать что-то новое. Но нет, письмами как-то сподручнее…

Урок: нужно стараться максимально интегрировать процессы и инструментарий отделов разработки и тестирования. Это поможет обоим отделам и проекту в целом. Иногда это требует небольших жертв от всех участвующих, но в конечном счете позволяет добиться куда больших успехов.

Тестировщики компании «КРУПНОЖЕСТЬ» всегда работают по строгим тест-кейсам. Запрещена любая свобода действий — и не дай бог кто-то позволит себе пропустить хоть один пункт в тест-плане! Отсутствующая галочка в чек-листе равносильна преступлению и карается чтением «Войны и Мира» вслух перед всем отделом. Отдельные инженеры целыми днями занимались исключительно поддержкой этой документации, а каждый тестировщик был обязан составлять кейсы для каждого затронутого им функционала. Конечно, качество было на высоте! Поначалу… Выяснилось, что на продакшене начали появляться баги. Баги на продакшене, Карл! При проверке чек-листов выяснилось, что этот функционал проверялся, и ответственный тестировщик с самым невинным видом активно кивает головой: проверял, проверял! А затем выяснилось, что некоторые компоненты продукта не проверялись уже годами просто потому, что они не нашли себе места в тест-документах. Руководителя отдела заставили писать отчет и объяснительную относительно происходящего в четырех томах с оглавлением.
Наверное, было бы лучше, если бы тестировщики при работе думали своей головой, а не следовали строгим инструкциям. Имели бы общий источник информации, но не в виде «Что делать», а в виде «Как это работает». Конечно, это может отрицательно повлиять на скорость тестирования, ведь каждый раз будет необходимо исследовать фичу или (не дай бог!) общаться с другими тестировщиками и (!) разработчиками, чтобы понять, что надо бы тут проверять.

Урок: общая документация, позволяющая определить, что стоит тестировать в той или иной задаче — хорошо. Подробные инструкции и кейсы… наверное, не очень. (разработчики самолетов — забудьте, что сейчас прочитали. ПОЖАЛУЙСТА!)

В компании «ПРИНТЕЛ» очень ценят разделение труда. Каждый тестировщик привязан к тому или иному функционалу и компоненту — и он прекрасно знает, что и как имеет смысл в нем тестировать. Качество и скорость на высоте, компания идет к успеху. А потом один из QA-инженеров выигрывает в лотерею и уезжает жить на Канары. Оставшиеся переглянулись и попробовали разобраться в том, что он за собой оставил. Никто ничего не понял, и тестировали кое-как, пока не был найден новый инженер на место счастливчика. Все вздохнули от облегчения…Пока не выяснилось, что в мечтах уехавший был врачом и все его записи велись немного непонятным почерком. Разработка компонента встала почти целиком до тех пор, пока новичок не смог освоиться в нем с нуля.

Урок: имеет смысл иметь практику обмена знаниями внутри QA-отдела. Можно периодически обмениваться задачами, чтобы не привыкать к одному компоненту (одно из плохих последствий такой «специализации» — «замыливающийся» глаз), можно проводить внутренние семинары и лекции, на которых специалисты расскажут о новшествах в своей сфере ответственности, интересных кейсах и технологиях: это приведет не только к взаимозаменяемости специалистов, но профессиональному росту каждого из них.

QA-инженер компании «КРАБЫРАДЫ» наконец-то закончил работу над сложной системной задачей, на которую он потратил не один рабочий день. Он проследил за ее отправкой на продакшн, вздохнул свободно и отправился пить пиво с друзьями. Правильно ли он поступает? Я так не думаю.
Даже если у его компании есть серьезный отдел мониторинга, круглосуточно красными глазами наблюдающий за десятками и сотнями графиков и метрик, ему может потребоваться немало времени, чтобы локализовать внезапно возникшую из ниоткуда ошибку или падение активности. Вот было бы здорово, если бы кто-то мог им помочь или даже просто не допустить того, чтоб им пришлось искать причины этого беспорядка…
А ведь тот самый инженер мог выпить сегодня всего на одну пинту «Гиннеса» меньше, зато спасти немало человеко-часов (и, возможно, денег компании), если бы потратил какое-то время на изучение поведения продакшена после релиза. Изучить логи ошибок, проверить тренды тех графиков, которые описывают состояние затронутых в задаче компонентов. Да, иногда баги добираются до продакшена. Виной тому может быть человеческий фактор, различия в окружении или даже просто одна из тех миллионов user story, которые генерируют настоящие пользователи.

Урок: QA-процесс не прекращается сразу же после релиза задачи на продакшен. Всегда имеет смысл последить за поведением нового функционала, и крайне важно иметь инструменты, которые это позволяют.

Тестировщик компании «ЯБЛОЧКО» впервые в жизни пропустил на продакшен досадный баг. Наверное, он мог его обнаружить, если бы потратил на это еще пару часов, но это уже случилось. Баг починили, но он успел затронуть пользователей. Компания очень недовольна тестировщиком. Разработчик фичи недоволен тестировщиком. Он получает взыскание и лишается премии, чтобы неповадно было и в дальнейшем не щадил себя при тестировании. Правильно ли поступила компания? Я думаю, что нет.
QA-процессы не отменяют возможность появления дефектов — они направлены на понижение вероятности их возникновения. И в этих процессах участвуют все затронутые в проекте люди. И ответственность за дефекты в равной степени ложится на всех: на руководителя, который недостаточно замотивировал и обучил своих сотрудников; на разработчика, который допустил ошибку; на тестировщика, который эту ошибку пропустил. Даже на тех инженеров, которые покрывали этот функционал автотестами — ведь их тесты могли поймать этот баг, но не смогли! Стоит ли их наказывать? Возможно, но только при системных проколах. Гораздо полезнее будет провести глубокое изучение причин произошедшего, организовать образовательные семинары и все возможные мероприятия, для того чтобы понизить вероятность возникновения подобных дефектов в будущем.

Урок: в возникновении дефектов виноваты все участвующие в проекте стороны, не стоит обвинять в его возникновении только тестировщика.

Автоматизация

В компании «СЦОННИ» приняли решение начать разработку автоматизированных тестов. Один из тестировщиков имеет навыки программирования, и эту задачу отдали ему. Он писал тесты, был доволен своей работой и в какой-то момент покрыл тестами почти весь продукт. Все были рады, пока не заметили, что ушедшему в другой проект тестировщику не стали искать замену.
Событие превратилось в тенденцию, и QA-отдел начал таять. Когда перепуганные инженеры прибежали к руководству, то с улыбкой ответило: «У нас теперь такие замечательные автотесты, зачем нам скучные несовременные ручные тестировщики?» Объяснить им ничего не получилось, и все осталось на своих местах. Дела шли хорошо до тех пор, пока на продакшене не стало появляться все больше и больше ошибок, и все они — в самом новом, еще не покрытом тестами функционалом. Руководство осознало свою ошибку, но было уже слишком поздно… *громкая драматическая музыка*

Урок: автотесты являются исключительно вспомогательным средством контроля качества и никоим образом не заменяют собой ручное тестирование.

А вот в компании «ШАНТСУНГ» такой проблемы не испытывали. Их отдел автоматизации тестирования был полностью отделен от отдела ручного тестирования. «Автоматизаторы» даже чувствовали себя представителями какой-то более высокой касты и снисходительно наблюдали за теми, кого они называли «ручниками». И было такое разделение, казалось, удобно всем, пока не стали возникать проблемы. «Автоматизаторы» стали так глубоко погружены в поддержку сотен своих тестов, что потеряли всякую возможность разрабатывать что-то новое (и соблюдать поставленные KPI, конечно), а «ручники» совершенно не представляли, что там происходит у их коллег, и перестали полагаться на тесты, проверяя вручную все то, что было тестами вполне покрыто (но про это никто не знал!), и это существенно уменьшило пользу от всего мероприятия.

Урок: гораздо лучше, когда с автотестами работают все представители QA-отдела. Пусть не все из них будут в состоянии написать тест с нуля, но сделать так, чтобы каждый инженер мог оценить состояние тестов в данный момент, понять причину их провалов, поправить простенькую ошибку или покрыть тестом новый несложный кейс, стоит.

Вместо послесловия

Надеюсь, что-то из того, о чем я многословно писал, окажется для вас полезным. Кому-то поможет найти шероховатости в процессах, другим подскажет выход из уже изучаемой проблемы. Даже если и не так, может, вы хотя бы посмеялись над тем, что я вам рассказал. Или хотя бы над моей наивностью. Главное — сделать мир лучше хоть в чем-то, хоть немножко. Правда?

Скачать материал

Скачать материал

Рабочие листы

к вашим урокам

Скачать

После выхода Приказов 381н и далее  785 н «Об утверждении требований к организации и проведению внутреннего контроля качества и безопасности медицинской деятельности», активно ведется обсуждение методик выполнения требований этого  приказа.

С 2019 года я  провела серию вебинаров, разъясняющих методику построения внутреннего контроля качества в мед. организации по новым требованиям. После вебинаров   у моих слушателей и подписчиков появилось много вопросов. Всех, у кого появились вопросы, я приглашаю на бесплатные консультации по скайпу. На консультациях специалисты мед. организаций, рассказывают, как у них идет внедрение внутреннего контроля качества. В итоге я увидела много ошибочных подходов.

Сделайте заявку  на бесплатную консультацию по  построению внутреннего контроля качества

В форме заявки пишите — «Консультация по ВКК»

В этой статье хочу предупредить эти ошибки.

Что такое – внутренний контроль качества медицинской организации?

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

На самом деле, это не что-то отдельно стоящее от управления медицинской организацией, это и есть система управления, но теперь целью этой системы должны стать качество   оказания медицинской помощи и безопасной деятельности медицинской организацией для удовлетворения требований потребителей деятельности медицинской организации, т.е. её пациентов.

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

Я обращаю Ваше внимание к системе менеджмента качества, так как внутренний контроль качества – это фактически подсистема системы менеджмента качества.

В одном из своих комментариев требований внутреннего контроля качества Михаил Мурашко, еще будучи генеральным директором «Росздравнадзора», также сказал, что внутренний контроль качества и безопасности медицинской деятельности мед. организации – это и есть система менеджмента качества.

В системах менеджмента качества определены принципы системного управления ( см. ГОСТ Р ИСО   9000-2015 «Системы менеджмента качества. Основные положения и словарь»):

1. Ориентация на потребителей

2. Лидерство (ответственность руководства)

3. Взаимодействие работников (вовлечение персонала)

4. Процессный подход

5. Улучшение

6. Принятие решений, основанное на свидетельствах

7. Менеджмент взаимоотношений

Эти принципы, как фундамент у здания, если хотя бы один принцип не будет соблюдаться, все здание завалится.

Итак, разберем основные системные ошибки при создании системы внутреннего контроля качества ( далее – ВКК) с точки зрения этих принципов.

Ошибка № 1. Отсутствие процессного подхода в управлении внутренним контролем качества, т.е. в управлении организацией.

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

Многие организации  при разработке ВКК по каждому направлению ВКК создают большое количество СОПов, алгоритмов, приказов, инструкций без понимания, как они между собой взаимоувязаны, какие будут показатели, как и кем они будут оцениваться. В итоге организация просто тонет в огромном документообороте. Персонал организации не понимает, какую практическую пользу все это несет, и активно сопротивляется выполнению требований ВКК.

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

Важно понимать, что СОПы – это процедуры процесса, а процедуры процесса – это есть функции, за выполнение которых в стандартах процесса  мы назначаем ответственных.

Процессный подход позволяет четко определить функции по участию в ВКК каждого сотрудника мед. организации и легко доработать должностные инструкции с учетом этих функций и ответственности за показатели результативности процесса.

Ошибка № 2. Руководитель мед. организации назначил уполномоченного по качеству: «пусть он все и делает».

Так, порой, размышляет не только руководитель медицинской организации, но и персонал.  Уполномоченный по качеству один разрабатывает всю документацию по ВКК. В итоге, вся система внутреннего контроля качества сводится к куче никому непонятных  документов. Все делается только для того, чтобы пройти проверки Росздравнадзора. Документы берутся из разных источников,  имеют разный формат, носят формальный характер. В такой ситуации ни о какой практической ценности внутреннего контроля качества говорить не приходится.

В этом подходе нарушен принцип — «взаимодействие, вовлечение работников».

Даже если вы приобрели готовый шаблон стандарта по процессу, соберите персонал, который компетентен в обсуждаемых вопросах, и вместе вычитайте документ, доработайте его под специфику вашей организации.

Документы – это инструменты управления, и чем более четко они проработаны, увязаны с реальными функциями персонала, тем проще будет навести порядок в организации. Каждый документ должен служить более правильному исполнению функций персонала организации, содержать критерии оценки качества выполнения установленных требований,  отражать взаимосвязи со смежными исполнителями. Чтобы документ был работающий и не вызывал отторжения персонала, который будет им пользоваться, используйте принцип «взаимодействия персонала», т.е. вовлекайте работников организации в разработку документов ВКК.

Назначьте ответственных по процессам (в терминологии менеджмента качества, ответственные по процессам ВКК могут называться «владельцами процессов»). Ответственных по процессам включите в комиссию по внутреннему контролю качества.

Ошибка № 3 Высшее руководство медицинской организации не принимает участия в работе комиссии по внутреннему контролю качества.

Это самая большая ошибка, так  как принцип — «Лидерство, ответственность руководства», — это самый главный системообразующий принцип.

В народном творчестве этот принцип отражается в поговорке – «рыба гниет с головы».

В такой ситуации персонал организации размышляет примерно так: «Если руководству это все не нужно, то зачем это нам?»

На комиссии по внутреннему контролю качества ответственные по процессам докладывают результативность своих процессов, анализируют причины, которые помешали достигнуть поставленных целей. Уполномоченный по качеству доносит информацию по проведенным внутренним аудитам. Анализируются поступившие жалобы от пациентов, рекламации от проверяющих органов.  Члены комиссии предлагают идеи по улучшению процессов и в целом системы внутреннего контроля качества. И только высшее руководство уполномочено принимать и утверждать выдвинутые идеи, утверждать решения.  Руководитель медицинской организации должен стать идейным вдохновителем всей системы внутреннего контроля качества, наставником и штурманом! Если этого не происходит, все превращается в формализм, и самые лучшие методики менеджмента качества перестают работать.

Сделайте заявку и получите бесплатно Положение по проведению совещаний комиссии по внутреннему контролю качества.

В форме заявки пишите — «Положение совещания комиссии по ВКК»

Ваш бизнес- консультант Светлана Лушникова

Задайте ваш вопрос по электронной почте shmk2@yandex.ru

 или позвоните на телефон/ WhatsApp +7- 962-029-77-72