ეს სახელმძღვანელო განმარტავს რა არის ტესტის სცენარი, ტესტის სცენარის მნიშვნელობასთან, განხორციელებასთან, მაგალითებთან და შაბლონებთან ერთად:
ნებისმიერი პროგრამული ფუნქციონალობა/მახასიათებელი, რომელიც შეიძლება შემოწმდეს ნათქვამია, რომ ეს არის ტესტის სცენარი. ნებისმიერი ტესტის სცენარის დაწერისას გათვალისწინებულია საბოლოო მომხმარებლის პერსპექტივა.
ეს სახელმძღვანელო დაგეხმარებათ უპასუხოთ კითხვებს: რატომ არის საჭირო ტესტის სცენარები, როცა ტესტის სცენარები დაწერილი და როგორ დავწეროთ ტესტის სცენარები.
რა არის ტესტის სცენარი?
განიხილეთ ჰიპოთეტური სიტუაცია: აქ არის უზარმაზარი ოკეანე. თქვენ უნდა იმოგზაუროთ ოკეანის გადაღმა ერთი ზღვის სანაპიროდან მეორეზე. მაგალითად, მუმბაიდან, ინდოეთის ზღვის სანაპიროდან კოლომბომდე, შრილანკას ზღვის სანაპირომდე.
მოგზაურობის რეჟიმი, რომელიც შეგიძლიათ აირჩიოთ:
(i) ავიახაზები: აიღეთ ფრენა კოლომბოში
(ii) საზღვაო გზები: კოლომბოში გასამგზავრებლად გემზე უპირატესობა მიანიჭეთ
(iii) რკინიგზა: წადით მატარებლით შრილანკაში
ახლა სატესტო სცენარებისთვის: მგზავრობა მუმბაის ზღვის სანაპიროდან კოლომბოს ზღვის სანაპირომდე არის ფუნქცია, რომელიც შესამოწმებელია.
ტესტის სცენარებში შედის:
- მოგზაურობა ავიახაზებით,
- მგზავრობა წყლის ხაზებით ან
- მოგზაურობა რკინიგზით.
ამ ტესტის სცენარებს ექნება სატესტო შემთხვევები.
ტესტის შემთხვევები, რომლებიც შეიძლება დაიწეროს ზემოაღნიშნული ტესტის სცენარებისთვის, მოიცავს:
ტესტიადგილობრივად და ატვირთული ინტერნეტ კავშირის ხელმისაწვდომობის მიხედვით. 6 რამდენიმე მომხმარებლის მიერ შესრულებული ცვლილებები არ არის ზედმეტად დაწერილი. 7 მრავალ მომხმარებელს შეუძლია ერთ დოკუმენტზე მუშაობა. 8 შესრულებული სამუშაო ინახება, თუ ფაილის ატვირთვისას ინტერნეტ კავშირი დაიკარგება. 9 გაზიარების შეზღუდვები გამოიყენება სწორად. 10 ნახვის შეზღუდვის მომხმარებლებს არ შეუძლიათ რაიმე შესწორება დოკუმენტებზე. 11 დოკუმენტები შეიძლება გამოქვეყნდეს ინტერნეტში ფართო საზოგადოებისთვის. 12 შესრულებული ცვლილებები დოკუმენტები ინახება დროის შტამპით & ავტორის დეტალები.
ტესტის სცენარების რაოდენობა მრავალჯერადი და ძალიან დიდი იქნება Google Docs-ისთვის. ასეთ შემთხვევებში, ზოგადად, მხოლოდ მიღების კრიტერიუმებს ადგენენ და ამტკიცებენ დაინტერესებული მხარეები და გუნდის წევრები მუშაობენ ამ მიღების კრიტერიუმებზე. სატესტო შემთხვევების დაწერა, უფრო სწორად, ტესტის სცენარებისთვის შეიძლება იყოს ამომწურავი ამოცანა უზარმაზარი აპლიკაციებისთვის.
ეს მიღების კრიტერიუმები მთავარ როლს თამაშობს განმეორებითი პროცესის დაგეგმვაში და არასოდეს უნდა იყოს უგულებელყოფილი. მათი წინასწარ და წინასწარ განსაზღვრა თავიდან აიცილებს სიურპრიზებს ან შოკებს სპრინტების ან გამოშვებების ბოლოს
მიცემულია წინაპირობა.
როდესაც მოქმედების შესასრულებლად.
შემდეგ მოსალოდნელია შედეგი.
Formats of Given,როდის და შემდეგ გამოსადეგია მიღების კრიტერიუმების დასაზუსტებლად.
ტესტის სცენარის შაბლონის მაგალითი
| გამოიყენეთ ამბავი ID # | ტესტი სცენარის ID # | ვერსია # | სატესტო სცენარები | # ტესტის შემთხვევები | მნიშვნელობა |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | გადაამოწმეთ, სწორად იხსნება თუ არა Kindle App. | 4 | High |
| USID12.1 | TSID12.1.2 | Kin12.4 | დაადასტურეთ Kindle აპის შენახვის მოცულობა. | 3 | საშუალო |
დასკვნა
ნებისმიერი პროგრამული ტესტირებისას, სასიცოცხლო ციკლის გაგება და ტესტის სცენარების ჩამოყალიბება ძალიან მნიშვნელოვანი ელემენტია. პროგრამული უზრუნველყოფის ხარისხი შეიძლება გაუმჯობესდეს ტესტის სცენარებისთვის კარგი საფუძვლის არსებობით. ხშირად, ტესტის შემთხვევისა და ტესტის სცენარების გამოყენება შეიძლება ურთიერთშეცვლილი იყოს.
თუმცა, ცერის წესია, რომ ტესტის სცენარი გამოიყენება მრავალი ტესტის შემთხვევის დასაწერად ან შეგვიძლია ვთქვათ, რომ ტესტის შემთხვევები მიღებულია ტესტის სცენარებიდან. კარგად განსაზღვრული ტესტის სცენარები უზრუნველყოფს კარგი ხარისხის პროგრამულ უზრუნველყოფას.
სცენარი: მოგზაურობა ავიახაზებითსატესტო შემთხვევები შეიძლება მოიცავდეს სცენარებს, როგორიცაა:
- ფრენა არის დაგეგმილი დროის მიხედვით .
- ფრენა არ არის დაგეგმილი დროის მიხედვით.
- დადგა საგანგებო სიტუაცია (ძლიერი ნალექი და შტორმი).
იგივე გზით, ტესტების ცალკეული ნაკრები შეიძლება დაიწეროს სხვა დარჩენილი სცენარებისთვის.
ახლა მოდით გადავიდეთ ტექნოლოგიურ ტესტირების სცენარებზე.
ყველაფერი, რისი ტესტირებაც შესაძლებელია, არის ტესტის სცენარი. ამრიგად, ჩვენ შეგვიძლია განვაცხადოთ, რომ ნებისმიერი პროგრამული უზრუნველყოფის ფუნქცია, რომელიც ტესტირებაშია, შეიძლება დაიყოს რამდენიმე მცირე ფუნქციონირებად და შეიძლება ეწოდოს „ტესტის სცენარი“.
ნებისმიერი პროდუქტის კლიენტისთვის მიწოდებამდე, პროდუქტის ხარისხი უნდა იყოს შეფასდეს და შეფასდეს. ტესტის სცენარი ხელს უწყობს პროგრამული უზრუნველყოფის აპლიკაციის ფუნქციონალური ხარისხის შეფასებას, რომელიც შეესაბამება მის ბიზნეს მოთხოვნებს.
ტესტერის სცენარი არის პროცესი, რომლის დროსაც ტესტერი ამოწმებს პროგრამულ აპლიკაციას საბოლოო მომხმარებლის პერსპექტივიდან. პროგრამული უზრუნველყოფის აპლიკაციის შესრულება და ხარისხი საფუძვლიანად არის შეფასებული საწარმოო გარემოში დანერგვამდე.
ტესტის სცენარის მნიშვნელობა
- ერთ ტესტის სცენარს შეიძლება ჰქონდეს მრავალი „ტესტის შემთხვევა“. ის შეიძლება ჩაითვალოს, როგორც დიდი პანორამული გამოსახულება და სატესტო შემთხვევები არის პატარა ნაწილები, რომლებიც მნიშვნელოვანია პანორამის დასასრულებლად.
- ეს არის ერთი ხაზის განცხადება და ტესტი.შემთხვევები მოიცავს ნაბიჯ-ნაბიჯ აღწერას ტესტის სცენარის განცხადების მიზნის დასასრულებლად.
- მაგალითი:
ტესტის სცენარი: გააკეთეთ ტაქსის სერვისის გადახდა შესრულდა.
ეს იქნება რამდენიმე ტესტის შემთხვევა, როგორც ეს ქვემოთ არის ნათქვამი:
(i) გამოყენებული გადახდის მეთოდი: PayPal, Paytm, საკრედიტო/სადებეტო ბარათი.
(ii) გადახდა შესრულდა წარმატებით.
(iii) გადახდა წარუმატებელია.
(iv) გადახდის პროცესი შეწყდა.
(v) გადახდის მეთოდებზე წვდომა შეუძლებელია.
(vi) აპლიკაცია შუალედში იშლება.
- ტესტის სცენარები ამგვარად ეხმარება პროგრამული აპლიკაციის შეფასებას რეალურ სამყაროში არსებული სიტუაციების მიხედვით.
- ტესტის სცენარები. როდესაც განსაზღვრულია, დაეხმარეთ ტესტის არეალის ორად გაყოფას.
- ამ ბიფურკაციას უწოდებენ პრიორიტეტიზაციას, რომელიც გვეხმარება პროგრამული აპლიკაციის მნიშვნელოვანი ფუნქციონალობის დადგენაში.
- ფუნქციონალობის პრიორიტეტული ტესტირება, ეხმარება დიდს. პროგრამული აპლიკაციის წარმატებით განხორციელების ხარისხი.
- როგორც ტესტის სცენარებს პრიორიტეტები მიენიჭება, ყველაზე მნიშვნელოვანი ფუნქციონალობა შეიძლება ადვილად იდენტიფიცირდეს და შემოწმდეს პრიორიტეტულად. ეს უზრუნველყოფს, რომ გადამწყვეტი ფუნქციების უმეტესობა კარგად მუშაობს და მასთან დაკავშირებული დეფექტები სათანადოდ არის აღბეჭდილი და გამოსწორებული.
- ტესტი სცენარები განსაზღვრავს პროგრამული უზრუნველყოფის ბიზნეს პროცესის მიმდინარეობას.და, ამრიგად, შესაძლებელია აპლიკაციის ბოლომდე ტესტირება.
განსხვავება ტესტის სცენარსა და ტესტის შემთხვევას შორის
| ტესტის სცენარი | ტესტის შემთხვევები |
|---|---|
| ტესტის სცენარი არის კონცეფცია. | ტესტის შემთხვევები არის გადაწყვეტილებები ამ კონცეფციის შესამოწმებლად. |
| ტესტის სცენარი არის მაღალი დონის ფუნქციონირება. | ტესტის შემთხვევები არის დეტალური პროცედურა მაღალი დონის ფუნქციონირების შესამოწმებლად. |
| ტესტის სცენარები მომდინარეობს მოთხოვნებიდან/მომხმარებლის ისტორიებიდან. | სატესტო შემთხვევები მიღებულია ტესტის სცენარებიდან. |
| ტესტის სცენარი არის „რა ფუნქციონალობაა შესამოწმებელი“ | ტესტის შემთხვევები არის „როგორ შევამოწმოთ ფუნქციონირება“. |
| ტესტის სცენარებს აქვს მრავალი ტესტის შემთხვევა. | სატესტო შემთხვევა შეიძლება იყოს დაკავშირებული ან არ იყოს დაკავშირებული რამდენიმე ტესტის სცენართან. |
| ერთი ტესტის სცენარები არასოდეს განმეორდება. | ერთი ტესტის შემთხვევა შეიძლება გამოყენებულ იქნას მრავალჯერ სხვადასხვა სცენარში. |
| საჭიროა მოკლე დოკუმენტაცია. | საჭიროა დეტალური დოკუმენტაცია. |
| სატესტო სცენარის დასასრულებლად საჭიროა ტვინის შტორმის სესიები. | პროგრამული აპლიკაციის დეტალური ტექნიკური ცოდნა საჭიროა |
| დროის დაზოგვა, რადგან წუთების დეტალები არ არის საჭირო. | დრო შრომატევადი, რადგან ყოველი წუთის დეტალი საჭიროებს ზრუნვას. |
| რემონტის ღირებულება დაბალია, როგორც საჭიროა რესურსებიდაბალი. | შენარჩუნების ღირებულება მაღალია, რადგან საჭირო რესურსები მაღალია |
რატომ არის სატესტო სცენარები შეუცვლელი?
სატესტო სცენარები გამომდინარეობს მოთხოვნებიდან ან მომხმარებლის ისტორიებიდან.
- აიღეთ სატესტო სცენარის მაგალითი კაბინის დაჯავშნისთვის.
- სცენარები შეიძლება იყოს ტაქსის დაჯავშნის ვარიანტები, გადახდის მეთოდები, GPS თრექინგი, საგზაო რუკა ნაჩვენებია სწორად თუ არა, ტაქსისა და მძღოლის დეტალები ნაჩვენებია სწორად თუ არა და ა.შ. ყველა ჩამოთვლილია ტესტის სცენარის შაბლონში.
- ახლა დავუშვათ, რომ ტესტის სცენარი არის იმის შესამოწმებლად, ჩართულია თუ არა მდებარეობის სერვისები, თუ არ არის ჩართული, აჩვენეთ შეტყობინება „ჩართეთ მდებარეობის სერვისები. ეს სცენარი გამოტოვებულია და არ არის ჩამოთვლილი ტესტის სცენარების შაბლონში.
- „მდებარეობის სერვისის“ სცენარი წარმოშობს მასთან დაკავშირებულ სხვა სატესტო სცენარებს.
ეს შეიძლება იყოს :
-
- მდებარეობის სერვისი ნაცრისფერია.
- მდებარეობის სერვისი ჩართულია, მაგრამ არა ინტერნეტი.
- ადგილობრივი სერვისების შეზღუდვები .
- არასწორი მდებარეობა ნაჩვენებია.
- ერთი სცენარის გამოტოვება შეიძლება ნიშნავს მრავალი სხვა გადამწყვეტი სცენარის ან ტესტის შემთხვევის გამოტოვებას . ამას შეიძლება ჰქონდეს დიდი უარყოფითი გავლენა პროგრამული აპლიკაციის დანერგვისას. ეს იწვევს რესურსების (ვადების) დიდ დაკარგვას.
- სატესტო სცენარები დიდად ეხმარება ამომწურავი ტესტირების თავიდან აცილებაში . ის უზრუნველყოფს, რომ ყველა გადამწყვეტი დამოსალოდნელი ბიზნეს ნაკადები ტესტირება ხდება, რაც შემდგომში ეხმარება აპლიკაციის ბოლომდე ტესტირებას.
- ეს არის დროის დაზოგვა. ასევე, ბევრად უფრო დეტალური აღწერა ტესტის შემთხვევების მიხედვით არ არის საჭირო. მითითებულია ერთი ხაზის აღწერა იმის შესახებ, თუ რა უნდა შემოწმდეს.
- ტესტის სცენარები იწერება გუნდის წევრების ბრენშტორმინგის სესიების შემდეგ. აქედან გამომდინარე, ნებისმიერი სცენარის (გადამწყვეტი თუ უმნიშვნელო) გამოტოვების ალბათობა მინიმალურია. ეს კეთდება ტექნიკური მახასიათებლების გათვალისწინებით და ასევე პროგრამული აპლიკაციის ბიზნეს ნაკადის გათვალისწინებით.
- უფრო მეტიც, ტესტის სცენარები შეიძლება დაამტკიცოს ბიზნეს ანალიტიკოსის კლიენტმა ან ორივემ, ვისაც აქვს მკაფიო ცოდნა ტესტირებადი აპლიკაციის შესახებ.
მაშასადამე, ტესტის სცენარები SDLC-ის შეუცვლელი ნაწილია.
ტესტის სცენარების განხორციელება
მოდით ვნახოთ ტესტის სცენარების განხორციელება ან როგორ დავწეროთ ტესტის სცენარები:
- ეპოსი/ბიზნეს მოთხოვნები ყალიბდება.
- Epic-ის მაგალითი : შექმენით Gmail ანგარიში. Epic შეიძლება იყოს აპლიკაციის მთავარი მახასიათებელი ან ბიზნეს მოთხოვნილება.
- Epics იყოფა მომხმარებელთა მცირე ისტორიებად სპრინტებში.
- მომხმარებლის ისტორიები მომდინარეობს Epics-დან. მომხმარებლის ეს ისტორიები უნდა იყოს საბაზისო და დამტკიცებული დაინტერესებული მხარეების მიერ.
- სატესტო სცენარები გამომდინარეობს მომხმარებლის ისტორიებიდან ან BRS (ბიზნესის მოთხოვნის დოკუმენტი), SRS (სისტემის მოთხოვნასპეციფიკაციის დოკუმენტი), ან FRS (ფუნქციური მოთხოვნის დოკუმენტი), რომლებიც დასრულებული და საბაზისოა.
- ტესტერები წერენ ტესტის სცენარებს.
- ეს ტესტის სცენარები დამტკიცებულია გუნდის ხელმძღვანელის, ბიზნეს ანალიტიკოსის ან პროექტის მენეჯერის მიერ. დამოკიდებულია ორგანიზაციაზე.
- თითოეული ტესტის სცენარი უნდა იყოს მიბმული მომხმარებლის მინიმუმ ერთ ისტორიასთან.
- დადებითი და უარყოფითი ტესტის სცენარი უნდა იყოს იდენტიფიცირებული.
- მომხმარებლის ისტორიები მოიცავს დათანხმების კრიტერიუმები, როგორიცაა :
- მიღების კრიტერიუმები არის პირობების ჩამონათვალი ან განზრახვის მდგომარეობა მომხმარებლის მოთხოვნებისთვის. კლიენტის მოლოდინები და ასევე გაუგებრობები გათვალისწინებულია მიღების კრიტერიუმების დაწერისას.
- ეს არის უნიკალური მომხმარებლის ერთი ამბავი და თითოეულ მომხმარებლის ისტორიას უნდა ჰქონდეს მინიმუმ ერთი მიღების კრიტერიუმი, რომელიც უნდა იყოს დამოუკიდებლად შესამოწმებელი.
- დაშვების კრიტერიუმები გვეხმარება იმის დადგენაში, თუ რომელი მახასიათებელია ფარგლებს გარეთ და რომელია პროექტის ფარგლებს გარეთ. ეს კრიტერიუმები უნდა შეიცავდეს როგორც ფუნქციურ, ასევე არაფუნქციურ მახასიათებლებს.
- ბიზნესის ანალიტიკოსები წერენ მიღების კრიტერიუმებს და პროდუქტის მფლობელი ამტკიცებს მათ.
- ან ზოგიერთ შემთხვევაში, პროდუქტის მფლობელს შეუძლია თავად დაწეროს კრიტერიუმები.
- ტესტის სცენარების მიღება შესაძლებელია მიღების კრიტერიუმებიდან.
ტესტის სცენარის მაგალითები
#1) ტესტის სცენარები Kindle App-ისთვის
Kindle არის აპი, რომელიც საშუალებას აძლევს ელექტრონულ მკითხველებს მოძებნონელექტრონული წიგნები ონლაინ, ჩამოტვირთეთ და შეიძინეთ ისინი. Amazon Kindle აძლევს ელექტრონული წიგნის მკითხველს წიგნის ხელში დაჭერისა და მისი წაკითხვის რეალურ გამოცდილებას. აპში გვერდების გადაბრუნებაც კი მშვენივრად არის სიმულირებული.
ახლა მოდით აღვნიშნოთ ტესტის სცენარები. ( შენიშვნა: ქვემოთ ჩამოთვლილია შეზღუდული სცენარები, რათა მიიღოთ ზოგადი იდეა ტესტის სცენარის დაწერის შესახებ. მისგან შეიძლება იყოს მრავალი ტესტის შემთხვევა).
| ტესტის სცენარები # | ტესტის სცენარები |
|---|---|
| 1 | გადაამოწმეთ სწორად გაშვებული თუ არა Kindle App. |
| 2 | დაადასტურეთ ეკრანის გარჩევადობის კორექტირება სხვადასხვა მოწყობილობის მიხედვით, აპის გაშვების შემდეგ. |
| 3 | დაადასტურეთ, რომ ნაჩვენები ტექსტი იკითხება. |
| 4 | გადაამოწმეთ, რომ მასშტაბირებისა და შემცირების პარამეტრები მუშაობს. |
| 5 | დაამოწმეთ, რომ Kindle აპში იმპორტირებული თავსებადი ფაილები იკითხება. |
| 6 | დაადასტურეთ შენახვის მოცულობა Kindle აპლიკაცია. |
| 7 | დაადასტურეთ ჩამოტვირთვის ფუნქცია სწორად მუშაობს. |
| 8 | დაადასტურეთ, რომ გვერდის შემობრუნების სიმულაცია მუშაობს სწორად |
| 9 | დაადასტურეთ eBook-ის ფორმატების თავსებადობა Kindle აპთან. |
| 10 | დაამოწმეთ შრიფტები, რომლებიც მხარდაჭერილია Kindle აპის მიერ. |
| 11 | დაადასტურეთ Kindle აპის მიერ გამოყენებული ბატარეის ხანგრძლივობა. |
| 12 | დაამოწმეთ შესრულებაKindle-ის დამოკიდებულია ქსელის დაკავშირებაზე (Wi-Fi, 3G ან 4G). |
მრავალი ტესტის შემთხვევის გამოყვანა შესაძლებელია ზემოთ აღწერილი თითოეული ტესტის სცენარიდან.
#2) დაშვების კრიტერიუმები Google Docs-ისთვის
„Google Docs“ არის ვებ-ზე დაფუძნებული აპლიკაცია Word დოკუმენტების, ელცხრილების, სლაიდების და ფორმების შესაქმნელად, რედაქტირებისთვის და გასაზიარებლად. ყველა ფაილზე წვდომა შესაძლებელია ინტერნეტით ინტერნეტ ბრაუზერის გამოყენებით.
შექმნილი დოკუმენტების გაზიარება შესაძლებელია როგორც ვებგვერდი ან დასაბეჭდად მზა დოკუმენტი. მომხმარებელს შეუძლია დააწესოს შეზღუდვები, თუ ვის შეუძლია დოკუმენტების ნახვა და რედაქტირება. ერთი დოკუმენტის ერთობლივად გაზიარება და დამუშავება შესაძლებელია სხვადასხვა პიროვნების მიერ სხვადასხვა გეოგრაფიული მდებარეობიდან.
შეზღუდული ტესტის სცენარები მოცემულია ქვემოთ ზოგადი გაგებისთვის. Google Docs-ის სიღრმისეული ტესტის სცენარები შეიძლება იყოს საერთოდ ცალკე თემა.
| მიღების კრიტერიუმები # | მიღების კრიტერიუმები |
|---|---|
| 1 | Word, Sheets ან Forms წარმატებით გაიხსნება შეცდომის გარეშე. |
| 2 | თარგები ხელმისაწვდომია დოკუმენტებისთვის, ფურცლებისთვის და სლაიდები. |
| 3 | ხელმისაწვდომი შაბლონები ხელმისაწვდომია მომხმარებლებისთვის. |
| 4 | გამოყენებული შაბლონი რედაქტირებადია (მაგ.: შრიფტები, შრიფტის ზომა, ტექსტის დამატება, ტექსტის წაშლა, სლაიდის ჩასმა). |
| 5 | თუ ინტერნეტთან კავშირი დროებით მიუწვდომელია, ფაილის შენახვა შესაძლებელია |