დღეს შევეხოთ სანიტი ტიპის ტესტირებას და გამოყენების სტრატეგიას.
პროგრამული უზრუნველყოფის განვითარების სასიცოცხლო ციკლი არის სტრუქტურირებული პროცესი, რომელიც მოიცავს სხვადასხვა ტიპის ტესტირებას, თითოეულს აქვს უნიკალური/შესაბამისი მიზანი. ტესტირების ამ ტიპებს შორის, sanity ტესტირება გამოირჩევა, როგორც კრიტიკული ეტაპი, რომელიც მიზნად ისახავს უზრუნველყოს პროგრამული უზრუნველყოფის სტაბილურობა და ფუნქციონირება. ამ სტატიაში ჩვენ განვიხილავთ ეფექტური სიჯანსაღის ტესტირების სტრატეგიის შემუშავების დეტალებს, რომელიც მოიცავს მის მიზნებს.
პირველ რიგში გავარკვიოთ რა არის ეგრედ წოდებული “sanity” ტესტირება.
“Sanity” ტესტირება, რომელიც ხშირად განიხილება რეგრესიის ტესტირების ქვეჯგუფად, თამაშობს გადამწყვეტ როლს SDLC-ის ადრეულ ეტაპებზე.
მისი მიზანია შეაფასოს, მუშაობს თუ არა აპლიკაციის ძირითადი ფუნქციები ისე, როგორც მოსალოდნელია. Sanity ტესტირება ჩვეულებრივ არ არის სიღრმისეული , ფოკუსირებულია უფრო შეზღუდულ/კონკრეტულ ფუნქციებზე, რაც საშუალებას იძლევა ვნახოთ სწრაფი სურათი ძირითადი/კონკრეტული მოდულების მდგომარეობის შესახებ და ის გამოიყენება ძირითადად კოდის ერთი გარემოდან მომდევნო გარემოზე გადატანის პროცესში.
რა არის Sanity ტესტირების ტიპის მიზანი? – რა შედეგს უნდა ველოდოთ ამ ტიპის ტესტირებისგან
კარგად შესრულებული sanity ტესტირება ემსახურება თქვენი პროგრამული პროდუქტის მდგომარეობის შემოწმებას. ის იძლევა პასუხებს არსებული კოდის ერთი გარემოდან მეორე გარემოში გადატანის შედეგად მოხდა თუ არა არსებული მოდულების ან ლოგიკის დარღვევა, რომლებიც უკვეწარმართავს შემდგომი ტესტირების მიმართულებასაც.
- რამდენად სწორად მუშაობს პროდუქტის კონკრეტული ფლოუ (არსებული მოდულები, რომელიც უკვე შემოწმებული იყო ახალი მოდულის დამატების წინ
- მუშაობს თუ არა მომხმარებელთან დაკავშირებული ფუნქციები ხარვეზების გარეშე?
- არის თუ არა ყველაზე მნიშვნელოვანი ფუნქციები გამართული და ძირითადი ფუნქციონირებისთვის უნაკლოდ მუშაობის თუ არა
- იქცევა თუ არა მომხმარებლების მიერ ყველაზე ხშირად გამოყენებული ფუნქციები ისე, როგორც მოსალოდნელია
- ფუნქციონირებს თუ არა კონკრეტულ ვერსიაში დაგეგმილი ფუნქციები ისე, როგორც ეს იყო დაგეგმილი
- ხომ არ არსებობს რაიმე კრიტიკული საკითხი, რომელიც აპლიკაციას გამოუსადეგარი გახდის.
ამ საკითხებზე მიღებული პასუხებით ჩვენ შეგვიძლია მივიღოთ ინფორმირებული გადაწყვეტილებები. თუ სანიტი ტესტირება ვერ მოხერხდა (წარუმატებელი იქნა), აპლიკაცია უბრუნდება დეველოპერს პრობლემების აღმოსაფხვრელად, რაც ხელს უშლის პრობლემების შემდგომ განვითარებას. თუმცა, თუმცა თუ წარმატებულად მოხდა სანიტი ტესტირება და შედეგიც შესაბამისი იყო, პროგრამა/პროდუქტი გადადის შემდეგ ეტაპზე და უკვე შესაძლებელია და საჭიროა სისტემის საფუძვლიანი ტესტირება შესაბამისი ტესტირების მიდგომების გამოყენებით.
როდის უნდა ჩატარდეს საღი აზრის ტესტირება?
სანიტი ტესტირების ჩატარება შეგვიძლია შემდეგ სიტუაციებში:
- კოდის მცირე ცვლილებების შემდეგ.
- დაფიქსირებული შეცდომების/ბაგის/ხარვეზის/დეფექტის მოგვარების შემდეგ.
- პროგრამული უზრუნველყოფის დანერგვამდე (ერთი გარემოდან მეორეზე გადატანის დროს. ეს შეიძლება იყო პროდაქშენზე გატანამდე არსებულ წინა გარემოზე, თუ რა თქმა უნდა არსებობს რამდენიმე ტიპის გარემო)
როგორც სხვა ტიპის ტესტირებებსაც, ამასაც აქვს თავისი დადებითი და უარყოფითი მხარეები.
Sanity ტესტირების დადებითი და უარყოფითი მხარეები (უპირატესობება / ნაკლოვანებები):
უპირატესობები
- უზრუნველყოფს ინფორმირებას, ახალი ფუნქციონირების მიერ ხომ არ დაზიანდა არსებული ძირითადი ფუნქციონალი.
- სწრაფად აფასებს პროგრამული უზრუნველყოფის მზადყოფნას შემდგომი ტესტირებისთვის. (შემდეგ ეტაპზე გადასვლას)
- ზოგავს დროსა და რესურსებს
ნაკლოვანებები
- საფუძვლიანად არ ამოწმებს პროგრამული უზრუნველყოფის ფუნქციონირებას.
- უმნიშვნელო საკითხები (ხარვეზები და დეფექტები) შეიძლება შეუმჩნეველი დარჩეს.
- ფოკუსირებულია შემდგომი ტესტირებისთვის მზადყოფნაზე და არა ფუნქციონალურობის ამომწურავ ტესტირებაზე.
და საბოლოოდ რომ შევაჯამოთ:
სანიტი ტესტირების ძლიერი სტრატეგია აძლევს გუნდებს შესაძლებლობას მიიღონ ინფორმირებული გადაწყვეტილებები იმის შესახებ, გააგრძელონ უფრო ამომწურავი ტესტირება თუ უარი თქვან და პროდუქტი დაუბრუნდეს დეველოპმენტის ფაზას, რაც საბოლოოდ დაზოგავს დროსა და რესურსებს პროგრამული უზრუნველყოფის ხარისხის მიმართულებით რაც საბოლოოდ დადებითად აისახება პროდუქტის ყველა ასპექტში.
