நிறுவனச் சரிபார்ப்புப் பட்டியல்: QA/UAT-இல் தற்காலிக மின்னஞ்சலைப் பயன்படுத்தும் போது OTP அபாயத்தைக் குறைத்தல்

சுருக்கமாக:

• வெற்றி விகிதம் மற்றும் TTFOM (p50/p90, p95) உள்ளிட்ட அளவிடக்கூடிய SLO ஆக OTP நம்பகத்தன்மையை மதிப்பிடுங்கள்.
• நற்பெயரையும் பகுப்பாய்வுகளையும் பாதிக்காமல் இருக்க QA/UAT போக்குவரத்தையும் டொமைன்களையும் உற்பத்திச் சூழலிலிருந்து பிரிக்கவும்.
• மறுஅனுப்பல் இடைவெளிகளையும் சுழற்சிகளின் அதிகபட்ச எண்ணிக்கையையும் தரப்படுத்தவும்; ஒழுங்கான மறுமுயற்சிகளுக்குப் பிறகு மட்டுமே சுழற்சி செய்யவும்.
• சோதனை வகைக்கு ஏற்ப இன்பாக்ஸ் உத்திகளைத் தேர்ந்தெடுக்கவும்: பின்னடைவு சோதனைக்கு மீண்டும் பயன்படுத்தக்கூடியவை; திடீர் அதிகபட்சச் சோதனைகளுக்கு குறுகிய காலத்துக்கானவை.
• அனுப்புநர்×டொமைன் அளவீடுகளைத் தோல்விக் குறியீடுகளுடன் பதிவுசெய்து, காலாண்டுக் கட்டுப்பாட்டு மதிப்பாய்வுகளை கட்டாயப்படுத்தவும்.

QA/UAT இல் தற்காலிக மின்னஞ்சலைப் பயன்படுத்தும் நிறுவனங்களுக்கான OTP அபாயத்தைக் குறைப்பதற்கான சரிபார்ப்புப் பட்டியல்

இதில் ஒரு திருப்பம் உள்ளது: சோதனைச் சூழல்களில் OTP நம்பகத்தன்மை என்பது வெறும் "மின்னஞ்சல் விஷயம்" மட்டுமல்ல. இது நேரக் கையாளும் பழக்கங்கள், அனுப்புநரின் நற்பெயர், சாம்பல் பட்டியல், டொமைன் தேர்வுகள், மேலும் உங்கள் அணிகள் அழுத்தத்தின் கீழ் எவ்வாறு செயல்படுகின்றன என்பவற்றுக்கு இடையிலான தொடர்பாகும். இந்தச் சரிபார்ப்புப் பட்டியல் அந்தச் சிக்கலைப் பகிரப்பட்ட வரையறைகள், பாதுகாப்பு விதிமுறைகள் மற்றும் ஆதாரங்களாக மாற்றுகிறது. நீங்கள் தற்காலிக இன்பாக்ஸ்களுக்குப் புதியவராக இருந்தால், விதிமுறைகளையும் அடிப்படை நடைமுறைகளையும் அறிந்துகொள்ள முதலில் டெம்ப் மெயிலின் அத்தியாவசியங்களைப் படிக்கவும்.

1) QA/UAT இல் OTP அபாயத்தை வரையறுக்கவும்

QA, பாதுகாப்பு மற்றும் தயாரிப்புக் குழுக்கள் OTP நம்பகத்தன்மை குறித்து ஒரே மொழியில் பேசுவதற்கான பொதுவான சொற்களை வரையறுக்கவும்.

"OTP வெற்றி விகிதம்" என்றால் என்ன

OTP வெற்றி விகிதம் என்பது உங்கள் கொள்கை நிர்ணயித்த காலவரம்புக்குள் செல்லுபடியாகும் குறியீடு பெறப்பட்டு பயன்படுத்தப்படும் OTP கோரிக்கைகளின் சதவீதமாகும் (எ.கா., சோதனைச் செயல்முறைகளுக்கு பத்து நிமிடங்கள்). அனுப்புநர் (குறியீட்டை வழங்கும் பயன்பாடு அல்லது தளம்) மற்றும் பெறும் டொமைன் தொகுப்பு ஆகியவற்றின் அடிப்படையில் அதைக் கண்காணிக்கவும். சம்பவப் பகுப்பாய்வு நீர்த்துப்போகாமல் இருக்க, பயனர் கைவிட்ட நிகழ்வுகளைத் தனியாகப் பதிவு செய்யவும்.

அணிகளுக்கான TTFOM p50/p90

முதல் OTP செய்தியைப் பெறும் நேரம் (TTFOM)—"குறியீட்டை அனுப்பு" என்பதை அழுத்தியதிலிருந்து இன்பாக்ஸில் முதல் செய்தி வரும் வரையிலான வினாடிகள். p50 மற்றும் p90-ஐ (அழுத்தச் சோதனைகளுக்கு p95-ஐயும்) விளக்கப்படுத்தவும். இந்தப் பரவல்கள் தனிப்பட்ட அனுபவங்களை நம்பாமல், வரிசைத் தாமதம், வேகக் கட்டுப்பாடு மற்றும் சாம்பல் பட்டியல் ஆகியவற்றை வெளிப்படுத்துகின்றன.

தவறான எதிர்மறைகள் மற்றும் உண்மையான தோல்விகள்

ஒரு குறியீடு பெறப்பட்டிருந்தும் சோதனையாளரின் செயல்முறை அதை நிராகரிக்கும்போது "தவறான எதிர்மறை" ஏற்படுகிறது—பெரும்பாலும் பயன்பாட்டின் நிலை, தாவல்களுக்கு இடையில் மாறுதல், அல்லது காலாவதியான டைமர்கள். "உண்மையான தோல்வி" என்பது காலவரம்புக்குள் குறியீடு வராததாகும். உங்கள் வகைப்பாட்டில் இவற்றைத் தனித்தனியாகப் பதிவு செய்யவும்; உண்மையான தோல்விகளுக்கு மட்டுமே சுழற்சி மாற்றம் நியாயமானது.

ஸ்டேஜிங் சூழல் விநியோகத் திறனைச் சாய்க்கும் போது

ஸ்டேஜிங் எண்ட்பாயிண்ட்களும் செயற்கையான போக்குவரத்து முறைகளும் பெரும்பாலும் சாம்பல் பட்டியல் அல்லது குறைந்த முன்னுரிமைக்கு வழிவகுக்கும். உங்கள் அடிப்படை அளவீடு உற்பத்திச் சூழலைவிட மோசமாகத் தோன்றினால், அது எதிர்பார்க்கத்தக்கதே: மனிதர்கள் உருவாக்காத போக்குவரத்து வேறுபட்ட முறையில் விநியோகிக்கப்படுகிறது. சுருக்கமான அறிமுகத்திற்கு, சோதனையின்போது தற்காலிக இன்பாக்ஸ் முறைகள் விநியோகத்தை எவ்வாறு பாதிக்கின்றன என்பதற்கான விளக்கத்தை 2025 இல் சுருக்கமான தற்காலிக அஞ்சலைப் பார்க்கவும்.

2) பொதுவான தோல்வி நிலைகளை மாதிரியாக்குதல்

அதிக தாக்கம் ஏற்படுத்தும் விநியோகச் சிக்கல்களை வரைபடமாக்கி, கொள்கைகள் மற்றும் கருவிகள் மூலம் அவற்றை முன்கூட்டியே தடுக்கலாம்.

சாம்பல் பட்டியல் மற்றும் அனுப்புநர் நற்பெயர்

சாம்பல் பட்டியல், அனுப்புநர்கள் பின்னர் மீண்டும் முயற்சிக்க வேண்டும் எனக் கோருகிறது; எனவே முதல் முயற்சிகள் தாமதமாகலாம். புதிய அல்லது "குளிர்ந்த" அனுப்புநர் குளங்களும் அவற்றின் நற்பெயர் மேம்படும் வரை பாதிக்கப்படும். புதிய build-இன் அறிவிப்பு சேவை தொடங்கிய முதல் மணிநேரங்களில் p90 அதிகரிப்புகளை எதிர்பார்க்கலாம்.

ISP ஸ்பேம் வடிகட்டிகள் மற்றும் குளிர்ந்த குளங்கள்

சில வழங்குநர்கள் குளிர்ந்த IPகள் அல்லது டொமைன்களைக் கடுமையாகச் சோதிப்பார்கள். புதிய குளத்திலிருந்து QA சோதனைகள் OTPகளைத் தாறுமாறாக அனுப்பினால், அவை பிரச்சாரங்களைப் போலத் தோன்றி, முக்கியத்துவம் குறைந்த செய்திகளையும் தாமதப்படுத்தலாம். குறைந்த அளவில், சீரான இடைவெளியில் அனுப்பும் warm-up தொடர்கள் இதைத் தணிக்கும்.

விகித வரம்புகள் மற்றும் உச்சநேர நெரிசல்

மீண்டும் அனுப்பும் கோரிக்கைகளைத் திடீரென அதிகரிப்பது விகித வரம்புகளைத் தூண்டலாம். அதிகச் சுமையின்போது (எ.கா., விற்பனை நிகழ்வுகள், கேமிங் வெளியீடுகள்), அனுப்புநர் வரிசைகள் நீண்டு, TTFOM p90-ஐ அதிகரிக்கும். உங்கள் சரிபார்ப்புப் பட்டியலில் மீண்டும் அனுப்பும் காலச் சாளரங்களையும் சுயமாக ஏற்படுத்திக் கொள்ளும் தாமதங்களைத் தவிர்க்கும் வகையில் மீண்டும் முயற்சிக்கும் உச்சவரம்புகளையும் வரையறுக்க வேண்டும்.

ஓட்டங்களைச் சீர்குலைக்கும் பயனர் நடத்தைகள்

தாவல்களுக்கு இடையில் மாறுதல், மொபைல் செயலியைப் பின்னணியில் வைத்தல், தவறான மாற்றுப்பெயரை நகலெடுத்தல் ஆகியவை செய்தி வழங்கப்பட்டிருந்தாலும் நிராகரிப்பு அல்லது காலாவதியை ஏற்படுத்தலாம். சோதனைகளுக்கான UI micro-text-இல் "பக்கத்தில் இருங்கள், காத்திருங்கள், ஒருமுறை மீண்டும் அனுப்புங்கள்" என்ற உரையைச் சேர்க்கவும்.

3) தனித்தனி சூழல்கள், தனித்தனி சமிக்ஞைகள்

அனுப்புநர் நற்பெயரும் பகுப்பாய்வுகளும் பாதிக்கப்படாமல் இருக்க QA/UAT-ஐ production-இலிருந்து தனிமைப்படுத்துங்கள்.

ஸ்டேஜிங் vs உற்பத்தி களங்கள்

staging பயன்பாட்டிற்காகத் தனித்தனி அனுப்புநர் டொமைன்களையும் reply-to அடையாளங்களையும் பராமரிக்கவும். சோதனை OTPகள் production குளங்களில் கசிந்தால், நீங்கள் தவறான முடிவுகளைக் கற்றுக்கொள்வதுடன், production push-க்கு நற்பெயர் மிகவும் தேவைப்படும் நேரத்தில் அதைச் சேதப்படுத்தக்கூடும்.

சோதனைக் கணக்குகள் மற்றும் ஒதுக்கீடுகள்

பெயரிடப்பட்ட சோதனைக் கணக்குகளை உருவாக்கி, அவற்றுக்கு ஒதுக்கீடுகளை நிர்ணயிக்கவும். அதிர்வெண் சார்ந்த விதிகளைத் தூண்டும் நூற்றுக்கணக்கான தற்காலிக அடையாளங்களைவிட, கட்டுப்பாட்டுடன் பயன்படுத்தப்படும் சில சோதனை அடையாளங்கள் சிறந்தவை.

செயற்கை போக்குவரத்துக்கான காலச் சாளரங்கள்

உச்சநேரம் அல்லாத காலச் சாளரங்களில் செயற்கை OTP போக்குவரத்தை இயக்கவும். தாமதத்தை அளவிட குறுகிய வெடிப்புகளைப் பயன்படுத்துங்கள்; தவறான பயன்பாட்டைப் போல் தோன்றும் முடிவில்லாத வெள்ளத்தைத் தவிர்க்கவும்.

அஞ்சல் தடயத்தைத் தணிக்கை செய்தல்

உங்கள் சோதனைகள் பயன்படுத்தும் டொமைன்கள், IPகள் மற்றும் வழங்குநர்களின் பட்டியலைத் தயாரிக்கவும். staging அடையாளங்களுக்கான SPF/DKIM/DMARC அமைப்புகள் ஒரே மாதிரியாக உள்ளனவா என்பதை உறுதிப்படுத்தி, அங்கீகாரத் தோல்விகளையும் விநியோகச் சிக்கல்களையும் ஒன்றாகக் குழப்பிக் கொள்ளாதீர்கள்.

4) சரியான இன்பாக்ஸ் உத்தியைத் தேர்ந்தெடுத்தல்

சோதனைச் சமிக்ஞைகளை நிலைப்படுத்த, முகவரிகளை மீண்டும் பயன்படுத்த வேண்டிய நேரத்தையும் குறுகிய கால இன்பாக்ஸ்களைப் பயன்படுத்த வேண்டிய நேரத்தையும் தீர்மானிக்க முடியுமா?

Regression சோதனைக்கான மீண்டும் பயன்படுத்தக்கூடிய முகவரிகள்

நீண்டகாலச் சோதனைகளுக்கு (ரிக்ரெஷன் தொகுப்புகள், கடவுச்சொல் மீட்டமைப்பு சுழற்சிகள்), மீண்டும் பயன்படுத்தக்கூடிய முகவரி தொடர்ச்சியையும் நிலைத்தன்மையையும் வழங்குகிறது. token அடிப்படையிலான மறுதிறப்பு, பல நாட்களிலும் சாதனங்களிலும் ஏற்படும் குழப்பத்தைக் குறைத்து, பல build-களில் ஒரே மாதிரியான முடிவுகளை ஒப்பிடுவதற்கு ஏற்றதாக அமைகிறது. செயல்பாட்டு விவரங்களுக்கு, தற்காலிக அஞ்சல் முகவரியை மீண்டும் பயன்படுத்து சரியான inbox-ஐப் பாதுகாப்பாக மீண்டும் திறப்பதற்கான வழிமுறைகளைப் பார்க்கவும்.

வெடிப்பு சோதனைக்கான குறுகிய ஆயுள்

ஒருமுறை ஏற்படும் அதிகபட்சச் சுமைகளுக்கும் ஆய்வுசார் QA-க்கும், குறுகியகால inbox-கள் மீதமுள்ள தரவையும் பட்டியல் மாசுபாட்டையும் குறைக்கின்றன. காட்சிகளுக்கு இடையில் சுத்தமான மீட்டமைப்புகளையும் அவை ஊக்குவிக்கின்றன. ஒரு சோதனைக்கு ஒரே ஒரு OTP மட்டுமே தேவைப்பட்டால், 10 நிமிட அஞ்சல் போன்ற குறுகியகால மாதிரி பொருத்தமானதாக இருக்கும்.

Token அடிப்படையிலான மீட்பு ஒழுங்குமுறை

மீண்டும் பயன்படுத்தக்கூடிய சோதனை inbox முக்கியமானதாக இருந்தால், access token-ஐ ஒரு நற்சான்றிதழைப் போலக் கருதுங்கள். அதைச் சோதனைத் தொகுப்பின் பெயரில், பங்கு அடிப்படையிலான அணுகலுடன் password manager-ல் சேமிக்கலாம்.

முகவரி மோதல்களைத் தவிர்த்தல்

Alias-களைச் சீரற்றதாக்குதல், அடிப்படை ASCII-ஐப் பயன்படுத்துதல், விரைவான தனித்துவச் சரிபார்ப்பு ஆகியவை பழைய சோதனை முகவரிகளுடன் ஏற்படும் மோதல்களைத் தடுக்கின்றன. ஒவ்வொரு தொகுப்பிலும் alias-களுக்கு எவ்வாறு பெயரிடுவது அல்லது அவற்றை எவ்வாறு சேமிப்பது என்பதைத் தரப்படுத்துங்கள்.

5) சிறப்பாகச் செயல்படும் resend நேரச் சாளரங்களை அமைத்தல்

நேரச் செயல்பாடுகளைத் தரப்படுத்துவதன் மூலம் "rage resend" மற்றும் தவறான throttling-ஐக் குறைக்கவும்.

Resend செய்வதற்கு முன் குறைந்தபட்சக் காத்திருப்பு

முதல் கோரிக்கைக்குப் பிறகு, ஒருமுறை முறையாக retry செய்வதற்கு முன் 60–90 வினாடிகள் காத்திருக்கவும். இதனால் greylisting-ன் முதல் முயற்சி தோல்வியடைவதைத் தவிர்த்து, sender queue-களைச் சீராக வைத்திருக்கலாம்.

ஒருமுறை முறையாக retry செய்தல்

சோதனை script-ல் ஒரு முறையான retry-க்கு மட்டும் அனுமதியளித்து, பின்னர் இடைநிறுத்துங்கள். ஒரு குறிப்பிட்ட நாளில் p90 தாமதமாகத் தோன்றினால், அனைவரின் முடிவுகளையும் பாதிக்கும் வகையில் மீண்டும் மீண்டும் retry செய்வதற்குப் பதிலாக எதிர்பார்ப்புகளைச் சரிசெய்யுங்கள்.

App tab மாறுதலைக் கையாளுதல்

பயனர்கள் app-ஐ background-க்கு அனுப்பும்போதோ வேறு பக்கத்திற்குச் செல்லும்போதோ codes பெரும்பாலும் செல்லாதவையாகிவிடும். QA scripts-ல் "திரையில் தொடர்ந்து இருக்கவும்" என்பதைத் தெளிவான படியாகச் சேர்த்து, OS/background செயல்பாடுகளை logs-ல் பதிவு செய்யவும்.

டைமர் டெலிமெட்ரியைப் பிடிக்கிறது

துல்லியமான நேர முத்திரைகளைப் பதிவு செய்யவும்: கோரிக்கை, resend, inbox-க்கு வந்த நேரம், code உள்ளீடு, ஏற்றுக்கொள்ளப்பட்டது/நிராகரிக்கப்பட்டது என்ற நிலை. அனுப்புநர் மற்றும் டொமைன் அடிப்படையில் நிகழ்வுகளைக் குறியிடுங்கள்; இதனால் பின்னர் தடயவியல் ஆய்வு செய்ய முடியும்.

6) டொமைன் சுழற்சி கொள்கையை மேம்படுத்தவும்

சோதனைத் தரவின் கண்காணிப்புத் திறனைச் சிதைக்காமல், greylisting-ஐத் தவிர்க்கச் சரியான முறையில் rotation செய்யவும்.

அனுப்புநருக்கு சுழற்சி தொப்பிகள்

முதல் முயற்சி தோல்வியடைந்தவுடன் தானியங்கி சுழற்சி தொடங்கக்கூடாது. அனுப்புநர் அடிப்படையில் வரம்புகளை வரையறுக்கவும்: எடுத்துக்காட்டாக, ஒரே அனுப்புநர்×டொமைன் ஜோடிக்கான இரண்டு சாளரங்களும் தோல்வியடைந்த பிறகே சுழற்சி செய்யவும்—அமர்வுகளை ≤2 சுழற்சிகளாக வரம்பிட்டு நற்பெயரைப் பாதுகாக்கவும்.

பூல் பராமரிப்பும் TTLகளும்

பழையதும் புதியதுமான டொமைன்களின் கலவையுடன் டொமைன் பூல்களைத் தேர்ந்தெடுத்து நிர்வகிக்கவும். p90 தாமதம் அதிகரிக்கும்போது அல்லது வெற்றி விகிதம் குறையும்போது “சோர்வடைந்த” டொமைன்களுக்கு ஓய்வு அளிக்கவும்; அவை மீண்ட பிறகு மீண்டும் சேர்க்கவும். இன்பாக்ஸ் தெரிவுநிலை உங்கள் மதிப்பாய்வு சாளரத்துடன் ஒத்துப்போகும் வகையில், TTLகளைச் சோதனை நடைபெறும் இடைவெளிக்கு ஏற்ப அமைக்கவும்.

A/B ஒப்பீட்டுக்கான நிலையான ரூட்டிங்

பில்ட்களை ஒப்பிடும்போது, நிலையான ரூட்டிங்கைப் பயன்படுத்தவும்: அனைத்து மாறுபாடுகளிலும் ஒரே அனுப்புநரின் மின்னஞ்சல் ஒரே டொமைன் குடும்பத்திற்கே செல்ல வேண்டும். இது அளவீடுகள் ஒன்றுடன் ஒன்று கலப்பதைத் தடுக்கிறது.

சுழற்சியின் செயல்திறனை அளவிடுதல்

சுழற்சி என்பது ஊகத்தின் அடிப்படையிலானது அல்ல. ஒரே மாதிரியான மறு அனுப்பல் சாளரங்களின் கீழ், சுழற்சியுடனும் சுழற்சி இல்லாமலும் உள்ள மாறுபாடுகளை ஒப்பிடவும். விரிவான காரணவிளக்கத்திற்கும் பாதுகாப்பு வரம்புகளுக்கும், இந்த விளக்கத்தில் உள்ள OTPக்கான டொமைன் சுழற்சி பகுதியைப் பார்க்கவும்: OTP க்கான டொமைன் சுழற்சி.

7) சரியான அளவீடுகளைப் பதிவு செய்யுங்கள்

தாமதப் பரவல்களைப் பகுப்பாய்வு செய்து, மூலக் காரணக் குறிச்சொற்களை ஒதுக்குவதன் மூலம் OTP வெற்றியை அளவிடக்கூடியதாக மாற்றுங்கள்.

அனுப்புநர் × டொமைன் அடிப்படையிலான OTP வெற்றி: மேல்நிலை SLO-வை அனுப்புநர் × டொமைன் அணி அடிப்படையில் பிரித்துப் பார்க்க வேண்டும். இதன் மூலம் சிக்கல் தளம்/ஆப்ஸில் உள்ளதா அல்லது பயன்படுத்தப்படும் டொமைனில் உள்ளதா என்பதைத் தெரிந்துகொள்ளலாம்.

TTFOM p50/p90, p95

நடுத்தர மற்றும் உச்சநிலைத் தாமதங்கள் வெவ்வேறு நிலவரங்களைச் சொல்கின்றன. p50 அன்றாட செயல்திறனைக் குறிக்கிறது; p90/p95 நெருக்கடி, வேகக் கட்டுப்பாடு மற்றும் வரிசையில் காத்திருத்தல் ஆகியவற்றை வெளிப்படுத்துகிறது.

மறு அனுப்பல் ஒழுங்கு %

அதிகாரப்பூர்வ மறு அனுப்பல் திட்டத்தைப் பின்பற்றிய அமர்வுகளின் விகிதத்தைக் கண்காணிக்கவும். மிக விரைவாக மறு அனுப்பப்பட்ட சோதனைகளை டெலிவரிபிலிட்டி குறித்த முடிவுகளிலிருந்து நீக்கவும்.

தோல்வி வகைப்பாட்டுக் குறியீடுகள்

GL (greylisting), RT (விகித வரம்பு), BL (தடுக்கப்பட்ட டொமைன்; பயனர் தொடர்பு/தாவல் மாற்றம்), மற்றும் OT (மற்றவை). சம்பவக் குறிப்புகளில் குறியீடுகள் கட்டாயம்.

8) உச்சநேரங்களுக்கான QA செயல்திட்டத்தை உருவாக்குதல்

குறியீடுகளை இழக்காமல், கேமிங் வெளியீடுகள் அல்லது ஃபின்டெக் மாற்றங்களின்போது ஏற்படும் போக்குவரத்து வெடிப்புகளைக் கையாளுங்கள்.

நிகழ்வுகளுக்கு முன் வார்ம்-அப் இயக்கங்கள்

உச்சநேரத்திற்கு 24–72 மணி நேரத்திற்கு முன்பே, அறியப்பட்ட அனுப்புநர்களிடமிருந்து குறைந்த விகிதத்தில் வழக்கமான OTP அனுப்புதல்களை மேற்கொள்ளுங்கள்; இதன் மூலம் அனுப்புநர் நற்பெயரை வார்ம்-அப் செய்யலாம். வார்ம்-அப் காலம் முழுவதும் p90 போக்குக்கோடுகளை அளவிடுங்கள்.

ஆபத்து அடிப்படையிலான பேக்ஆஃப் சுயவிவரங்கள்

ஆபத்து வகைகளுடன் பேக்ஆஃப் வளைவுகளை இணைக்கவும். சாதாரண தளங்களுக்கு, சில நிமிடங்களில் இரண்டு மறுமுயற்சிகள் போதுமானவை. அதிக ஆபத்துள்ள ஃபின்டெக் சேவைகளுக்கு, நீண்ட இடைவெளிகளும் குறைவான மறுமுயற்சிகளும் எச்சரிக்கைகள் எழுப்பப்படுவதைக் குறைக்கும்.

கேனரி சுழற்சிகளும் எச்சரிக்கைகளும்

ஒரு நிகழ்வின்போது, 5–10% OTPகளை கேனரி டொமைன்களின் துணைத்தொகுப்பு வழியாக அனுப்புங்கள். கேனரிகளில் p90 அதிகரிப்பதையோ வெற்றி விகிதம் குறைவதையையோ கண்டால், முதன்மைக் குழுவை முன்கூட்டியேச் சுழற்றுங்கள்.

பேஜர் மற்றும் ரோல்பேக் தூண்டுதல்கள்

எண் அடிப்படையிலான தூண்டுதல்களை வரையறுக்கவும்—எடுத்துக்காட்டாக, OTP வெற்றி விகிதம் 10 நிமிடங்களுக்கு 92%-க்குக் கீழே குறைவது அல்லது TTFOM p90 180 வினாடிகளைத் தாண்டுவது. இத்தகைய நிலைகளில் ஆன்-கால் பணியாளர்களுக்கு பேஜ் அனுப்பவும், காத்திருப்பு இடைவெளிகளை நீட்டிக்கவும் அல்லது தயார் நிலையில் உள்ள குழுவுக்கு மாற்றவும்.

9) பாதுகாப்பான கையாளுதலும் தனியுரிமைக் கட்டுப்பாடுகளும்

ஒழுங்குபடுத்தப்பட்ட துறைகளில் சோதனை நம்பகத்தன்மையை உறுதி செய்யும் அதேவேளையில், பயனர் தனியுரிமையைப் பாதுகாக்கவும்.

பெறுவதற்கு மட்டும் பயன்படுத்தும் சோதனை அஞ்சல் பெட்டிகள்

துஷ்பிரயோக வாய்ப்புகளையும் வெளிச்செல்லும் அபாயத்தையும் கட்டுப்படுத்த, பெறுவதற்கு மட்டும் பயன்படுத்தும் தற்காலிக மின்னஞ்சல் முகவரியைப் பயன்படுத்துங்கள். இணைப்புகள் வெறுமனே இந்தச் செயல்முறையின் வரம்பிற்கு வெளியிலல்ல—Tmailor இன்பாக்ஸ் கோப்புகளைப் பெறவே முடியாது, ஏனெனில் உள்வரும் ஒவ்வொரு இணைப்பும் வந்தவுடனேயே நீக்கப்படுகிறது. சோதிக்கப்படும் செயல்முறை ஏதேனும் ஒன்றைக் கோப்பாக வழங்கினால், அதை இங்கே சரிபார்க்க முடியாது.

24 மணி நேரத் தெரிவுநிலை காலங்கள்

சோதனைச் செய்திகள் வந்த நேரத்திலிருந்து சுமார் 24 மணிநேரம் வரை காணக்கூடியதாக இருந்து, பின்னர் தானாகவே நீக்கப்பட வேண்டும். இந்தக் காலம் மதிப்பாய்வுக்கு போதுமான நீளமுடையதுடன், தனியுரிமையைப் பாதுகாக்கும் அளவுக்கு குறுகியதாகவும் இருக்கும். கொள்கை மேலோட்டமும் பயன்பாட்டுக் குறிப்புகளும் தேவையானால், தற்காலிக அஞ்சல் வழிகாட்டி குழுக்களுக்கான நிலையான அடிப்படைகளைத் தொகுக்கிறது.

GDPR/CCPA பரிசீலனைகள்

செயல்முறை அனுமதிக்கும் இடங்களில், உண்மையான தனிப்பட்ட தரவைச் சோதனை மின்னஞ்சல்களில் பயன்படுத்தாதீர்கள். ஒரு சோதனையில் அதைத் தவிர்க்க முடியாதபோது, அந்தச் சோதனைக்குத் தேவையான அளவுக்கு மட்டுமே தரவை வரையறுத்து, சேமிப்புக் காலத்தைக் குறுகியதாக வைத்திருந்து, பதிவுகள், ஸ்கிரீன்ஷாட்கள் மற்றும் நகலெடுக்கப்பட்ட குறியீடுகளை உடனடியாக நீக்குங்கள். குறுகிய சேமிப்புக் காலம், சுத்திகரிக்கப்பட்ட HTML மற்றும் படப் ப்ராக்ஸியிங் ஆகியவை தரவு வெளிப்பாட்டைக் குறைக்கின்றன; ஆனால் அவை பகிரப்பட்ட, அங்கீகாரமற்ற இன்பாக்ஸை தனிப்பட்ட தரவுக்கான பாதுகாப்பான இடமாக மாற்றாது. தற்காலிக மின்னஞ்சல் முகவரி கட்டுப்படுத்தப்பட்ட தரவுச் சேமிப்பிடம் அல்ல: முகவரியை வைத்திருக்கும் எவரும் அதில் வரும் உள்ளடக்கத்தைப் படிக்கலாம். மேலும், இன்பாக்ஸில் ஸ்பேம் கோப்புறையோ வடிப்பான்களோ இல்லாததால், உள்வரும் ஒவ்வொரு செய்தியும் நேரடியாகக் காட்டப்படும்.

பதிவு மறைப்பும் அணுகலும்

Access Tokenகளையும் குறியீடுகளையும் பதிவுகளிலிருந்து நீக்குங்கள்; இன்பாக்ஸ்களுக்கான Access Tokenகளில் பங்கு அடிப்படையிலான அணுகலை விரும்புங்கள். எந்தச் சோதனை அஞ்சல் பெட்டியை யார், எப்போது மீண்டும் திறந்தார்கள் என்பதற்கான தணிக்கைப் பதிவுகளைப் பராமரிக்கவும். Access Token என்பது தோல்வியின் ஒற்றைப் புள்ளி என்பதை நினைவில் கொள்ளுங்கள்: அது கடவுச்சொல் அல்ல, மீட்பு விசை; அது முகவரிக்கான அணுகலை வேறு யாரிடமிருந்தும் தடுக்காது; மேலும் தொலைந்த tokenஐ யாராலும், Tmailor உட்பட, மீண்டும் உருவாக்க முடியாது.

10) நிர்வாகம்: இந்தச் சரிபார்ப்புப் பட்டியலுக்குப் பொறுப்பாளர் யார்?

இந்த ஆவணத்தில் உள்ள ஒவ்வொரு கட்டுப்பாட்டிற்கும் பொறுப்பு, நடைமுறை இடைவெளி மற்றும் ஆதாரங்களை ஒதுக்குங்கள்.

OTP நம்பகத்தன்மைக்கான RACI

பொறுப்பாளர் உரிமையாளர் (பெரும்பாலும் QA), பொறுப்புக்கூறுபவர் ஸ்பான்சர் (பாதுகாப்பு அல்லது தயாரிப்பு), ஆலோசிக்கப்படுபவர் ( (உள்கட்டமைப்பு/மின்னஞ்சல்), மற்றும் தகவல் பெறுபவர் (ஆதரவு). இந்த RACI-ஐ ரெப்போவில் வெளியிடவும்.

காலாண்டுக் கட்டுப்பாட்டு மதிப்பாய்வுகள்

ஒவ்வொரு காலாண்டிலும், மறுஅனுப்பல் சாளரங்கள், சுழற்சி வரம்புகள் மற்றும் மெட்ரிக் லேபிள்கள் தொடர்ந்து அமல்படுத்தப்படுகின்றனவா என்பதைச் சரிபார்க்க, சரிபார்ப்புப் பட்டியலுக்கு எதிராக மாதிரி இயக்கங்கள் நடத்தப்படுகின்றன.

சான்றுகள் மற்றும் சோதனைப் பதிவுகள்

ஒவ்வொரு கட்டுப்பாட்டுடனும் ஸ்கிரீன்ஷாட்கள், TTFOM விநியோகங்கள் மற்றும் அனுப்புநர்×டொமைன் அட்டவணைகளை இணைக்கவும்—access tokenகளை அவை பயன்படுத்தப்படும் சோதனைத் தொகுப்புக்கான குறிப்புகளுடன் பாதுகாப்பாகச் சேமிக்கவும்.

தொடர்ச்சியான மேம்பாட்டு சுழற்சிகள்

சம்பவங்கள் நிகழும்போது, செயல்முறை/எதிர்முறையை runbook-ல் சேர்க்கவும். வரம்புகளைச் சரிசெய்து, டொமைன் தொகுப்புகளைப் புதுப்பித்து, சோதனையாளர்கள் பார்க்கும் உரையையும் புதுப்பிக்கவும்.

ஒப்பீட்டு அட்டவணை — சுழற்சியுடன் மற்றும் சுழற்சி இல்லாமல் (QA/UAT)

இந்த அட்டவணை பொறியியல் வழிகாட்டுதலே தவிர, செயல்திறன் ஒப்பீட்டுத் தரவு அல்ல. இதில் தாமதம் அல்லது வெற்றி விகிதப் புள்ளிவிவரங்கள் வேண்டுமென்றே இல்லை: அவை அனுப்பும் தளம், பெறும் டொமைன், உருவாக்கம் மற்றும் நாளின் நேரம் ஆகியவற்றைப் பொறுத்து மாறுபடும்; எனவே இங்கே குறிப்பிடப்படும் எந்த எண்ணையும் உங்களால் மீண்டும் உருவாக்க முடியாது. மேலே வரையறுக்கப்பட்ட மெட்ரிக்குகளை கருவியமைத்து, உங்கள் சொந்த அடிப்படை அளவை நிர்ணயியுங்கள் — பின்னர் இதை எவ்வாறு கையாள்வது என்பதைத் தீர்மானிக்கக் கீழே உள்ள வரிசைகளைப் பயன்படுத்துங்கள்.