சோதனையாளர்களுக்கான ஹேக்கத்தான் ஏன் நடத்தினோம்?

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

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

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

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

சோதனையாளர்களைத் தேடும்போது நாங்கள் சந்தித்தது

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

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

நாங்கள் எப்படி நிலைமையை சரிசெய்ய முயற்சித்தோம்

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

1. பல "லீவ்-இட்" நபர்களை அடையாளம் காண மதிப்பீட்டு நடைமுறைகளைப் பயன்படுத்த முயற்சித்தோம், அவர்களிடமிருந்து வலுவான நிபுணர்களை உருவாக்க முடியும்.

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

   குறிப்பாக, கவனத்தை சோதிக்கும் பணிகளை நாங்கள் கொண்டு வந்தோம், தொழில்நுட்பத்தின் திறன்களைப் புரிந்துகொள்வது மற்றும் பன்முக கலாச்சாரத்தின் அம்சங்கள்:

   
   

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

   அவை ஒவ்வொன்றையும் பற்றி கொஞ்சம் சொல்கிறேன்.

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

   
   
   பின்னர், 1-2 மாத இடைவெளியில், மேலும் இரண்டு சந்திப்புகளை நடத்தினோம். ஏற்கனவே இரு மடங்கு பங்கேற்பாளர்கள் இருந்தனர். "Ufa மென்பொருள் QA மற்றும் சோதனை சந்திப்பு #2" இல் நாங்கள் பொருள் பகுதியில் ஆழமாக மூழ்கினோம். அவர்கள் பிழை கண்காணிப்பு அமைப்புகள், UI/UX சோதனை, டோக்கர், அன்சிபிள் ஆகியவற்றைப் பற்றி பேசினர், மேலும் டெவலப்பருக்கும் சோதனையாளருக்கும் இடையே ஏற்படக்கூடிய முரண்பாடுகள் மற்றும் அவற்றைத் தீர்ப்பதற்கான வழிகள் பற்றியும் பேசினர்.

   எங்கள் மூன்றாவது சந்திப்பு, "Ufa மென்பொருள் QA மற்றும் சோதனை சந்திப்பு #3," சோதனையாளர்களின் பணியுடன் மறைமுகமாக தொடர்புடையது, ஆனால் புரோகிராமர்களின் தொழில்நுட்ப மற்றும் நிறுவன கடமைகளை சரியான நேரத்தில் நினைவூட்டுவதில் பயனுள்ளதாக இருந்தது: சுமை சோதனை, e2e சோதனை, ஆட்டோடெஸ்டிங்கில் செலினியம், இணைய பயன்பாட்டு பாதிப்புகள் .

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

   → சோதனையின் முதல் படிகள் - Ufa மென்பொருள் QA மற்றும் சோதனை சந்திப்பு #1
   → UI/UX சோதனை - Ufa மென்பொருள் QA மற்றும் சோதனை சந்திப்பு #2
   → பாதுகாப்பு சோதனை, சுமை சோதனை மற்றும் தானியங்கு சோதனை - Ufa QA மற்றும் சோதனை சந்திப்பு #3

3. இறுதியில் சோதனையாளர்களுக்காக ஒரு ஹேக்கத்தான் நடத்த முயற்சிக்க முடிவு செய்தோம்

சோதனையாளர்களுக்கான ஹேக்கத்தானை நாங்கள் எவ்வாறு தயார் செய்து நடத்தினோம்

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

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

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

எங்களிடம் கிடைத்தது இங்கே: ஹேக்கத்தானின் பின்னடைவுகள்.

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

நாம் என்ன தவறுகளை செய்தோம், சிறப்பாக என்ன செய்ய முடியும்?

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

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

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

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

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

நீங்கள் என்ன சாதித்தீர்கள்?

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

ஆதாரம்: www.habr.com