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

5.1 მიმოხილვა და მიზანი

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

არცერთი რელიზი, განახლება ან ვერსიის ამაღლება (როგორც ეს განსაზღვრულია თავი 1, §1.4-ში) არ გადაიტანება საწარმოო გარემოში აქ აღწერილი ტესტირების სასიცოცხლო ციკლის წარმატებით დასრულების გარეშე.

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

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

5.2 მოქმედების სფერო

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

• (a) რელიზები/განახლებები (v11.xx) — კლიენტისთვის სპეციფიკური ინკრემენტული ცვლილებები, რომლებიც მიეწოდება 3-დღიანი Agile სპრინტებით (§4.7).
• (b) ვერსიის ამაღლებები (v11 → v12) — ძირითადი ვერსიის, მთელ პროდუქტზე მოქმედი ცვლილებები, რომლებიც მიეწოდება დაახლოებით წელიწადში ერთხელ (§4.8).
• (c) კონფიგურაციის ცვლილებები — მოდულების აქტივაცია, სამუშაო პროცესების მორგება, ანგარიშების შაბლონები, როლებისა და უფლებების კორექტირება.
• (d) მონაცემთა მიგრაციის არტეფაქტები — იმპორტის ტრანსფორმაციები, ETL სკრიპტები, სქემის მიგრაციის პატჩები.
• (e) ინტეგრაციის ინტერფეისები — API ბოლო წერტილები, webhook დამმუშავებლები, მესამე მხარის კონექტორების ადაპტერები.
• (f) ინფრასტრუქტურული ცვლილებები — მონაცემთა ბაზის ძრავის განახლებები, შუალედური პროგრამული უზრუნველყოფის (middleware) ვერსიების ამაღლება, TLS სერტიფიკატების როტაცია.

SQT ჩარჩო მოიცავს როგორც მიმწოდებლის შიდა ტესტირებას (§5.4–§5.7), რომელიც ტარდება კლიენტის UAT-მდე, ისე კლიენტის უნივერსალურ სამომხმარებლო მიღების ტესტირებას (§5.8), რომელიც წარმოადგენს საწარმოო გარემოსთვის მზადყოფნის ოფიციალურ კონტროლის წერტილს.

5.3 AI-ით გაძლიერებული ტესტირების ჩარჩო

5.3.1 არქიტექტურის მიმოხილვა

მიმწოდებელი იყენებს სპეციალურად შექმნილ AI ტესტირების პლატფორმას, რომელიც სამი ძირითადი ფენისგან შედგება:

5.3.2 AI სატესტო აგენტები

თითოეული კლიენტის ProjectVIEW ERP-ის ინსტანციას უკავშირდება ერთი ან მეტი ინდივიდუალური AI სატესტო აგენტი, რომელიც კონფიგურირებულია კლიენტის შემდეგი ასპექტების დარგობრივი ცოდნით:

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

AI აგენტების ვერსიები იმართება აპლიკაციის კოდის ბაზასთან ერთად, მიმწოდებლის Git-ის განშტოების სტრატეგიის გამოყენებით (Master → Client → Working განშტოებები, §4.7.2), რაც უზრუნველყოფს, რომ სატესტო კონფიგურაციები ვითარდებოდეს იმ პროგრამულ უზრუნველყოფასთან სინქრონულად, რომელსაც ისინი ამოწმებენ.

5.3.3 უსაფრთხო API ინტეგრაცია

უსაფრთხო API ინტეგრაციის ფენა უზრუნველყოფს სტრუქტურირებულ საკომუნიკაციო ფენას AI სატესტო აგენტებსა და ProjectVIEW ERP-ს შორის და შესაძლებელს ხდის:

• (a) API-ის გამოძახება: აგენტები იძახებენ ProjectVIEW-ის REST/GraphQL API-ებს ჩანაწერების შესაქმნელად, წასაკითხად, განსაახლებლად და წასაშლელად, რითაც ახდენენ მომხმარებლის რეალური ტრანზაქციების სიმულაციას UI-ზე დამოკიდებულების გარეშე.
• (b) მონაცემთა ბაზის შემოწმება: მხოლოდ წაკითხვის უფლებით წვდომა კლიენტის Dev/Sandbox მონაცემთა ბაზაზე, ტრანზაქციის შემდეგ მონაცემთა მთლიანობის შეზღუდვების, რეფერენციული თანმიმდევრულობისა და გამოთვლილი ველების შესამოწმებლად.
• (c) UI ავტომატიზაციის მისაბმელები: როდესაც ბიზნეს-ლოგიკა მჭიდროდაა დაკავშირებული ფრონტ-ენდთან (მაგ., ველების პირობითი ხილვადობა, ფორმების დინამიკური ვალიდაცია), ინტეგრაციის ფენა აგენტის ინსტრუქციებს გადასცემს უინტერფეისო (headless) ბრაუზერის მეშვეობით, რომელიც ზუსტად ასახავს ProjectVIEW-ის UI-ს.
• (d) მოვლენების აღრიცხვა: აგენტსა და ERP-ს შორის ყველა ინტერაქცია აღირიცხება ცვლილებისგან დაცულ აუდიტის კვალში, მათ შორის მოთხოვნების შიგთავსი, პასუხის კოდები, დროითი მაჩვენებლები და შემოწმების შედეგები.

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

5.4 ტესტირების მეთოდოლოგია

5.4.1 ტესტირების დონეები

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

5.4.2 სატესტო გარემოები

მიმწოდებლის მხარეს ტესტირება (L1–L4) სრულდება მხოლოდ კლიენტისთვის გამოყოფილ Dev/Sandbox გარემოში (§2.3.1). ეს გარემო:

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

ექსპლუატაციაში გაშვების შემდეგ Dev/Sandbox გარემო გადადის Staging (წინასაწარმოო) როლში (§2.3.2), ინარჩუნებს ზემოთ ჩამოთვლილ ყველა თვისებას და დამატებით კლიენტისთვის UAT გარემოს ფუნქციას ასრულებს.

5.5 მონაცემთა ნაკადების სრული ციკლის სიმულაცია

5.5.1 სიმულაციის მიზნები

AI აგენტები ახდენენ რეალისტური, სრული ციკლის მონაცემთა ნაკადების სიმულაციას, რომლებიც ProjectVIEW ERP-ში ბიზნეს-ტრანზაქციის მთელ სასიცოცხლო ციკლს მოიცავს. მიზნებია:

• (a) დადასტურდეს, რომ ერთ მოდულში შექმნილი მონაცემები სწორად გადაეცემა, გარდაიქმნება და ხელმისაწვდომია ყველა მომდევნო მოდულში.
• (b) დადასტურდეს, რომ ბიზნეს-წესები (დამტკიცებების ჯაჭვები, შეტყობინებები, გაანგარიშებები) ყოველ ეტაპზე სწორად ამოქმედდება.
• (c) შემოწმდეს, რომ მომხმარებლების ერთდროული ქმედებები არ იწვევს რბოლის მდგომარეობებს (race conditions), ურთიერთბლოკირებებს (deadlocks) ან მონაცემთა დაზიანებას.
• (d) გაიზომოს ტრანზაქციების დაყოვნება და გამტარუნარიანობა განსაზღვრულ SLO ზღვრებთან მიმართებით (§3.3).

5.5.2 სიმულაციის სცენარები

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

5.5.3 მონაცემთა საწყისი შევსება და სცენარის შესრულება

ყოველი სიმულაციური გაშვების წინ AI აგენტები ავტონომიურად:

• (a) ქმნიან წინაპირობით მონაცემებს: ქმნიან ძირითად ჩანაწერებს (პროექტები, მომწოდებლები, მომხმარებლები, ხარჯების კოდები), რომლებიც საჭიროა შესამოწმებელი სცენარის შემავალ მონაცემებად.
• (b) ასრულებენ ტრანზაქციების ჯაჭვს: უსაფრთხო API ინტეგრაციის ფენის მეშვეობით იძახებენ ProjectVIEW-ის API-ებს, რათა ბიზნეს-პროცესის თითოეული ნაბიჯი სწორი თანმიმდევრობით, რეალისტური მონაცემებითა და დროითი ინტერვალებით შეასრულონ.
• (c) ამოწმებენ ყოველ საკონტროლო წერტილს: ყოველი ნაბიჯის შემდეგ აგენტი მიმართავს მონაცემთა ბაზას და/ან API-ს, რათა დაადასტუროს, რომ მოსალოდნელი მდგომარეობის ცვლილება მოხდა (ჩანაწერი შეიქმნა/განახლდა, სამუშაო პროცესი გადავიდა შემდეგ ეტაპზე, შეტყობინება გაიგზავნა).
• (d) აფიქსირებენ მტკიცებულებებს: ყოველი API გამოძახება, მონაცემთა ბაზის მოთხოვნა, შემოწმების შედეგი და დროითი გაზომვა აღირიცხება ცვლილებისგან დაცულ სატესტო მტკიცებულებების საცავში, რომელიც დაკავშირებულია განთავსების ტიკეტთან.
• (e) ასუფთავებენ გარემოს: დასრულების შემდეგ აგენტი სნეპშოტის/აღდგენის შესაძლებლობით აბრუნებს გარემოს საბაზისო მდგომარეობაში, რაც უზრუნველყოფს, რომ სატესტო არტეფაქტებმა მომდევნო გაშვებები არ დააბინძუროს.

5.6 მომხმარებლის ინტერაქციის სიმულაცია

5.6.1 მიზანი

თუ API-ს დონის ტესტირება (§5.5) ამოწმებს სერვერულ (backend) ლოგიკას, მომხმარებლის ინტერაქციის სიმულაცია ადასტურებს, რომ ProjectVIEW-ის სამომხმარებლო ინტერფეისი სწორად ფუნქციონირებს ადამიანი მომხმარებლების მიერ მისი გამოყენებისას. AI აგენტები იმეორებენ მომხმარებლის რეალისტურ ინტერაქციებს, მათ შორის:

• ფორმების შევსებას ვალიდური, არავალიდური და ზღვრული მნიშვნელობების მონაცემებით.
  • ნავიგაციას მრავალეტაპიან სამუშაო პროცესებში (ოსტატები, დამტკიცების ჯაჭვები, დოკუმენტების ატვირთვის თანმიმდევრობები).
  • როლებზე დაფუძნებული წვდომის უზრუნველყოფას — აგენტები შეისხამებენ სხვადასხვა როლის/უფლებების მქონე მომხმარებლებს, რათა დაადასტურონ, რომ UI ელემენტები სწორად ჩანს/იმალება, აქტიურდება/იბლოკება.
  • ადაპტურ ქცევას — ტესტირება დესკტოპისა და პლანშეტის ეკრანის ზომებზე განლაგების მთლიანობის დასადასტურებლად.
  • ხელმისაწვდომობის შესაბამისობას — იმის შემოწმება, რომ კლავიატურით ნავიგაცია, ARIA ატრიბუტები და კონტრასტის თანფარდობები შეესაბამება WCAG 2.1 AA მოთხოვნებს.

5.6.2 ინტერაქციის სცენარები

მომხმარებლის ინტერაქციის სიმულაციები აგებულია პერსონაზე დაფუძნებული სატესტო სკრიპტების გარშემო:

5.6.3 დეფექტების კლასიფიკაცია

მომხმარებლის ინტერაქციის სიმულაციისას გამოვლენილი დეფექტები კლასიფიცირდება იმავე სიმძიმის ტაქსონომიით, რომელიც გამოიყენება საოპერაციო ინციდენტებისთვის (§4.3):

5.7 მონაცემთა მთლიანობის ვალიდაცია

5.7.1 მოქმედების სფერო

მონაცემთა მთლიანობა ვალიდირდება სამ დონეზე ყოველი სატესტო გაშვების შემდეგ და განთავსების ნებისმიერი გადატანამდე:

5.7.2 მთლიანობის შემოწმებები

AI აგენტი ყოველი სიმულაციური სცენარის დასრულებისას ასრულებს მთლიანობის შემდეგ შემოწმებებს:

(a) ობლივი ჩანაწერების არარსებობა: SELECT მოთხოვნები ყველა საკავშირო და შვილიბილ ცხრილში ადასტურებს, რომ არცერთი ჩანაწერი არ მიუთითებს არარსებულ მშობელ ჩანაწერზე. (b) ბალანსის გადამოწმება: ფინანსური მოდულებისთვის — თითოეულ ხარჯთა ცენტრში დებეტის ჯამი უდრის კრედიტის ჯამს; ბიუჯეტის აღებული ვალდებულებები + ფაქტიური + დარჩენილი უდრის ბიუჯეტის ჯამს. (c) თანმიმდევრობის მთლიანობა: ავტომატურად დანომრილი თანმიმდევრობები (დოკუმენტების ნომრები, ტრანზაქციების ID-ები) არ შეიცავს წყვეტებს და დუბლიკატებს. (d) კონკურენტული წვდომის უსაფრთხოება: აგენტის პარალელური ნაკადები, რომლებიც ერთმანეთთან წინააღმდეგ განახლებებს ასრულებენ, იძლევიან დეტერმინირებულ, სწორ შედეგებს ოპტიმისტური ბლოკირების (optimistic locking) შესაბამისი რეაქციებით. (e) შენახული მონაცემების დაშიფვრა: მგრძნობიარე ველები (პერსონალური მონაცემები (PII), ფინანსური მონაცემები) მონაცემთა ბაზაში ინახება დაშიფრული სახით; ღია ტექსტი ხელმისაწვდომია მხოლოდ აპლიკაციის გაშიფვრის ფენის მეშვეობით.

5.7.3 მონაცემთა მთლიანობის ანგარიში

ყოველი სატესტო ციკლი აყალიბებს მონაცემთა მთლიანობის ავტომატურ ანგარიშს, რომელიც შეიცავს:

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

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

5.8 უნივერსალური სამომხმარებლო მიღების ტესტირება (UAT)

5.8.1 UAT-ის წინაპირობები

მიმწოდებელი არ მოიწვევს კლიენტს UAT-ის დასაწყებად, სანამ არ შესრულდება შემდეგი წინაპირობები:

• (a) ყველა L1–L4 სატესტო დონე დასრულებულია და გაუქმებელი P1/P2 დეფექტი არ არსებობს.
• (b) მონაცემთა მთლიანობის ანგარიში (§5.7.3) აჩვენებს შემოწმებების 100%-იან წარმატებას.
• (c) კლიენტის Staging გარემო განახლებულია კანდიდატ ბილდით.
• (d) სატესტო შემთხვევების შაბლონები, სატესტო მონაცემები და მომხმარებლის საარსებო მონაცემები მომზადებული და გადაცემულია კლიენტის მიერ დანიშნული UAT-ის ხელმძღვანელისთვის.

5.8.2 UAT-ის ჩატარება

UAT-ს ატარებენ კლიენტის დანიშნული წარმომადგენლები Staging გარემოში. მიმწოდებელი ვალდებულია:

• წარმოადგინოს კლიენტის ბიზნეს-პროცესებთან შესაბამისი სტრუქტურირებული სატესტო შემთხვევების შაბლონები.
  • მოამზადოს რეალისტური სატესტო მონაცემები, რომლებიც ასახავს საწარმოო სცენარებს პერსონალური მონაცემების გამჟღავნების გარეშე.
  • UAT-ის პერიოდში უზრუნველყოს მომსახურების სამსახურის (Service Desk) ხელმისაწვდომობა დეფექტების რეგისტრაციისთვის, ტრიაჟისთვის და გადაწყვეტისთვის.
  • დანიშნოს მიმწოდებლის გამოყოფილი QA სპეციალისტი UAT-ის საკონტაქტო პირად, რომელიც ხელმისაწვდომია რეალურ დროში მხარდაჭერისთვის საერთო WhatsApp Business ჯგუფის (§4.4) და ჩაშენებული ტიკეტების სისტემის (§4.1) მეშვეობით.

5.8.3 UAT-ის დადასტურება

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

თუ კლიენტი UAT-ის დაწყების თარიღიდან ათი (10) სამუშაო დღის განმავლობაში არ წარადგენს დადასტურებას ან უარს, მიმწოდებელი გააგზავნის წერილობით შეხსენებას. თუ პასუხი არ იქნება მიღებული დამატებითი ხუთი (5) სამუშაო დღის განმავლობაში, რელიზი ჩაითვლება კლიენტის მიერ მიღებულად.

5.8.4 UAT-ის დეფექტების მართვა

UAT-ის დროს გამოვლენილი დეფექტები იმართება ჩაშენებული ტიკეტების სისტემის (§4.1) მეშვეობით და კლასიფიცირდება §5.6.3-ში მოცემული სიმძიმის ტაქსონომიის შესაბამისად. გამოიყენება შემდეგი წესები:

• P1/P2 დეფექტები: ბლოკავს UAT-ის დადასტურებას. მიმწოდებელი ვალდებულია გამოასწოროს და ხელახლა წარადგინოს შეხებული ფუნქციონალი მიმდინარე სპრინტის ციკლის ფარგლებში.
  • P3 დეფექტები: არ ბლოკავს დადასტურებას. მიმწოდებელი გამოასწორებს მომდევნო სპრინტში და კლიენტს დაუდასტურებს გადაწყვეტას.
  • P4 დეფექტები: აღირიცხება დავალებების რიგში (backlog). გამოსწორება იგეგმება რესურსების ხელმისაწვდომობისა და კლიენტის მიერ მითითებული პრიორიტეტების მიხედვით.

5.9 პროცესების ოპტიმიზაციის საკონსულტაციო მომსახურება

5.9.1 მიმოხილვა

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

5.9.2 მიგნებების გენერირება

ტესტირების შესრულებისას AI აგენტები უწყვეტად აღრიცხავენ და ანალიზებენ:

• (a) ტრანზაქციების დაყოვნების კანონზომიერებებს: სამუშაო პროცესის იმ ნაბიჯების გამოვლენა, რომლებიც სისტემატურად დამუშავების შეუსაბამოდ დიდ დროს მოიხმარებენ, რაც ბიზნეს-წესებში ან მონაცემებზე წვდომის სქემებში შესაძლო ვიწრო ადგილებზე მიუთითებს.
• (b) გამონაკლისების სიხშირეს: ვალიდაციის ჩავარდნების, ბიზნეს-წესების მიერ უარყოფისა და დამტკიცების უარების კატალოგიზაცია პროცესებში ხახუნის წერტილების გამოსავლენად, რომლებიც შესაძლოა მიუთითებდნენ არასწორად კონფიგურირებულ წესებს ან მომხმარებლისთვის ბუნდოვან მითითებებს.
• (c) მონაცემთა ხარისხის ანომალიებს: არასრული ჩანაწერების, ნაგულისხმევი მნიშვნელობების ზედმეტი გამოყენების ან მონაცემთა შეტანის სისტემური შეცდომების კანონზომიერებების გამოვლენა, რომლებიც ფორმების ხელახლა დიზაინის ან სავალდებულო ველების კორექტირების საჭიროებაზე მიუთითებს.
• (d) უფლებების კონფლიქტებს: როლის/უფლებების იმ კომბინაციების გამოვლენა, რომლებიც ქმნიან ზედმეტ დამტკიცების შეფერხებებს ან, პირიქით, მოვალეობების გამიჯვნის ხარვეზებს.
• (e) ნაკლებად გამოყენებულ ფუნქციებს: იმ აქტივირებული მოდულების ან ფუნქციების მონიშვნა, რომლებიც კონფიგურირებულია, მაგრამ რეალისტურ სატესტო სცენარებში არ გამოიყენება, რაც შესაძლო სატრენინგო ხარვეზებზე ან ზედმეტ სალიცენზიო ხარჯებზე მიუთითებს.

5.9.3 რეკომენდაციების წარდგენა

პროცესების ოპტიმიზაციის რეკომენდაციები:

• ერთიანდება: პროცესების ოპტიმიზაციის სტრუქტურირებულ ანგარიშში ყოველი ძირითადი სატესტო ციკლის (სპრინტის რელიზის ან ვერსიის ამაღლების) შემდეგ.
  • კლასიფიცირდება: გავლენის (მაღალი/საშუალო/დაბალი), ძალისხმევის (კონფიგურაციის ცვლილება, მცირე დეველოპმენტი, მნიშვნელოვანი დეველოპმენტი) და რისკის (რისკის გარეშე, დაბალი რისკი, საჭიროებს UAT-ს) მიხედვით.
  • წარდგენილია: კლიენტისთვის მომსახურების კვარტალური მიმოხილვის (§3.9) დროს მომსახურების მიწოდების მენეჯერის მიერ.
  • კონტროლდება: როგორც სამოქმედო პუნქტები მომსახურების უწყვეტი გაუმჯობესების (CSI) რეესტრში (§4.10) შეთანხმებული ვადებითა და პასუხისმგებლებით.

5.9.4 მოქმედების შეზღუდვები

პროცესების ოპტიმიზაციის საკონსულტაციო მომსახურება გაწეულია საინფორმაციო საფუძველზე. ნებისმიერი რეკომენდაციის დანერგვა წარმოადგენს კონფიგურაციის ცვლილებას ან დეველოპმენტის მოთხოვნას, რომელიც რეგულირდება ცვლილებების მართვისა და სპრინტების დაგეგმვის შესაბამისი პროცესებით (§4.6, §4.7). მიმწოდებელი არ დანერგავს ოპტიმიზაციულ ცვლილებებს კლიენტის თანხმობისა და, საჭიროების შემთხვევაში, ფარგლების ცვლილების ოფიციალური მოთხოვნის (§2.7) გარეშე.

5.10 ტესტირების მართვა და ანგარიშგება

5.10.1 ტესტირების მტკიცებულებების საცავი

მიმწოდებელი თითოეული კლიენტისთვის აწარმოებს ტესტირების მტკიცებულებების ცენტრალიზებულ, ცვლილებისგან დაცულ საცავს, რომელიც შეიცავს:

• ტესტირების გეგმებს და სატესტო შემთხვევების სპეციფიკაციებს თითოეული განთავსებისთვის.
• AI აგენტების შესრულების ჟურნალებს (API ინტერაქციების სრული კვალი, დროის შტამპები, შემოწმების შედეგები).
• მონაცემთა მთლიანობის ანგარიშებს (§5.7.3).
• პროცესების ოპტიმიზაციის ანგარიშებს (§5.9.3).
• UAT მტკიცებულებების პაკეტებს (სატესტო შემთხვევების შედეგები, დეფექტების ჟურნალები, დადასტურების დოკუმენტები).
• რეგრესიული ნაკრების ევოლუციის ისტორიას (დამატებული/შეცვლილი/გაუქმებული სატესტო შემთხვევები).

ტესტირების მტკიცებულებები ინახება ჩარჩოს მოქმედების ვადის განმავლობაში და დამატებით თორმეტი (12) თვის განმავლობაში, ან მონაცემთა დაცვის შესაბამისი რეგულაციით (GDPR, მუხლი 5(1)(e); არაბთა გაერთიანებული საქართვოს PDPL, მუხლი 5) განსაზღვრული ვადით, იმის მიხედვით, თუ რომელი უფრო ხანგრძლივია.

5.10.2 ხარისხის მეტრიკები

მიმწოდებელი ადევნებს თვალს და ანგარიშს წარუდგენს ხარისხის შემდეგ მეტრიკებზე, რომლებიც შედის მომსახურების კვარტალურ მიმოხილვაში (§3.9):

5.10.3 უწყვეტი გაუმჯობესება

SQT ჩარჩო უწყვეტად უმჯობესდება დემინგის ციკლის (დაგეგმვა-შესრულება-შემოწმება-ქმედება) შესაბამისად:

• (a) დაგეგმვა: ტესტირების სტრატეგია და AI აგენტების კონფიგურაციები ისინჯება და ახლდება ყოველი კვარტლის დასაწყისში ხარისხის მეტრიკების ტენდენციებისა და კლიენტის უკუკავშირის საფუძველზე.
• (b) შესრულება: განახლებული სატესტო ნაკრები და აგენტების კონფიგურაციები ინერგება კლიენტის Staging გარემოში.
• (c) შემოწმება: ხარისხის მეტრიკები (§5.10.2) ფასდება სამიზნე მნიშვნელობებთან მიმართებით; სამიზნე მნიშვნელობის ყოველი ვერ მიღწევის შემთხვევაში ტარდება ძირეული მიზეზის ანალიზი.
• (d) ქმედება: მაკორექტირებელი და პრევენციული ქმედებები აღირიცხება CSI რეესტრში (§4.10) და სრულდება მომდევნო სპრინტების ციკლებში.

5.11 უსაფრთხოება და შესაბამისობა

5.11.1 სატესტო მონაცემების დაცვა

SQT პროცესში გამოყენებული ყველა სატესტო მონაცემი ექვემდებარება წინამდებარე ჩარჩოს მონაცემთა დაცვის ვალდებულებებს (თავი [მონაცემთა დაცვა — მომავალი თავის მითითება]). კერძოდ:

• საწარმოო მონაცემები ანონიმიზდება ან ფსევდონიმიზდება არასაწარმოო გარემოებში გამოყენებამდე, GDPR-ის 89(1) მუხლისა და არაბთა გაერთიანებული საქართვოს PDPL-ის მე-5 მუხლის შესაბამისად.
• AI აგენტები არ ინახავენ კლიენტის მონაცემებს სატესტო სესიის მიღმა. AI სატესტო აგენტების მიერ დამუშავებული ყველა მონაცემი დროებითია და იშლება სესიის დასრულებისათანავე.
• API ტოკენები შეზღუდულია მინიმალურად საჭირო უფლებებით, აქვთ შეზღუდული ვადა და ავტომატურად უქმდება სესიის დასრულებისას.
• ტესტირების მტკიცებულებების ჟურნალები დაშიფრულია შენახვისას (AES-256) და გადაცემისას (TLS 1.3).

5.11.2 აგენტების მართვა

მიმწოდებლის მიერ SQT ჩარჩოში AI აგენტების გამოყენება რეგულირდება:

• ევროკავშირის AI აქტთან შესაბამისობით: პროგრამული უზრუნველყოფის ტესტირებისთვის გამოყენებული AI აგენტები ევროკავშირის AI აქტის (რეგულაცია (EU) 2024/1689) შესაბამისად კლასიფიცირდება მინიმალური რისკის მქონედ, ვინაიდან ისინი მუშაობენ არასაწარმოო მონაცემებზე კონტროლირებად გარემოში და არ იღებენ ავტონომიურ გადაწყვეტილებებს, რომლებიც გავლენას ახდენს ფიზიკურ პირებზე.
• NIST AI RMF: მიმწოდებლის AI ტესტირების მეთოდოლოგია შეესაბამება NIST-ის AI რისკების მართვის ჩარჩოს (AI RMF 1.0) პრინციპებს — ვალიდურობას, საიმედოობასა და ანგარიშვალდებელობას.
• ადამიანის ზედამხედველობა: AI აგენტები მუშაობენ ადამიანის ზედამხედველობით. ყველა სატესტო შედეგი, ოპტიმიზაციის რეკომენდაცია და განთავსების გადაწყვეტილება ქმედებამდე საჭიროებს ადამიანის მიერ განხილვასა და დამტკიცებას.
• გამჭვირვალობა: მიმწოდებელი კლიენტის მოთხოვნისამებრ წარუდგენს AI აგენტების კონფიგურაციების, გადაწყვეტილებების ლოგიკისა და ინტერაქციების ჟურნალების დოკუმენტაციას ნებისმიერი სატესტო ციკლისთვის.

ევროკავშირის AI აქტი — რეგულაცია (EU) 2024/1689 NIST-ის AI რისკების მართვის ჩარჩო 1.0

5.12 პროცესების რეესტრი

5.12.1 პროცესების რეესტრი

5.12.2 RACI მატრიცა

R = შემსრულებელი | A = პასუხისმგებელი | C = კონსულტანტი | I = ინფორმირებული

5.12.3 პროცესის ნაკადი — პროგრამული უზრუნველყოფის ხარისხისა და ტესტირების სასიცოცხლო ციკლი