ലോഞ്ചിന് മുമ്പ് നിങ്ങളുടെ ആപ്പ് എങ്ങനെ പരീക്ഷിക്കാം: ഒരു പ്രായോഗിക പ്രീ-ലോഞ്ച് പദ്ധതി
ലോഞ്ചിന് മുമ്പ് ആപ്പ് പരീക്ഷിക്കാൻ, ഒരു ഉപയോക്താവിന് പൂർത്തിയാക്കാൻ കഴിയേണ്ട കുറച്ച് യാത്രകൾ പട്ടികപ്പെടുത്തുക, ഓരോന്നും പുതിയ ഒരു ഉപയോക്താവായി ലാപ്ടോപ്പിലും ഫോണിലും പ്രവർത്തിപ്പിക്കുക, പിന്നെ അവ തെറ്റാകാവുന്ന വഴികൾ പരീക്ഷിക്കുക: ശൂന്യമായ ഡാറ്റ, തെറ്റായ ഇൻപുട്ട്, രണ്ടാമത്തെ അക്കൗണ്ട്, മന്ദഗതിയിലുള്ള കണക്ഷൻ. പണവും സ്വകാര്യ ഡാറ്റയും ഉൾപ്പെടുന്നതെന്തും അധിക ശ്രദ്ധയോടെ പരിശോധിക്കുക, പ്രസിദ്ധീകരിച്ച ശേഷം ലൈവ് URL-ൽ പ്രധാന യാത്രകൾ ആവർത്തിക്കുക. അവസാനം, ആപ്പ് ഒരിക്കലും കാണാത്ത ഒരാൾ അത് ഉപയോഗിക്കാൻ ശ്രമിക്കുന്നത് നിരീക്ഷിക്കുക.
ഇതിന് ഒരു QA ടീമോ ടെസ്റ്റിംഗ് ഫ്രെയിംവർക്കോ വേണ്ട. ഒരു ലിസ്റ്റും ഒന്നോ രണ്ടോ മണിക്കൂറും, അത് യഥാർഥത്തിൽ ക്ലിക്ക് ചെയ്ത് കടന്നുപോകാനുള്ള അച്ചടക്കവും മതി.
ഘട്ടം 1: പ്രധാനപ്പെട്ട യാത്രകൾ എഴുതുക
ഒരു ഉപയോക്താവ് വരുന്ന ആരംഭം മുതൽ അവസാനം വരെയുള്ള ജോലിയാണ് യാത്ര. മിക്ക ആപ്പുകൾക്കും യഥാർഥത്തിൽ പ്രധാനമായ മൂന്ന് മുതൽ ആറ് വരെ യാത്രകളുണ്ട്. ഒരു ബുക്കിംഗ് ആപ്പിന്:
- സൈൻ അപ്പ് ചെയ്ത് അക്കൗണ്ട് സ്ഥിരീകരിക്കുക
- ഒരു ക്ലാസ് കണ്ടെത്തി ബുക്ക് ചെയ്യുക
- ഒരു ബുക്കിംഗ് റദ്ദാക്കുക
- ഒരു ക്ലാസ് പാസിന് പണം നൽകുക
- സ്റ്റാഫ്: ഇന്നത്തെ ബുക്കിംഗുകൾ കാണുക
നിങ്ങൾ ഉപയോക്തൃ സ്റ്റോറികൾ എഴുതിയിട്ടുണ്ടെങ്കിൽ, അവയുടെ സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ നിങ്ങളുടെ ടെസ്റ്റ് കേസുകൾ തന്നെയാണ്. ഇല്ലെങ്കിൽ, ഓരോ യാത്രയ്ക്കും ഒരു വരി വീതം, “വിജയം” എന്താണെന്ന് സഹിതം എഴുതുക.
റാങ്ക് ചെയ്യുക. പണം ഉണ്ടാക്കുന്നവയോ എല്ലാ ഉപയോക്താക്കളും എത്തുന്നവയോ (സൈൻ അപ്പ്, ലോഗിൻ, പ്രധാന പ്രവർത്തനം) ആദ്യം, ഏറ്റവും കൂടുതൽ പരീക്ഷിക്കുന്നു.
ഘട്ടം 2: ഒരു പുതിയ ഉപയോക്താവായി സന്തോഷകരമായ പാത പരീക്ഷിക്കുക
“സന്തോഷകരമായ പാത” എന്നാൽ യാത്ര ഉദ്ദേശിച്ചതുപോലെ നടക്കുന്നത്. ഒരു അപരിചിതൻ അനുഭവിക്കുന്നതുപോലെ പരീക്ഷിക്കുക:
- ഒരു സ്വകാര്യ ബ്രൗസർ വിൻഡോ ഉപയോഗിക്കുക, നിങ്ങൾ ലോഗിൻ ചെയ്തിട്ടില്ലാത്തതും സംരക്ഷിച്ച ഡാറ്റ ഇല്ലാത്തതുമായി.
- പരിശോധിക്കാൻ കഴിയുന്ന ഒരു യഥാർഥ ഇമെയിലുള്ള ഒരു പുതിയ അക്കൗണ്ട്.
- ഹോം പേജിൽ നിന്നോ ഒരു ലിങ്കിൽ നിന്നോ തുടങ്ങുക, നിർമ്മിക്കുമ്പോൾ ബുക്ക്മാർക്ക് ചെയ്ത പേജിൽ നിന്നല്ല.
പുതിയ ഉപയോക്താക്കൾക്ക് ഡാറ്റ ഉണ്ടാകില്ല. ലിസ്റ്റ് ശൂന്യമായിരിക്കുമ്പോഴോ പ്രൊഫൈലിന് ഫോട്ടോ ഇല്ലാത്തപ്പോഴോ ഇതുവരെ ഒന്നും വാങ്ങിയിട്ടില്ലാത്തപ്പോഴോ മാത്രം പല ബഗുകളും കാണിക്കുന്നു. നിങ്ങളുടെ സ്വന്തം അക്കൗണ്ട്, ടെസ്റ്റ് ഡാറ്റ നിറഞ്ഞത്, അവയെ മറയ്ക്കുന്നു.
ഘട്ടം 3: അത് തകർക്കാൻ ശ്രമിക്കുക
ഇപ്പോൾ ഓരോ യാത്രയും ആവർത്തിച്ച്, മനഃപൂർവം തെറ്റായ കാര്യം ചെയ്യുക.
| ഇത് പരീക്ഷിക്കുക | നിങ്ങൾ പരിശോധിക്കുന്നത് |
|---|---|
| ഫോമുകൾ ശൂന്യമായോ സ്പെയ്സുകൾ മാത്രമുള്ളതായോ സമർപ്പിക്കുക | നിർബന്ധിത ഫീൽഡുകൾ വ്യക്തമായ സന്ദേശത്തോടെ നടപ്പാക്കപ്പെടുന്നു |
| വളരെ നീണ്ട ടെക്സ്റ്റ്, ഇമോജി, ഉച്ചാരണ ചിഹ്നങ്ങളുള്ള പേരുകൾ | ലേഔട്ട് നിലനിൽക്കുന്നു, ഡാറ്റ ശരിയായി സേവ് ആകുന്നു |
| തെറ്റായ ഫോർമാറ്റുകൾ: ഫോൺ ഫീൽഡിൽ അക്ഷരങ്ങൾ, കഴിഞ്ഞ തീയതി | പേജിലും സെർവറിലും വാലിഡേഷൻ |
| സബ്മിറ്റ് ബട്ടൺ രണ്ടുതവണ ക്ലിക്ക് ചെയ്യുക | ഡ്യൂപ്ലിക്കേറ്റ് ഓർഡറുകളോ ബുക്കിംഗുകളോ ഇല്ല |
| ഫ്ലോയുടെ നടുവിൽ ബ്രൗസർ ബാക്ക് ബട്ടൺ | തകർന്ന അവസ്ഥയോ നഷ്ടപ്പെട്ട ഡാറ്റയോ ഇല്ല |
| ഓരോ പേജിലും റീഫ്രഷ് ചെയ്യുക | ഡാറ്റ നിലനിൽക്കുന്നു; ശൂന്യ പേജോ 404-ഓ ഇല്ല |
| ലോഗ് ഔട്ട് ചെയ്ത ശേഷം ബാക്ക് അമർത്തുക | സ്വകാര്യ പേജുകൾ കാണിക്കുന്നില്ല |
| ഒരേ കാര്യം എഡിറ്റ് ചെയ്യുന്ന രണ്ട് ടാബുകൾ | അവസാന സേവ് ആദ്യത്തേതിനെ നിശ്ശബ്ദമായി മായ്ക്കുന്നില്ല |
റീഫ്രഷിംഗ് ശ്രദ്ധിക്കേണ്ട കാര്യമാണ്: നിങ്ങൾ ക്ലിക്ക് ചെയ്ത് കടന്നുപോകുമ്പോൾ ആപ്പ് പ്രവർത്തിക്കുന്നു, പക്ഷേ ആഴത്തിലുള്ള ഒരു പേജിൽ റീഫ്രഷ് ചെയ്യുമ്പോൾ 404 കാണിക്കുന്നുവെങ്കിൽ, ഡിപ്ലോയ് ചെയ്ത ശേഷമുള്ള 404 പിശകുകൾ എങ്ങനെ പരിഹരിക്കാം കാണുക.
ഘട്ടം 4: രണ്ട് അക്കൗണ്ടുകളോടെ അനുമതികൾ പരീക്ഷിക്കുക
അക്കൗണ്ടുകളുള്ള ഏതൊരു ആപ്പിനും ഇത് ഏറ്റവും പ്രധാനപ്പെട്ട പരിശോധനയാണ്, പലപ്പോഴും ഒഴിവാക്കപ്പെടുന്നതും.
രണ്ട് സാധാരണ ഉപയോക്താക്കൾ, A, B, (നിങ്ങളുടെ ആപ്പിൽ ഉണ്ടെങ്കിൽ) ഒരു അഡ്മിൻ എന്നിവരെ സൃഷ്ടിക്കുക.
- A ആയി ഒരു റെക്കോർഡ് സൃഷ്ടിക്കുക. B ആയി ലോഗിൻ ചെയ്യുക. B-ക്ക് അത് കാണാനോ എഡിറ്റ് ചെയ്യാനോ ഡിലീറ്റ് ചെയ്യാനോ കഴിയുമോ? ഡിസൈൻ അങ്ങനെയല്ലെങ്കിൽ കഴിയരുത്.
- A ആയി, നിങ്ങളുടെ റെക്കോർഡുകളിലൊന്നിന്റെ URL പകർത്തുക. B ആയി ലോഗിൻ ചെയ്ത് ആ URL നേരിട്ട് തുറക്കുക.
- ഒരു സാധാരണ ഉപയോക്താവായി, URL-കൾ ടൈപ്പ് ചെയ്ത് അഡ്മിൻ പേജുകൾ തുറക്കുക.
- പൂർണമായും ലോഗ് ഔട്ട് ചെയ്ത് അതേ URL-കൾ പരീക്ഷിക്കുക.
ഇവിടെ ഒരു പ്രശ്നം കണ്ടാൽ, അത് പരിഹരിക്കുന്നതുവരെ ലോഞ്ച് ചെയ്യരുത്. പരിശോധന സെർവറിലാണ് നടക്കേണ്ടത്, ഒരു ബട്ടൺ ഒളിപ്പിച്ചു വയ്ക്കുന്നതിലൂടെയല്ല. AI നിർമ്മിച്ച ആപ്പുകൾക്കുള്ള സുരക്ഷാ ചെക്ക്ലിസ്റ്റ് കൂടുതൽ ആഴത്തിൽ പോകുന്നു.
ഘട്ടം 5: യഥാർഥ ഉപകരണങ്ങളിൽ പരീക്ഷിക്കുക
ഒരു ഇടുങ്ങിയ ബ്രൗസർ വിൻഡോ മാത്രമല്ല, യഥാർഥ ഫോണിൽ ആപ്പ് തുറക്കുക.
- ഓരോ ബട്ടണും സൂം ചെയ്യാതെ ടാപ്പ് ചെയ്യാൻ കഴിയുന്നുണ്ടോ?
- നിങ്ങൾ ടൈപ്പ് ചെയ്യുന്ന ഫീൽഡ് കീബോർഡ് മറയ്ക്കുന്നുണ്ടോ?
- പട്ടികകളും വീതിയുള്ള ഉള്ളടക്കവും സ്ക്രോൾ ചെയ്യുകയോ പൊതിയുകയോ ചെയ്യുന്നുണ്ടോ, പേജിനെ വശത്തേക്ക് തള്ളാതെ?
- പിഞ്ച് ചെയ്യാതെ ടെക്സ്റ്റ് വായിക്കാൻ കഴിയുന്നുണ്ടോ?
കുറഞ്ഞത് ഒരു iPhone (Safari), ഒരു Android ഫോൺ (Chrome) എന്നിവ കടം വാങ്ങാൻ കഴിഞ്ഞാൽ പരീക്ഷിക്കുക. Safari-ക്ക് തീയതികൾ, വീഡിയോ, ഫിക്സഡ്-പൊസിഷൻ ഘടകങ്ങൾ എന്നിവയിൽ സ്വന്തം വിചിത്ര സ്വഭാവങ്ങളുണ്ട്.
ഘട്ടം 6: പണവും ഇമെയിലും അവസാനം മുതൽ അവസാനം വരെ
കാർഡുകൾ ചാർജ് ചെയ്യുന്നതോ ഇമെയിലുകൾ അയക്കുന്നതോ ആയ എന്തിനും പൂർണമായ ഒരു റൺ-ത്രൂ വേണം.
പേയ്മെന്റുകൾ. നിങ്ങളുടെ പേയ്മെന്റ് ദാതാവിന്റെ ടെസ്റ്റ് മോഡും ടെസ്റ്റ് കാർഡ് നമ്പറുകളും ഉപയോഗിക്കുക. ഒരു വിജയകരമായ പേയ്മെന്റ്, നിരസിക്കപ്പെട്ട കാർഡ്, റദ്ദാക്കിയ ചെക്ക്ഔട്ട് എന്നിവ പരിശോധിക്കുക. പേയ്മെന്റിന് ശേഷം ഓർഡറോ സബ്സ്ക്രിപ്ഷനോ നിങ്ങളുടെ ആപ്പിൽ കാണിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, ദാതാവിന്റെ ഡാഷ്ബോർഡിൽ മാത്രമല്ല. നിങ്ങളുടെ ആപ്പ് വെബ്ഹുക്കുകളെ (പേയ്മെന്റ് ദാതാവ് നിങ്ങളുടെ സെർവറിലേക്ക് അയക്കുന്ന സന്ദേശങ്ങൾ) ആശ്രയിക്കുന്നെങ്കിൽ, അവ ഡെവലപ്മെന്റിൽ മാത്രമല്ല, പ്രസിദ്ധീകരിച്ച ആപ്പിലും എത്തുന്നുണ്ടെന്ന് പരിശോധിക്കുക. പിന്നെ, ലോഞ്ചിന് മുമ്പ്, ലൈവ് കീകളിലേക്ക് മാറി നിങ്ങൾ റീഫണ്ട് ചെയ്യുന്ന ഒരു ചെറിയ യഥാർഥ വാങ്ങൽ നടത്തുക.
ഇമെയിലുകൾ. രണ്ടോ മൂന്നോ വ്യത്യസ്ത ദാതാക്കളിൽ യഥാർഥ വിലാസങ്ങളോടെ സൈൻ അപ്പ് ചെയ്യുക. ഇമെയിലുകൾ എത്തുന്നുവെന്നും സ്പാമിൽ പോകുന്നില്ലെന്നും അവയിലെ ഓരോ ലിങ്കും പ്രിവ്യൂ വിലാസത്തിനല്ല, ലൈവ് ഡൊമെയ്നിലേക്കാണ് പോകുന്നതെന്നും ഉറപ്പാക്കുക.
ഘട്ടം 7: വേഗതയും പിശകുകളും പരിശോധിക്കുക
- ബ്രൗസറിന്റെ ഡെവലപ്പർ ടൂളുകൾ (വലത് ക്ലിക്ക് → Inspect) തുറന്ന് ഓരോ പ്രധാന പേജിലും Console ടാബ് നോക്കുക. ചുവന്ന പിശകുകൾ ഒന്നും തകർന്നതായി കാണാത്തപ്പോഴും ശരിയാക്കേണ്ടതാണ്.
- വൈ-ഫൈക്ക് പകരം മൊബൈൽ ഡാറ്റയിൽ ഫോണിൽ സൈറ്റ് ലോഡ് ചെയ്യുക. ആദ്യ സ്ക്രീൻ നിരവധി സെക്കൻഡ് എടുക്കുന്നുവെങ്കിൽ, ആദ്യം ചിത്രങ്ങളുടെ വലുപ്പം നോക്കുക.
- ഒരു സൗജന്യ ഓഡിറ്റ് പ്രവർത്തിപ്പിക്കുക, ഉദാഹരണത്തിന് Chrome-ന്റെ devtools-ലെ Lighthouse, പ്രകടനത്തെയും ആക്സസിബിലിറ്റിയെയും കുറിച്ച് ഒരു ദ്രുത വായനയ്ക്ക്.
ഘട്ടം 8: പ്രിവ്യൂ മാത്രമല്ല, പ്രസിദ്ധീകരിച്ച ആപ്പ് പരീക്ഷിക്കുക
പ്രിവ്യൂയും പ്രസിദ്ധീകരിച്ച ആപ്പും ഒരേ എൻവയോൺമെന്റല്ല. ലോഞ്ചിനെക്കുറിച്ച് ആരോടെങ്കിലും പറയുന്നതിന് മുമ്പ്, ലൈവ് URL-ൽ പ്രധാന യാത്രകൾ ആവർത്തിക്കുക:
- എല്ലാ എൻവയോൺമെന്റ് വേരിയബിളുകളും രഹസ്യങ്ങളും പ്രസിദ്ധീകരിച്ച ആപ്പിന് സജ്ജമാണോ?
- ശരിയായ ഡാറ്റാബേസാണോ ഉപയോഗിക്കുന്നത്, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഡാറ്റയോടെ?
- ലോഗിൻ റീഡയറക്ടുകളും ഇമെയിൽ ലിങ്കുകളും ലൈവ് ഡൊമെയ്ൻ ഉപയോഗിക്കുന്നുണ്ടോ?
- ഒരു ഡീപ് പേജിൽ റീഫ്രഷ് ചെയ്താൽ ശരിയായി ലോഡ് ആകുന്നുണ്ടോ?
ഘട്ടം 9: മറ്റൊരാൾ ഇത് ഉപയോഗിക്കുന്നത് നിരീക്ഷിക്കുക
ഒന്നോ രണ്ടോ ആളുകൾക്ക് ഒരു ലക്ഷ്യം നൽകുക (“ശനിയാഴ്ചത്തേക്ക് ഒരു യോഗ ക്ലാസ് ബുക്ക് ചെയ്യുക”), നിർദേശങ്ങളല്ല. നിരീക്ഷിക്കുക, സഹായിക്കരുത്, അവർ എവിടെയാണ് സംശയിക്കുന്നതെന്ന് എഴുതിവെക്കുക. ആശയക്കുഴപ്പമുള്ള വാക്കുകളും ഒളിഞ്ഞിരിക്കുന്ന ബട്ടണുകളും കണ്ടെത്താനുള്ള ഏറ്റവും വേഗമേറിയ മാർഗമാണിത്. ഇതിന്റെ വലിയ പതിപ്പിന്, ഒരു ബീറ്റ ടെസ്റ്റ് എങ്ങനെ നടത്താം കാണുക.
അവർ ഒരു ബഗിൽ തട്ടുമ്പോൾ, അത് ശരിയായി എഴുതിവെക്കുക: ഘട്ടങ്ങൾ, പ്രതീക്ഷിച്ച ഫലം, യഥാർഥ ഫലം. നല്ല ബഗ് റിപ്പോർട്ട് എങ്ങനെ എഴുതാം ഫോർമാറ്റ് കാണിക്കുന്നു.
പരിശോധിക്കാൻ AI ഉപയോഗിക്കുന്നത്
AI നിർമ്മിച്ച ആപ്പാണെങ്കിൽ, ടെസ്റ്റുകൾ ആസൂത്രണം ചെയ്യാനും പ്രവർത്തിപ്പിക്കാനും AI-യോട് സഹായം ചോദിക്കാം:
ഈ ആപ്പിലെ പ്രധാന ഉപയോക്തൃ യാത്രകൾ പട്ടികപ്പെടുത്തുക, ഓരോന്നിനും, ഏറ്റവും തകരാൻ സാധ്യതയുള്ള എഡ്ജ് കേസുകൾ: ശൂന്യ അവസ്ഥകൾ, തെറ്റായ ഇൻപുട്ട്, അനുമതികൾ, റീഫ്രഷ്. ഞാൻ പിന്തുടരാവുന്ന ഒരു ചെക്ക്ലിസ്റ്റായി ഇടുക.
രണ്ട് വ്യത്യസ്ത ടെസ്റ്റ് ഉപയോക്താക്കളായി ലോഗിൻ ചെയ്ത്, ഉപയോക്താവ് B-ക്ക് A സൃഷ്ടിച്ചതൊന്നും കാണാനോ മാറ്റാനോ കഴിയുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക, A-യുടെ റെക്കോർഡ് URL-കൾ നേരിട്ട് തുറന്ന് നോക്കുന്നതുൾപ്പെടെ. എന്തെങ്കിലും ശരിയാക്കുന്നതിന് മുമ്പ് കണ്ടെത്തിയത് റിപ്പോർട്ട് ചെയ്യുക.
AI-യുടെ സ്വന്തം ടെസ്റ്റ് റിപ്പോർട്ട് ഒരു ആദ്യ പാസായി കണക്കാക്കുക. പണവും അനുമതിയും ഉൾപ്പെടുന്ന യാത്രകൾ ഇപ്പോഴും നിങ്ങൾ തന്നെ ക്ലിക്ക് ചെയ്ത് പരിശോധിക്കുക.
Mythex-ൽ ടെസ്റ്റിംഗ്
Mythex-ൽ, /test കമാൻഡ് App Testing പ്രവർത്തിപ്പിക്കുന്നു: ഏജന്റ് നിങ്ങളുടെ ലൈവ് പ്രിവ്യൂവിനെതിരെ ഒരു ബ്രൗസർ ഓടിച്ച്, പേജുകളിൽ ക്ലിക്ക് ചെയ്ത്, സ്ക്രീൻഷോട്ടുകൾ എടുത്ത്, തകർന്ന ഫ്ലോകൾ ചാറ്റിൽ റിപ്പോർട്ട് ചെയ്യുന്നു. ഒരു നിർദിഷ്ട യാത്രയോടെയാണ് ഇത് ഏറ്റവും നന്നായി പ്രവർത്തിക്കുന്നത്, ഉദാഹരണത്തിന് “സൈൻ അപ്പും ഒരു ക്ലാസ് ബുക്ക് ചെയ്യലും പരീക്ഷിക്കുക”. കണ്ടെത്തിയത് /fix ഉപയോഗിച്ചോ സാധാരണ സന്ദേശത്തിലൂടെയോ ശരിയാക്കുക, പിന്നെ /test വീണ്ടും പ്രവർത്തിപ്പിക്കുക. App Testing പ്രിവ്യൂ ഉപയോഗിക്കുന്നു, അതിനാൽ പ്രസിദ്ധീകരിച്ച ശേഷം പ്രധാന യാത്രകൾ പ്രസിദ്ധീകരിച്ച URL-ൽ നിങ്ങൾ തന്നെ പരിശോധിക്കുക. ഡോക്സിലെ App Testing കാണുക, എന്തെങ്കിലും പരാജയപ്പെടുമ്പോൾ AI നിർമ്മിച്ച ആപ്പ് ഡീബഗ് ചെയ്യുന്നത് എങ്ങനെ എന്ന ഞങ്ങളുടെ ഗൈഡും.
സാധാരണ തെറ്റുകൾ
- നിങ്ങളായി മാത്രം പരീക്ഷിക്കുക. ധാരാളം ഡാറ്റയുള്ള നിങ്ങളുടെ അഡ്മിൻ അക്കൗണ്ട് ശൂന്യ-അവസ്ഥ, അനുമതി ബഗുകളെ മറയ്ക്കുന്നു.
- ലാപ്ടോപ്പിൽ മാത്രം പരീക്ഷിക്കുക. പല സൈറ്റുകളിലെയും മിക്ക സന്ദർശകരും ഫോണിലാണ് എത്തുന്നത്.
- രണ്ടാമത്തെ അക്കൗണ്ട് ഒഴിവാക്കുക. ഉപയോക്താക്കൾക്കിടയിൽ ഡാറ്റ ചോരുന്നത് ഒരു ആപ്പിന് ലോഞ്ച് ചെയ്യാവുന്ന ഏറ്റവും ഗുരുതരമായ ബഗാണ്.
- പ്രിവ്യൂയെ വിശ്വസിക്കുക. ലൈവ് ആപ്പിന് വ്യത്യസ്ത ക്രമീകരണങ്ങളുണ്ട്; അതും പരീക്ഷിക്കുക.
- അടുത്തുള്ള ഭാഗങ്ങൾ വീണ്ടും പരിശോധിക്കാതെ ബഗുകൾ ശരിയാക്കുക. ഒരു ഫോമിലെ ഫിക്സ് കോഡ് പങ്കിടുന്ന മറ്റൊന്നിനെ തകർത്തേക്കാം.
പ്രീ-ലോഞ്ച് ചെക്ക്ലിസ്റ്റ്
- പ്രധാന യാത്രകൾ പട്ടികപ്പെടുത്തി റാങ്ക് ചെയ്തു
- സ്വകാര്യ വിൻഡോയിൽ പുതിയ ഉപയോക്താവായി ഓരോ യാത്രയും വിജയിക്കുന്നു
- ശൂന്യ, തെറ്റായ, നീണ്ട, ഡ്യൂപ്ലിക്കേറ്റ് ഇൻപുട്ട് കൈകാര്യം ചെയ്യുന്നു
- എല്ലാ പേജുകളിലും റീഫ്രഷ് പ്രവർത്തിക്കുന്നു
- ഉപയോക്താക്കൾക്ക് പരസ്പരത്തിന്റെ ഡാറ്റ കാണാനോ മാറ്റാനോ കഴിയില്ല, URL വഴിയും
- സാധാരണ ഉപയോക്താക്കൾക്കും ലോഗ് ഔട്ട് ചെയ്ത സന്ദർശകർക്കും അഡ്മിൻ പേജുകൾ തടഞ്ഞിരിക്കുന്നു
- യഥാർഥ iPhoneലും Android ഫോണിലും പ്രവർത്തിക്കുന്നു
- പേയ്മെന്റുകൾ പരീക്ഷിച്ചു: വിജയം, നിരസിക്കൽ, റദ്ദാക്കൽ, പിന്നെ ആപ്പ് അപ്ഡേറ്റാകുന്നു
- ഇമെയിലുകൾ എത്തുന്നു, സ്പാം ഒഴിവാക്കുന്നു, ലൈവ് ഡൊമെയ്നിലേക്ക് ലിങ്ക് ചെയ്യുന്നു
- പ്രധാന പേജുകളിൽ കൺസോളിൽ ചുവന്ന പിശകുകളില്ല
- പ്രസിദ്ധീകരിച്ച URL-ൽ പ്രധാന യാത്രകൾ ആവർത്തിച്ചു
- നിങ്ങൾ നിരീക്ഷിക്കുമ്പോൾ കുറഞ്ഞത് ഒരു പുറത്തുള്ള വ്യക്തിയെങ്കിലും ഇത് പരീക്ഷിച്ചു
ചോദ്യങ്ങൾ
ഒരു ചെറിയ ആപ്പിന് ലോഞ്ചിന് മുമ്പ് എത്ര ടെസ്റ്റിംഗ് വേണം?
പുതിയ ഒരു ഉപയോക്താവ് ഫോണിലും ലാപ്ടോപ്പിലും പ്രധാന യാത്രകൾ പൂർത്തിയാക്കാനാകുമെന്നും, ഉപയോക്താക്കൾക്ക് പരസ്പരത്തിന്റെ ഡാറ്റ കാണാൻ കഴിയില്ലെന്നും, പണം ഉൾപ്പെടുന്നതെല്ലാം അവസാനം മുതൽ അവസാനം വരെ പ്രവർത്തിക്കുന്നുവെന്നും ഉറപ്പാകാൻ മതിയായത്. മിക്ക ചെറിയ ആപ്പുകൾക്കും അത് ആഴ്ചകളല്ല, കുറച്ച് ശ്രദ്ധയോടെയുള്ള മണിക്കൂറുകളാണ്.
MVP-ക്ക് ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ വേണോ?
നിർബന്ധമില്ല. പ്രധാന യാത്രകളുടെ മാനുവൽ ടെസ്റ്റിംഗ് മിക്ക ലോഞ്ച് തടസ്സപ്പെടുത്തുന്ന ബഗുകളും കണ്ടെത്തുന്നു. ആപ്പ് പതിവായി മാറ്റുകയും മുമ്പ് പ്രവർത്തിച്ചിരുന്നത് തകർത്തില്ലെന്ന് വേഗത്തിൽ അറിയണമെന്നും വരുമ്പോഴാണ് ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ പ്രയോജനം നൽകിത്തുടങ്ങുന്നത്.
പ്രിവ്യൂവിലോ ലൈവ് ആപ്പിലോ ടെസ്റ്റ് ചെയ്യണോ?
രണ്ടും. പ്രിവ്യൂവിൽ നന്നായി പരീക്ഷിക്കുക, പിന്നെ പ്രസിദ്ധീകരിച്ച ആപ്പിൽ പ്രധാന യാത്രകൾ ആവർത്തിക്കുക, കാരണം നഷ്ടമായ എൻവയോൺമെന്റ് വേരിയബിളുകൾ, വ്യത്യസ്ത ഡാറ്റാബേസ്, റൂട്ടിംഗ് ക്രമീകരണങ്ങൾ എന്നിവ ലൈവ് പതിപ്പിനെ വ്യത്യസ്തമായി പ്രവർത്തിപ്പിക്കാം.
എന്നെ കൂടാതെ എന്റെ ആപ്പ് ആര് ടെസ്റ്റ് ചെയ്യണം?
ഇതുവരെ കാണാത്ത കുറഞ്ഞത് ഒരാളെങ്കിലും. അവർക്ക് നിർദേശങ്ങളല്ല, ഒരു ലക്ഷ്യം നൽകുക, സഹായിക്കാതെ നിരീക്ഷിക്കുക. ബിൽഡർമാർ അറിയാതെ പൊട്ടുന്ന വഴികൾ ഒഴിവാക്കുന്നു.