ტესტის ავტომატიზაციის რჩევები და საუკეთესო პრაქტიკა

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

ეს ასევე ხსნის ტვირთი QA– სგან რეგრესიული ტესტების განმეორებით ჩატარებას, რაც ზოგავს QA– ს სხვა ტესტირების აქტივობებზე ფოკუსირებას.

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

სახელმძღვანელო vs ავტომატიზირებული - ტესტირება vs შემოწმება

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

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

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

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



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

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

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

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

ასევე, არ შეამციროთ ტესტირების მოცულობა მხოლოდ იმისთვის, რომ ტესტმა იმუშაოს ან ჩააბაროს.

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

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

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

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

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

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

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

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

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

ნუ ავტომატიზირებთ არასტაბილურ ფუნქციონირებას

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

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

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

ნუ ელით მაგიას ტესტის ავტომატიზაციისგან

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

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

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

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

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

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

მიზანი სწრაფი კავშირი

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

ამ სწრაფი უკუკავშირის მარყუჟის მისაღებად, ტესტები უნდა ავტომატიზირდეს კომპონენტზე ან API ფენაზე, UI– ს იმედის გარეშე.

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

გაიგეთ კონტექსტი

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

API ტესტები ან ინტეგრაციის ტესტები უზრუნველყოფს ფუნქციების და კლასების ერთობლივ მუშაობას და მონაცემთა გადაცემა ერთი კლასიდან მეორეში.

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

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

UI დონეზე, ჩვენ ავტომატიზირებთ სცენარებს ვიდრე სიუჟეტებს.

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

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

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

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

ასევე, ავტომატიზირებული ტესტების დიდი რაოდენობა ზრდის ხარჯებს და ძნელია მათი შენარჩუნება.

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

გამოიყენეთ ტესტის ტექნიკა ტესტის ავტომატიზაციაში

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

ნუ ავტომატიზირებთ ქაოსს

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

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

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

გაქვთ ტესტის ავტომატიზაციის რჩევები, რომლებიც ამ ჩამონათვალს დაემატება?