विषय 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. गैर-कार्यात्मक आवश्यकताओं को कार्यात्मक जितनी गंभीरता से परखें। यथार्थवादी चरम मांग के विरुद्ध प्रदर्शन और लोड परीक्षण चलाएं — शिफ्ट हैंडओवर, सोमवार-सुबह लॉगिन, एक क्षेत्रीय आउटेज ट्रैफ़िक को फिर से रूट करना — क्योंकि एक क्लिनिकल सिस्टम जो लोड के तहत रेंगने की गति तक धीमा हो जाता है वह ठीक तब विफल हुआ जब यह सबसे अधिक मायने रखता था। Web Content Accessibility Guidelines (WCAG) के विरुद्ध सुरक्षा परीक्षण और अभिगम्यता परीक्षण को स्थायी, गैर-वैकल्पिक परीक्षण प्रकारों के रूप में शामिल करें। गैर-कार्यात्मक दोष टालने में आसान और प्रोडक्शन में खोजने में महंगे हैं।

5. अभिगम्यता परीक्षण को स्वचालित करें, फिर इसे लोगों के साथ सत्यापित करें। स्वचालित WCAG जांच हर बिल्ड पर सस्ते में मुद्दों का एक सार्थक अंश पकड़ती हैं (गायब लेबल, खराब कंट्रास्ट, संरचना), लेकिन वे उन चीज़ों को चूक जाती हैं जो सहायक प्रौद्योगिकी के वास्तविक उपयोगकर्ताओं के लिए सबसे अधिक मायने रखती हैं। स्वचालित स्कैनिंग को स्क्रीन रीडर, केवल-कीबोर्ड नेविगेशन, और आवर्धन का उपयोग करने वाले लोगों द्वारा मैनुअल परीक्षण के साथ जोड़ें। अभिगम्यता सार्वजनिक निकायों के लिए एक कानूनी कर्तव्य है और एक क्लिनिकल-सुरक्षा मुद्दा है जब बहिष्कृत उपयोगकर्ता एक क्लिनिशियन या अपनी खुद की देखभाल प्रबंधित करने वाला एक रोगी है।

6. यथार्थवादी परिस्थितियों में वास्तविक क्लिनिशियनों के साथ उपयोगकर्ता स्वीकृति परीक्षण चलाएं। उन वास्तविक लोगों के साथ UAT निर्धारित करें जो सिस्टम का उपयोग करेंगे — नर्स, GP, प्रशासक, फार्मासिस्ट — वास्तविक वर्कफ़्लो का अभ्यास करते हुए, आदर्श रूप से एक ऐसी सेटिंग में जो वार्ड या क्लिनिक को दर्शाती हो, कोई शांत बैठक कक्ष नहीं। उनकी प्रतिक्रिया खतरनाक वर्कफ़्लो बेमेल पकड़ती है (गलत क्षण दिखाई गई एक चेतावनी, एक डिफ़ॉल्ट जो त्रुटि को आमंत्रित करता है) जो यूनिट परीक्षण नहीं पकड़ सकते। क्लिनिकल बैकफ़िल समय बजट करें ताकि 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, वास्तविक नर्सों के साथ सिम्युलेटेड परिदृश्यों के माध्यम से काम करते हुए, एक वर्कफ़्लो दोष सामने लाता है जिसे किसी डेवलपर ने नहीं देखा था: पुष्टिकरण संवाद स्कोर के बाद दिखाई दिया, स्टाफ को इसे प्रतिवर्ती रूप से खारिज करने के लिए ललचाते हुए। टीम प्रवाह को फिर से डिज़ाइन करती है और एक रिग्रेशन परीक्षण जोड़ती है। लाइव-गो पर, तीन कॉस्मेटिक दोष दस्तावेज़ीकृत, स्वीकृत मुद्दों के रूप में शिप होते हैं; गणना को छूने वाले दो ठीक किए गए और उनके पास होने तक रिलीज़ को रोका गया, और सुरक्षा मामला सीधे परीक्षण साक्ष्य का हवाला देता है। लाइव संचालन में छह महीने बाद, कार्य सूची में एक नियमित परिवर्तन एक रिग्रेशन परीक्षण को ट्रिप करता है जो, अनदेखा, एक वृद्धि अलर्ट को दबा देता — पाइपलाइन में पकड़ा गया, तैनाती से पहले ठीक किया गया, कभी एक वार्ड तक नहीं पहुंचा।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक छोटी डिजिटल-स्वास्थ्य कंपनी को पहले दिन से अपने DNA में स्वचालित परीक्षण और निरंतर एकीकरण बनाने का लाभ है, बिना किसी विरासत मैनुअल परीक्षण प्रक्रिया को खोलने के, और एक बड़ा ट्रस्ट जिससे ईर्ष्या करेगा उतनी तेज़, सुरक्षित पुनरावृत्ति प्राप्त कर सकती है। खतरा यह है कि उत्पाद-बाज़ार फिट का पीछा करते हुए परीक्षण को टालने योग्य विलासिता के रूप में मानना, और गैर-कार्यात्मक और क्लिनिकल-सुरक्षा परीक्षण पर कंजूसी करना जिसकी अभी तक कोई शुरुआती ग्राहक मांग नहीं कर रहा है। संस्थापक को याद रखना चाहिए कि DCB0129 दायित्व कंपनी के आकार की परवाह किए बिना निर्माता से जुड़ते हैं, इसलिए एक सुरक्षा दावे के पीछे रिग्रेशन साक्ष्य पूर्व-राजस्व भी वैकल्पिक नहीं है। सिंथेटिक परीक्षण डेटा भी एक स्टार्टअप का दोस्त है: यह कंपनी के पास इसे सुरक्षित रूप से करने के लिए नियंत्रण होने से पहले वास्तविक रोगी डेटा को संभालने के प्रशासन भार से बचता है।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, या एक एकल-साइट क्लिनिक — आमतौर पर अपने क्लिनिकल सिस्टम बनाने के बजाय खरीदता है, इसलिए इसका परीक्षण काम निर्माण नहीं, स्वीकृति है: यह पुष्टि करना कि एक आपूर्तिकर्ता का अपडेट या एक नया एकीकरण अभी भी वास्तविक वर्कफ़्लो में सुरक्षित रूप से काम करता है इससे पहले कि स्टाफ इस पर निर्भर करे। बहुत कम या कोई समर्पित IT क्षमता के साथ, व्यावहारिक अनुशासन हर आपूर्तिकर्ता परिवर्तन के बाद उच्चतम-जोखिम यात्राओं (बुकिंग, प्रिस्क्राइबिंग, अवलोकन रिकॉर्ड करना) के विरुद्ध चलाई गई एक छोटी, दोहराने योग्य जांच-सूची है, आदर्श रूप से सिंथेटिक रोगियों के साथ एक परीक्षण या प्रशिक्षण वातावरण में लाइव रिकॉर्ड के बजाय। वही DCB0160 तैनाती-सुरक्षा और अभिगम्यता कर्तव्य एक बड़े ट्रस्ट के समान लागू होते हैं, लेकिन बिना परीक्षण टीम के, इसलिए यथार्थवादी कदम आपूर्तिकर्ता के आश्वासन पर झुकना है जबकि मुट्ठी भर स्थानीय स्वीकृति जांच को बनाए रखना है जो केवल आप कर सकते हैं — क्या यह इस क्लिनिक के वास्तविक काम करने के तरीके में फिट बैठता है? एक छोटा प्रदाता जो इसे भी छोड़ता है और सीधे लाइव रोगियों पर परिवर्तनों का परीक्षण करता है वह एक खराब अपडेट दूर है एक सुरक्षा घटना से जिसे पकड़ने का उसके पास कोई तरीका नहीं है।

बड़ा संगठन#

एक NHS ट्रस्ट या प्रमुख आपूर्तिकर्ता पैमाने पर और पूर्ण आश्वासन के तहत परीक्षण चलाता है: समर्पित परीक्षण वातावरण, क्लिनिकल बैकफ़िल के साथ औपचारिक UAT, परिचालन स्वीकृति परीक्षण, सुरक्षा पेनेट्रेशन परीक्षण, और लाइव क्लिनिकल सिस्टमों में रिलीज़ को द्वारित करने वाले परिवर्तन सलाहकार बोर्ड। विशिष्ट चुनौती विरासत है — बड़े, पुराने सिस्टम पतली स्वचालित परीक्षण कवरेज के साथ, जहां हर परिवर्तन से डर लगता है क्योंकि कोई आश्वस्त नहीं है कि यह क्या तोड़ सकता है, धीमे, महंगे, मैनुअल रिग्रेशन चक्र उत्पन्न करते हुए। रणनीतिक कदम उच्चतम-जोखिम क्षेत्रों के आसपास स्वचालित परीक्षण कवरेज में लगातार निवेश करना है, डर को आत्मविश्वास में और धीमी रिलीज़ को तेज़, सुरक्षित में बदलते हुए। उद्यम एकीकृत सिस्टमों में परीक्षण का समन्वय भार भी उठाते हैं, जहां एक आपूर्तिकर्ता के उत्पाद में एक परिवर्तन दूसरे को तोड़ सकता है।

सरकार#

एक राष्ट्रीय निकाय Service Standard, प्रकाशित सेवा मूल्यांकन, और सार्वजनिक जवाबदेही की उच्चतम बार के तहत परीक्षण देता है, जहां एक राष्ट्रव्यापी सिस्टम में एक परीक्षण विफलता लाखों को प्रभावित कर सकती है और संसद तक पहुंच सकती है। WCAG के विरुद्ध अभिगम्यता परीक्षण सार्वजनिक क्षेत्र निकायों के लिए लागू एक कानूनी कर्तव्य है, और राष्ट्रीय पैमाने पर गैर-कार्यात्मक परीक्षण — लोड, लचीलापन, सुरक्षा — वैकल्पिक के बजाय अस्तित्वगत है। चुनौती कई आपूर्तिकर्ताओं और एकीकृत सेवाओं में गुणवत्ता आश्वासन का समन्वय करना है, और एक फैले हुए कार्यक्रम में पूर्णता की एक सुसंगत परिभाषा रखना है। राष्ट्रीय सेवाएं पारिस्थितिकी तंत्र को भी आकार देती हैं: परीक्षण डेटा, उपकरण, और मानक जिन्हें एक सरकारी निकाय अनिवार्य या प्रकाशित करता है वे मानदंड बन जाते हैं जिनके लिए आपूर्तिकर्ता बनाते हैं।

सामान्य विफलता मोड#

• उलटा पिरामिड। परीक्षण ज़्यादातर धीमी, मैनुअल, अंत-से-अंत जांच है; फीडबैक धीमा है, कवरेज पतला है, और समय दबाव में रिग्रेशन परीक्षण छोड़ा जाता है। उपाय: तेज़ स्वचालित यूनिट और एकीकरण परीक्षणों के एक व्यापक आधार में निवेश करें।
• एक अंत-चरण के रूप में परीक्षण। परीक्षण लाइव-गो से पहले ठूंसा गया एक चरण है और जब अनुसूची फिसलती है तो पहली चीज़ काटी जाती है। उपाय: बाएं शिफ्ट करें और परीक्षण को निरंतर एकीकरण पाइपलाइन में वायर करें ताकि यह निरंतर और सस्ता हो।
• परीक्षण वातावरण में लाइव डेटा। यथार्थता के लिए वास्तविक रोगी रिकॉर्ड कम-संरक्षित परीक्षण सिस्टमों में कॉपी किए जाते हैं, एक उल्लंघन की प्रतीक्षा में बनाते हुए। उपाय: डिफ़ॉल्ट रूप से सिंथेटिक और अनामीकृत डेटा; केवल एक प्रशासित अपवाद के रूप में लाइव डेटा।
• हरा बिल्ड, कोई आत्मविश्वास नहीं। परीक्षण पास होते हैं लेकिन तुच्छ चीज़ें कवर करते हैं जबकि वास्तविक क्लिनिकल खतरे अपरीक्षित रहते हैं। उपाय: परीक्षणों को स्पष्ट रूप से खतरा लॉग और उच्चतम-जोखिम यात्राओं में मैप करें।
• एक स्वचालित टिक-बॉक्स के रूप में अभिगम्यता। एक पासिंग स्वचालित स्कैन को अनुरूपता माना जाता है जबकि वास्तविक सहायक-प्रौद्योगिकी उपयोगकर्ता कभी शामिल नहीं होते। उपाय: स्वचालित जांच को विकलांग उपयोगकर्ताओं द्वारा मैनुअल परीक्षण के साथ जोड़ें।
• माफ की गई पूर्णता की परिभाषा। "पूर्ण" परिभाषित है लेकिन समय सीमा दबाव में नियमित रूप से खारिज किया जाता है, असुरक्षित काम को पूर्ण के रूप में लॉन्च करते हुए। उपाय: द्वार स्वचालित करें और किसी को गुणवत्ता आधार पर एक लॉन्च रोकने का अधिकार दें।

परिपक्वता मॉडल#

जांच-सूची#

• एक परीक्षण पिरामिड मौजूद है: व्यापक स्वचालित यूनिट/एकीकरण कवरेज, कुछ अंत-से-अंत परीक्षण, सभी निरंतर एकीकरण में चलाए गए।
• DCB0129/0160 खतरा लॉग में उच्चतम खतरों को हर एक नामित, स्वचालित रिग्रेशन परीक्षणों में मैप किया गया है।
• किसी भी परिवर्तन के एक लाइव क्लिनिकल सिस्टम तक पहुंचने से पहले एक रिग्रेशन सूट चलता है और पास होना चाहिए।
• परीक्षण और स्टेजिंग वातावरण सिंथेटिक या अनामीकृत डेटा का उपयोग करते हैं; लाइव रोगी डेटा कभी लापरवाही से उपयोग नहीं किया जाता।
• महत्वपूर्ण क्लिनिकल यात्राओं के लिए यथार्थवादी चरम मांग के विरुद्ध प्रदर्शन और लोड परीक्षण चलाया जाता है।
• सुरक्षा परीक्षण और WCAG अभिगम्यता परीक्षण (स्वचालित प्लस सहायक-प्रौद्योगिकी उपयोगकर्ताओं के साथ मैनुअल) स्थायी परीक्षण प्रकार हैं।
• उपयोगकर्ता स्वीकृति परीक्षण वास्तविक क्लिनिशियनों के साथ यथार्थवादी परिस्थितियों में चलाया जाता है, बैकफ़िल समय बजट के साथ।
• एक पूर्णता की परिभाषा और लागू गुणवत्ता द्वार मौजूद हैं और समय सीमा दबाव में चुपचाप माफ नहीं किए जाते।
• दोषों को क्लिनिकल प्रभाव द्वारा त्रिआज किया जाता है, और लाइव-गो पर शिप किए गए ज्ञात मुद्दों को स्वीकृत, शमित जोखिमों के रूप में दर्ज किया जाता है।
• परीक्षण साक्ष्य क्लिनिकल सुरक्षा मामला रिपोर्ट में सीधे उद्धृत किया जाता है।

मुख्य स्रोत#

• NHS England Digital — DCB0129 और DCB0160 क्लिनिकल जोखिम प्रबंधन मानक; खतरा लॉग और क्लिनिकल सुरक्षा मामला रिपोर्ट।
• NHS England — NHS Service Standard और NHS Digital Service Manual (अभिगम्यता, परीक्षण, और एक विश्वसनीय सेवा संचालित करना)।
• GOV.UK Service Manual (Government Digital Service) — परीक्षण, परीक्षण डेटा और वातावरण, अभिगम्यता, और निरंतर डिलीवरी मार्गदर्शन।
• W3C Web Accessibility Initiative — Web Content Accessibility Guidelines (WCAG) 2.2 और परीक्षण तकनीकें।
• NHS England — Digital Technology Assessment Criteria (DTAC), क्लिनिकल सुरक्षा, तकनीकी आश्वासन, और उपयोगिता/अभिगम्यता सहित।
• ISTQB (International Software Testing Qualifications Board) — मूलभूत परीक्षण शब्दावली और परीक्षण स्तर।
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018।
• Mike Cohn — परीक्षण पिरामिड अवधारणा; Martin Fowler / Continuous Delivery (Humble & Farley) — परीक्षण स्वचालन और 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/