ტესტის ავტომატიზაციის მცდარი წარმოდგენები

ამ სტატიაში ჩვენ განვიხილავთ ტესტის ავტომატიზაციის ყველაზე გავრცელებულ არასწორ წარმოდგენებს და იმას, თუ როგორ აფერხებს ეს ორგანიზაციებს სატესტო ავტომატიზაციაში წარმატების მიღწევაში.

ძნელი წარმოსადგენი არ არის პროდუქტის განვითარების პარალელურად ავტომატიზირებული ტესტირების სარგებელი - უფრო სწრაფი გამოშვება, გაზრდილი ტესტის გაშუქება, ხშირი ტესტის შესრულება, უფრო სწრაფი გამოხმაურება შემქმნელ გუნდთან, მხოლოდ რამდენიმე დასახელებისთვის, თუმცა ბევრმა ორგანიზაციამ არ გადადგა ნაბიჯი ან გამძლეა ინვესტიციის ჩადებაში ტესტის ავტომატიზაციისთვის.



ტესტის ავტომატიზაციის მცდარი წარმოდგენები

ალბათ, ყველაზე რთული და რთული ასპექტი ნებისმიერი სატესტო ავტომატიზაციის მცდელობაში არის ავტომატიზირებული ტესტირების შეზღუდვების გააზრება და რეალისტური მიზნებისა და მოლოდინების დადგენა იმედგაცრუების თავიდან ასაცილებლად. ამის გათვალისწინებით, მოდით ვნახოთ რამდენიმე ყველაზე გავრცელებული გაუგებრობა და მითი ტესტის ავტომატიზაციის შესახებ:


ავტომატიზირებული ტესტირება უკეთესია ვიდრე მანუალური ტესტირება

მიხეილ ბოლტონის ბლოგ პოსტზე მითითებით ტესტირება შემოწმების წინააღმდეგ , ავტომატიზირებული ტესტირება ნამდვილად არ არის ტესტირება. ეს არის ფაქტების შემოწმება. როდესაც ჩვენ გაგებული გვაქვს სისტემა, ჩვენ შეგვიძლია განვახორციელოთ ეს გაგება ფორმების შემოწმების დროს და შემდეგ ავტომატიზირებული ამოწმებს, ჩვენ ვადასტურებთ ჩვენს გაგებას. ტესტირება, სამაგიეროდ, არის საგამოძიებო სავარჯიშო, სადაც მიზნად ისახავს ახალი სისტემის მოპოვებას ტესტირებული სისტემის შესახებ, კვლევის საშუალებით.

ტესტირებისთვის საჭიროა, რომ ადამიანმა საფუძვლიანად განიხილოს სისტემის გამოყენებადობა. ჩვენ შეგვიძლია დავადგინოთ ანომალიები, როდესაც ამას არ ველოდით. ჩვენ არ უნდა ვიყოთ მსუბუქი ერთის ან მეორის მიმართ, რადგან ორივე მეთოდი საჭიროა განაცხადის ხარისხის შესახებ ინფორმაციის მისაღებად.


100% ავტომატიზირებული ტესტირების მიღწევა

როგორც არ არსებობს პრაქტიკული გზა 100% -იანი ტესტის დაფარვის მისაღწევად (დაუსრულებელი შესაძლო პერმუტაციების გამო), იგივე ეხება ტესტის ავტომატიზაციას. ჩვენ შეგვიძლია გავზარდოთ ტესტის დაფარვა ავტომატიზირებული ტესტების ჩატარებით მეტი მონაცემებით, უფრო მეტი კონფიგურაციით, ოპერაციული სისტემების, ბრაუზერების მრავალფეროვნებით დაფარვით, მაგრამ 100% -ის მიღწევა მაინც არარეალური მიზანია. როდესაც საქმე ავტომატიზირებულ ტესტირებას ეხება, მეტი ტესტი სულაც არ ნიშნავს უკეთეს ხარისხს ან უკეთეს ნდობას. ყველაფერი დამოკიდებულია იმაზე, თუ რამდენად კარგი ტესტია შექმნილი. იმის ნაცვლად, რომ მიზნად ისახავდეთ სრულ გაშუქებას, ყურადღება გაამახვილეთ ფუნქციონირების ყველაზე მნიშვნელოვან არეზე, რომელიც ბიზნესისთვის გადამწყვეტია.

სწრაფი ROI

ტესტის ავტომატიზაციის ამოხსნის განხორციელებისას, არსებობს სხვა ურთიერთდაკავშირებული განვითარების ღონისძიებები, ვიდრე მხოლოდ სკრიფტინგის ტესტის შემთხვევები. ჩვეულებრივ, საჭიროა შემუშავდეს ისეთი ჩარჩო, რომელსაც შეუძლია ხელი შეუწყოს ბიზნესისთვის სასარგებლო და მნიშვნელოვან ოპერაციებს, როგორიცაა საცდელი შემთხვევის შერჩევა, ანგარიშგება, მონაცემებზე დაყრდნობით და ა.შ.

ჩარჩოს შემუშავება არის პროექტი თავისთავად და მოითხოვს კვალიფიციურ დეველოპერებს და მშენებლობას დრო სჭირდება. მაშინაც კი, როდესაც სრულად ფუნქციონალური ჩარჩოა შექმნილი, ავტომატიზირებული შემოწმებების სკრიფტინგი თავდაპირველად უფრო მეტ დროს მოითხოვს, ვიდრე იგივე ტესტის ხელით შესრულება. ამიტომ, როდესაც ჩვენ ახლადგამომუშავებული ახალი მახასიათებლის შესახებ სწრაფი გამოხმაურება დაგვჭირდება, მისი ხელით შემოწმება, როგორც წესი, უფრო სწრაფია, ვიდრე ტესტის ავტომატიზაცია. ამასთან, ROI უბრუნდება გრძელვადიან პერსპექტივაში, როდესაც საჭიროა იგივე ტესტების შესრულება რეგულარული ინტერვალებით.

დეფექტების გამოვლენის უმაღლესი მაჩვენებელი ავტომატიზირებული შემოწმებების საშუალებით

მიუხედავად იმისა, რომ გამყიდველის მიერ მოწოდებული და სახლში მომზადებული სატესტო ავტომატიზაციის მრავალი გადაწყვეტილება დახვეწილი და ძალზედ ეფექტურია რთული ოპერაციების შესრულებაში, ისინი ვერასოდეს შეძლებენ კონკურენციას გაუწიონ ადამიანის ტესტერის ინტელექტს, რომელსაც შეუძლია დაინახოს მოულოდნელი ანომალიები პროგრამაში, ტესტირებული სისტემის წინააღმდეგ სკრიპტული ტესტების კომპლექტის შესრულება. ბედის ირონიით, ხალხი ავტომატიზირებულ ტესტირებას ელოდება უამრავი შეცდომის გამო, სავარაუდოდ, გაზრდილი ტესტის დაფარვის გამო, მაგრამ სინამდვილეში ეს ასე არ არის.


მართალია, ავტომატიზირებული ტესტები კარგად იძენს რეგრესიის პრობლემების დაჭერას - მას შემდეგ, რაც კოდის ბაზაში დაემატა ახალი ფუნქცია, უნდა დავრწმუნდეთ, რომ არ გავტეხეთ ამჟამინდელი ფუნქციონირება და ეს ინფორმაცია სწრაფად დაგვჭირდება - მაგრამ, რეგრესიის საკითხების რაოდენობა, უმეტეს შემთხვევაში, გაცილებით ნაკლებია ვიდრე ახალი ფუნქციონირება, რომელიც ვითარდება.

გასათვალისწინებელია კიდევ ერთი საკითხი ის არის, რომ ავტომატიზირებული შემოწმებები მხოლოდ იმ პროგრამის შემოწმებას დააპროგრამებს, ვინც სცენარს წერს. სკრიპტები ისეთივე კარგია, როგორც მათ ვინც დაწერა. ყველა ავტომატიზირებული შემოწმება სიხარულით შეიძლება გაიაროს, მაგრამ ძირითადი ხარვეზები შეიძლება შეუმჩნეველი დარჩეს, რამაც შეიძლება ცუდი წარმოდგენა შექმნას პროდუქტის ხარისხზე. არსებითად, შემოწმებამ შეიძლება დაადასტუროს დეფექტების არსებობა, მაგრამ ვერ დაამტკიცებს მათი არარსებობის შესახებ.

ჩვენ მხოლოდ ერთეულის ტესტის ავტომატიზაცია გვჭირდება

ასე რომ, თუ დეფექტების აღმოჩენის ალბათობა მეტია ახალი მახასიათებლების ტესტირებისას, რატომ არ ვაწარმოებთ ავტომატიზირებულ ტესტებს ახალი ფუნქციონირების საწინააღმდეგოდ, როდესაც ის ვითარდება? ეს გარკვეულწილად ეხება გუნდებს, რომლებიც ვარჯიშობენ TDD .

დეველოპერები ჯერ წერენ ერთეულის ტესტს, უყურებენ მის წარუმატებლობას და შემდეგ წერენ საკმარის კოდს, რომ მიიღონ ერთეულის ტესტის გავლა და ციკლი მეორდება, სანამ არ დანიშნულ ფუნქციონირებას მიაღწევს. სინამდვილეში, ეს ავტომატიზირებული ერთეულის ტესტები ამოწმებს ახალ ფუნქციონირებას და დროთა განმავლობაში ისინი ქმნიან ერთეულის რეგრესიულ პაკეტს, რომელიც განმეორებით ხორციელდება ახალი ფუნქციონირების მიწოდებასთან ერთად.


მაგრამ ამას წინათგრძნობა აქვს. მიუხედავად იმისა, რომ TDD დიდი წახალისებაა და წარმოადგენს ძლიერი განვითარების პრაქტიკას ხარისხის მშენებლობის საფუძველიდან, ერთეულის ტესტები მხოლოდ პროგრამისტის შეცდომების და არა ჩავარდნების პოვნაშია. არსებობს ტესტირების გაცილებით დიდი ასპექტი, რაც ხდება მაშინ, როდესაც ყველა კომპონენტი ერთმანეთთან არის მიბმული და ქმნის სისტემას.

სინამდვილეში, ბევრ ორგანიზაციას აქვს ავტომატიზირებული შემოწმების უმეტესობა სისტემის UI ფენაზე. ამასთან, სკრიფტინგის ავტომატიზირებული შემოწმებები UI– სთვის ან სისტემისთვის, როდესაც ფუნქციები შემუშავებულია, საუკეთესო შემთხვევაში საშიში ამოცანაა, რადგან ახალი ფუნქციონირება არასტაბილურია (მრავალ ცვლილებას განიცდის) განვითარების პროცესში. ასევე, მოსალოდნელი ფუნქციონალი შეიძლება მოგვიანებით არ იყოს ცნობილი, ამიტომ ცვალებადი ფუნქციონირების ავტომატიზირებისთვის დროის დახარჯვა არ არის წახალისებული.

ჩვენ მხოლოდ სისტემის UI ავტომატიზაცია გვჭირდება

ავტომატიზირებული შემოწმებების ჩატარების მნიშვნელობებია UI და სისტემის დონეზე. ჩვენ ვხვდებით, თუ რას განიცდის მომხმარებელი აპლიკაციასთან ურთიერთობისას; ჩვენ შეგვიძლია შეამოწმოთ ბოლოდან ბოლომდე ნაკადი და 3მეორეპარტიის ინტეგრაცია, როდესაც სხვაგვარად ვერ ვცდილობდით; ჩვენ ასევე შეგვიძლია ტესტების ჩვენება კლიენტებსა და საბოლოო მომხმარებლებამდე, რათა მათ შეძლონ ტესტის გაშუქების შეგრძნება. ამასთან, მხოლოდ UI ფენის ავტომატიზირებულ შემოწმებებზე დამოკიდებულებას აქვს საკუთარი პრობლემები.

UI მუდმივად იცვლება ვიზუალური დიზაინისა და გამოყენებადობის ასამაღლებლად და ავტომატიზირებული შემოწმებების გამო ვერ ხერხდება UI– ს ცვლილებების გამო და არა ფუნქციონალურ ცვლილებებში, შეიძლება ცრუ შთაბეჭდილება მოახდინოს განაცხადის მდგომარეობაზე.


UI ავტომატიზირებული შემოწმება შესრულების სიჩქარეში ასევე გაცილებით ნელია, ვიდრე ერთეულის ან API ფენისა და ამის გამო, გუნდისთვის უკუკავშირის ციკლი ნელია. შესაძლოა დეფექტის დადგომამდე რამდენიმე საათს დასჭირდეს და დეველოპერებს დაუბრუნდეს. და როდესაც რამე არასწორად ხდება, ძირეული მიზეზის ანალიზი უფრო მეტ ხანს გრძელდება, რადგან ადვილი არ არის გასაგები, თუ სად არის შეცდომა.

მნიშვნელოვანია თითოეული ტესტის კონტექსტის გაგება და რომელ ფენაში უნდა მოხდეს ტესტის ავტომატიზაცია. ტესტის ავტომატიზაცია უნდა იყოს განვითარების აქტივობის ნაწილი, ამიტომ მთელი გუნდი პასუხისმგებელია ტესტის ავტომატიზაციაზე, დეველოპერები წერენ ერთეულის ტესტებს, პროგრამის შემქმნელებს ტესტის წერაში ასრულებენ და ინარჩუნებენ მიღების ტესტებს API და / ან UI– ში.

კარგავს რწმენას და ნდობას ტესტის ავტომატიზაციისადმი

ეს ბოლო არ არის მითი ტესტის ავტომატიზაციის შესახებ, მაგრამ გვერდითი მოვლენაა, როდესაც ტესტის ავტომატიზაცია არასწორი ხდება. ბევრ საათს ხარჯავთ საცდელი ავტომატიზაციის შესანიშნავი გადაწყვეტილების შემუშავებაში, საუკეთესო იარაღებისა და საუკეთესო პრაქტიკის გამოყენებით, მაგრამ თუ ავტომატიზირებული შემოწმებები გუნდს არ ეხმარება, ეს უშედეგოა.

თუ გუნდს არ აქვს ხილვადობა ან ცოდნა იმის შესახებ, თუ რა არის ავტომატიზირებული და ახორციელებს, ისინი ან გაათავისუფლებენ უცნობი შიშისგან ან რეგრესიის ტესტირების მცდელობებს დუბლირებას ახდენენ. თუ ავტომატიზირებული შემოწმებები არის ქერცლიანი, ნელი, იძლევა წყვეტილ შედეგებს, ამან შეიძლება გუნდი უფრო მეტად დააბნიოს ვიდრე უსაფრთხოების ქსელი და ნდობის გამაძლიერებელი.


არ შეგეშინდეთ ავტომატიზირებული ამოწმების მოხსნის, რომლებიც ყოველთვის ვერ ხერხდება ან არათანმიმდევრულ შედეგებს იძლევა. ამის ნაცვლად, მიზნად დაისახეთ ტესტების სუფთა და საიმედო კომპლექტი, რომლებსაც შეუძლიათ სწორი მითითება განაცხადის ჯანმრთელობის შესახებ.



დასკვნა

ტესტის ავტომატიზაცია არის გრძელვადიანი ინვესტიცია. ამას დრო და გამოცდილება დასჭირდება ტესტის ავტომატიზაციის ჩარჩოებისა და ავტომატიზირებული სკრიპტების შემუშავებასა და შენარჩუნებაში. ტესტის ავტომატიზაცია არ არის ერთჯერადი ძალისხმევა, როდესაც გამოყოფთ გამოსავალს და უშვებთ მუშაობას. ამას მუდმივი მონიტორინგი და განახლება სჭირდება.

იმის ნაცვლად, რომ მიზნად ისახავდეს სახელმძღვანელო QA– ს შეცვლას ან ავტომატიზირებულ შემოწმებებს უამრავი დეფექტის აღმოჩენაზე, უნდა ვიცოდეთ ის უპირატესობები, რაც მას გუნდს მოუტანს, როგორიცაა QA– ს გათავისუფლება უფრო მეტი კვლევითი ტესტირებისთვის, სადაც დეფექტების გამოვლენის შანსი მაქსიმალურია, ან ავტომატიზირებული გამოყენება. სკრიპტები ტესტის მონაცემების შესაქმნელად, რომელთა გამოყენება შესაძლებელია სახელმძღვანელო ტესტირებისთვის.

შეზღუდვების გააზრება და რეალისტური მოლოდინის დადგენა მნიშვნელოვანია ტესტის ავტომატიზაციის ამ მითების დასაძლევად.