როგორ ვატესტოთ აპი გაშვებამდე: პრაქტიკული გაშვების წინა გეგმა
აპის გაშვებამდე ტესტირებისთვის ჩამოწერეთ რამდენიმე მოგზაურობა, რომელთა დასრულებაც მომხმარებელს უნდა შეეძლოს, გაიარეთ თითოეული როგორც სრულიად ახალმა მომხმარებელმა ლეპტოპსა და ტელეფონზე, შემდეგ სცადეთ, როგორ შეიძლება ისინი ცუდად დასრულდეს: ცარიელი მონაცემები, არასწორი შეყვანა, მეორე ანგარიში, ნელი კავშირი. გადაამოწმეთ ყველაფერი, რაც ფულს ან პირად მონაცემებს ეხება, განსაკუთრებული ყურადღებით, და გამოქვეყნების შემდეგ ცოცხალ 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 ჩანართს თითოეულ მთავარ გვერდზე. წითელი შეცდომები ღირს გამოსწორებას, მაშინაც კი, თუ არაფერი ჩანს გატეხილად.
- ჩატვირთეთ საიტი ტელეფონზე მობილური ინტერნეტით, არა Wi-Fi-ით. თუ პირველი ეკრანი რამდენიმე წამს იტვირთება, ჯერ სურათების ზომას შეხედეთ.
- გაუშვით უფასო აუდიტი, მაგალითად Lighthouse Chrome-ის დეველოპერის ხელსაწყოებში, სწრაფი შეფასებისთვის შესრულებისა და ხელმისაწვდომობის შესახებ.
ნაბიჯი 8: ატესტეთ გამოქვეყნებული აპი და არა მხოლოდ გადახედვა
გადახედვა და გამოქვეყნებული აპი ერთი და იგივე გარემო არ არის. სანამ ვინმეს გაუმხელთ გაშვებას, გაიმეორეთ მთავარი მოგზაურობები ცოცხალ URL-ზე:
- ყველა გარემოს ცვლადი და საიდუმლო დაყენებულია გამოქვეყნებული აპისთვის?
- იყენებს თუ არა სწორ მონაცემთა ბაზას, იმ მონაცემებით, რომელსაც ელოდებით?
- იყენებენ თუ არა შესვლის გადამისამართებები და ელფოსტის ბმულები ცოცხალ დომენს?
- იტვირთება თუ არა გვერდი სწორად, როცა ღრმა გვერდზე განაახლებთ?
ნაბიჯი 9: უყურეთ, როგორ იყენებს სხვა ადამიანი
მიეცით ერთ ან ორ ადამიანს მიზანი („დაჯავშნე იოგას კლასი შაბათისთვის“), და არა ინსტრუქცია. უყურეთ, არ დაეხმაროთ, და ჩაინიშნეთ, სად ყოყმანობენ. ეს ყველაზე სწრაფი გზაა გაუგებარი ფორმულირებებისა და დამალული ღილაკების საპოვნელად. უფრო დიდი ვერსიისთვის იხილეთ როგორ ჩავატაროთ ბეტა ტესტი.
როცა შეცდომას აწყდებიან, ჩაწერეთ სწორად: ნაბიჯები, მოსალოდნელი შედეგი და რეალური შედეგი. ჩვენი გზამკვლევი კარგი ბაგ-რეპორტის დაწერა ფორმატს გაჩვენებთ.
AI-ის გამოყენება ტესტირებისთვის
თუ AI-ით აშენებთ, შეგიძლიათ სთხოვოთ მას დაგეხმაროთ ტესტების დაგეგმვასა და გაშვებაში:
ჩამოწერე ამ აპის მთავარი მომხმარებლის მოგზაურობები და თითოეულისთვის ყველაზე სავარაუდო კიდური შემთხვევები, რომლებიც შეიძლება გატყდეს: ცარიელი მდგომარეობები, არასწორი შეყვანა, უფლებები და განახლება. მომაწოდე ჩამონათვალის სახით, რომელსაც შემდეგ ავივლი.
შედი ორი სხვადასხვა სატესტო მომხმარებლით და შეამოწმე, შეუძლია თუ არა მომხმარებელ B-ს A-ს მიერ შექმნილი რამის ნახვა ან შეცვლა, მათ შორის A-ს ჩანაწერების URL-ების პირდაპირ გახსნით. მომაწოდე, რა აღმოაჩინე, სანამ რამეს გამოასწორებ.
AI-ის საკუთარ ტესტ-ანგარიშს პირველ შემოწმებად მიიჩნიეთ. ფულისა და უფლებების მოგზაურობები მაინც თავად გაიარეთ.
ტესტირება Mythex-ში
Mythex-ში ბრძანება /test აშვებს აპის ტესტირებას: აგენტი ბრაუზერს მართავს თქვენს ცოცხალ გადახედვაზე, ეწვევა გვერდებს, იღებს ეკრანის ანაბეჭდებს და ჩატში აცნობებს გატეხილ მოგზაურობებს. ყველაზე კარგად მუშაობს კონკრეტული მოგზაურობისთვის, მაგალითად „შეამოწმე რეგისტრაცია და კლასის დაჯავშნა“. იპოვნილი პრობლემები გაასწორეთ /fix-ით ან ჩვეულებრივი შეტყობინებით, შემდეგ კი ისევ გაუშვით /test. აპის ტესტირება გადახედვას იყენებს, ამიტომ გამოქვეყნების შემდეგ მთავარი მოგზაურობები გამოქვეყნებულ URL-ზე თავად შეამოწმეთ. იხილეთ აპის ტესტირება დოკუმენტაციაში და ჩვენი გზამკვლევი AI-ით აშენებული აპის გამართვა, როცა რამე ვერ მუშაობს.
გავრცელებული შეცდომები
- მხოლოდ საკუთარ თავზე ტესტირება. თქვენი ადმინისტრატორის ანგარიში, სავსე მონაცემებით, მალავს ცარიელი მდგომარეობისა და უფლებების შეცდომებს.
- მხოლოდ ლეპტოპზე ტესტირება. ბევრი საიტის უმეტესი ვიზიტორი ტელეფონიდან შემოდის.
- მეორე ანგარიშის გამოტოვება. მონაცემების გაჟონვა მომხმარებლებს შორის ყველაზე სერიოზული შეცდომაა, რითაც აპი შეიძლება გაეშვას.
- გადახედვის ნდობა. ცოცხალ აპს სხვა პარამეტრები აქვს; ის ისიც გაატესტეთ.
- შეცდომების გასწორება მეზობელი ნაწილების ხელახალი შემოწმების გარეშე. ერთი ფორმის შესწორებამ შეიძლება სხვა ფორმა გატეხოს, თუ ისინი კოდს იზიარებენ.
გაშვების წინა ჩეკლისტი
- მთავარი მოგზაურობები ჩამოწერილი და რანჟირებული
- ყოველი მოგზაურობა გადის როგორც სრულიად ახალი მომხმარებელი პირად ფანჯარაში
- ცარიელი, არასწორი, გრძელი და დუბლირებული შეყვანა დამუშავებულია
- განახლება მუშაობს ყველა გვერდზე
- მომხმარებლებს არ შეუძლიათ ერთმანეთის მონაცემების ნახვა ან შეცვლა, URL-ითაც კი
- ადმინისტრატორის გვერდები დაბლოკილია ჩვეულებრივი მომხმარებლებისა და გამოსული ვიზიტორებისთვის
- მუშაობს რეალურ iPhone-ზე და Android ტელეფონზე
- გადახდები გატესტილია: წარმატება, უარყოფა, გაუქმება, და აპი ამის შემდეგ განახლდება
- ელფოსტები მოდის, არ ხვდება სპამში და ბმულები ცოცხალ დომენს მიუთითებს
- მთავარ გვერდებზე კონსოლში წითელი შეცდომები არ არის
- მთავარი მოგზაურობები გამეორებულია გამოქვეყნებულ URL-ზე
- მინიმუმ ერთმა გარეშე ადამიანმა სცადა, შენი თვალწინ
კითხვები
რამდენი ტესტირება სჭირდება პატარა აპს გაშვებამდე?
საკმარისი იმისთვის, რომ დარწმუნდეთ: მთავარი მოგზაურობები მუშაობს სრულიად ახალი მომხმარებლისთვის ტელეფონსა და ლეპტოპზე, მომხმარებლებს არ შეუძლიათ ერთმანეთის მონაცემების ნახვა, და ყველაფერი, რაც ფულს ეხება, ბოლომდე მუშაობს. პატარა აპებისთვის ეს, როგორც წესი, რამდენიმე ფოკუსირებული საათია და არა კვირები.
MVP-სთვის მჭირდება ავტომატური ტესტები?
არა აუცილებლად. ძირითადი მოგზაურობების ხელით ტესტირება უმეტეს გაშვების შემაფერხებელ შეცდომას იჭერს. ავტომატური ტესტები მაშინ იხდის თავს, როცა აპს ხშირად ცვლით და გსურთ სწრაფად იცოდეთ, თუ რამე გატეხეთ, რაც აქამდე მუშაობდა.
უნდა ვატესტო გადახედვაზე თუ ცოცხალ აპზე?
ორივეზე. საფუძვლიანად გატესტეთ გადახედვაში, შემდეგ გაიმეორეთ მთავარი მოგზაურობები გამოქვეყნებულ აპზე, რადგან გარემოს ცვლადების დაკარგვამ, სხვა მონაცემთა ბაზამ ან მარშრუტიზაციის პარამეტრებმა შეიძლება ცოცხალი ვერსია სხვაგვარად მოიქცეს.
ჩემს გარდა, ვინ უნდა ატესტოს აპი?
მინიმუმ ერთი ადამიანი, რომელმაც ის არასდროს ნახა. მიეცით მიზანი და არა ინსტრუქცია, და უყურეთ მის მოქმედებას დახმარების გარეშე. ავტორები ხშირად, გაუცნობიერებლად, ერიდებიან იმ გზებს, რომლებიც იშლება.