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

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

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

● ტესტირების გეგმა (Test plan)

● ტესტ-ქეისები
● ჩეკ-ლისტები
● ბაგ-რეპორტი
● ტესტირების რეპორტი
● Requirements Traceability Matrix

● ამოცანა
● დიზაინი
 Testing Documentation
Test Plan

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

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

სატესტო გეგმას ქმნის ან მენეჯერი, მიდლ ან უფროსი ტესტერი, ან ტესტერების გუნდის ხელმძღვანელი.
 Testing Documentation
მაგ: Test Plan მოიცავს შემდეგ პუნქტებს:
● შესავალი (პროექტის მოკლე აღწერა, რა სახის პროგრამული უზრუნველყოფა არის გასატესტი: ვებპროექტი,
მობილური აპლიკაცია, დესკტოპ აპლიკაცია, ვებ-სერვისი …
● როდის დაიწყება / დასრულდება ტესტირების პროცესი (entry/exit criteria)
● სად ვტესტავთ? (რომელ დივაისებზე, რომელ ბრაუზერებში, რომელ სერვერებზე…)
● ფუნქციონალი, რომლის ტესტირებასაც არ იგეგმება
● ტესტირების მიდგომები (Test approaches) - აქ შედის ის მეთოდები და ტექნიკები, რომლის დახმარებითაც
ვგეგმავთ ტესტირების შესრულებას.
● ტესტირებისთვის საჭირო ხელსაწყოები, პროგრამები (მაგ წვდომის გახსნა არსებულ მონაცემთა ბაზებზე )
● Test deliverables, ანუ ის დოკუმენტები, რომლებსაც დამკვეთს გადავცემთ ტესტირების დასრულების
შემდეგ (Test summary report, Requirements traceability matrix (RTM)
● Risks - შესაძლოა დადგეს მრავალი სახის რისკი, რაც თავის მხრივ ხელს უშლოს ხარისხიანი პროგრამული
პროდუქტის შექმნას. შესაბამისად, უნდა ვეცადოთ რისკების განსაზღვრა თუნდაც მინიმალურ დონეზე.
Test Plan
 რისკების განსაზღვრა ტესტირებაში

1. თუ ტესტირების პროცესი იწყება გვიან და ტესტერი თავიდანვე არ არის ჩართული პროექტში

2. თუ პროგრამისტი ვერ ჩაეტევა მისთვის გამოყოფილ ვადებში, გამოდის რომ ტესტირებისთვის შედარებით
ნაკლები დრო დაგვრჩება
3. თუ ცვლილებები მოხდება ახალი ვერსიის გაშვებამდე ცოტა ხნით ადრე, შესაძლოა ამან გამოიწვიოს
ხარვეზები, რომელთა აღმოჩენა, გასწორება, re-testing და regression testing ვერ მოესწროს დროულად
4. თუ ტესტირების გუნდში არ გვყავს საკმარისი რაოდენობის თანამშრომლები ან მათი კვალიფიკაცია არ არის
შესაბამისი დონის
5. თუ ტესტერებს და გუნდის სხვა წევრებს შორის არის დაძაბული, არასაკმარისი ან არასწორიკომუნიკაცია.
მაგალითად, როდესაც დაძაბული ურთიერთობა ყალიბდება ტესტერებს და პროგრამისტებს შორის
 რისთვის და ვისთვისაა საჭირო Test Plan

1. პირველ რიგში ეს სჭირდება ტესტერების გუნდს, რადგან თითოეულმა ტესტერმა იცოდეს პროგრამული
უზრუნველყოფის რა ნაწილი უნდა გატესტოს, ტესტირების რა მეთოდები უნდა გამოიყენოს და რა ვადებში
უნდა ჩაეტიოს.
2. Test Plan -ის შექმნის დროს გვიჩნდება ბევრი კითხვა, რაც გვეხმარება საბოლოო პროდუქტის მიზნების
უკეთ გაგებაში.
3. Test Plan ასევე სჭირდება პროექტ მენეჯერს, დამკვეთს და ზოგადად ბიზნესს, რადგან ქონდეთ ზუსტი
წარმოდგენა თუ რა, როგორ, ვის მიერ და როდის იქნება გატესტილი.
 Test summary report

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

Test summary report მოიცავს შემდეგი სახის ინფორმაციას:

1. სულ რამდენი test case ან check list არის შექმნილი
2. Test case -ბის ან check list -ის რა პროცენტი არის executed
3. Test case -ბის ან check list -ის რა პროცენტი არის passed და failed
4. ტესტირების დროს სულ რამდენი ხარვეზი იქნა აღმოჩენილი
5. რა პრიორიტეტების იყო აღმოჩენილი ხარვეზები (high, medium, low)
6. რამდენი ხარვეზი გასწორდა და რამდენი ხარვეზი არის ჯერ კიდევ გასასწორებელი
 Requirements Traceability Matrix (RTM)

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

RTM მატრიცა აუცილებლად მოიცავს შესაბამისობას

1. ფუნქციონალის დასახელებას და
2. ტესტ ქეისების ნომრებს შორის, რომელთა მეშვეობით მოხდა ამ ფუნქციონალის გატესტვა
Requirements Traceability Matrix (RTM)
 დიზაინის ტესტირება
➢ დიზაინის ტესტირება შეიძლება მოგვიწიოს იმ კუთხით, რომ შევამოწმოთ დიზაინერის მიერ
შექმნილი დიზაინი ამოცანის მიხედვით
➢ და შექმნილი პროგრამული პროდუქტის ტესტირება დიზაინის მიხედვით.

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

1. Figma
2. Adobe XD
3. Sketch
4. Framer X
5. Adobe XD

ტესტერს გახსნილი აქვს დიზაინის დოკუმენტი და მზა პროგრამული პროდუქტი და ადარებს რამდენად
ემთხვევა ისინი ერთმანეთს (ზომები, განლაგება, ფერები ...)
 დიზაინის ტესტირება
ასე გამოიყურება ფიგმაში აწყობილი დიზაინი და რეალური ვებ-გვერდი:
 დიზაინის ტესტირება
ასე გამოიყურება XD-ში აწყობილი დიზაინი :
 Independent Testing
გარკვეული დონით დამოუკიდებლობა, ტესტერს უფრო მოქნილს და ეფექტურს ხდის ხარვეზების პოვნაში.
დამოუკიდებელი ტესტირების ხარისხი განისაზღვრება შემდეგნაირად: (დაბალი დონიდან მაღალ დონემდე).
1. როცა დეველოპერი ტესტავს თავის კოდს.
2. როცა დეველოპერები ან ტესტერები ტესტავენ კოლეგების პროდუქტს.
3. ტესტირების ჯგუფები ორგანიზაციიდან, რომლებიც წარუდგენენ ტესტ რეპორტს პროექტის მენეჯერს.
4. დამოუკიდებელი ტესტირები, დასპეციალიზირებულები usability, security, performance, portability
ტესტირებაში.
5. დამოუკიდებელი ტესტერები, რომლებიც მუშაობენ ორგანიზაციის გარეთ, ან მუშაობენ working on-site (in-
house) ან off-site (outsourcing).
 ტესტ მენეჯერის და ტესტერის ამოცანები (ტასკები)
ტესტ მენეჯერის მოვალეობაში შესაძლოა შედიოდეს:

1. ორგანიზაციისთვის ტესტირების სტრატეგიის განვითარება კონტექსტის გათვალისწინებით.

2. რისკების და მიზნების გაანალიზება, ტესტირების მეთოდის შერჩევა, ტესტირების დროის და
ღირებილიბის განსაზღვრა, რესურსების მოძიება.
3. ტესტირების გეგმის შედგენა, განახლება.
4. ტესტირების გეგმის შეთანხმება PM თან და PO სთან.
5. ტესტირების პერსპექტივების და პროექტის აქტივობების შეთავსება, დაგეგმვა, რომ კვეთაში არ მოვიდეს
სხვა პროექტთან.
6. ტესტირების პროგრესის და შედეგების მონიტორინგი,ტესტირების დასრულებისათვის სხვადასხვა
აქტივობების ზედამხედველობა.
7. ტესტირების პროგრესის შემაჯამებელი რეპორტის მომზადება და მიწოდება (წარდგენა).
8. დეფექტების მენეჯმენტის სისტემის შექმნის უზრუნველყოფა.
9. ტესტირების პროგრესის განმსაზღვრელი საშუალების დანერგვა.
10. სატესტო გარემოს შერჩევა.
11. ტესტირების ჯგუფის ხელშეწყობა, ტესტერების უნარების აღმჩენა, განვითარება (ტრენინგები, ქოუჩინგი)
 ტესტ მენეჯერის და ტესტერის ამოცანები (ტასკები)

ტესტერის მოვალეობები:

1. ტესტირების გეგმის მიმოხილვა და დაგეგმვის დროს ჩართულობა, მონაწილეობა.

2. მოთხოვნების user stories, acceptance criteria, სპეციფიკაციების, ტესტირების მოდელების გაანალიზება
და შეფასება.
3. ტესტირების პირობების განსაზღვრა და დოკუმენტირება.
4. ტესტ ქეისების შესრულების მიმდევრობის განსაზღვრა.
5. სატესტო მონაცემების (data) მომზადება.
6. ხარვეზების დოკუმენტირება.
7. ტესტირების ხელშემწყობისთვის შესაბამისი თულების გამოყენება.
8. არაფუნქციონალური მახასიათებლების შეფასება, როგორიცაა: performance efficiency, reliability,
usability, security, compatibility, and portability
9. სხვა ტესტერის მიერ ჩატარებული ტესტირების მიმოხილვა.
 Thanks!

CREDITS: This presentation template was created by

Slidesgo, including icons by Flaticon and infographics &
images by Freepik