მეტი ტესტური დაფარვა, იგივე QA გუნდი: AnyTest-ის შესაძლებლობების ტექნიკური გეგმა

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

AnyTest გთავაზობთ სამუშაოს განსხვავებულ დაყოფას: მიეცით აგენტებს ვებ აპის URL, მიეცით საშუალება მათ გამოიკვლიონ და შექმნან ბოლომდე ტესტები, შემდეგ სთხოვეთ ადამიანს გადახედოს UI-ს ნაბიჯებს და დაამტკიცოს ან მოითხოვოს ცვლილებები. ეს არის სამუშაო პროცესი, რომელიც აღწერილია [AnyTest-ის პროდუქტის გვერდზე] (https://anytest.dev). შესაძლებლობა არის, რომ არსებულ QA ინჟინერს ჰქონდეს უფრო დიდი, უკეთ განხილული სატესტო პორტფოლიო და არ მოხსნას ადამიანი, რომელსაც ესმის, რა უნდა გააკეთოს პროდუქტმა.

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

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

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

[Playwright-ის საუკეთესო პრაქტიკის სახელმძღვანელო] (https://playwright.dev/docs/best-practices) რეკომენდაციას იძლევა მომხმარებლისთვის ხილული ქცევის ტესტირებას და არა განხორციელების დეტალებს, ტესტების იზოლირებას და ელასტიური ლოკატორების გამოყენებას. ეს პრინციპები უზრუნველყოფს სასარგებლო მიმოხილვის ჩამონათვალს ნებისმიერი გენერირებული ბრაუზერის ტესტისთვის. ისინი არ ამტკიცებენ, რომ გამყიდველი მიჰყვება მათ ყველა გამომუშავებაში.

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

ტექნიკური სამუშაო პროცესი არსებული QA გუნდისთვის

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

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

დაყენება და გასუფთავება მკაფიოდ შეინახეთ. [Playwright მოწყობილობები] (https://playwright.dev/docs/test-fixtures) გვიჩვენებს, თუ როგორ შეუძლია სატესტო ჩარჩოს რესურსებს განსაზღვრული სასიცოცხლო ციკლი მისცეს. ეს არის საინჟინრო მითითება და არა პრეტენზია AnyTest-ის იმპლემენტაციის შესახებ. იქ, სადაც თქვენი საკუთარი სტეკი მხარს უჭერს მას, დათესეთ დეტერმინისტული მონაცემები, ცვალებად ჩანაწერებს ტესტირება და შეინახეთ მარცხის დიაგნოსტიკური მტკიცებულებები.

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

რეპროდუცირებადი საორიენტაციო ნიშანი, ROI სლაიდამდე

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

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

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

სიმულირებული სიმძლავრე ერთი, ორი, სამი და ხუთი ინჟინრისთვის

დავუშვათ, რომ თითოეულ ინჟინერს აქვს კვირაში 20 საათი ამ დაფარვის მარყუჟისთვის სხვა მოვალეობების შემდეგ. ეს არის დაგეგმვის დაშვება და არა განცხადება ნორმალური სამუშაო კვირის შესახებ. საბაზისო მოითხოვს 2.0 საათს მშენებლობას, 0.5 საათს განხილვას და 0.5 საათს მუდმივ მოვლას თითო მიღებულ ტესტური სცენარიზე: სულ 3.0 ადამიანური საათი.

დავუშვათ, რომ აგენტის დახმარებით კანდიდატს ესაჭიროება 0,25 საათი საჭე, 0,50 საათი განხილვა, 0,25 საათი კორექტირება და 0,50 საათი შენარჩუნება: 1,50 ადამიანური საათი თითო მიღებულ ტესტური სცენარიზე. ყოველ კვირას დაამატეთ 2.0 საათის საერთო გუნდის დაყენება და კოორდინაცია. ვივარაუდოთ, რომ მიღების სტანდარტები და რისკის ნაზავი უცვლელი რჩება. აგენტის ლოდინის დრო ადამიანური საათების მიღმაა, მაგრამ შესაძლოა მაინც შეზღუდოს მიწოდების გრაფიკი.

ყოველკვირეული სიმძლავრის ფორმულები არის იატაკი (20 x ინჟინრები / 3.0) საბაზისო და იატაკი ((20 x ინჟინრები - 2.0) / 1.5) კანდიდატისთვის. მთელი ტესტური სცენარები დამრგვალებულია და არა ზემოთ.

• ერთი ინჟინერი: 20 ხელმისაწვდომი საათი; საბაზისო 6 მიღებული მგზავრობა; კანდიდატი 12. სოლო QA-ის მფლობელს შეუძლია გამოიყენოს თავისუფალი დრო საძიებო სესიებისთვის და დაინტერესებული მხარეების რისკების განხილვისთვის, ვიდრე გახდეს ტესტის ჩაწერის ბლოკად.
• ორი ინჟინერი: 40 საათი; საბაზისო 13; კანდიდატი 25. ერთი შეიძლება ფლობდეს მიღებას და რისკის შერჩევას, ხოლო მეორე ფლობს დიაგნოზს და შენარჩუნებას, როლების როტაციით, რათა თავიდან აიცილოს ახალი კარიბჭის შექმნა.
• სამი ინჟინერი: 60 საათი; საბაზისო 20; კანდიდატი 38. საკუთრების დაყოფა პროდუქტის ფართობის მიხედვით, საერთო განხილვის სტანდარტით, ვიდრე თითოეული ინჟინერი ინარჩუნებს შეუთავსებელ გენერირებულ კომპლექტს.
• ხუთი ინჟინერი: 100 საათი; საბაზისო 33; კანდიდატი 65. მიმოხილვისა და ტესტის მონაცემების კოორდინაცია სერიოზულ შეზღუდვად იქცევა; სავარაუდო ორსაათიანი ზედნადები უნდა შემოწმდეს და არა ავტომატურად გადატანილი.

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

სიმულირებული ROI ფიქსირებულ გამომავალზე

სამართლიანი ღირებულების შედარებისთვის, შეადგინეთ ყოველკვირეული გამომუშავება ექვს მიღებულ ტესტური სცენარიზე თითო ინჟინერზე. საბაზისო ადამიანური დრო არის 18 საათი თითო ინჟინერზე. კანდიდატის ადამიანური დრო არის 9 საათი თითო ინჟინერზე პლუს 2 საათი თითო გუნდზე. გამოჯანმრთელების დრო უდრის 9 x ინჟინერს - კვირაში 2 საათს.

გამოიყენეთ ოთხკვირიანი დაგეგმვის პერიოდი და სავარაუდო დატვირთული სამუშაო ღირებულება 60 აშშ დოლარი საათში. მხოლოდ საილუსტრაციოდ, ვივარაუდოთ $400 ინსტრუმენტის ხარჯი და $50 დამატებითი შესრულების ხარჯი პერიოდზე. ეს არის ჰიპოთეტური მონაცემები და არა AnyTest ფასები. სიმძლავრის ღირებულება უდრის აღდგენილ საათებს x 60$. წმინდა მოდელირებული ღირებულება უდრის სიმძლავრის ღირებულებას - $450. მოდელირებული ROI უდრის წმინდა მოდელირებულ ღირებულებას / $450 x 100.

• 1 ინჟინერი: 24 ტესტური სცენარი; 28 გამოთავისუფლებული საათი; USD 1680 დროის ღირებულება; USD 1230 წმინდა მოდელირებული ღირებულება; 273% მოდელირებული ROI.
• 2 ინჟინერი: 48 ტესტური სცენარი; 64 გამოთავისუფლებული საათი; USD 3840 დროის ღირებულება; USD 3390 წმინდა მოდელირებული ღირებულება; 753% მოდელირებული ROI.
• 3 ინჟინერი: 72 ტესტური სცენარი; 100 გამოთავისუფლებული საათი; USD 6000 დროის ღირებულება; USD 5550 წმინდა მოდელირებული ღირებულება; 1233% მოდელირებული ROI.
• 5 ინჟინერი: 120 ტესტური სცენარი; 172 გამოთავისუფლებული საათი; USD 10320 დროის ღირებულება; USD 9870 წმინდა მოდელირებული ღირებულება; 2193% მოდელირებული ROI.

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

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

გააკეთეთ მოდელი წარუმატებელი, სანამ მას ენდობით

ერთი ინჟინრისთვის, რომელიც ახორციელებს ექვს ტესტური სცენარის კვირაში, გაზარდეთ კანდიდატის განხილვის დრო 0.50-დან 1.25 საათამდე. კანდიდატი ახლა ღირს 2,25 საათი მგზავრობისთვის, პლუს ორი საერთო საათი: 15,5 საათი 18 საბაზისო ღირებულების წინააღმდეგ. კვირაში მხოლოდ 2.5 საათი აღდგება, 600 დოლარი ღირს ოთხი კვირის განმავლობაში. სავარაუდო $450 ხარჯის შემდეგ, წმინდა მოდელირებული ღირებულება არის $150 და ROI არის 33%.

თუ განხილვას სჭირდება 2.0 საათი ტესტური სცენარისთვის, კანდიდატი მიაღწევს 3.0 საათს მგზავრობისთვის, პლუს ზედნადები: 20 საათი 18 საბაზისო ხაზის წინააღმდეგ. ის უფრო მეტ დროს ხარჯავს ადამიანისათვის. უფრო რთულმა სცენარებმა, უფრო მაღალმა მოვლა-პატრონობამ ან ცუდმა ნახაზებმა შეიძლება წაშალოს საქმე. ეს მგრძნობელობის ტესტი არის ის, თუ რატომ უნდა მოითხოვოს უფროსმა გაზომილი პილოტი, ვიდრე დაეთანხმოს ხელსაყრელ სცენარს.

[DORA-ის 2024 წლის კვლევა] (https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf) იუწყება, რომ AI-თან დაკავშირებული მიღწევები ინდივიდუალურ სამუშაოში ავტომატურად არ ითარგმნება პროგრამული უზრუნველყოფის მიწოდების უკეთეს შესრულებაში. მისი გამოკითხვის ასოციაციები არ არის AnyTest ნიშნული და არ შეუძლია ამ გუნდის შედეგის პროგნოზირება. სასარგებლო გაკვეთილი არის მიწოდების სისტემის გაზომვა და არა მონახაზის მოცულობის აღნიშვნა.

QA ინჟინრის წინადადება უფროსს

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

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

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