موضوع 3.7 — جانچ اور معیار کی یقین دہانی

ایک جملے میں: صحت اور نگہداشت میں، جانچ اور معیار کی یقین دہانی ریلیز سے پہلے کیا جانے والا مرحلہ نہیں بلکہ مسلسل نظم و ضبط ہے جو اس کے شواہد کا بڑا حصہ فراہم کرتا ہے کہ خدمت طبی طور پر محفوظ، قابلِ رسائی، محفوظ سلامتی والی، اور مریض کی نگہداشت کو چھونے کے لائق ہے۔

یہ صحت اور نگہداشت میں کیوں اہم ہے#

ہر ڈیجیٹل خدمت خرابیاں رکھتی ہے؛ واحد سوالات یہ ہیں کہ کتنی، کتنی سنگین، اور کیا آپ انہیں مریض کے متاثر ہونے سے پہلے پاتے ہیں یا بعد میں۔ صارفین کی ایپ میں غیر دریافت شدہ خرابی صارف کی دوپہر ضائع کرتی ہے۔ طبی نظام میں یہ غلط مریض کی الرجیاں دکھا سکتی ہے، بچوں کی دوا کی خوراک غلط طور پر گول کر سکتی ہے، یا خاموشی سے ریفرل ایسی قطار میں گرا سکتی ہے جسے کوئی مانیٹر نہیں کرتا۔ جانچ ان خرابیوں کو جلد پانے کی منظم کوشش ہے، اور معیار کی یقین دہانی کنٹرولز کا وسیع تر نظام ہے جو معیار کو قسمت یا بہادری پر منحصر ہونے سے روکتا ہے۔

اسی لیے صحت کے IT میں جانچ طبی تحفظ سے جدا نہیں۔ DCB0129/0160 کے خطرات کے لاگ (دیکھیے موضوع 1.6 — طبی تحفظ اور خطرات کا انتظام) میں درج خطرات تبھی حقیقتاً کم ہوتے ہیں جب جانچ ثابت کرے کہ کمی کام کرتی ہے اور ہر بعد کی تبدیلی کے بعد بھی کام کرتی رہتی ہے۔ وہ تحفظ کا مقدمہ جو دعویٰ کرے "نظام دہری نسخہ نویسی روکتا ہے" بغیر دہرائی جا سکنے والی جانچ کے، یقین دہانی نہیں بلکہ دعویٰ ہے۔ جانچ طبی تحفظ کی دلیل کے نیچے شواہد کی بنیاد ہے۔

داؤ مساوات اور عوامی اعتماد کے بھی ہیں۔ وہ خدمت جو رسائی کے معیارات کے مقابل کبھی نہیں جانچی گئی بطور ڈیفالٹ معذور صارفین کو خارج کرے گی (دیکھیے موضوع 1.9 — ڈیجیٹل شمولیت اور رسائی)۔ وہ خدمت جو صرف زندہ مریضوں کے ریکارڈ کی نقلوں سے جانچی جائے اس ڈیٹا کی خلاف ورزی کا خطرہ رکھتی ہے جو اس اعتماد کو کھوکھلا کرتی ہے جس پر NHS منحصر ہے۔ اور رقم معمولی نہیں: لائیو آپریشن میں پائی گئی خرابی دوبارہ کام کرنے کی لاگت ڈیزائن میں پکڑنے سے کئی گنا ہے، اور سنگین طبی واقعہ دونوں سے کہیں مہنگا ہے۔ ناکافی جانچ بچت نہیں؛ یہ مؤخر اور پھولا ہوا بل ہے، جو کبھی نقصان میں ادا ہوتا ہے۔

بنیادی تصورات#

جانچ بمقابلہ معیار کی یقین دہانی۔ جانچ نقائص تلاش کرنے اور رویے کی تصدیق کے لیے نظام کو آزمانے کا عمل ہے۔ معیار کی یقین دہانی عملوں کا وسیع تر مجموعہ ہے — معیارات، جائزے، "مکمل" کی تعریفیں، دروازے — جو معیار کو آخر میں معائنے سے داخل کرنے کے بجائے اندر بناتے ہیں۔ جانچ بتاتی ہے کہ آیا یہ تعمیر کام کرتی ہے؛ QA وہ وجہ ہے کہ آپ کی تعمیریں عموماً کام کرتی ہیں۔ دونوں اہم ہیں، اور رہنما اکثر پہلے کو فنڈ دیتے اور دوسرے کو نظر انداز کرتے ہیں۔

جانچ کا اہرام اور بائیں طرف کھسکاؤ۔ صحت مند جانچ کی حکمت عملی میں بہت سے تیز، سستے یونٹ ٹیسٹ (انفرادی افعال کی جانچ)، کم انضمام کے ٹیسٹ (جانچ کہ اجزا مل کر کام کرتے ہیں)، اور چند سست، مہنگے سرے سے سرے تک ٹیسٹ (پورے صارف کے سفر کی جانچ) ہوتے ہیں۔ یہ "جانچ کا اہرام" رائے کو تیز اور دیکھ بھال کو سستا رکھتا ہے۔ یہ بائیں طرف کھسکاؤ کی جانچ سے جڑتا ہے — جانچ کو دورانیے میں پہلے لانا، تاکہ نقائص ریلیز سے پہلے ہڑبڑی کی چھان بین میں پائے جانے کے بجائے سستے میں ڈیزائن سے نکال دیے جائیں۔ الٹا اہرام (زیادہ تر دستی سرے سے سرے تک ٹیسٹ) سست، نازک، اور تنبیہ کی علامت ہے۔

فعلی اور غیر فعلی جانچ۔ فعلی جانچ پوچھتی ہے "کیا نظام وہ کرتا ہے جو اسے کرنا چاہیے؟" — درست حساب، درست کام کے بہاؤ، درست ڈیٹا۔ غیر فعلی جانچ پوچھتی ہے "یہ کتنی اچھی طرح برتاؤ کرتا ہے؟" — کارکردگی اور بوجھ (کیا یہ جواب دہ رہتا ہے جب پورا ٹرسٹ صبح 08:00 بجے لاگ اِن کرے؟)، سلامتی (کیا اسے توڑا جا سکتا ہے؟)، بھروسا، اور رسائی۔ صحت اور نگہداشت میں غیر فعلی ناکامیاں اکثر سب سے خطرناک ہیں: فعلی طور پر کامل نظام جو ری سس کال کے دوران ٹائم آؤٹ ہو جائے طبی طور پر ناکام ہو چکا ہے۔

رجعت کی جانچ۔ رجعت کی جانچ تبدیلی کے بعد موجودہ ٹیسٹ دوبارہ چلاتی ہے تاکہ تصدیق کرے کہ ایک چیز ٹھیک کرنے یا جوڑنے سے دوسری نہیں ٹوٹی۔ لائیو طبی نظاموں میں یہ واحد سب سے اہم تحفظ کی عادت ہے: زیادہ تر طبی سافٹ ویئر کے واقعات نئی خصوصیات سے نہیں بلکہ ان تبدیلیوں سے آتے ہیں جنہوں نے خاموشی سے کام کرتا رویہ توڑ دیا۔ قابلِ اعتماد رجعت کا مجموعہ وہ ہے جو آپ کو سانس روکے بغیر لائیو نظام بدلنے دیتا ہے۔

جانچ کی خودکاری اور مسلسل انضمام۔ جانچ کی خودکاری سافٹ ویئر سے ٹیسٹ دہرائے جا سکنے طریقے سے چلاتی ہے، تاکہ بڑا مجموعہ ہر تبدیلی پر منٹوں میں چلے۔ مسلسل انضمام — بار بار انضمام اور تبدیلیوں کی خودکار جانچ — کے ساتھ مل کر یہ جانچ کو کبھی کبھار کے واقعے سے مسلسل حفاظتی جال میں بدل دیتی ہے (دیکھیے موضوع 3.5 — ترسیل کے دورانیے)۔ خودکاری انسانی فیصلے کی جگہ نہیں لیتی؛ یہ انسانوں کو وہ تحقیقی اور طبی جانچ کرنے کے لیے آزاد کرتی ہے جو مشینیں نہیں کر سکتیں۔

قبولیت کی جانچ۔ قبولیت کی جانچ، اور مخصوص طور پر صارف کی قبولیت کی جانچ (UAT)، وہ جگہ ہے جہاں حقیقی معالجین اور صارفین لائیو ہونے سے پہلے تصدیق کرتے ہیں کہ نظام ان کے اصل سیاق میں کام کرتا ہے۔ آپریشنل قبولیت کی جانچ (OAT) تصدیق کرتی ہے کہ خدمت چلائی، بیک اپ کی اور بحال کی جا سکتی ہے۔ حقیقی آخری صارفین کے ساتھ UAT وہ کام کے بہاؤ کی عدم مطابقتیں پکڑتی ہے جو کوئی ڈویلپر ٹیسٹ نہیں پکڑے گا۔

جانچ کے ماحول اور محفوظ جانچ کا ڈیٹا۔ نفاذ کا ماحول وہ نظام ہے جہاں سافٹ ویئر چلتا ہے — عموماً ڈویلپمنٹ، ٹیسٹ، اسٹیجنگ، اور پیداوار کی سطحیں۔ جانچ کو پیداوار سے مماثل ماحول چاہیے لیکن اسے کبھی لاپروائی سے زندہ مریض کا ڈیٹا استعمال نہیں کرنا چاہیے۔ محفوظ مشق مصنوعی ڈیٹا (مصنوعی طور پر بنایا گیا) یا مناسب طور پر گمنام ڈیٹا استعمال کرتی ہے، تاکہ ریفرل فارم کی جانچ کسی حقیقی شہری کی تشخیص لیک نہ کر سکے۔

معیار کے دروازے، "مکمل" کی تعریف، اور نقص کا انتظام۔ "مکمل" کی تعریف بیان کرتی ہے کہ "ختم" کا کیا مطلب ہے (جانچا ہوا، قابلِ رسائی، دستاویزی، تحفظ کے لحاظ سے جائزہ شدہ) تاکہ معیار ہر خصوصیت کے لیے قابلِ مذاکرات نہ ہو۔ معیار کے دروازے وہ چیک پوائنٹ ہیں جنہیں تبدیلی کو آگے بڑھنے کے لیے پاس کرنا ہے۔ نقص کی درجہ بندی پائے گئے نقائص کو شدت اور طبی اثر کے لیے جانچنے، اور فیصلہ کرنے کا نظم و ضبط والا عمل ہے کہ کیا ٹھیک کرنا ہے، کب، اور کیا معلوم مسئلے کے طور پر بھیجا جا سکتا ہے۔

بہترین طریقے#

1. اہرام بنائیں اور جانچ کو بائیں طرف کھسکائیں۔ تیز خودکار یونٹ اور انضمام کے ٹیسٹ کی وسیع بنیاد میں سرمایہ کاری کریں جو ہر تبدیلی پر چلیں، تاکہ نقائص لکھے جانے کے منٹوں میں سامنے آئیں نہ کہ ہفتوں بعد UAT میں۔ سست سرے سے سرے تک ٹیسٹ مٹھی بھر نازک سفروں کے لیے رکھیں — نسخہ، ریفرل، شناخت کا ملاپ۔ یہ جانچ کو سستا اور تیز بناتا ہے، جو دراصل ٹیموں کو زیادہ کرنے پر آمادہ کرتا ہے۔

2. رجعت کی جانچ کو طبی تحفظ کا کنٹرول سمجھیں۔ کسی بھی تبدیلی کے لائیو طبی نظام تک پہنچنے سے پہلے، خودکار رجعت کے مجموعے کو تصدیق کرنی ہوگی کہ موجودہ، تحفظ سے متعلق رویہ اب بھی کام کرتا ہے۔ DCB0129/0160 کے خطرات کے لاگ سے اپنے اعلیٰ ترین خطرات کو براہِ راست نام والے رجعت کے ٹیسٹوں سے نقشہ بنائیں، تاکہ کوئی تبدیلی جو معلوم خطرہ دوبارہ متعارف کرائے خودکار طور پر تعمیر ناکام کر دے۔ یہی وہ طریقہ ہے جو آپ کو لائیو نظاموں پر خاموش طبی خطرہ جمع کیے بغیر تکرار کرنے دیتا ہے۔

3. بطور ڈیفالٹ زندہ مریض کے ڈیٹا سے کبھی جانچ نہ کریں۔ جانچ اور اسٹیجنگ کے ماحول کو مصنوعی یا مضبوطی سے گمنام ڈیٹا کے ساتھ فراہم کریں، جسے پیداوار جیسی معلومات کی نظامت اور DPIA کا نظم و ضبط چلائے (دیکھیے موضوع 1.7 — معلومات کی نظامت، ڈیٹا کا تحفظ اور سائبر سیکیورٹی)۔ اگر کسی مخصوص جانچ کو واقعی پیداوار جیسا ڈیٹا چاہیے تو اسے دستاویزی قانونی بنیاد، کم سے کم کرنے، اور آڈٹ کے ساتھ قابو شدہ استثنا سمجھیں — معمول کی سہولت نہیں۔ ٹیسٹ ڈیٹا بیس بھی مریضوں کا ڈیٹا بیس ہے۔

4. غیر فعلی تقاضوں کی جانچ فعلی جتنی سنجیدگی سے کریں۔ حقیقت پسندانہ چوٹی کی مانگ کے مقابل کارکردگی اور بوجھ کی جانچ چلائیں — شفٹ کی حوالگی، پیر کی صبح کے لاگ اِن، علاقائی بندش جو ٹریفک موڑ دے — کیونکہ طبی نظام جو بوجھ تلے رینگنے لگے وہ ٹھیک اس وقت ناکام ہوا جب اہم تھا۔ سلامتی کی جانچ اور ویب کنٹینٹ ایکسیسبیلٹی گائیڈ لائنز (WCAG) کے مقابل رسائی کی جانچ کو مستقل، غیر اختیاری ٹیسٹ کی اقسام کے طور پر شامل کریں۔ غیر فعلی نقائص کو ٹالنا آسان اور پیداوار میں دریافت کرنا مہنگا ہے۔

5. رسائی کی جانچ خودکار کریں، پھر لوگوں سے تصدیق کریں۔ خودکار WCAG جانچ مسائل کا بامعنی حصہ (غائب لیبل، کمزور کنٹراسٹ، ڈھانچہ) ہر تعمیر پر سستے میں پکڑتی ہے، لیکن وہ مسائل چھوڑ دیتی ہے جو معاون ٹیکنالوجی کے حقیقی صارفین کے لیے سب سے زیادہ اہم ہیں۔ خودکار اسکیننگ کو اسکرین ریڈرز، صرف کی بورڈ کی نیویگیشن، اور بڑا کرنے استعمال کرنے والے لوگوں کی دستی جانچ سے جوڑیں۔ رسائی سرکاری اداروں کے لیے قانونی فرض ہے اور تحفظ کا مسئلہ جب خارج شخص معالج ہو یا اپنی نگہداشت سنبھالتا مریض۔

6. حقیقی معالجین کے ساتھ حقیقت پسندانہ حالات میں صارف کی قبولیت کی جانچ چلائیں۔ UAT ان اصل لوگوں کے ساتھ شیڈول کریں جو نظام استعمال کریں گے — نرسیں، جی پیز، منتظمین، فارماسسٹ — حقیقی کام کے بہاؤ چلاتے ہوئے، مثالی طور پر ایسی ترتیب میں جو وارڈ یا کلینک کی عکاسی کرے، خاموش میٹنگ روم میں نہیں۔ ان کی رائے خطرناک کام کے بہاؤ کی عدم مطابقتیں پکڑتی ہے (غلط لمحے پر دکھائی گئی انتباہ، ڈیفالٹ جو غلطی کی دعوت دے) جنہیں یونٹ ٹیسٹ نہیں پکڑ سکتے۔ طبی بیک فل کا وقت بجٹ کریں تاکہ UAT خیر سگالی میں نچوڑے جانے کے بجائے ٹھیک سے ہو۔

7. "مکمل" کی تعریف اور معیار کے دروازے صریح اور نافذ بنائیں۔ اپنے سیاق کے لیے اتفاق کریں کہ "مکمل" کا کیا مطلب ہے — ٹیسٹ پاس، رسائی کی مطابقت، سلامتی کی اسکین صاف، طبی تحفظ کا جائزہ مکمل، دستاویزات اپ ڈیٹ — اور اسے دروازے کے طور پر نافذ کریں، خواہش کے طور پر نہیں۔ "مکمل" کی تعریف جو لکھی ہو مگر آخری تاریخ کے دباؤ میں معمول سے چھوڑ دی جائے کسی تعریف کے نہ ہونے سے بدتر ہے، کیونکہ یہ غیر محفوظ کام کو مکمل کے طور پر دھو دیتی ہے۔ دروازے جہاں ممکن ہو خودکار ہونے چاہییں تاکہ خاموشی سے چھوڑے نہ جا سکیں۔

8. طبی شدت کو ذہن میں رکھ کر نقائص کی درجہ بندی اور انتظام کریں۔ ہر نقص کا جائزہ صرف تکنیکی شدت نہیں بلکہ طبی اثر اور امکان کے لیے لیں، اپنے خطرات کے لاگ جیسے خطرے کے عدسے سے۔ ظاہری خرابی انتظار کر سکتی ہے؛ وہ نقص جو غلط خوراک میں حصہ ڈال سکے لائیو ہونے کی تاریخ سے قطع نظر ریلیز روکتا ہے۔ نقائص کا نظر آنے والا رجسٹر رکھیں، اور لائیو ہونے پر بھیجے معلوم مسائل کے بارے میں دیانت دار رہیں کہ وہ قبول شدہ، کم کیے گئے خطرات کے طور پر ہیں، چھپائے ہوئے نہیں۔

9. جانچ کو ترسیل کی پائپ لائن کے اندر شامل کریں، اس کے بعد نہیں۔ خودکار ٹیسٹ، سلامتی کی اسکیننگ، اور رسائی کی جانچ کو مسلسل انضمام اور ترسیل کی پائپ لائن میں جوڑیں تاکہ ہر تبدیلی آگے بڑھنے سے پہلے جانچی جائے (دیکھیے موضوع 3.5 — ترسیل کے دورانیے)۔ یہ معیار کو مسلسل اور سستا بناتا ہے، اور اس کا مطلب ہے کہ جانچی ہوئی اصلاح جلد نافذ کرنے کی صلاحیت — جو خود تحفظ کا کنٹرول ہے — ہمیشہ دستیاب ہے۔ دستی، منصوبے کے آخر کی جانچ کے مرحلے سست، دیر سے، اور وقت کم ہونے پر سب سے پہلے قربان ہونے والی چیز ہیں۔

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات#

1. اگر ہم کل اپنے لائیو طبی نظام میں ایک چیز بدلیں تو ہمیں کتنا یقین ہے کہ اگر اس سے کچھ اور ٹوٹا تو ہمیں مریض سے پہلے پتا چل جائے گا؟ یہ سوال آپ کی رجعت کی جانچ کی پختگی اور آپ کے تحفظ کے دعووں کی دیانت کو پرکھتا ہے۔ زیادہ تر سنگین طبی سافٹ ویئر کے واقعات انوکھی نئی ناکامیاں نہیں بلکہ رجعتیں ہیں: وہ تبدیلی جس نے خاموشی سے وہ رویہ توڑ دیا جسے سب مستحکم سمجھتے تھے، جو صرف تب دریافت ہوا جب کسی معالج یا مریض سے ٹکرایا۔ اچھی بحث کسی حالیہ حقیقی تبدیلی کا سراغ ان ٹیسٹوں تک لگاتی ہے جو رجعت پکڑ لیتے، اور پوچھتی ہے کہ آیا DCB0129/0160 کے خطرات کے لاگ کے اعلیٰ ترین خطرات میں سے ہر ایک کے پیچھے خودکار ٹیسٹ ہے جو خطرے کے دوبارہ ابھرنے پر ناکام ہو۔ سامنے لانے کی کشش اصلاحات تیزی سے بھیجنے کے دباؤ اور یہ ثابت کرنے کے نظم و ضبط کے درمیان ہے کہ کچھ اور نہیں ٹوٹا — اور آیا آپ کی پائپ لائن وہ ثبوت خودکار بناتی ہے یا اسے کسی کے یاد رکھ کر جانچنے پر چھوڑتی ہے۔ سوچیں کہ آپ کا ٹیسٹ مجموعہ چلنے میں کتنا وقت لیتا ہے، کیا یہ ہر تبدیلی پر چلتا ہے، اور کیا کسی نے آخری تاریخ تک پہنچنے کے لیے ناکام ہوتے ٹیسٹ خاموشی سے بند کیے۔ دیانت دار جواب "ہمارے پاس اپنے طبی خطرات سے بندھا رجعت کا مجموعہ ہے اور ہم اس پر بھروسا کرتے ہیں" اور "ہم اپنی کی ہوئی تبدیلی جانچتے ہیں اور امید رکھتے ہیں" میں فرق کرتا ہے۔ اگر جواب بعد والا ہے تو آپ ایسا طبی خطرہ اٹھا رہے ہیں جو آپ دیکھ نہیں سکتے۔

2. ہمارا ٹیسٹ ڈیٹا کہاں سے آتا ہے، اور کیا کوئی ٹیسٹ کبھی حقیقی مریض کی معلومات بے نقاب کر سکتا ہے؟ جانچ کے ماحول ڈیٹا کی خلاف ورزی کا عام اور کم جانچا گیا راستہ ہیں، کیونکہ دباؤ تلے ٹیمیں آسان ترین حقیقت پسندانہ ڈیٹا کی طرف ہاتھ بڑھاتی ہیں — پیداوار کی نقل — اور نتیجے کے مریض ریکارڈ پھر کم محفوظ ٹیسٹ نظاموں، لیپ ٹاپس، یا سپلائر کے ماحول میں پڑے رہتے ہیں۔ یہ سوال ٹیم سے کہتا ہے کہ ہر ٹیسٹ اور اسٹیجنگ ماحول کا سراغ اس کے ڈیٹا کے ماخذ تک لگائے، اور دیانت داری سے مانے کہ آیا زندہ ڈیٹا کی "بس اس بار" کی نقلیں معمول بن چکی ہیں۔ بحث کے قابل سمجھوتا حقیقت پسندی بمقابلہ تحفظ ہے: مصنوعی اور گمنام ڈیٹا محفوظ تر ہے لیکن حقیقی ڈیٹا کے بے ترتیب کنارے کے معاملات چھوڑ سکتا ہے، جبکہ زندہ ڈیٹا حقیقت پسندانہ ہے لیکن نظامت اور خلاف ورزی کی ذمہ داری، اور حقیقی گمنامی نظر آنے سے مشکل ہے کیونکہ ملانے پر ریکارڈز کی دوبارہ شناخت ہو سکتی ہے۔ ٹھوس زاویوں میں شامل ہے کہ جانچ کے ماحول تک کون رسائی رکھتا ہے، کیا ٹیسٹ ڈیٹا بیس پیداوار کی طرح خفیہ اور آڈٹ ہوتے ہیں، اور کیا آپ کے سپلائرز کے جانچ کے ماحول اسی معیار پر پورے اترتے ہیں۔ مضبوط جواب دانستہ حکمت عملی بیان کرتا ہے — بطور ڈیفالٹ مصنوعی ڈیٹا، درست گمنامی، زندہ ڈیٹا صرف دستاویزی، کم سے کم، وقت کی حد والے استثنا کے طور پر — معلومات کی نظامت کی تفتیش کے منتظر حادثے کے بجائے۔

3. جب لائیو ہونے کی تاریخ اور معیار کا معیار ٹکرائیں تو اصل میں کیا ڈھیلا ہوتا ہے — اور فیصلہ کون کرتا ہے؟ ہر ترسیل بالآخر اس لمحے کا سامنا کرتی ہے جب جانچ مکمل نہیں، کوئی نقص حل نہیں، یا رسائی کی مطابقت نامکمل ہے، اور لانچ قریب ہے؛ آپ کا ادارہ اس لمحے میں کیسے برتاؤ کرتا ہے ظاہر کرتا ہے کہ آیا معیار حقیقی کنٹرول ہے یا محض آرزو۔ یہ سوال ٹیم سے کہتا ہے کہ آخری بار جب ایسا ہوا اسے یاد کرے اور دیانت داری سے بیان کرے کہ کیا کاٹا گیا: کیا یہ ظاہری بیک لاگ تھا، یا رجعت کی جانچ، UAT، یا رسائی کا آڈٹ؟ کشمکش حقیقی ہے اور اسے ہاتھ ہلا کر ٹالنا نہیں چاہیے — تاریخیں اہم ہیں، فنڈنگ کے چکر بے رحم ہیں، اور لامتناہی جانچ خود ناکامی کا طریقہ ہو سکتی ہے — لیکن حل طبی اور مساوات کے خطرے سے منظم ہونا چاہیے، جو سب سے زور سے چیخے اس سے نہیں۔ بحث کریں کہ لانچ کو معیار کی بنیاد پر کیریئر کے خطرے کے بغیر روکنے کا اختیار کس کے پاس ہے، کیا آپ کی "مکمل" کی تعریف کبھی رسمی طور پر چھوڑی جاتی ہے اور کس کے ذریعے، اور کیا لائیو ہونے پر بھیجے گئے معلوم نقائص کو قبول شدہ خطرات کے طور پر ریکارڈ کیا جاتا ہے یا خاموشی سے دفن کر دیا جاتا ہے۔ اچھا جواب واضح، نامزد فیصلے کا راستہ دکھاتا ہے، ایک روشن لکیر جس کے نیچے نقص تاریخ سے قطع نظر ریلیز روکتا ہے (کچھ بھی جو مریض کے نقصان میں حصہ ڈال سکے)، اور ایسی ثقافت جہاں "ابھی نہیں، یہ محفوظ نہیں" کہنے کو سزا کے بجائے انعام ملتا ہے۔

4. کیا ہمارے ٹیسٹ ان چیزوں کا احاطہ کر رہے ہیں جو مریض کو نقصان پہنچا سکتی ہیں، یا صرف ان کا جنہیں جانچنا آسان ہے؟ سبز تعمیر تبھی تسلی بخش ہے جب اس کے پیچھے ٹیسٹ حقیقی طبی خطرات کو آزمائیں، اور یہ بے آرام حد تک عام ہے کہ صحت مند دکھتا احاطے کا عدد ایسے مجموعے پر بیٹھا ہو جو معمولی گیٹرز اور سیٹرز جانچتا ہے جبکہ بگاڑ کا اسکور، شناخت کا ملاپ، اور الرجی کی نمائش بغیر جانچ کے رہ جائیں۔ یہ سوال ٹیم سے کہتا ہے کہ ٹیسٹ کا مجموعہ DCB0129/0160 کے خطرات کے لاگ اور اعلیٰ ترین خطرے والے صارف کے سفروں کے مقابل رکھے اور خطرہ بہ خطرہ پوچھے، "اگر یہ غلط ہوا تو کون سا نام والا ٹیسٹ ناکام ہوگا؟" کشمکش یہ ہے کہ احاطے کے پیمانے حجم کو انعام دیتے ہیں، خطرے کی مطابقت کو نہیں، اور ٹیمیں فیصد کے پیچھے بھاگنے پر مائل ہوتی ہیں بجائے ان بے ڈھنگے، خودکار کرنے میں مشکل معاملات کا سامنا کرنے کے — حدی قدریں، غائب ان پٹس، غیر معمولی طبی امتزاج — جو ٹھیک وہ جگہ ہیں جہاں مریض زخمی ہوتے ہیں۔ ٹھوس زاویوں میں شامل ہے کہ آیا حدی اور کنارے کے معاملات جانچے جاتے ہیں، آیا تحقیقی اور طبی جانچ (وہ فیصلہ جو مشینیں بدل نہیں سکتیں) کی خودکاری کے ساتھ جگہ ہے، اور آیا کسی نے کبھی حقیقی واقعے کا سراغ اس خلا تک لگایا جو ٹیسٹوں کو پکڑ لینا چاہیے تھا۔ دیانت دار جواب خطرے سے وزن شدہ احاطے کی بات کرتا ہے اور اعلیٰ ترین خطرات کی حفاظت کرنے والے ٹیسٹوں کا نام لے سکتا ہے، ایک واحد فیصد کو اس طرح نقل کرنے کے بجائے جیسے وہ یقین دہانی ہو۔

5. جب ہم رسائی کی جانچ کرتے ہیں تو کیا حقیقی معذور صارفین اور حقیقی معالجین کمرے میں ہیں، یا صرف خودکار اسکینر؟ خودکار WCAG جانچ سستی ہے اور ہر تعمیر پر ہونی چاہیے، لیکن وہ ان رکاوٹوں کا صرف حصہ پکڑتی ہے جو واقعی لوگوں کو خارج کرتی ہیں، اور خدمت ہر خودکار قاعدہ پاس کر کے بھی اسکرین ریڈر یا صرف کی بورڈ سے ناقابلِ استعمال رہ سکتی ہے۔ یہ سوال پوچھتا ہے کہ آیا آپ کی رسائی اور صارف کی قبولیت کی جانچ معاون ٹیکنالوجی استعمال کرنے والے حقیقی لوگوں اور حقیقی کام کے بہاؤ پر چلتے حقیقی معالجین تک پہنچتی ہے، یا "ہم نے رسائی جانچی" خاموشی سے "اسکینر سبز تھا" کا مطلب رکھتا ہے۔ سامنے لانے کا سمجھوتا لاگت اور سازوسامان بمقابلہ دیانت ہے: معاون ٹیکنالوجی کے صارفین کو بھرتی کرنا اور حقیقت پسندانہ UAT کے لیے طبی وقت کی بیک فل کرنا مہنگا اور چھوڑنا آسان ہے، پھر بھی چھوڑنا ہی وہ طریقہ ہے جس سے قانونی فرض ٹوٹتا اور خطرناک کام کے بہاؤ کی عدم مطابقت — غلط لمحے پر انتباہ، ڈیفالٹ جو غلطی کی دعوت دے — لائیو وارڈ تک پہنچتی ہے۔ بات کریں کہ آپ کسے شامل کرتے ہیں، وہ کتنے نمائندہ ہیں، کیا جانچ ایسی ترتیب میں ہوتی ہے جو کلینک کی عکاسی کرے نہ کہ خاموش میٹنگ روم، اور وہ جو پاتے ہیں اس کا آپ کیا کرتے ہیں۔ مضبوط جواب خودکار جانچ کو معذور صارفین کی دستی جانچ اور معالج کی قیادت والے UAT کے ساتھ مستقل، بجٹ شدہ مشق کے طور پر بیان کرتا ہے، لائیو ہونے سے پہلے ایک بار نشان زد خانے کے طور پر نہیں۔

6. جب تبدیلی ہمارے نظام اور کسی اور کے نظام کے درمیان حد پار کرے تو جوڑ کی جانچ کون کرتا ہے — اور کیا ہمیں پتا چلے گا اگر وہ ٹوٹ جائے؟ جدید صحت اور نگہداشت کی خدمات مربوط نظاموں کے مجموعے ہیں — EPR، قومی ریڑھ کی خدمت، پیتھالوجی فیڈ، تیسرے فریق سپلائر کا ماڈیول — اور سب سے خطرناک نقائص اکثر کسی ایک جزو کے اندر نہیں بلکہ ان کے جوڑوں میں رہتے ہیں، جہاں انٹرفیس کے ایک طرف کی تبدیلی خاموشی سے دوسری طرف کو توڑ دیتی ہے۔ یہ سوال ٹیم سے کہتا ہے کہ اپنے اہم انضمام کا نقشہ بنائے اور ہر ایک کے لیے پوچھے کہ سرے سے سرے تک ٹیسٹ کا مالک کون ہے، حد کے پار کون سا مصنوعی ڈیٹا بہتا ہے، اور سپلائر کی ریلیز میں توڑنے والی تبدیلی مریضوں تک پہنچنے سے پہلے کیسے پکڑی جائے گی۔ کشمکش یہ ہے کہ کوئی ایک ٹیم مشترکہ انٹرفیس کے لیے مکمل ذمہ دار محسوس نہیں کرتی، معاہدے اور تبدیلی کے مشاورتی بورڈ مختلف رفتار پر چلتے ہیں، اور تنظیمی حدود پار جانچ سست، سیاسی، اور قسمت پر چھوڑنا آسان ہے۔ ٹھوس زاویوں میں معاہدے اور انٹرفیس کے ٹیسٹ، مشترکہ جانچ کے ماحول، سپلائر کی تبدیلی کے نوٹس کیسے سنبھالے جاتے ہیں، اور آیا آپ کا رجعت کا مجموعہ مربوط سفر (ریفرل بھیجا، موصول، تسلیم) کو آزماتا ہے نہ کہ صرف اپنا آدھا۔ دیانت دار جواب ہر جوڑ کے ذمہ دار کا نام لیتا ہے اور ایسا طریقہ دکھاتا ہے — جہاں ممکن ہو خودکار — جو حد پار رجعت پکڑے، یہ فرض کرنے کے بجائے کہ دوسرے فریق کے پاس احاطہ ہے۔

عملی مثال: صحت اور نگہداشت کی ایک مثال#

ایک ایکیوٹ NHS ٹرسٹ اپنے برقی مریض ریکارڈ کے اندر نیا برقی مشاہدات اور ابتدائی انتباہی اسکور (EWS) ماڈیول جاری کر رہا ہے، کاغذی چارٹس کی جگہ لیتے ہوئے جن پر نرسیں اہم علامات درج کرتی ہیں اور نظام بگاڑ کا اسکور شمار کرتا ہے۔ طبی خطرہ واضح ہے: غلط اسکور کا مطلب ہو سکتا ہے کہ بگڑتے مریض کو اوپر نہیں بھیجا گیا۔

ٹیم شروع ہی سے اہرام بناتی ہے۔ یونٹ ٹیسٹ EWS کے حساب کو قومی اسکورنگ کے قواعد کے مقابل احاطہ کرتے ہیں، بشمول حدی معاملات (ٹھیک وہ حدیں جہاں اسکور اوپر بھیجنے میں بدلتا ہے) اور بے ڈھنگے ان پٹس (غائب سانس کی شرح، اضافی آکسیجن پر مریض)۔ انضمام کے ٹیسٹ تصدیق کرتے ہیں کہ اسکور درست طور پر اوپر بھیجنے کے الرٹ اور نرسنگ کے کاموں کی فہرست تک بہتا ہے۔ سرے سے سرے تک ٹیسٹوں کا چھوٹا مجموعہ بستر کے پاس اندراج سے متحرک الرٹ تک پورے سفر کو آزماتا ہے۔ DCB0160 کے خطرات کے لاگ کا ہر خطرہ نام والے ٹیسٹوں سے نقشہ بند ہے، اور پورا مجموعہ مسلسل انضمام کی پائپ لائن میں ہر تبدیلی پر خودکار چلتا ہے۔

جانچ کے ماحول مصنوعی مریضوں کے ساتھ فراہم کیے جاتے ہیں — بگڑتی راہوں سمیت حقیقت پسندانہ اہم علامات کے نمونے — تاکہ کوئی حقیقی ریکارڈ پیداوار سے باہر نہ جائے۔ کارکردگی کی جانچ شفٹ کی حوالگی پر مکمل وارڈ راؤنڈ کی نقل کرتی ہے، تصدیق کرتے ہوئے کہ چوٹی کے بوجھ پر الرٹ سیکنڈوں میں چلتے ہیں۔ رسائی کی جانچ، ہر تعمیر پر خودکار اور اسکرین کو بڑا کرنے والی نرس کے ساتھ دستی طور پر تصدیق شدہ، کم کنٹراسٹ کا الرٹ بینر پکڑتی ہے۔

پائلٹ وارڈ پر UAT، حقیقی نرسوں کے ساتھ جو نقلی منظرنامے چلاتی ہیں، کام کے بہاؤ کی خرابی ظاہر کرتی ہے جو کسی ڈویلپر نے نہیں دیکھی تھی: تصدیق کا مکالمہ اسکور کے بعد ظاہر ہوتا تھا، عملے کو اسے بے سوچے مسترد کرنے پر آمادہ کرتا ہوا۔ ٹیم بہاؤ دوبارہ ڈیزائن کرتی ہے اور رجعت کا ٹیسٹ شامل کرتی ہے۔ لائیو ہونے پر، تین ظاہری نقائص دستاویزی، قبول شدہ مسائل کے طور پر بھیجے جاتے ہیں؛ دو جو حساب کو چھوتے تھے ٹھیک کیے گئے اور پاس ہونے تک ریلیز روکی؛ اور تحفظ کا مقدمہ ٹیسٹ کے شواہد کا براہِ راست حوالہ دیتا ہے۔ لائیو آپریشن کے چھ مہینے بعد، کاموں کی فہرست میں معمول کی تبدیلی رجعت کے ٹیسٹ کو متحرک کرتی ہے جو، بغیر پکڑے، اوپر بھیجنے کے الرٹ کو دبا دیتی — پائپ لائن میں پکڑی گئی، نفاذ سے پہلے ٹھیک ہوئی، کبھی وارڈ تک نہ پہنچی۔

شعبہ جاتی زاویے#

اسٹارٹ اپ#

چھوٹی ڈیجیٹل صحت کی کمپنی کا فائدہ ہے کہ وہ پہلے دن سے خودکار جانچ اور مسلسل انضمام کو اپنی بنیاد میں رکھ سکتی ہے، کھولنے کو کوئی پرانا دستی جانچ کا عمل نہیں، اور ایسی تیز، محفوظ تکرار حاصل کر سکتی ہے جس پر بڑا ٹرسٹ رشک کرے۔ خطرہ جانچ کو عیاشی سمجھ کر ٹالنا ہے جبکہ مصنوعہ اور منڈی کی موزونیت کا پیچھا ہو، اور غیر فعلی اور طبی تحفظ کی جانچ کم کرنا جس کا ابھی کوئی ابتدائی گاہک مطالبہ نہیں کر رہا۔ بانی کو یاد رکھنا چاہیے کہ DCB0129 کی ذمہ داریاں کمپنی کے سائز سے قطع نظر مینوفیکچرر پر لاگو ہیں، اس لیے تحفظ کے دعوے کے پیچھے رجعت کے شواہد آمدن سے پہلے بھی اختیاری نہیں۔ مصنوعی ٹیسٹ ڈیٹا بھی اسٹارٹ اپ کا دوست ہے: یہ حقیقی مریض کا ڈیٹا سنبھالنے کا نظامت کا بوجھ بچاتا ہے اس سے پہلے کہ کمپنی کے پاس اسے محفوظ طریقے سے کرنے کے کنٹرولز ہوں۔

چھوٹا کاروبار#

ایک قائم شدہ چھوٹا فراہم کنندہ — جی پی پریکٹس، کمیونٹی فارمیسی، کیئر ہوم، یا ایک مقام کا کلینک — عموماً اپنے طبی نظام بنانے کے بجائے خریدتا ہے، اس لیے اس کا جانچ کا کام قبولیت ہے، تعمیر نہیں: تصدیق کرنا کہ سپلائر کی اپ ڈیٹ یا نیا انضمام عملے کے اس پر انحصار کرنے سے پہلے حقیقی کام کے بہاؤ میں اب بھی محفوظ طور پر کام کرتا ہے۔ کم یا کسی مخصوص IT صلاحیت کے بغیر، عملی نظم و ضبط ہر سپلائر کی تبدیلی کے بعد سب سے زیادہ خطرے کے سفروں (بکنگ، نسخہ نویسی، مشاہدات کا اندراج) کے مقابل چلائی جانے والی مختصر، دہرائی جا سکنے والی جانچ فہرست ہے، مثالی طور پر زندہ ریکارڈز کے بجائے مصنوعی مریضوں کے ساتھ جانچ یا تربیت کے ماحول میں۔ وہی DCB0160 نفاذ کے تحفظ اور رسائی کے فرائض لاگو ہیں جو بڑے ٹرسٹ پر، مگر جانچ کی ٹیم کے بغیر، اس لیے حقیقت پسندانہ قدم سپلائر کی یقین دہانی پر انحصار ہے جبکہ وہ مٹھی بھر مقامی قبولیت کی جانچ رکھنا جو صرف آپ کر سکتے ہیں — کیا یہ اس کلینک کے کام کرنے کے طریقے میں آتا ہے؟ چھوٹا فراہم کنندہ جو یہ بھی چھوڑ دے اور تبدیلیاں براہِ راست زندہ مریضوں پر جانچے وہ ایک خراب اپ ڈیٹ دور ہے اس تحفظ کے واقعے سے جسے پکڑنے کا اس کے پاس کوئی طریقہ نہیں۔

بڑا ادارہ#

NHS ٹرسٹ یا بڑا سپلائر پیمانے پر اور مکمل یقین دہانی کے تحت جانچ چلاتا ہے: مخصوص جانچ کے ماحول، طبی بیک فل کے ساتھ رسمی UAT، آپریشنل قبولیت کی جانچ، سلامتی کی دخول کی جانچ، اور لائیو طبی نظاموں کو ریلیز روکنے والے تبدیلی کے مشاورتی بورڈ۔ خصوصیتی چیلنج پرانا نظام ہے — بڑے، پرانے نظام جن میں خودکار جانچ کا پتلا احاطہ ہے، جہاں ہر تبدیلی سے ڈر لگتا ہے کیونکہ کوئی پراعتماد نہیں کہ وہ کیا توڑ سکتی ہے، سست، مہنگے، دستی رجعت کے چکر پیدا کرتے ہوئے۔ حکمت عملی کا قدم اعلیٰ ترین خطرے کے علاقوں کے گرد خودکار جانچ کے احاطے میں مستقل سرمایہ کاری ہے، خوف کو اعتماد اور سست ریلیزوں کو تیز، محفوظ ریلیزوں میں بدلتے ہوئے۔ بڑے اداروں پر مربوط نظاموں میں جانچ کی ہم آہنگی کا بوجھ بھی ہے، جہاں ایک سپلائر کی مصنوعہ میں تبدیلی دوسرے کی مصنوعہ توڑ سکتی ہے۔

حکومت#

قومی ادارہ سروس اسٹینڈرڈ، شائع شدہ خدمتی تشخیصوں، اور عوامی جواب دہی کے بلند ترین معیار کے تحت جانچ کرتا ہے، جہاں ملک گیر نظام میں جانچ کی ناکامی لاکھوں کو متاثر کر سکتی اور پارلیمنٹ تک پہنچ سکتی ہے۔ WCAG کے مقابل رسائی کی جانچ سرکاری اداروں کے لیے نافذ قانونی فرض ہے، اور قومی پیمانے پر غیر فعلی جانچ — بوجھ، لچک، سلامتی — اختیاری نہیں بلکہ وجودی ہے۔ چیلنج بہت سے سپلائرز اور مربوط خدمات میں معیار کی یقین دہانی کی ہم آہنگی، اور پھیلے ہوئے پروگرام میں "مکمل" کی یکساں تعریف رکھنا ہے۔ قومی خدمات ماحولیاتی نظام کو بھی ڈھالتی ہیں: جو ٹیسٹ ڈیٹا، آلات، اور معیارات حکومتی ادارہ لازمی کرتا یا شائع کرتا ہے وہ معمول بن جاتے ہیں جن پر سپلائرز بناتے ہیں۔

عام ناکامی کے طریقے#

• الٹا اہرام۔ جانچ زیادہ تر سست، دستی، سرے سے سرے تک کی ہے؛ رائے سست، احاطہ پتلا، اور وقت کے دباؤ میں رجعت کی جانچ چھوڑ دی جاتی ہے۔ تریاق: تیز خودکار یونٹ اور انضمام کے ٹیسٹ کی وسیع بنیاد میں سرمایہ کاری کریں۔
• جانچ بطور آخری مرحلہ۔ جانچ لائیو ہونے سے پہلے ٹھونسا گیا مرحلہ ہے اور شیڈول پھسلنے پر سب سے پہلے کٹتی ہے۔ تریاق: بائیں طرف کھسکائیں اور جانچ کو مسلسل انضمام کی پائپ لائن میں جوڑیں تاکہ یہ مسلسل اور سستی ہو۔
• ٹیسٹ ماحول میں زندہ ڈیٹا۔ حقیقی مریض کے ریکارڈ حقیقت پسندی کے لیے کم محفوظ جانچ کے نظاموں میں نقل کیے جاتے ہیں، جو خلاف ورزی کا منتظر حادثہ بناتے ہیں۔ تریاق: بطور ڈیفالٹ مصنوعی اور گمنام ڈیٹا؛ زندہ ڈیٹا صرف منظم استثنا کے طور پر۔
• سبز تعمیر، اعتماد نہیں۔ ٹیسٹ پاس ہوتے ہیں مگر معمولی چیزوں کا احاطہ کرتے ہیں جبکہ حقیقی طبی خطرات بغیر جانچ کے ہیں۔ تریاق: ٹیسٹوں کو صریح طور پر خطرات کے لاگ اور اعلیٰ ترین خطرے کے سفروں سے نقشہ بنائیں۔
• رسائی بطور خودکار خانے کا نشان۔ پاس ہوتا خودکار اسکین مطابقت سمجھا جاتا ہے جبکہ معاون ٹیکنالوجی کے حقیقی صارفین کبھی شامل نہیں ہوتے۔ تریاق: خودکار جانچ کو معذور صارفین کی دستی جانچ سے جوڑیں۔
• چھوڑ دی گئی "مکمل" کی تعریف۔ "مکمل" متعین ہے مگر آخری تاریخ کے دباؤ میں معمول سے رد ہوتی ہے، غیر محفوظ کام کو مکمل کے طور پر لانچ کرتی ہوئی۔ تریاق: دروازے خودکار کریں اور کسی کو معیار کی بنیاد پر لانچ روکنے کا اختیار دیں۔

پختگی کا ماڈل#

جانچ فہرست#

• جانچ کا اہرام موجود ہے: وسیع خودکار یونٹ/انضمام کا احاطہ، کم سرے سے سرے تک ٹیسٹ، سب مسلسل انضمام میں چلتے ہیں۔
• DCB0129/0160 کے خطرات کے لاگ کے اعلیٰ ترین خطرات ہر ایک نام والے، خودکار رجعت کے ٹیسٹوں سے نقشہ بند ہیں۔
• کسی بھی تبدیلی کے لائیو طبی نظام تک پہنچنے سے پہلے رجعت کا مجموعہ چلتا اور پاس ہونا لازمی ہے۔
• ٹیسٹ اور اسٹیجنگ کے ماحول مصنوعی یا گمنام ڈیٹا استعمال کرتے ہیں؛ زندہ مریض کا ڈیٹا لاپروائی سے کبھی استعمال نہیں ہوتا۔
• اہم طبی سفروں کے لیے حقیقت پسندانہ چوٹی کی مانگ کے مقابل کارکردگی اور بوجھ کی جانچ چلتی ہے۔
• سلامتی کی جانچ اور WCAG رسائی کی جانچ (خودکار جمع معاون ٹیکنالوجی صارفین کے ساتھ دستی) مستقل ٹیسٹ کی اقسام ہیں۔
• صارف کی قبولیت کی جانچ حقیقی معالجین کے ساتھ حقیقت پسندانہ حالات میں، بجٹ شدہ بیک فل وقت کے ساتھ چلتی ہے۔
• "مکمل" کی تعریف اور نافذ معیار کے دروازے موجود ہیں اور آخری تاریخ کے دباؤ میں خاموشی سے چھوڑے نہیں جاتے۔
• نقائص طبی اثر سے درجہ بند ہیں، اور لائیو ہونے پر بھیجے معلوم مسائل قبول شدہ، کم کیے گئے خطرات کے طور پر ریکارڈ ہیں۔
• ٹیسٹ کے شواہد کا طبی تحفظ کے مقدمے کی رپورٹ میں براہِ راست حوالہ دیا جاتا ہے۔

کلیدی ماخذ#

• NHS انگلینڈ ڈیجیٹل — DCB0129 اور DCB0160 طبی خطرات کے انتظام کے معیارات؛ خطرات کا لاگ اور طبی تحفظ کے مقدمے کی رپورٹ۔
• NHS انگلینڈ — NHS سروس اسٹینڈرڈ اور NHS ڈیجیٹل سروس مینوئل (رسائی، جانچ، اور قابلِ اعتماد خدمت چلانا)۔
• GOV.UK سروس مینوئل (گورنمنٹ ڈیجیٹل سروس) — جانچ، ٹیسٹ ڈیٹا اور ماحول، رسائی، اور مسلسل ترسیل کی رہنمائی۔
• W3C ویب ایکسیسبیلٹی انیشی ایٹو — ویب کنٹینٹ ایکسیسبیلٹی گائیڈ لائنز (WCAG) 2.2 اور جانچ کی تکنیکیں۔
• NHS انگلینڈ — ڈیجیٹل ٹیکنالوجی اسسمنٹ کرائٹیریا (DTAC)، بشمول طبی تحفظ، تکنیکی یقین دہانی، اور قابلِ استعمالیت/رسائی۔
• ISTQB (انٹرنیشنل سافٹ ویئر ٹیسٹنگ کوالیفکیشنز بورڈ) — بنیادی جانچ کی اصطلاحات اور ٹیسٹ کی سطحیں۔
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018۔
• مائیک کوہن — جانچ کے اہرام کا تصور؛ مارٹن فاؤلر / Continuous Delivery (ہمبل اور فارلی) — جانچ کی خودکاری اور CI/CD کی مشق۔

حوالہ جات#

1. Software testing — Wikipedia — https://en.wikipedia.org/wiki/Software_testing
2. Quality assurance — Wikipedia — https://en.wikipedia.org/wiki/Quality_assurance
3. Unit testing — Wikipedia — https://en.wikipedia.org/wiki/Unit_testing
4. Integration testing — Wikipedia — https://en.wikipedia.org/wiki/Integration_testing
5. Shift-left testing — Wikipedia — https://en.wikipedia.org/wiki/Shift-left_testing
6. Non-functional testing — Wikipedia — https://en.wikipedia.org/wiki/Non-functional_testing
7. Regression testing — Wikipedia — https://en.wikipedia.org/wiki/Regression_testing
8. Test automation — Wikipedia — https://en.wikipedia.org/wiki/Test_automation
9. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
10. Acceptance testing — Wikipedia — https://en.wikipedia.org/wiki/Acceptance_testing
11. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
12. Deployment environment — Wikipedia — https://en.wikipedia.org/wiki/Deployment_environment
13. Synthetic data — Wikipedia — https://en.wikipedia.org/wiki/Synthetic_data
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
16. Testing your service, and test data and environments — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology
17. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/WAI/standards-guidelines/wcag/
18. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-tools/digital-technology-assessment-criteria-dtac/
19. Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK Government / GOV.UK — https://www.legislation.gov.uk/uksi/2018/952/contents/made
20. Continuous Delivery — Jez Humble and David Farley — https://continuousdelivery.com/