ያለ QA ሃብት መሞከር

በገንቢዎች እና በቢ.ኤስ. እና ያለ QA ሀብት ብቻ የሶፍትዌር መተግበሪያን በቂ ምርመራ ማድረግ ይቻላልን?

እዚህ ሁለት የአስተሳሰብ ትምህርት ቤቶች አሉ-

አንደኛው ሁሉም ሳንካዎች ከቁጥር ጋር እንደሚዛመዱ እና ለእርስዎ ኮድ በጣም ከፍተኛ የሙከራ ሽፋን ካለዎት በመሠረቱ ምንም ሳንካዎች አይኖርዎትም የሚል እምነት ነው ፡፡ እንደ ሞካሪዎች ሁላችንም ይህ እውነት እንዳልሆነ ሁላችንም እናውቃለን!


ሌላኛው እምነት እርስዎ በቂ የአሃድ ምርመራዎችን ያካሂዳሉ እንዲሁም ትግበራ ለዓላማ ተስማሚ መሆኑን ለማረጋገጥ ውህደትን ፣ ስርዓትን እና የተጠቃሚ ተቀባይነት ፍተሻ ያካሂዳሉ ፡፡ ምንም እንኳን ይህ ጥሩ ሀሳብ ቢመስልም ገንቢዎች አዳዲስ ባህሪያትን በኮድ ላይ ማግኘት ስለሚያስፈልጋቸው ተግባራዊ አይደለም!

እነዚህ ሁለቱም እምነቶች ጽንፈኞች ናቸው ፡፡


የራስዎን ኮድ መፈተሽ ውጤታማ ሊሆን ይችላል ፣ ምክንያቱም እንደ ገንቢ የትኛው የኮድዎ ክፍል ውስብስብ እና የበለጠ ተጋላጭ የመሆን እድሉ ሰፊ ስለሆነ ያው እርስዎ በዚያ አካባቢ ላይ ያተኩራሉ። እንዲሁም ተጨማሪ QA እንደሌለ በማወቅ አንድ ገንቢ እንደሚናገረው የጥራት ኮድ ለመጻፍ ይገደዳሉ

በመጀመሪያ ሥራዬ ውስጥ QA አልነበረኝም ፡፡ የራሴን ኮድ ከመልቀቄ በፊት በቂ ጥራት ያለው መሆኑን ማረጋገጥ የእኔ ነበር ፣ እናም ያ ገጽታ በጣም ፈርቶኛል የጥራት ኮድ መፃፍ መማር (ይህም ማለት በመሠረቱ የራስዎን ኮድ በደንብ እየፈተኑ ነው ፣ የራስዎን QA እያደረጉ ነው) ፡፡

የገንቢ ሙከራው በቂ ነው?

የሶፍትዌር ገንቢዎች የራሳቸውን ኮድ ጥራት በባለቤትነት እንዲወስዱ ማበረታታት ጥሩ እርምጃ ነው ብዬ አምናለሁ ፣ ሆኖም የራስዎን ኮድ ሲሞክሩ አንድ ሙሉ የትልች ክፍሎችን የማጣት ዕድሉ ሰፊ ነው ፡፡

ሊያስቧቸው የሚችሏቸውን ዓይነት ትሎች በመያዝ ረገድ በጣም ውጤታማ ሊሆኑ ይችላሉ ፣ ግን እነዚያ ሁል ጊዜ በመጀመሪያ ቦታ ለመያዝ በጣም ቀላሉ ስህተቶች ናቸው ፡፡ ለራስዎ የሚጽ Theቸው ፈተናዎች ኮዱ ምን ማድረግ እንዳለበት ፣ ምን ዓይነት ግብዓቶችን ማስተናገድ እንዳለበት ፣ ወዘተ በሚሉ ግምቶችዎ ውስጥ ስህተቶችን ለመያዝ በጭራሽ ጥሩ ሥራ አይሠሩም ፡፡ ከተመሳሳይ ግምቶች ስብስብ ጀምሮ።


እንደ ራስ-ሰር ሞካሪነት መሥራት ማለት በሁለቱም ላይ በሙከራ እና በኮድ ላይ ማተኮር ነበረብኝ ፣ እናም ብዙ ጊዜ ታገልኩ ነበር! ፈተናዎቹን በምሰጥርበት ጊዜ ኮዱ እንዲፈጽም እና ፈተናው እንዲያልፈው ማረጋገጥ ፈልጌ ነበር ፣ ዋናው ትኩረቴ በኮዲንግ ላይ ስለነበረ ትክክለኛውን ፈተና ምን እንደ ሆነ በጣም አልተጨነኩም ፡፡ ብዙም ሳይቆይ ዋጋ የማይሰጡ የማይጠቅሙ ሙከራዎችን በራስ-ሰር ማድረጌን ተገነዘብኩ ፡፡

ሌላው ልብ ሊባል የሚገባው ነጥብ ዩኒት ምርመራ በኮድ ውስጥ የፕሮግራም አወጣጥ ስህተቶችን ብቻ ይይዛል ፣ የአሃድ ምርመራ በመተግበሪያው ውስጥ አለመሳካቶችን አይለይም ማለት ነው ፣ ይህም ማለት 100% የኮድ ሽፋን ካለዎት ይህ ማለት ከ ‹ሳንካ› ነፃ መተግበሪያ ማለት አይደለም ፡፡

ከመተላለፉ በፊት የራስዎን ኮድ በንጥል ሙከራዎች ለመፈተሽ ሁልጊዜ አስፈላጊ ቢሆንም ፣ ያንን ሁለተኛው የዓይኖች ስብስብ ከባህሪው አንጻር ማየቱ አስፈላጊ ነው ፡፡ እኛ በትክክል በትክክል ለመምታት እና በእውነቱ ያልተለመዱ የጠርዝ ጉዳዮችን ለማስገኘት ከኮዱ ጋር በጣም እንቀርባለን ፣ እና ጥሩ የ QA ሰዎች ይህንን ለማድረግ በጣም የተዋጣላቸው ናቸው። እንደ ሞካሪዎች ባሉ ሌላ የተጠቃሚዎች ስብስብ በስርዓት ደረጃ መሞከር ብዙውን ጊዜ በጣም አስደሳች ሳንካዎችን ያሳያል ፡፡

ደግሞም ፣ ሁሉም ስለ ተግባራዊ ሙከራ አይደለም። ከፍተኛ ጥራት ያለው ሶፍትዌር ለመልቀቅ ከፈለግን ስለ አፈፃፀም ምርመራ ፣ ስለደህንነት ምርመራ ፣ ስለአጠቃቀም አጠቃቀም ፍተሻ ፣ ወዘተ ልንጨነቅ እና መጨነቅ አለብን ፡፡


ለምን አሁንም QA እንፈልጋለን?

መሞከሪያዎች አንዳንድ ጊዜ ለጠቅላላው የመላኪያ ቧንቧ ማነቆ ሆነው ይታያሉ ፡፡ መለቀቁን ለማስቆም ሁሉም ነገር ያለ በእጅ ጣልቃ-ገብነት እና ሳንካዎችን የማይነሱ ሞካሪዎች ሁሉ በራስ-ሰር ቢሠሩ በጣም የተሻለ አይሆንም?

ሞካሪዎች እንደ ማነቆዎች ሲታዩ የችግሩ አንድ አካል በገንቢዎች መካከል የጥራት ባለቤትነት ባለመኖሩ ነው ፡፡ ሁሉም ለምርቱ ጥራት ተጠያቂ እንደሆኑ ብቻ ከተሰማቸው (ኮድ ብቻ አይደለም) ከዚያ ገንቢዎች እና ሞካሪዎች ወደ አንድ ግብ ይሰራሉ።

ሞካሪዎች የተሻሉ የንጥል ሙከራዎችን ለመጻፍ ከአዘጋጆች ጋር ሊጣመሩ ይችላሉ እንዲሁም ገንቢዎች በራስ-ሰር ቼኮች በመፃፍ ሞካሪዎችን ሊረዱ እንዲሁም በስርዓት ሙከራ ወቅት በጣም የሚበታተኑ ቦታዎችን ለመፈለግ ጥሩ ሙከራዎችን ለመንደፍ ሞካሪዎችን ስለ ማመልከቻው ሥነ-ሕንፃ ማስተማር ይችላሉ ፡፡

በአንድ ተስማሚ ዓለም ውስጥ ፣ ሞካሪዎች ምንም እንከን ማግኘት የለባቸውም ፣ ወይም ቢያንስ ጥቃቅን ጉድለቶች. ጉድለቶችን መፈለግ ሥራው “የ QA ቡድን” ሲኖር ገንቢዎች ሁሉንም ጉድለቶች ፈልጎ ለማግኘት በሞካሪዎች ላይ ብቻ መመርመራቸው ገንቢዎች በልማት እና በኮድ ላይ ያተኮሩ ናቸው ፡፡


የ “ያሁ” የ “QA” እና የሙከራ ክፍልን የማስወገድ እርምጃ ገንቢዎች የምርቱን ጥራት በባለቤትነት እንዲወስዱ የሚያበረታታ ቢሆንም አሁንም ጠንካራ ምርት ለማረጋገጥ በቂ አይደለም ፡፡ ይህን ከተናገርኩ ከሞካሪዎች ቡድን ጋር እንኳን አሁንም ቢሆን ከ ‹ሳንካ-ነፃ› ሶፍትዌሮች ዋስትና መስጠት አትችሉም ነገር ግን አስፈላጊው ነገር ሶፍትዌሩ ከተለያዩ የአመለካከት አቅጣጫዎች እና ከተለያዩ አመለካከቶች እንዲመለከተው ማረጋገጥ ነው ፡፡ ጥሩ የ QA ተግባር (ከ QA ቡድን በተቃራኒ) ይመጣል ፡፡

ሞካሪዎች ሶፍትዌሮችን ከመልቀቃቸው በፊት በጣም ወሳኝ የሆኑትን ስህተቶች ለመለየት የሚረዱ ገንቢዎች ምርጥ የጥራት ማረጋገጫ ልምዶችን እንዲከተሉ እና በቴክኒካዊ እና በንግድ የሙከራ ዲዛይኖች እንዲረዱ ማድረግ ይችላሉ ፡፡