சுறுசுறுப்பான சோதனை உத்தி எடுத்துக்காட்டு வார்ப்புரு



சுறுசுறுப்பான சோதனை உத்தி

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

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

இங்கே, ஒரு மாதிரி சுறுசுறுப்பான சோதனை உத்தி மற்றும் ஆவணத்தில் என்ன சேர்க்க வேண்டும் என்பதைப் பார்ப்போம்.


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

ஒரு பொதுவான பணி அறிக்கை பின்வருமாறு:


வாடிக்கையாளரின் தேவைகளைப் பூர்த்திசெய்யும் பணி மென்பொருளை தொடர்ந்து வழங்குவதற்கு _ விரைவான கருத்தை வழங்குவதன் மூலம் _ குறைபாடு கண்டறிதலைக் காட்டிலும் _ தடுப்பு தடுப்பு.

உதவியவா்:


  • ஒரு கதையின் ஏற்றுக்கொள்ளும் அளவுகோல்களை / சோதனைகளை நாம் முதலில் வரையறுக்கும் வரை எந்தக் குறியீடும் எழுதப்படக்கூடாது

  • ஒரு கதை அதன் ஏற்றுக்கொள்ளும் சோதனைகள் அனைத்தும் கடந்து செல்லும் வரை முழுமையானதாக கருதப்படாது

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


  • QA என்பது தயாரிப்புகள் வாடிக்கையாளர் தேவைகளை ஒரு முறையான, நம்பகமான முறையில் பூர்த்திசெய்வதை உறுதிசெய்யும் செயல்பாடுகளின் தொகுப்பாகும்.



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



சோதனை நிலைகள்

அலகு சோதனை

ஏன்: குறியீடு சரியாக உருவாக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்த

WHO: டெவலப்பர்கள் / தொழில்நுட்ப கட்டிடக் கலைஞர்கள்


என்ன: அனைத்து புதிய குறியீடு + மரபு குறியீட்டின் மறு-காரணி மற்றும் ஜாவாஸ்கிரிப்ட் அலகு சோதனை

எப்பொழுது: புதிய குறியீடு எழுதப்பட்டவுடன்

எங்கே: உள்ளூர் தேவ் + சிஐ (உருவாக்கத்தின் ஒரு பகுதி)

எப்படி: தானியங்கு, ஜூனிட், டெஸ்ட்என்ஜி, PHPUnit




API / சேவை சோதனை

ஏன்: கூறுகளுக்கு இடையிலான தொடர்பு செயல்படுவதை உறுதி செய்ய

WHO: டெவலப்பர்கள் / தொழில்நுட்ப கட்டிடக் கலைஞர்கள்

என்ன: புதிய வலை சேவைகள், கூறுகள், கட்டுப்படுத்திகள் போன்றவை

எப்பொழுது: புதிய ஏபிஐ உருவாக்கப்பட்டு தயாரானவுடன்


எங்கே: உள்ளூர் தேவ் + சிஐ (உருவாக்கத்தின் ஒரு பகுதி)

எப்படி: தானியங்கி, சோப் யுஐ, ஓய்வு கிளையண்ட்



ஏற்றுக்கொள்ளும் சோதனை

ஏன்: வாடிக்கையாளரின் எதிர்பார்ப்புகளை பூர்த்தி செய்வதை உறுதி செய்ய

WHO: டெவலப்பர் / SDET / கையேடு QA

என்ன: கதைகள் மீதான ஏற்றுக்கொள்ளல் சோதனைகளை சரிபார்க்கிறது, அம்சங்களின் சரிபார்ப்பு

எப்பொழுது: அம்சம் தயாராக இருக்கும்போது மற்றும் அலகு சோதிக்கப்படும் போது

எங்கே: சிஐ / சோதனை சூழல்

எப்படி: தானியங்கி (வெள்ளரி)



கணினி சோதனை / பின்னடைவு சோதனை / UAT

ஏன்: ஒருங்கிணைக்கும்போது முழு அமைப்பும் செயல்படுவதை உறுதி செய்ய

WHO: SDET / கையேடு QA / வணிக ஆய்வாளர் / தயாரிப்பு உரிமையாளர்

என்ன: காட்சி சோதனை, பயனர் பாய்ச்சல்கள் மற்றும் வழக்கமான பயனர் பயணங்கள், செயல்திறன் மற்றும் பாதுகாப்பு சோதனை

எப்பொழுது: ஏற்றுக்கொள்ளும் சோதனை முடிந்ததும்

எங்கே: நிலை சூழல்

எப்படி: தானியங்கு (வெப் டிரைவர்) ஆய்வு சோதனை



தயாரிப்பு பின்னிணைப்பு

மென்பொருள் மேம்பாட்டு தோல்விக்கான பொதுவான காரணம் தெளிவற்ற தேவைகள் மற்றும் குழுவின் வெவ்வேறு உறுப்பினர்களின் தேவைகளின் மாறுபட்ட விளக்கம்.

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

ஒரு நல்ல பயனர் கதை இருக்க வேண்டும்:

நான் (மற்ற அனைவரின்) சார்பு

என் egotiable (அம்சங்களுக்கான ஒரு குறிப்பிட்ட ஒப்பந்தம் அல்ல)

வி மாற்றத்தக்க (அல்லது செங்குத்து )

இருக்கிறது தூண்டக்கூடியது (ஒரு நல்ல தோராயத்திற்கு)

எஸ் மால் (ஒரு மறு செய்கைக்குள் பொருந்தும் வகையில்)

டி estable (கொள்கையளவில், அதற்கான சோதனை இன்னும் இல்லையென்றாலும்)

பயனர் கதைகளை எழுத பின்வரும் வடிவம் பயன்படுத்தப்பட வேண்டும்

As a [role] I want [feature] So that [benefit]

கதையை வளர்ப்பதன் மூலம் அவர்கள் எந்த மதிப்பைச் சேர்க்கிறார்கள் என்பதை அனைவரும் அறிந்திருக்க வேண்டும் என்பதால், “நன்மை” பகுதியை மறந்துவிடக்கூடாது என்பது முக்கியம்.

ஏற்று கொள்வதற்கான நிபந்தனை

ஒவ்வொரு பயனர் கதைகளும் ஏற்றுக்கொள்ளும் அளவுகோல்களைக் கொண்டிருக்க வேண்டும். இது அணியின் வெவ்வேறு உறுப்பினர்களுடன் தொடர்பு கொள்ள ஊக்குவிக்கும் மிக முக்கியமான உறுப்பு.

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

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

Scenario 1: Title Given [context] And [some more context]... When  [event] Then  [outcome] And [another outcome]...

கதை பட்டறைகள் / ஸ்பிரிண்ட் திட்டமிடல்

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

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

குறைபாடுகளைத் தடுக்கும்

கதை பட்டறைகளில், PO, BA, Dev, மற்றும் QA ஆகியவை இதில் ஈடுபட வேண்டும்.

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

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

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

அதேபோல், ஸ்பிரிண்ட் திட்டமிடல் கூட்டங்களில், ஒரு கதைக்கு வழங்கப்பட்ட மதிப்பீடுகளில் சோதனை முயற்சியும் குறியீட்டு முயற்சியும் இருக்க வேண்டும். QA (கையேடு மற்றும் ஆட்டோமேஷன்) கூட இருக்க வேண்டும் கதையைச் சோதிப்பதற்கான மதிப்பீட்டை வழங்க ஸ்பிரிண்ட் திட்டமிடல் கூட்டங்களில்.



வளர்ச்சி

வளர்ச்சி தொடங்கும் போது, ​​புதிய உற்பத்தி குறியீடு மற்றும் / அல்லது மரபு குறியீட்டை மாற்றியமைப்பது ஆதரிக்கப்பட வேண்டும் டெவலப்பர்களால் எழுதப்பட்ட அலகு சோதனைகள் மற்றும் மற்றொரு டெவலப்பர் அல்லது திறமையான SDET ஆல் மதிப்பாய்வு செய்யப்பட்டது.

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

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



டெவலப்பர் சோதனை

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

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

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



தானியங்கு ஏற்றுக்கொள்ளல் சோதனைகள் மற்றும் செயல்படாத சோதனை

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

தானியங்கு ஏற்றுக்கொள்ளல் சோதனைகள் வழக்கமாக கெர்கின் மொழியில் எழுதப்பட்டு வெள்ளரி போன்ற BDD கருவியைப் பயன்படுத்தி செயல்படுத்தப்படுகின்றன.

நினைவில் கொள்ளுங்கள் : எல்லா சோதனைகளும் தானியங்கி செய்யப்பட வேண்டியதில்லை!

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

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

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

பாதுகாப்பு சோதனைகள் பெறப்பட்ட அடிப்படை பாதுகாப்பு பாதிப்புகளை சரிபார்க்க வேண்டும் OWASP

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

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



பின்னடைவு சோதனை

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

ஸ்மோக் பேக் - 15 நிமிடங்களுக்கு மேல் இருக்கக்கூடாது

இந்த பேக் மேலும் மேம்பாடு அல்லது சோதனைக்கு பயன்பாடு நிலையானது என்பதை உறுதிப்படுத்த உயர் மட்ட செயல்பாடுகளை மட்டுமே கொண்டுள்ளது.

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

  • தயாரிப்பு தேடல்,
  • தயாரிப்பு விமர்சனம்
  • பொருளை வாங்கவும்
  • கணக்கு உருவாக்கம் / கணக்கு உள்நுழைவு

முழு பின்னடைவு பொதி - 1 மணி நேரத்திற்கு மேல் இருக்கக்கூடாது

இந்த பேக் சோதனைகளின் முழு பின்னடைவு தொகுப்பைக் கொண்டுள்ளது மற்றும் புகை மூட்டையில் சேர்க்கப்படாத எல்லாவற்றையும் கொண்டுள்ளது.

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



UAT மற்றும் ஆய்வு சோதனை

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

PO (தயாரிப்பு உரிமையாளர்) பயனர் ஏற்றுக்கொள்ளும் சோதனைகளை இயக்க வேண்டும் அல்லது கட்டமைக்கப்பட்ட தயாரிப்பை உறுதிப்படுத்த வணிக ஏற்றுக்கொள்ளல் சோதனைகள் எதிர்பார்த்தது மற்றும் அது பயனரின் எதிர்பார்ப்புகளை பூர்த்தி செய்கிறது.

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



முடிந்தது அளவுகோல்

மேலே உள்ள அனைத்து நடவடிக்கைகளும் முடிந்ததும், சிக்கல்கள் எதுவும் காணப்படவில்லை என்றால், கதை முடிந்தது!

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

சுவாரசியமான கட்டுரைகள்