പരിശോധനയുടെ അടിസ്ഥാന പ്രശ്നം

ആമുഖം

ഗുഡ് ആഫ്റ്റർനൂൺ, ഖബ്രോവ്സ്ക് നിവാസികൾ. ഇപ്പോൾ ഞാൻ ഒരു ഫിൻടെക് കമ്പനിയുടെ QA ലീഡ് ഒഴിവിനായുള്ള ഒരു ടെസ്റ്റ് ടാസ്‌ക് പരിഹരിക്കുകയായിരുന്നു. ഒരു പൂർണ്ണ ചെക്ക്‌ലിസ്റ്റും ഒരു ഇലക്ട്രിക് കെറ്റിൽ പരീക്ഷിക്കുന്നതിനുള്ള ടെസ്റ്റ് കേസുകളുടെ ഉദാഹരണങ്ങളും ഉള്ള ഒരു ടെസ്റ്റ് പ്ലാൻ സൃഷ്ടിക്കുന്നതിനുള്ള ആദ്യ ചുമതല, നിസ്സാരമായി പരിഹരിക്കാൻ കഴിയും:

• GOST 7400-81. ഗാർഹിക ഇലക്ട്രിക് കെറ്റിലുകളും ഇലക്ട്രിക് സമോവറുകളും. സ്പെസിഫിക്കേഷനുകൾ (ഭേദഗതികൾ നമ്പർ 1-8 സഹിതം)
• GOST IEC 60335-1-2015 വീട്ടുപകരണങ്ങളും സമാനമായ ഇലക്ട്രിക്കൽ ഉപകരണങ്ങളും. സുരക്ഷ. ഭാഗം 1. പൊതുവായ ആവശ്യകതകൾ
  പൂർണ്ണമായ ചെക്ക്‌ലിസ്റ്റ് ഉള്ള ഒരു മികച്ച ടെസ്റ്റ് പ്ലാനിനെക്കുറിച്ച് ചിന്തിക്കുന്നത് ബുദ്ധിമുട്ടാണ്.

എന്നാൽ രണ്ടാം ഭാഗം ഒരു ചോദ്യമായി മാറി: "എല്ലാ ടെസ്റ്റർമാർക്കും പൊതുവായ എന്തെങ്കിലും പ്രശ്നങ്ങൾ കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നതിൽ നിന്ന് അവരെ തടയുന്നുണ്ടോ?"

ടെസ്റ്റിങ്ങിനിടെ ഞാൻ നേരിട്ട ഏറിയും കുറഞ്ഞും ശ്രദ്ധേയമായ എല്ലാ പ്രശ്‌നങ്ങളും ലിസ്റ്റുചെയ്യുക, ചെറിയ കാര്യങ്ങൾ ഒഴിവാക്കുക, ബാക്കിയുള്ളവ സംഗ്രഹിക്കുക എന്നതാണ് ആദ്യം മനസ്സിൽ വന്നത്. എന്നാൽ ഇൻഡക്റ്റീവ് രീതി "എല്ലാവർക്കും" ബാധകമല്ലാത്ത ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുമെന്ന് ഞാൻ പെട്ടെന്ന് മനസ്സിലാക്കി, പക്ഷേ, ഏറ്റവും മികച്ചത്, "ഭൂരിപക്ഷം" പരീക്ഷിക്കുന്നവർക്ക് മാത്രം. അതിനാൽ, മറുവശത്ത് നിന്ന് അതിനെ സമീപിക്കാൻ ഞാൻ തീരുമാനിച്ചു, ഇത് സംഭവിച്ചു.

നിർവചനങ്ങൾ

ഒരു പുതിയ പ്രശ്നം പരിഹരിക്കുമ്പോൾ ഞാൻ സാധാരണയായി ചെയ്യുന്ന ആദ്യത്തെ കാര്യം അത് എന്തിനെക്കുറിച്ചാണെന്ന് മനസിലാക്കാൻ ശ്രമിക്കുക എന്നതാണ്, ഇത് ചെയ്യുന്നതിന് അത് ഉന്നയിക്കുന്ന വാക്കുകളുടെ അർത്ഥം ഞാൻ മനസ്സിലാക്കേണ്ടതുണ്ട്. മനസ്സിലാക്കേണ്ട പ്രധാന വാക്കുകൾ ഇനിപ്പറയുന്നവയാണ്:

• ഒരു പ്രശ്നം
• ടെസ്റ്റർ
• ടെസ്റ്റർ ജോലി
• ടെസ്റ്റർ കാര്യക്ഷമത

നമുക്ക് വിക്കിപീഡിയയിലേക്കും സാമാന്യബുദ്ധിയിലേക്കും തിരിയാം:
പ്രശ്നം (പുരാതന ഗ്രീക്ക് πρόβλημα) വിശാലമായ അർത്ഥത്തിൽ - പഠനവും പ്രമേയവും ആവശ്യമുള്ള സങ്കീർണ്ണമായ സൈദ്ധാന്തികമോ പ്രായോഗികമോ ആയ പ്രശ്നം; ശാസ്ത്രത്തിൽ - ഏതെങ്കിലും പ്രതിഭാസങ്ങൾ, വസ്തുക്കൾ, പ്രക്രിയകൾ എന്നിവയുടെ വിശദീകരണത്തിൽ എതിർ സ്ഥാനങ്ങളുടെ രൂപത്തിൽ പ്രത്യക്ഷപ്പെടുന്ന ഒരു വൈരുദ്ധ്യാത്മക സാഹചര്യം, അത് പരിഹരിക്കാൻ മതിയായ സിദ്ധാന്തം ആവശ്യമാണ്; ജീവിതത്തിൽ, ആളുകൾക്ക് മനസ്സിലാക്കാവുന്ന ഒരു രൂപത്തിലാണ് പ്രശ്നം രൂപപ്പെടുത്തിയിരിക്കുന്നത്: “എനിക്കറിയാം, എങ്ങനെയെന്ന് എനിക്കറിയില്ല,” അതായത്, എന്താണ് നേടേണ്ടതെന്ന് അറിയാം, പക്ഷേ അത് എങ്ങനെ ചെയ്യണമെന്ന് അറിയില്ല. . വൈകിയാണ് വരുന്നത്. lat. പ്രശ്നം, ഗ്രീക്കിൽ നിന്ന്. πρόβλημα "മുന്നോട്ട് എറിഞ്ഞു, മുന്നിൽ വെച്ചു"; προβάλλω ൽ നിന്ന് “മുന്നോട്ട് എറിയുക, നിങ്ങളുടെ മുൻപിൽ വയ്ക്കുക; കുറ്റം".

ഇതിൽ വലിയ അർത്ഥമില്ല, വാസ്തവത്തിൽ, "പ്രശ്നം" = "എല്ലാം കൈകാര്യം ചെയ്യേണ്ടത്."
ടെസ്റ്റർ - ഒരു ഘടകമോ സിസ്റ്റമോ പരിശോധിക്കുന്നതിൽ പങ്കെടുക്കുന്ന ഒരു സ്പെഷ്യലിസ്റ്റ് (ഞങ്ങൾക്ക് എല്ലാ ടെസ്റ്ററുകളിലും താൽപ്പര്യമുള്ളതിനാൽ തരങ്ങളായി വിഭജിക്കില്ല, അതിന്റെ ഫലം:
ടെസ്റ്ററുടെ ജോലി - പരിശോധനയുമായി ബന്ധപ്പെട്ട പ്രവർത്തനങ്ങളുടെ ഒരു കൂട്ടം.
കാര്യക്ഷമത (lat. എഫക്റ്റിവസ്) - നേടിയ ഫലവും ഉപയോഗിച്ച വിഭവങ്ങളും തമ്മിലുള്ള ബന്ധം (ISO 9000: 2015).
ഫലമായി - ഗുണപരമായോ അളവിലോ പ്രകടിപ്പിക്കുന്ന പ്രവർത്തനങ്ങളുടെ (ഫലം) അല്ലെങ്കിൽ സംഭവങ്ങളുടെ ഒരു ശൃംഖലയുടെ (പരമ്പര) അനന്തരഫലം. സാധ്യമായ ഫലങ്ങളിൽ നേട്ടം, ദോഷം, നേട്ടം, നഷ്ടം, മൂല്യം, വിജയം എന്നിവ ഉൾപ്പെടുന്നു.
"പ്രശ്നം" പോലെ, ചെറിയ അർത്ഥമുണ്ട്: ജോലിയുടെ ഫലമായി പുറത്തുവന്ന ഒന്ന്.
വിഭവം - ഒരു വ്യക്തിയുടെയോ ആളുകളുടെയോ ഏതെങ്കിലും പ്രവർത്തനം നടത്തുന്നതിനുള്ള അളവ് അളക്കാവുന്ന സാധ്യത; ആവശ്യമുള്ള ഫലം ലഭിക്കുന്നതിന് ചില പരിവർത്തനങ്ങൾ ഉപയോഗിക്കാൻ അനുവദിക്കുന്ന വ്യവസ്ഥകൾ. ടെസ്റ്റർ ഒരു വ്യക്തിയാണ്, സുപ്രധാന വിഭവങ്ങളുടെ സിദ്ധാന്തത്തിന് അനുസൃതമായി, ഓരോ വ്യക്തിയും നാല് സാമ്പത്തിക ആസ്തികളുടെ ഉടമയാണ്:
പണം (വരുമാനം) ഒരു പുതുക്കാവുന്ന വിഭവമാണ്;
ഊർജ്ജം (ജീവശക്തി) ഭാഗികമായി പുതുക്കാവുന്ന ഒരു വിഭവമാണ്;
സമയം സ്ഥിരവും അടിസ്ഥാനപരമായി പുതുക്കാനാവാത്തതുമായ ഒരു വിഭവമാണ്;
അറിവ് (വിവരം) ഒരു പുനരുൽപ്പാദിപ്പിക്കാവുന്ന വിഭവമാണ്, അത് വളരാനും നശിപ്പിക്കാനും കഴിയുന്ന മനുഷ്യ മൂലധനത്തിന്റെ ഭാഗമാണ്[1].

ഞങ്ങളുടെ കാര്യത്തിൽ കാര്യക്ഷമതയുടെ നിർവചനം പൂർണ്ണമായും ശരിയല്ലെന്ന് ഞാൻ ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്നു, കാരണം നമ്മൾ കൂടുതൽ അറിവ് ഉപയോഗിക്കുന്നു, കാര്യക്ഷമത കുറയുന്നു. അതിനാൽ, കാര്യക്ഷമതയെ "നേടിയ ഫലങ്ങളും ചെലവഴിച്ച വിഭവങ്ങളും തമ്മിലുള്ള അനുപാതം" എന്ന് ഞാൻ പുനർ നിർവചിക്കും. അപ്പോൾ എല്ലാം ശരിയാണ്: ജോലി സമയത്ത് അറിവ് പാഴായില്ല, പക്ഷേ ഇത് ടെസ്റ്ററുടെ അടിസ്ഥാനപരമായി പുതുക്കാനാവാത്ത വിഭവത്തിന്റെ ചെലവ് കുറയ്ക്കുന്നു - അവന്റെ സമയം.

തീരുമാനം

അതിനാൽ, ടെസ്റ്റർമാരുടെ പ്രവർത്തനത്തിന്റെ ഫലപ്രാപ്തിയെ തടസ്സപ്പെടുത്തുന്ന ആഗോള പ്രശ്‌നങ്ങൾക്കായി ഞങ്ങൾ തിരയുകയാണ്.
ഒരു പരീക്ഷകന്റെ ജോലിയിൽ ചെലവഴിക്കുന്ന ഏറ്റവും പ്രധാനപ്പെട്ട വിഭവം അവന്റെ സമയമാണ് (ബാക്കിയുള്ളവ ഒരു തരത്തിലല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ കുറയ്ക്കാം), കാര്യക്ഷമതയുടെ ശരിയായ കണക്കുകൂട്ടലിനെക്കുറിച്ച് സംസാരിക്കുന്നതിന്, ഫലവും സമയമായി കുറയ്ക്കണം. .
ഇത് ചെയ്യുന്നതിന്, ടെസ്റ്റർ തന്റെ പ്രവർത്തനത്തിലൂടെ ഉറപ്പുനൽകുന്ന ഒരു സിസ്റ്റം പരിഗണിക്കുക. അത്തരമൊരു സംവിധാനം ഒരു ടെസ്റ്റർ ഉൾപ്പെടുന്ന ഒരു പ്രോജക്റ്റാണ്. പ്രോജക്റ്റ് ജീവിത ചക്രം ഇനിപ്പറയുന്ന അൽഗോരിതം ഉപയോഗിച്ച് ഏകദേശം പ്രതിനിധീകരിക്കാം:

1. ആവശ്യകതകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നു
2. സാങ്കേതിക സവിശേഷതകളുടെ രൂപീകരണം
3. വികസനം
4. പരിശോധിക്കുന്നു
5. നിർമ്മാണത്തിലേക്ക് വിടുക
6. പിന്തുണ (ഗോട്ടോ ഇനം 1)

ഈ സാഹചര്യത്തിൽ, മുഴുവൻ പ്രോജക്റ്റിനെയും ഒരേ ജീവിത ചക്രം ഉപയോഗിച്ച് ഉപപദ്ധതികളായി (സവിശേഷതകൾ) വിഭജിക്കാം.
പ്രോജക്റ്റിന്റെ വീക്ഷണകോണിൽ നിന്ന്, അതിൽ കുറച്ച് സമയം ചെലവഴിക്കുന്നു, അതിന്റെ നടപ്പാക്കൽ കൂടുതൽ ഫലപ്രദമാണ്.
അതിനാൽ, പ്രോജക്റ്റിന്റെ വീക്ഷണകോണിൽ നിന്ന് ഒരു ടെസ്റ്ററിന്റെ പരമാവധി കാര്യക്ഷമതയുടെ നിർവചനത്തിലേക്ക് ഞങ്ങൾ വരുന്നു - പരിശോധനയ്ക്കുള്ള സമയം പൂജ്യമാകുമ്പോൾ ഇത് പ്രോജക്റ്റിന്റെ അവസ്ഥയാണ്. എല്ലാ ടെസ്റ്റർമാർക്കും ഒരു പൊതു പ്രശ്നം ഈ സമയം നേടാനുള്ള കഴിവില്ലായ്മയാണ്.

ഇത് എങ്ങനെ കൈകാര്യം ചെയ്യണം?

നിഗമനങ്ങൾ വളരെ വ്യക്തവും വളരെക്കാലമായി പലരും ഉപയോഗിച്ചുവരുന്നു:

1. വികസനവും പരിശോധനയും ഏതാണ്ട് ഒരേസമയം ആരംഭിക്കുകയും അവസാനിക്കുകയും വേണം (ഇത് സാധാരണയായി വകുപ്പാണ് ചെയ്യുന്നത് QA). വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്ന എല്ലാ പ്രവർത്തനങ്ങളും ഇതിനകം തന്നെ ഓട്ടോടെസ്റ്റുകളാൽ മൂടപ്പെട്ടിരിക്കുമ്പോഴാണ് അനുയോജ്യമായ ഓപ്ഷൻ CI.
2. ഒരു പ്രോജക്റ്റിന് കൂടുതൽ സവിശേഷതകൾ ഉണ്ട് (അത് കൂടുതൽ സങ്കീർണ്ണമാണ്), പുതിയ പ്രവർത്തനം പഴയതിനെ തകർക്കുന്നില്ലെന്ന് പരിശോധിക്കാൻ കൂടുതൽ സമയം ചെലവഴിക്കേണ്ടിവരും. അതിനാൽ, പദ്ധതി കൂടുതൽ സങ്കീർണ്ണമാകുമ്പോൾ കൂടുതൽ ഓട്ടോമേഷൻ ആവശ്യമാണ് റിഗ്രഷൻ ടെസ്റ്റിംഗ്.
3. ഓരോ തവണയും ഞങ്ങൾക്ക് പ്രൊഡക്ഷനിൽ ഒരു ബഗ് നഷ്ടപ്പെടുകയും ഒരു ഉപയോക്താവ് അത് കണ്ടെത്തുകയും ചെയ്യുമ്പോൾ, പോയിന്റ് 1 മുതൽ ആരംഭിക്കുന്ന പ്രോജക്റ്റ് ലൈഫ് സൈക്കിളിലൂടെ കൂടുതൽ സമയം ചെലവഴിക്കേണ്ടി വരും (ആവശ്യകതകൾക്കൊപ്പം പ്രവർത്തിക്കുക, ഈ സാഹചര്യത്തിൽ, ഉപയോക്താക്കൾ). ഒരു ബഗ് നഷ്‌ടപ്പെടാനുള്ള കാരണങ്ങൾ പൊതുവെ അജ്ഞാതമായതിനാൽ, ഞങ്ങൾക്ക് ഒരു ഒപ്റ്റിമൈസേഷൻ പാത മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ - ഉപയോക്താക്കൾ കണ്ടെത്തിയ എല്ലാ ബഗുകളും അത് വീണ്ടും ദൃശ്യമാകില്ലെന്ന് ഉറപ്പാക്കാൻ റിഗ്രഷൻ പരിശോധനയിൽ ഉൾപ്പെടുത്തണം.

അവലംബം: www.habr.com