டெஸ்ட் ஆட்டோமேஷன் மற்றும் நவீன QA உடன் சிக்கல்கள்

சுறுசுறுப்பான மற்றும் டெவொப்ஸில் சோதனை ஆட்டோமேஷனில் சில பொதுவான சிக்கல்கள் யாவை?

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

அதிக தானியங்கி சோதனைகள் மூலம் சிறந்த தரமான மென்பொருளை வெளியிடுகிறோமா? நான் நினைக்கவில்லை!


நான் சமீபத்தில் ஒரு சமூக ஊடக வலையமைப்பில் ஒரு இடுகையைப் பார்த்தேன்

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


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

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

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

நல்ல சோதனை நிகழ்வுகளை எவ்வாறு எழுதுவது என்பதை நாங்கள் மக்களுக்குக் கற்பிக்கவில்லை என்றால், நாங்கள் முழுமையாக தானியங்கி முறையில் முடிவடையும்…


என் விளக்கம் ... 'தனம்'. :-)

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



நவீன QA உடன் சிக்கல்கள்

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

குறிப்பு:டெஸ்ட் ஆட்டோமேஷன் மூலம், நான் பெரும்பாலும் குறிப்பிடுகிறேன் ONION சோதனை ஆட்டோமேஷன்.

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


சோதனையாளர்கள் இன்னும் சோதிக்கிறார்களா?

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

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

“நான் 100% ஆட்டோமேஷன் பொறியாளர்”, அல்லது “80% ஆட்டோமேஷன் 20% கையேடு” அல்லது அதைவிட மோசமான “நான் கையேடு சோதனையை வெறுக்கிறேன்” போன்ற விஷயங்களை நீங்கள் அடிக்கடி கேட்பீர்கள். அதிர்ச்சி!

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


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

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

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

கையேடு சோதனையில் சரிவு

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


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

இருப்பினும், பெரும்பாலான கையேடு சோதனையாளர்கள் இந்த முயற்சிகளை எடுப்பதற்கான உண்மையான காரணம் என்னவென்றால், “தானியங்கி சோதனை” கையேடு சோதனைக்கு மேலானது என்ற பொதுவான நம்பிக்கை உள்ளது, ஏய், குறியீட்டு முறை வேடிக்கையானது, இல்லையா?

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

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



டெஸ்ட் ஆட்டோமேஷனில் சிக்கல்கள்

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

பொதுவான தவறுகள் மீண்டும் மீண்டும் நடப்பதை நான் காண்கிறேன்:

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

தவறான எதிர்பார்ப்புகள்

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

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

இருப்பினும், தானியங்கு காசோலைகள் நிறைய பின்னடைவு சிக்கல்களைக் கண்டால், டெவலப்பர்களின் திறன்களையும் மேம்பாட்டு செயல்முறையையும் நான் கேள்விக்குள்ளாக்குவேன். UI தானியங்கி சோதனைகள் [செலவில் நடத்தப்படக்கூடாது] அல்லது அசிங்கமான குறியீட்டுக்கு [ஈடுசெய்யப்படக்கூடாது].

தவறான அடுக்கு, தவறான கருவிகள் மற்றும் தவறான நேரம்

சுறுசுறுப்பான அணிகளில் பெரும்பான்மையான “டெஸ்ட் ஆட்டோமேஷன் பொறியாளர்கள்”, ஒரு பயனர் கதையைப் பார்த்து, அதை ஏற்றுக்கொள்வதற்கான அளவுகோல்களை தானியக்கமாக்குங்கள். பெரும்பாலும் இது செலினியம் மற்றும் வெள்ளரிக்காய் ஆகியவற்றின் கலவையால் செய்யப்படுகிறது.

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

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

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

UI சோதனைகள் ஆட்டோமேஷனைப் பொறுத்தவரை, சைப்ரஸ் ஒரு சிறந்த கருவி. இது முன்-இறுதி டெவலப்பர்களுக்கான டி.டி.டி கருவி போன்றது. டெவலப்பர்கள் புதிய UI கூறுகளின் நடத்தை குறித்து மிக விரைவான கருத்தைப் பெறுகிறார்கள்.

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

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

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

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

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

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

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

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

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

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

எனவே, ஒவ்வொரு முறையும் நீங்கள் ஒரு “சோதனையை” தானியக்கமாக்குவதற்கு செலவழிக்கும்போது, ​​சோதனை செய்யாமல் நீங்கள் வீணடிக்கும் நேரத்தைப் பற்றி சிந்தியுங்கள்!

முக்கிய பகுதிகளை புறக்கணித்தல்

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

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

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

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

நவீன மென்பொருள் விநியோகத்தின் ஒரு பகுதியாக அவற்றை நாங்கள் ஏற்றுக்கொள்கிறோம்.

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

முக்கிய காட்சிகள் இல்லை

காட்சிகள் ராஜா! எல்லாவற்றிற்கும் மேலாக, பிழைகள் வெளிப்படுத்தும் காட்சிகள் இது.

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

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



செயல்பாட்டில் சிக்கல்கள்

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

  • தயாரிப்பு உரிமையாளர் பயனர் கதைகளை இல்லை அல்லது குறைந்தபட்ச ஏற்றுக்கொள்ளும் அளவுகோல்களுடன் எழுதுகிறார்.
  • ஒரு பயனர் கதைக்கான பல்வேறு காட்சிகளைப் பற்றி விவாதிக்க கதை சுத்திகரிப்பு அமர்வுகளுக்கு போதுமான நேரம் ஒதுக்கப்படவில்லை.
  • ஏற்றுக்கொள்ளும் அளவுகோல்கள் ஏற்றுக்கொள்ளும் சோதனைகளாக விளக்கப்படுகின்றன - ஆம், இரண்டிற்கும் இடையே வேறுபாடு உள்ளது !
  • பெரும்பாலும் செலினியம் மற்றும் / அல்லது வெள்ளரிக்காயைப் பயன்படுத்தி பயனர் கதைகளில் ஏற்றுக்கொள்ளும் அளவுகோல்களை மட்டுமே சோதனையாளர்கள் தானியங்குபடுத்துகிறார்கள்.
  • தானியங்கு சோதனை என்பது எப்போதும் “ஆட்டோமேஷன் சோதனையாளர்களின்” பொறுப்பாகும்.
  • டெவலப்பர்களுக்கு சோதனைப் பொதிகளில் என்ன இருக்கிறது என்பது தெரியாது அல்லது தானியங்கு சோதனைகளை எவ்வாறு செயல்படுத்துவது என்று கூட தெரியாது.
  • தானியங்கு சோதனைகள் எப்போதும் விரிவடையும் “பின்னடைவு பொதிக்கு” ​​சேர்க்கப்படுகின்றன, எனவே ஒவ்வொரு முறையும் இயக்க அதிக நேரம் எடுக்கும்.
  • UI தானியங்கு செயல்பாட்டு சோதனைகள் உருவாக்க குழாய் இணைப்பில் ஒருங்கிணைக்கப்பட்டுள்ளன, இது நல்லது ஆனால்…

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

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

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

உள்கட்டமைப்பு தோல்விகள்

தோல்விகள் இதேபோன்ற வடிவத்தைக் காட்டுகின்றன

  • ஒருங்கிணைப்பு புள்ளிகளில் தோல்வி.
  • 3 வது தரப்பு பயன்பாடுகளுடன் தொடர்புகொள்வதில் தோல்வி.
  • வலை சேவைகள் “மேலே” இல்லை மற்றும் API இறுதி புள்ளிகளுக்கான கோரிக்கைகள் தோல்வியடைகின்றன.
  • VM கள் அல்லது முனைகளில் ஒன்றில் தவறான உள்ளமைவு, இதனால் இடைப்பட்ட சிக்கல்கள் ஏற்படும்.

இன்னும், வளர்ச்சி அல்லது விநியோக செயல்முறையின் ஒரு பகுதியாக இந்த சிக்கல்களைச் சரிபார்க்க எந்த செயல்முறையும் இல்லை.

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



சுருக்கம்

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

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

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

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

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

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

நீங்கள் “டெஸ்ட் ஆட்டோமேஷன்” வணிகத்தில் இருந்தால், API கள் அல்லது UI கூறுகளின் செயல்பாட்டை சோதிக்க செலினியத்தைப் பயன்படுத்த வேண்டாம். அதற்கு பதிலாக, ஒவ்வொரு வெளியீட்டிற்கும் முன்னர் வணிக தொடர்ச்சியில் நம்பிக்கையை வழங்க சில பயனுள்ள மற்றும் வணிக-முக்கியமான காட்சிகளை மட்டுமே தானியங்குபடுத்த செலினியத்தைப் பயன்படுத்தவும்.

கடைசியாக, ஒவ்வொரு முறையும் நீங்கள் ஒரு “சோதனையை” தானியக்கமாக்குவதற்கு செலவழிக்கும்போது, ​​சோதனை செய்யாமல் நீங்கள் வீணடிக்கும் நேரத்தைப் பற்றி சிந்தியுங்கள்!

மேலும் படிக்க:

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