கீறலில் இருந்து QA செயல்பாட்டை எவ்வாறு அமைப்பது

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

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

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


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

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


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



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

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

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

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


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

பின்னடைவு சோதனை / ஸ்பிரிண்ட் சோதனை

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

இணையாக குறைந்தது இரண்டு பணிகள் உள்ளன: ஸ்பிரிண்டில் புதிய கதைகளைச் சோதித்தல் மற்றும் ஓரளவு பின்னடைவு சோதனை செய்தல்.

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


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

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

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

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


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

மிக முக்கியமாக, இந்த பின்னடைவு காட்சிகள் தானியங்கி செய்யப்பட வேண்டும்.

தானியங்கு சோதனை

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

வரிசைப்படுத்தல் / பைப்லைனை உருவாக்குதல்

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


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

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

கதை பட்டறைகள்

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

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

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

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

வளர்ச்சியின் போது டெவலப்பர் சோதனை / சோதனை

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

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

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

தொடர்ச்சியான ஒருங்கிணைப்பு / சோதனை சூழல்கள்

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

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

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

செயல்படாத சோதனை

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

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

கருத்தில் கொள்ள வேண்டிய பிற புள்ளிகள்

  • குறுக்கு உலாவி, குறுக்கு சாதன சோதனை
  • மொபைல் மற்றும் டேப்லெட் சோதனை
  • தானியங்கி சோதனைகளின் இணையான செயல்படுத்தல்
  • ஆய்வு சோதனை
  • ஜிரா, ஜென்கின்ஸ், செலினியம் போன்ற கருவிகள்…
  • தொடர்ச்சியான முன்னேற்றம்
  • சோதனையாளர்களின் ஆட்சேர்ப்பு

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