ყველა ტესტერი მიზნად ისახავს გაზარდოს ტესტ ქეისები, დაფაროს ტესტირების სამიზნე აპლიკაციის ყველა მოდული, რომ პროდუქტის მიტანა მომხმარებლამდე მოხდეს ხარვეზების გარეშე და არიდებული იქნას სამომავლოდ ხარვეზები უკვე რეალურ სამუშაო გარემოზე (ეგრედ წოდებულ პროდაქშენზე), კარგად დაგეგმილი ტესტირების სტრატეგია მოიცავს ტესტირების სხვადასხვა ტიპებს და ეტაპებს მაგრამ რთული სისტემებისთვის წარმატებული და სიცოცხლისუნარიანი ტესტირების სტრატეგიის პოვნა შეიძლება რთული იყოს. მაგრამ სხვა მიდგომებმა (ზოგადად განვითარებამ) და თანამედროვე შეხედულებებმა ბევრად გააადვილა საქმე QA-სთვის. ზოგადად ძირითადი წინაპირობა არის ის, რომ ის, რაც ადრე მუშაობდა, ისევ უნდა მუშაობა ისე, როგორც მოსალოდნელი იყო და სხვა დამოუკიდებელ მოდულების იმპლემენტაციას არ უნდა ქონდეს გამოწვეული ხარვეზები. მთელი სისტემა თანმიმდევრულად უნდა მუშაობდეს თავიდან ბოლომდე.
თუმცა ამ ყველაფრის წარმატებით გადასალახად ვიყენებთ სხვადასხვა ტიპის ტესტირებისას, რომლებსაც აქვთ თითქოს მსგავსი მიზნები, და ადვილია მათი ერთმანეთში არევა, რაც შემდგომ იწვევს დაბნებას და მოკლედ კარგი არაფერი ხდება.
ერთ-ერთი ასეთი ტესტირების ტიპი არის E2E ტესტირება და რეგრესიის ტესტირება. ისინი იმდენად ჰგვანან თავიანთ მიდგომით და შედეგებით, რომ არსებობს საერთოდ მცდარი წარმოდგენა ტესტირების ინდუსტრიაში, რომ ან ეს ორი ერთნაირია, ან ერთი მოიცავს მეორეს.
ტესტერები ხშირად ფიქრობენ, რომ რადგან E2E (End To End) ტესტირება ზოგჯერ ავტომატური რეგრესიის ტესტირების ნაწილია, ეს იგივეა, რაც რეგრესიის ტესტირება. მაგრამ სინამდვილეში, არის განსხვავებები პოსტში დეტალურად განვიხილავთ თითოეულ მათგანს და როგორ განსხვავდებიან ისინი ერთმანეთისგან.
რა არის End To End ტესტირება?
E2E ტესტირება არის ტესტირების მეთოდოლოგია, რომელმაც უნდა შეამოწმოს, მუშაობს თუ არა სისტემის ნაკადი (ფლოუ) დიზაინისა და მოლოდინების მიხედვით თავიდან ბოლომდე. ის ეხმარება სისტემის დამოკიდებულების იდენტიფიცირებასა და ამოცნობაში. პროცესი ასევე უზრუნველყოფს სწორ ინფორმირებას სხვადასხვა სისტემასა და მათ კომპონენტებს შორის. E2E ტესტირება ჩვეულებრივ ფუნქციური ტესტირების შემდეგ. ის ასტიმულირებს რეალურ დროში პარამეტრებს სატესტო გარემოსა და მონაცემების გამოყენებით. და საერთოდაც უფრო მარტივი ენით რომ ავხსნათ ეს არის ტესტირების ტიპი რომლის დროსაც უბრალოდ მოწმედება წარმატებით გადის user journey თავიდან ბოლომდე.
მნიშვნელოვანია იცოდეთ, რომ E2E ტესტირება არ უნდა იყოს ერთჯერადი აქტივობა. და ამის გაგება გადამწყვეტია იმ ბიზნესებისთვის, რომლებიც მუშაობენ როგორც ქლაუდზე, ასევე ქლაუდის გარეთ, რადგან მათ სჭირდებათ ინტეგრაციის მჭიდრო მონიტორინგი. ტესტერებს შეუძლიათ დაზოგონ დამატებითი ძალისხმევა და დრო ფართომასშტაბიანი ავტომატიზაციის ტესტირების განხორციელებით. მათ უნდა გაამახვილონ ყურადღება ტესტის დიზაინზე და ტესტის შედეგების ანალიზზე.
რა არის რეგრესიის ტესტირება?
მისი მიზანია დაადასტუროს, რომ ახალმა პროგრამულმა ცვლილებამ არ გამოიწვია უკვე არსებული და შემოწმებული ფუნქციურობის „გაფუჭება”. „Regression” ტესტირების დროს მიმდინარეობს უკვე გაშვებული ტესტების ხელახალი გაშვება. აღნიშნული ტესტირების ტიპი უზრუნველყოფს, რომ ახალ პროგრამულ ცვლილებას არ აქვს გვერდითი მოვლენები არსებულ ფუნქციაზე. „Regression” ტესტების გაშვების აუცილებლობა დგება მაშინ, როდესაც ხდება ქვემოთ მითითებული ერთ-ერთი მოვლენა:
- იცვლება მომხმარებლის მოთხოვნები, მაშასადამე იცვლება კოდი მოთხოვნების შესაბამისად;
- პროგრამას ემატება ახალი მახასიათებელი;
- ფიქსირდება პროგრამული დეფექტი.
მსგავსი ტიპის ტესტირებისას გამოყენებადია ავტომატური მატესტირებელი ინსტრუმენტები, რადგან ყოველი პროგრამული ცვლილებისას მიმდინარეობს ერთიდაიმავე ტესტების მრავალჯერადი გაშვება
ახლა კი შევადაროთ ეს ორი ტესტირების ტიპი ერთმანეთს:
- E2E ტესტირების დროს ყურადღება გამახვილებულია სამუშაო პროცესებზე (user journey). რეგრესიის ტესტირება ადასტურებს, რომ ახალმა ცვლილებებმა უარყოფითი გავლენა არ მოახდინა არსებულ ფუნქციონირებაზე.
- E2E ტესტირება ამოწმებს ინტეგრაციისა და ქვესისტემის საკითხებს ბიზნეს პროცესის მიმდინარეობის შესამოწმებლად. რეგრესიის ტესტირება იგივეს აკეთებს იმით, რომ დარწმუნდება, რომ ახალი ცვლილებები ხელს არ უშლის ძველი კოდის ფუნქციონირებას.
- E2E ტესტირება მოითხოვს ტესტ სცენარების (ქეისების) დამატებას სტაბილურად, პროგრამის/აპლიკაციის ზრდის პარალელურად, რეგრესიული ტესტირება ხელახლა ახორციელებს უკვე არსებულებს ტესტ ქეისების გაშვებას. ( რა თქმა უნდა ისიც საჭიროებს განახლება დამატებას მაგრამ არა იმ პროპორციით რაც ხდება E2E ტესტირებისთვის)
- E2E ტესტები მუდმივად გადის პროგრამული უზრუნველყოფის განვითარების სასიცოცხლო ციკლს ( ანუ ეს მონაწიელეობს CI/CD ში), ხოლო რეგრესიის ტესტები ტარდება მხოლოდ პრედაქშენზე გასვლის წინ ან პროგრამირების ცვლილების შემდეგ და მისი ახალ გარემოზე განთავსების წინ.
- ტესტერები ასრულებენ E2E ტესტირებას რეალურ მოწყობილობებზე ან იმიტირებულ გარემოში, მომხმარებლის გამოცდილების მიბაძვით. (იდენტური გარემო, ემულატორები, სიმულატორები და სხვა მრავალი ხერხის გამოყენებით) რეგრესიის ტესტები კი უბრალოდ პროდაქშენზე გასვლის წინ ხდება ამ მიდგომის გამოყენება პროდაქშენის გარემოს წინ მდგარ გარემოზე. მაგ. ტესტ გარემო ან პრე პროდ გარემო და სხვ.
სარგებელი და გამოწვევები.
თქვენ შეგიძლიათ მარტივად შეასრულოთ E2E, დევ გარემოში, რადგან ძირითადი სამიზნე მიბაძავს საბოლოო მომხმარებლის ინტერაქციას. მას შემდეგ, E2E ტესტირება ამოწმებს ყველა ფენას და სისტემას (როგორც უკვე ავღნიშნეთ ზემოთ, ის გადის სრულ ფლოუს, user journey). ასე რომ E2E არსებობა ნამდვილად სასარგებლოა. 🙂
მაგრამ სარგებელს მოყვება უკვე გამოწვევებიც. ზოგჯერ ტესტერები ყოველთვის ვერ იღებენ წვდომას ყველა სამუშაო გარემოზე. (რაც ართულებს e2e სცენარების შექმნას იმ გვარად რომ მუშაობდეს ნებისმიერი გარემოსთვის), ან მაგალითად ზოგი ერთ გარემოზე შეიძლება გადაულახავი ბარიერიც კი იყო ეგრედ წოდებული გარე სერვისებთან წვდომა და შეიძლება მათი ჩანაცვლება/გვერდის ავლაც არ იყოს მარტივი გზა. E2E ასევე ექვემდებარება პროგრამული უზრუნველყოფის განახლებებს და სხვა ურთიერთქმედებებს. მრავალი განმეორებადი და გრძელვადიანი ტესტის შექმნა და გაშვება შეიძლება იყოს ერთფეროვანი და შრომატევადი. (ხანაც მოსაწყენიც : ) ) უფრო მეტიც, უფრო დიდი ზომის ტესტის კომპლექტის შენარჩუნება დიდ ძალისხმევასა და დროს მოითხოვს. ასე რომ მთლად ისეც არაა რომ შექმნა და მიატოვო 😀
ახლა ვნახოთ რა სარგებელი მოაქვს რეგრესიულ ტესტირებას:
რეგრესიის ტესტირების საუკეთესო რამ არის, ტესტერებს შეუძლიათ სწრაფად ამოიცნონ დეფექტები SDLC-ის ადრეულ ფაზებში. ეს ტესტები ხელს უწყობს სისტემის სტაბილურობის შეფასებას სხვადასხვა ცვლილებების გზით. ამიტომ, CI/CD არ იქნება სრულყოფილი ამ ტესტირების ტიპის გარეშე. რეგრესიის ტესტირება ამცირებს და, ზოგიერთ შემთხვევაში, გამორიცხავს შემდგომ შეცდომებს. შესაბამისად, მნიშვნელოვნად უწყობს ხელს მომხმარებლის კმაყოფილებას. ის ასევე გთავაზობთ უწყვეტობას სამუშაო ნაკადების უზრუნველსაყოფად. (დიახ მესმის რომ ესეც თითქოს E2E გამოდის, მაგრამ ცდებით )
რაც შეეხება რეგრესიის გამოწვევებს:
რაც უფრო მეტ ფუნქციონალურობას და განახლებებს ამატებთ თქვენს პროგრამა (აპლიკაციას) , ის იზრდება. ამას შეუძლია რეგრესიის ტესტირება რთული გახადოს, რადგან ის აფართოებს მის ფარგლებს – რეგრესიის ტესტირების ციკლში გამეორებები იზრდება მზარდი ტესტის კომპლექტთან ერთად. მიუხედავად იმისა, რომ ავტომატიზაცია დიდწილად ეხმარება, რეგრესიის ტესტირება ხდება მთლიანობაში დამღლელი და შრომატევადი. თან ყველა ბედნიერებასთან ერთად დიდი ნაწილი რეგრესიის მაინც ხელით (მანუალურად) ხდება.
და მაინც ვცადოთ შეჯამება:
ტესტირების ყველა ტიპი ემსახურება განსხვავებულ მიზანს. როგორც E2E, ასევე რეგრესიის ტესტებს აქვთ უპირატესობების, დაბრკოლებების, მახასიათებლებისა. ვინაიდან პროგრამული უზრუნველყოფის მიზნები შეიძლება იყოს ცვლადი, ტესტირების მიდგომები ასევე უნიკალური უნდა იყოს.
მიუხედავად იმისა, რომ ძირითადი მიზანი აპის გაუმჯობესებაა, ასეთმა ცვლილებებმა შეიძლება გამოიწვიოს შეუთავსებლობა ზოგიერთ სფეროში. მაგრამ თუ თქვენ იყენებთ როგორც რეგრესიის, ისე E2E ტესტირებას, ეს საწინდარია აპლიკაციის მაღალი ხარისხის და “უბაგიანობის” 🙂
ახლა, როდესაც გვესმის განსხვავება რეგრესიასა და E2E ტესტირებას შორის, შეიძლება იფიქროთ იმაზე, თუ რომელია უფრო შესაფერისი თქვენი ბიზნესის საჭიროებებისთვის. იდეალური გზა არ არის ამ ორს შორის არჩევანის გაკეთება. ამის ნაცვლად, თქვენ შეგიძლიათ გახადოთ ის თქვენი ტესტირების სტრატეგიის ნაწილი 🙂
თქვენ შეგიძლიათ მარტივად გამოიყენოთ რეგრესიის და E2E ტესტირების ტიპები თქვენს მთლიან სამუშაო ფლოუში თუ ჯანსაღ ბალანსს დაამყარებთ ავტომატიზაციასა და მანუალ ტესტირებას შორის. თუმცა, უნდა გახსოვდეთ, რომ საჭიროების შემთხვევაში ავტომატიზაციის გამოყენება მნიშვნელოვანი ნაბიჯია და ის მოქმედების ვადების საგრძნობლად შემცირებას.
