Dmytro
1/2 Как обещал вверху 👆, расскажу о паре реальных проектов в интересных областях, над которыми мне довелось работать в последние годы. 💡 Работал над Callisto Eye — системой для микрохирургии глаза. Прежде всего удаление катаракты и имплантация искусственных…
2/2. Продолжение. Начало тут 👆
⚙️ В проекте Callisto Eye я отвечал за контроль качества. Один из главных вызовов — реалистичные автоматические тесты на реальном железе, которые симулируют целый рабочий день хирурга. Они должны были ловить даже мельчайшие сбои: функциональные ошибки, утечки памяти, взаимные блокировки (deadlocks), нарушения в синхронизации потоков, неожиданные задержки в UI — всё, что может проявиться только в долгосрочном, живом сценарии.
Тесты должны были не просто запускать отдельные функции или проверять отклик интерфейса, а наблюдать за поведением всей системы под нагрузкой, максимально приближённой к реальности операционной.
Среди множества задач особенно запомнились две.
Одна — чисто техническая.
Вторая — методологическая и по-настоящему новая.
🧩 Проблема 1: установка софта через CI (Continuous Integration) на кастомном "железе"
Callisto Eye — это не просто приложение, которое можно поставить из пакетного менеджера. Это полноценная ОС + tightly coupled системные компоненты, заточенные под определённый стек железа. Поэтому мы тестировали целые образы жёсткого диска, чтобы полностью воспроизвести окружение, как в операционной. CI должен был уметь автоматически прошивать систему этим образом, с нуля и надёжно — каждый раз. Сетевая загрузка (PXE boot) немного усложняла жизнь и с ней пришлось повозиться, но это хотя бы известная штука.. А вот вторая проблема стала по-настоящему новым вызовом.
🔍 Проблема 2: как быть уверенным, что сами автотесты не врут?
Автотест — это тоже софт. А если в нём баг? Что, если тест "зелёный", а на деле хирург в разгар операции увидит пустой экран?
Цена ошибки — зрение пациента. Поэтому пришлось разработать целую методологию и алгоритмический фреймворк, чтобы верифицировать надёжность самих тестов.
К сожалению, пока не оформил это в полноценную статью — руки не дошли. Хотя я неоднократно выступал на различных конференциях по медицинской технике с этой темой и рассказывал про это устно:
👉 https://medtechstars.eu/schedule/dmitrychibisov/
Из опубликованного — есть только старая статья (там ещё не всё понимание было сформировано, но всё же кое-что есть, если вдруг кому интересно):
📄 https://www.researchgate.net/publication/370595971_Patterns_of_Test_Automation
@easy_about_complex
#RealWorldProblems #SoftwareQuality #TestAutomation #SoftwareDevelopment #MedTech #Engineering
P.S. Следующий пост про real-world-проекты будет из области современного машиностроения и продвинутой индустриальной 3d-печати. Но сначала немного теории и вообще науки 👇👇👇
⚙️ В проекте Callisto Eye я отвечал за контроль качества. Один из главных вызовов — реалистичные автоматические тесты на реальном железе, которые симулируют целый рабочий день хирурга. Они должны были ловить даже мельчайшие сбои: функциональные ошибки, утечки памяти, взаимные блокировки (deadlocks), нарушения в синхронизации потоков, неожиданные задержки в UI — всё, что может проявиться только в долгосрочном, живом сценарии.
Тесты должны были не просто запускать отдельные функции или проверять отклик интерфейса, а наблюдать за поведением всей системы под нагрузкой, максимально приближённой к реальности операционной.
Среди множества задач особенно запомнились две.
Одна — чисто техническая.
Вторая — методологическая и по-настоящему новая.
🧩 Проблема 1: установка софта через CI (Continuous Integration) на кастомном "железе"
Callisto Eye — это не просто приложение, которое можно поставить из пакетного менеджера. Это полноценная ОС + tightly coupled системные компоненты, заточенные под определённый стек железа. Поэтому мы тестировали целые образы жёсткого диска, чтобы полностью воспроизвести окружение, как в операционной. CI должен был уметь автоматически прошивать систему этим образом, с нуля и надёжно — каждый раз. Сетевая загрузка (PXE boot) немного усложняла жизнь и с ней пришлось повозиться, но это хотя бы известная штука.. А вот вторая проблема стала по-настоящему новым вызовом.
🔍 Проблема 2: как быть уверенным, что сами автотесты не врут?
Автотест — это тоже софт. А если в нём баг? Что, если тест "зелёный", а на деле хирург в разгар операции увидит пустой экран?
Цена ошибки — зрение пациента. Поэтому пришлось разработать целую методологию и алгоритмический фреймворк, чтобы верифицировать надёжность самих тестов.
К сожалению, пока не оформил это в полноценную статью — руки не дошли. Хотя я неоднократно выступал на различных конференциях по медицинской технике с этой темой и рассказывал про это устно:
👉 https://medtechstars.eu/schedule/dmitrychibisov/
Из опубликованного — есть только старая статья (там ещё не всё понимание было сформировано, но всё же кое-что есть, если вдруг кому интересно):
📄 https://www.researchgate.net/publication/370595971_Patterns_of_Test_Automation
@easy_about_complex
#RealWorldProblems #SoftwareQuality #TestAutomation #SoftwareDevelopment #MedTech #Engineering
P.S. Следующий пост про real-world-проекты будет из области современного машиностроения и продвинутой индустриальной 3d-печати. Но сначала немного теории и вообще науки 👇👇👇
MedTech Stars - Die große Webkonferenz der Medizintechnik
QM für Medizinprodukte – Nutzen und Kosten der Software-Validierung im MedTech-Umfeld
Die ISO-Norm 13485 verlangt die Validierung von Prozessen und Werkzeugen, die bei der Entwicklung von Medizinprodukten und medizinischer Software eingesetzt werden. Über das „WIE“ einer Werkzeug-Validierung macht die ISO 13485 allerdings keine Aussagen. Deswegen…
👍6🔥3❤1