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

4 გაკვეთილი
 ტესტირების პროცესის სასიცოცხლო ციკლი
(Software Testing Life Cycle)

ტესტირების პროცესი შედგება შემდეგი ეტაპებისგან:

★ Test planning
★ Test Monitoring and Control
★ Test analysis
★ Test design
★ Test implementation
★ Test execution
★ Test completion
 Test planning
Test Planning - ტესტირების დაგეგმვა მოიცავს ისეთ აქტივობებს, რომლებიც განსაზღვრავს ტესტირების
მიზნებს და ტესტების შესრულების მიდგომებს.
პირველ შეხვედრებზე, როდესაც ჯერ კიდევ არ არის ცნობილი პროდუქტის დეტალები თუ რის გაკეთებას
ვგეგმავთ ზუსტად და მიმდინარეობს მსჯელობა, განხილვა და იდებიის ანალიზი, სწორედ ამ დროს ხდება
ტესტირების გეგმის მონახაზის შექმნაც. ეს მონახაზი შეიძლება შეიქმნას მენეჯმენტის მიერ და ამ ეტაპზე არ
არის სავალდებულო ტესტერის ჩართვა.
ტესტირების გეგმის გადახედვა და განახლება პერიოდულად ხდება მონიტორინგის და კონტროლის
შეფასებების შედეგად.

ტესტირების დაგეგმვა შეიძლება მოიცავდეს შემდეგ აქტივობებს:

★ ტესტირების მაშტაბის, მიზნების და რისკების განსაზღვრა.
★ ტესტირების მიდგომების განსაზღვრა.
★ ტესტირების აქტივობების ინტეგრაცია და კოორდინაცია პროგრამულ უზრუნველყოფაში.
★ გადაწყვეტილების მიღება რა უნდა გაიტესტოს, რესურსების განსაზღვრა სხვადასხვა
აქტივობებისთვის.
★ ტესტირების აქტივობების განსახორციელებლად ვადების გაწერა ( f test analysis, design,
implementation, execution, and evaluation activities )
★ ტესტირების მონიტორინგისთვის და კონტროლის განმსაზღვრელი თულის შერჩევა.
★ Ტესტირების აქტივობებისთვის ბიუჯეტის განსაზღვრა.
★ entry and exit criteria-ს განსაზღვრა.
 Test planning
Entry criteria - ყოველი ტესტირების ეტაპისთვის იმის განსაზღვრა, თუ როდის უნდა დავიწყოთ ამ ფაზის
ტესტირება . (ეჯაილ დეველოპმენტში ეწოდება definition of ready ).
Entry criteria:
★ ამოცანა, დიზაინი, წვდომები, სატესტო დივაისები, პროგრამები, ტესტ-ქეისები,
★ სატესტო გარემოებზე წვდომა.
★ სატესტო იარაღები (Tools)
★ სატესტო მონაცემები (test data), რომელიც პროგრამული პროდუქტის შინაარსიდან გამომდინარე
სხვადასხვა სახის არის. სატესტო მონაცემები შეიძლება იყოს საკრედიტო ბარათები, მობილურის
ნომრები, პასპორტები, ფოტოები, ვიდეოები ...)

Exit criteria - ანუ რა მდგომარეობას უნდა მივაღწიოთ იმისთვის, რომ დავასრულოთ ტესტირება. ( ეჯაილ
დეველოპმენტში ეწოდება definition of done ).
Exit criteria:
★ დაგეგმილი ტესტ ქეისების განხორციელება.
★ წინასწარ განსაზღვრულ დონემდე დაფარული requirements, user stories, acceptance criteria, risks,
code.
★ გადაუჭრელი დეფექტების რაოდენობა, უნდა შეესაბამებოდეს განსაზღვრულ რაოდენობას.
★ სავარაუდოდ დარჩენილი დეფექტების რაოდენობა უნდა იყოს დაბალი.
★ ხარისხის მაჩვენებელი დონეები (reliability, usability, security, )უნდა იყოს დამაკმაყოფილებელი.
★ ბიუჯეტი ან ბაზარზე გასვლის ვადა ამოიწურა.
 Test monitoring and control
Test monitoring and control, იწყება test planning -ის შემდეგ და გრძელდება ტესტირების პროცესის
ბოლომდე, სანამ არ დასრულდება პროდუქტზე მუშაობა.

Monitoring - მონიტორინგის ეტპაზე ხდება მიმდინარე შედეგის მუდმივი შედარება დაგეგმილ

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

Control - იღებს ინფორმაციას მიმდინარე სიტუაციის შესახებ monitoring -სგან. მაგალითად, რა გაიტსტა,
რა მუშაობას, რა არ მუშაობს, კიდევ რა სამუშაოები არის დარჩენილი, როდის მივაღწევთ exit criteria -ს
და ამ ინფორმაციის საფუძველზე იღებს გადაწყვეტილებებს. მაგალითად, გუნდში ამატებს ახალ წევრებს,
ან ამცირებს გასატესტ ფუნქციონალს, ამცირებს სატესტო დივაისებს / ბრაუზერებს, ზრდის
ტესტირებისთვის გამოყოფილ დროს და ასე შემდეგ.
კონტროლს უზრუნველყოფს ტესტირების გუნდის ხელმძღვანელი ან ტესტ მენეჯერი, რომელიც
აზუსტებს მიმდინარე სიტუაციას ტესტერთან და იღებს შემსაბამის გადაწყვეტილებებს.
 Test analysis
Test analysis - ეს არის ამოცანის და დიზაინის გაცნობა, გააზრება, კითხვების დასმა და ანალიზი.
ეს ეტაპი პასუხობს კითხვას ‘რა გავტესტოთ ?’ (what to test? )

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

★ამოცანა და დიზაინი რომ არ იყოს ბუნდოვანი,არასრული, გაურკვეველი და ორაზროვანი

★ამოცანა და დიზაინი რომ იყოს დეტალური და მაქსიმალურად გათვლილი იყოს ყველა შესაძლო
შემთხვევა
★ამოცანაში და დიზაინში რომ არის იყოს ურთიერთგამომრიცხავი მოთხოვნები
★განისაზღვროს რა გაიტესტოს
არასრული მოთხოვნების “კლიენტის საიდენტიფიკაციო მონაცემების” ფაბჯარა:
მაგალითი ● “პირადი ნომერი” - სავალდებულოდ შესავსები ველი;
● “გაიმეორეთ პირადი ნომერი” - ველი არის
სავალდებულოდ შესავსები და ივსება კლიენტის პირადი
ნომერი. იმ შემთხვევაში თუ შეყვანილი პირადი ნომერი
არ დაემთხვა კლიენტის პირად ნომერს, სისტემა
ვიზუალურად მიგვანიშნებს არავალიდურ
მნიშვნელობაზე შესაბაისი ტექსტით: “მნიშვნელობა არ
ემთხვევა. სცადეთ თავიდან!” (იხ. სურ. 15)
● “სახელი” - ველი ივსება ავტომატურად, თუ შეყვანილი
პირადი ნომრით ბანკის ბაზაში მოიძებნა კლიენტი. სხვა
შემთხვევაში ველს ხელით ავსებს CRM-ის მომხმარებელი.
ველის შევსება სავალდებულოა და შესძლებელია
მხოლოდ ქართული ტექსტის შეყვანა(სურ. 15);
● „გვარი“ - ველი ივსება ავტომატურად, თუ პირადი ნომრის
შეყვანის შემდეგ, ამ პირადი ნომრით ბანკის ბაზაში
მოიძებნა კლიენტი; სხვა შემთხვევაში ველს ხელით ავსებს
CRM-ის მომხმარებელი. ველის შევსება სავალდებულოა
და შესძლებელია მხოლოდ ქართული ტექსტის
შეყვანა(სურ. 16);
● „მობილური“-ველი განკუთვნილია კლიენტის მობილური
ტელეფონის ნომრისთვის (სურ. 16);
● X -ღილაკით იხურება „კლიენტის საიდენტიფიკაციო
მონაცემების“ ფანჯარა და CRM-ის მომხამრებელი
ბრუნდება იმ ინტერფეისზე, საიდანაც მოხდა „მარტივი
იდენტიფიკაციის“ ინიცირება;
● ღილაკი „შედმეგი“-ღილაკზე ზემოქმედებით სრულდება
მარტივი იდენტიფიკაცია, „კლიენტის საიდენტიფიკაციო
მონაცემების“ ფანჯარა იხურება და პროცესი გრძელდება
ბიზნეს პროცესით გათვალისწინებულ ბიჯზე.
 მოთხოვნების მაგალითი

რა კითხვების დასმა შეიძლება იდენტიფიკაციის ფანჯრის სრულყოფილად გასატესტად?

● პირადი ნომრის ფორმატი არ არის დაზუსტებული, მაგ მხოლოდ ციფრები თუ ასოებიც და

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

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

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

მაგ: მაქსიმუმ შესაძლებელი იყო სესხის თანხა ყოფილიყო 8000 ლარი.

iOS -ის დეველპერის გადაწყვეტა:

როგორც კი მომხმარებელმა შეიყვანა

მაქსიმუმზე მეტი თანხა და დააჭირა
ღილაკზე “შემდეგი”, გამოვიდა შესაბამისი
შეტყობინება
Android -ის დეველპერის გადაწყვეტა:

როგორც კი მომხმარებელმა შეიყვანა

მაქსიმუმზე მეტი თანხა, ღილაკს
“შემდეგი” შეეცვალა ფერი და ის აღარ
არის აქტიური, ანუ მას აღარ ეჭირება
ამოცანის და დიზაინის ტესტირება UX -ის კუთხით
მაგალითად, მომხმარებელი წერს პოსტს, აკრიფა საკმაოდ დიდი ტექსტი და შემთხვევით
დააჭირა დახურვის ან back ღილაკზე …

ასეთ დროს მომხმარებლის მიერ აკრეფილი ტექსტი არ უნდა დაიკარგოს და უნდა

ვკითხოთ ნადვილად სურს თუ არა პოცესის დასრულება.

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

დააზუსტოს შემდეგი დეტალები:
1. რომელი ველებია სავალდებულო
2. რა ზომის და ფორმატის ფაილების, ფოტოების და ვიდეობის ატვირთვა არის
შესაძლებელი
3. მომხმარებელმა რომ არ შეავსოს სავალდებულო ველები მაშინ რა ხდება ...
 Test design
Test design - ეს არის სატესტო იდეების მოფიქრების ეტაპი, ანუ რა ქეისებით გავტესტავთ პროგრამულ
პროდუქტს, როგორი სახის test data დაგვჭირდება …

ეს ეტაპი პასუხობს კითხვას ‘როგორ გავტესტოთ ?’ (How to test? )

● განვსაზღვრავთ: სატესო მონაცემებს, ტესტ-ქეისებს, სატესტო გარემოს, სატესტო ხელსაწყოებს,

ტესტირების ტექნიკებს
 Test implementation
Test implementation - ეს არის სატესტო იდეების განხორციელების/შექმნის ეტაპი, ანუ რა ქეისებით
გავტესტავთ პროგრამულ პროდუქტს, როგორი სახის test data დაგვჭირდება …

ეს ეტაპი პასუხობს კითხვას ‘ყველაფერი გვაქვს იმისთვის, რომ დავიწყოთ ტესტირება ?’ (do we now have
everything in place to run the tests? )

Test implementation მოიცავს შემდეგ აქტივობებს:

★ სატესტო გარემოს აწყობა და მომზადება

★ ტესტ ქეისების დაწერა
★ სატესტო მონაცემების შექმნა და მოგროვება
★ ავტომატიზირებული სკრიპტების დაწერა
★ სხვადასხვა test suite -ების შექმნა (smoke test suite, regression test suite, mobile test suite, web test
suite...)
 Test execution

Test execution - ეს არის უშუალოდ ტესტირების პროცესი, როდესაც ტესტ ქეისების მიხედვით
ვტესტავთ და ვანიჭებთ მას passed / failed. როდესაც ტესტ ქეისის სტატუსი არის failed, რა თქმა უნდა
ვქმნით შესაბამის ბაგ რეპორტს სისტემაში.

Test execution მოიცავს შემდეგ აქტივობებს:

★ ტესტების განხორციელება ან მანუალურად ან სპეციალური ხელსაწყოს საშუალებით
★ მიმდინარე შედეგის შედარება მოსალოდნელ შედეგთან
★ შეცდომის გაანალიზება და საწყისი მიზეზის დადგენა
★ ბაგ-რეპორტის შედგენა
★ დეფექტების ხელმეორედ გადამოწმება ( execution of a corrected test, confirmation testing, and/or
regression testing)
 Test completion

Test completion - ეს არის ეტაპი როდესაც ვემზადებით რელიზისთვის და არის code freeze -ს ეტაპი,
ანუ როდესაც კოდში არ შეგვაქვს ცვლილებები და არ ვასწორებთ ხარვეზებს. ეჯაილ პროექტებში ეს არის
იტერაციების დასრულების ეტაპი.

Test completion მოიცავს შემდეგ აქტივობებს:

★ დაუხურავი ბაგ-რეპორტების დამუშავება (დამკვეთთან ან მენეჯერთან შეთანხმებით ან გადადება, ან
ჩეინჯ-რექვესთეის ან მოთხოვნების ბექლოგში ახალი მოთხოვნების დარეგისტრირება )
★ Test summary report -ის მომზადება დამკვეთისთვის
★ სატესტო გარემოს მოწესრიგება შემდგომი გამოყენებისთვის
★ ტესტ-ქეისების დააფდეითება
★ Lesson learned გაანალიზება (ან რეტროსპექტივა ეჯაილ პროექტებში) , თუ რა წარიმართა
არასწორად, რომ შემდეგი ტესტირებისას გთვალისწნებული იყო და აღარ გავიმეოროთ.
 Software Development Lifecycle Models
Software Development Lifecycle (SDLC) არის ჩარჩო, რომელიც განსაზღვრავს სხვადასხვა აქტივობებს
პროგრამული უზრუნველყოფის შექმნის პროცესში და ამ აქტივობების ლოგიკურ და ქრონოლოგიურ კავშირს
ერთმანეთთან.

არსებობს SDLC-ის სხვადასხვა სახის მოდელები, სადაც აქტივობები

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

★ Requirements
★ Analysis
★ Architecture, Design
★ Development, Coding
★ Testing
★ Deployment
★ Maintenance
 Software Development Lifecycle Models
Requirements - ეს არის პირველი ეტაპი და ბიზნეს ანალიტიკოსი
აგროვებს აღმოცენებული იდეის შესახებ მოთხოვნებს
კლიენტისგან/დამკვეთისგან.
დამკვეთი შეიძლება იყოს კომანიის შიდა განყოფილების წევრი ან გარე პირი
(სხვა კომპანიიდან).

Analysis - მოთხოვნების მოგროვების შემდეგ ხდება მათი გაანალიზება და

პროდუქტის შესახებ მოთხოვნების დოკუმენტის შედგენა (ამოცანის
ჩამოყალიბება).
SRS (Software Requirement Specification) document.
 Software Development Lifecycle Models
System Design - ამ ეტაპზე სისტემური არქიტექტორის და უფროსი დეველოპერების მიერ ხდება
შესაქმნელი პროდუქტის შესახებ არქიტექტურის შემუშავება. ხდება იმის გაწერა, თუ როგორ უნდა
მუშაობდეს ყოველი მოდული და კომპონენტი.

მაგ: ქსელების, მნაცემთა ბაზების, აპლიკაციების, სისტემის ინტერფეისის, მომხმარებლის ინტერფეიის

სისტემური და პროგრამული დიზაინის მომზადება, ანუ რა ტექნოლოგიები იქნება გამოყენებული, რომელი
მონაცემთა ბაზა, რომელი პროგრამირების ენას გამოვიყენებთ…
Software Requirements Specifications (SRS ) დოკუმენტი გარდაიქმნება
‘Design specification’ დოკუმენტად.

არქიტექტურის ეტაპზე ვარკვევთ რისი საშუაებით მივიღოთ ის,

Ტაც გვჭირდება ( How to achieve what is needed? )
 Software Development Lifecycle Models
UI/UX Design - UX / UI დიზაინერი ეცნობა ამოცანას და ქმნის პროდუქტის დიზაინს.

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

გაუმართავი UI/UX საიტზე:

https://userinyerface.com/game.html

შეუსაბამო UI :
https://torontocupcake.com/resources.html

შეუსაბამო ფერები:
https://www.pennyjuice.com/childcare-juice-concentrates
 Software Development Lifecycle Models

Development - ეს ის ეტაპია, როდესაც იწყება კოდის წერა და პროდუქტის შექმნა არსებული

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

შედეგად ვიღებთ Source Code Document (SCD)-ს და პროგრამულ პროდუქტს.

 Software Development Lifecycle Models

Testing - ამ ეტაპზე ტესტერი იწყებს მიღებული ვერსიის (Build) ტესტირებას.

ამ ეტაპზე მოწმდება:
● პროდუქტი აკმაყოფილებს თუ არა ყველა მოთხონას (სპეციფიკაციებს),
● ხდება აღმოჩენილი ხარვეზების აღწერა და დაფიქსირება,
● ხდება ამ ხარვეზების გასწორება, დეველოპერი აწყობს ახალ build-ს და გადასცემს ტესტერს
ხელახლა გასატესტად (re-testing) , ანუ ყოველი აღმოჩენილი ხარვეზი გადის დეფექტების
სასიცოცხლო ციკლს.
 Software Development Lifecycle Models

Deployment - წარმატებული ტესტირების შემდეგ პროდუქტი გადაეცემა დამკვეთს.

● დამკვეთი სურვილის მიხედვით თავადაც ტესტავს პროგრამულ პროდუქტს , ეს არის user
acceptance testing.
● პროგრამული განახლება ძირითადად ხდება ხოლმე არასამუშაო საათებში (თუ არსებული
პროდუქტია და ცვლილებების შეტანაა საჭირო)
● სწორედ ეს ვერსიაა ის, რომელიც მიდის მოხმარებლებთან.
● თუ UAT დამაკმაყოფილებელია და დამკვეთი კმაყოფილია,
მაშინ ხდება პროდუქტის რელიზი (release/launch)
● თუ პროცესში დამკვეთი აღმოაჩენს მნიშვნელოვან ხარვეზებს,
მაშინ ვუბრუნდებით ხარვეზების გასწორების ეტაპზე და
ხელახლა ვაწყობთ ახალ ბილდს.
 Software Development Lifecycle Models

Maintenance - დამკვეთთან წინასწარი შეთანხმების შემთხვევაში, პროდუქტის რეალურ გარემოში

გაშვების შემდეგ კვლავ ხდება მხარდაჭერის გაწევა.
● ანუ რეალურ გარემოში იუზერების (მომხმარებლების) მიერ აღმოჩენილი ხარვეზების მხარდაჭერა.
● მომხმარებლები როდსაც იწყებენ პროდუქტის გამოყენებას, დროდადრო მცირე ცვლილებების
განხორციელება
● ამ მხარდაჭერისთვის ძირითადად არსებობს ხოლმე ცალკე
მხარდაჭერის გუნდი და helpdesk support system.
 Software Development and Software Testing
ტესტერმა უნდა იცოდეს პროგრამული უზრუნველყოფის შექმნის პროცესის სხვადასხვა მოდელების არსი.

რამდენიმე მიზეზი, რატომ არის ნიშვნელოვანი SDLC:

★ გვაძლევს პროექტის გეგმის სრულ ხედვას

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

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

ავირჩევთ, ტესტირების აქტივობები უნდა დაიწყოს სასიცოცხლო ციკლის საწყის ეტაპებზე, ადრეული
ტესტირების პრინციპიდან გამომდინარე.
Software Development and Software Testing

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

ტესტირების მახასიათებლები:

★ დეველოპმენტის ყოველი აქტივობისთვის არსებობს ტესტირების შესაბამისი აქტივობა

★ ტესტირების ყოველ test level-ს აქვს ამ დონისთვის მახასიათებელი ტესტირების მიზნები (test
objectives)
★ კონკრეტული test level-ის ტესტირების ანალიზი და დიზაინი იწყება დეველოპმენტის (შექმნის)
შესაბამისი აქტივობის სტადიაზე
★ ტესტერებმა უნდა მიიღონ მონაწილეობა მოთხოვნების განსაზღვრის და დახვეწის დისკუსიებში,
ასევე ჩართული იყვნენ სამუშაო პროდუქტების (მაგ.: მოთხოვნები, დიზაინი, მომხმარებლის
ისტორიები და ა.შ.) განხილვაში, როგორც კი ამ პროდუქტების (work products) სამუშაო ვერსია
იქნება მზად.
 Software Development Lifecycle Models
პროგრამული უზრუნველყოფის შექმნის სასიცოცხლო ციკლი სილაბუსის მიხედვით კლასიფიცირდება
შემდეგნაირად:

Sequential development models (პროგრამის შექმნის თანმიმდევრული მოდელები)

Iterative and incremental development models (პროგრამის შექმნის იტერაციული და ინკრემენტული
მოდელები)

იტერაციული - განმეორებითი
ინკრემენტული - თანდათანობითი,
ზრდადობითი
Software Development Lifecycle Models

Waterfall - თანმიმდევრული, კასკადური, ჩანჩქერისებური მოდელი, სადაც მთლიანი

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

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

უარყოფითი მხარეები:
● ცვლილების სურვლის შემთხვევაში არ შეგვიძლია უკან დაბრუნება (შესაძლებელია
მხოლოდ ერთი ფაზით წინ დაბრუნება).
● დამკვეთი საბოლოო პროდუქტს ნახულობს მხოლოდ ბოლოში და უკუკავშირს
გვახნობებს ამ ეტაპზე,
● ტესტერები ჩართული არიან მხოლოდ ბოლოსკენ ტესტირების ეტაპზე და არ ხდება
მოთხოვნების ტესტირება,
● დეველოპერები ქმნიან ბევრ დოკუმენტაციას და ფერხდება პროცესი.
Software Development Lifecycle Models

V-მოდელი - ასევე ცნობილია, როგორც ვრიფიკაციის და ვალიდაციის მოდელი (V&V),

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

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

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

Agile - შეიქმნა იტერაციული მოდელის საფუძველზე. ეს არც მეთოდი და

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

ეჯაილს მიეკუთვნება სხვადასხვა framework-ები (ჩარჩო):

● სკრამი
● კანბანი
● TDD (Test driven development)
● XP…
The Agile Manifesto - ღირებულებები
● Individuals and interactions over processes and tools - პიროვნებებსა და ურთიერთობებს
ვამჯობინებთ პროცესებსა და ინსტრუმენტებს.
(ანუ პირველი ღირებულება გვეუბნება იმას, რომ ურთიერთობები ადამიანებს შორის ძალიან
მნიშვნელოვნია. Agile გარემოში გუნდის წევრები ეხმარებიან ერთმანეთს, უზიარებენ
ცოდნას და გამოცდილებას. ურთიერთობაში ასევე იგულისხმება დამკვეთთან ხშირი
ურთიერთობა, პროდუქტის ეტაპობრივი წარდგენა, დამკვეთის უკუკავშირის (feedback)
მოსმენა და გათვალისწინება.).

● Working software over comprehensive documentation - მომუშავე პროგრამულ

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

● Customer collaboration over contract negotiation - დამკვეთთან თანამშრომლობას

ვამჯობინებთ კონტრაქტის პირობებს და შეთანხმებას.

● Responding to change over following a plan - ცვლილებაზე რეაგირებას ვამჯობინებთ

გეგმის ზედმიწევნით დაცვას.
 ეჯაილ ტესტირების პრინციპები
● ხარისხის უზრუნველყოფა და არა ხარისხის კონტროლი
● მუდმივი ტესტირება და არა დასასრულისს ტესტირების წარმოება
● ადრეული ფაზიდან ჩართულობა ტესტირების სახით და არადასასრულს
● ხარისხზე პასუხიმგებლობა გუნდზე და არა მხოლოდ ტესტირებაზე
● ხარისხზე პასუხიმგებლობა გუნდის ყველა წევრის მიერ და არა
დამოუკიდებელი ტესტირების გუნდის მიერ
● რეგრესიყლი ტესტირების ავტომატიზირება და არა მანუალურად წარმოება
● ტექნიკური და API ტესტირების წარმოება და არა უბრალოდ GUI
ტესტირება
● Exploratory ტესტირება და არა Scripted ტესტირება
● მომხმარებლის ისტორიების და საჭიროებების ანალიზი და არა
მოთხოვნის სპეციფიკაციაზე ფოკუსირება
● Agile testing მდგომარეობს იმაში რომ დავრწმუნდეთ პროგრამული
უზრუნველყოფა სწორად არის იქნება, ნაცვლად იმისა, რომ დავრწმუნდეთ
რამდენად ფუჭდება მაგ როგორიცაა Monkey ტესტირება
● მუდმივი უკუკავშირი და არა დაგეგმილი
● მეტად ზრუნვა ხარვეზების პრევენცია ვიდრე ხარვეზების აღმოჩენაზე
 Scrum

Scrum - ეს არის პროექტების მართვისთვის ფრეიმფორქი. ეს არის იტერაციულ-ინკრემენტული ჩარჩო (framework),

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

სკრამში გვაქვს :
Product backlog ეს არის დავალებების სია მთელი პროდუქტის შექმნისთვის და
Sprint backlog - ყოველი სპრინტისთვის ცალ-ცალკე.
ბექლოგი ძირითადად შედგება იუზერ სთორებისგან, ტასკებისგან.
ბექლოგზე პასუხისმგებელი არის პროდაქტ ოუნერი და ისვე ახორციელებს დავალებების პრიორიტიზაციასაც.
ყოველ დავალებას აქვს თავისი story point (სირთულის შეფასება).
Scrum
 Scrum
ამ პროცესის ყოველ მონაწილეს აქვს თავისი როლები (ყველა როლი
თანასწორია) :
● Product owner - პროდუქტის მფლობელი . ადამიანი,
რომელიც კარგად იცნობს კლიენტის მხარეს, იცნობს ბაზარს,
კლიენტთან აქვს ხშირი ურთიერთობა. იცის ბიზნესს რა სურს
და ეს დაკვეთა მოაქვს გუნდთან. პროდუქტის მფლობელი
მომხმარებლის სურვილებს აქცევს იუზერ სთორიებად
(მომხმარებლის ისტორიებად). იუზერ სთორის აქვს შემდეგი
ფორმულირება: “ მე როგორც იუზერს მინდა ეს …, რომ მივიღო
ეს …
● development team - ვინც მუშაობს პროექტზე
(დეველოპერები, დიზაინერები, ანალლიტიკოსი, ტესტერი … ).
მინიმუმ 3 და მაქსიმუმ 9 წევრისგან.
● Scrum-master - ვინც ზრუნავს, რომ სკრამის პრინციპები
დაცული იყოს. (ეს როლი შეიძლება მოირგოს პროექტ
მენეჯერმა, ან გუნდის რომელიმე წევრმა ან QA-მ ), ეხმარება
გუნდს დაბრკოლების გადალახვაში.
 Scrum
სკრამში არსებობს სხვადასხვა სახის შეხვედრები/ღონისძიებები:
● Sprint Planning - ტარდება სპრინტის დასაწყისში და განისაზღვრება სამუშაოს მოცულობა და სამუშაოს
შესრულების ხერხები. ამ შეხვედრას ესწრება მთელი გუნდი.
ამ შეხვედრაზე ისმება 3 კითხვა: რატომ, რა, როგორ? რატომ და რა-ზე პასუხს სცემს პროდაქტ ოუნერი, ხოლო
როგორ გაკეთდება, ამას ამბობს დეველოპერი.
დიდი ბექლოგის მიხედვით იქმნება სპრინტის ბექლოგი და ეს ბექლოგი არის უკვე დეველოპმენთ გუნდის.

● Stand-up (daily scrum)- მოკლე შეხვედრა, რომელიც ტარდება ყოველ დღე და მონაწილეობას იღებს გუნდის ყველა
წევრი.
გუნდის ყოველი წევრი პასუხობს 3 კითხვაზე: რა გავაკეთე? რას გავაკეთებ? რამე ხომ არ მაფერხებს?
გრძელდება დაახლოებით 15 წუთი.

● Sprint review - დამკვეთს ვუკეთებთ პრეზენტაციას და წარვუდგენთ ჩვენს მიერ მიღებულ ინკრემენტს, რომელიც
მივიღეთ სპრონტის ფარგლებში.

● Sprint retrospective - ტარდება სპრინტის ბოლოს. მისი არსი მდგომარეობს იმაში, რომ მოხდეს იდენტიფიცირება
რა წარიმართა სწორად და რა არის გასაუმჯობესებელი.
რესტროსპეაატივა გვეხმარება განვსაზღვროთ, რა მუშაობს (რომ გუნდი კონცენტრირდეს ამ ასპექტებზე), და რა არ
მუშაობს (დრო დაუთმონ , რომ გაუმჯობესების გზები მოიძებნოს).
 Scrum

Scrum Framework -ის შემთხვევაში პროექტი თანმიმდევრულად გადის ქვემოთ ჩამოთვლილ ეტაპეს:
• Product owner -ი ეტაპობრივად ამატებს ახალ მოთხოვნებს product backlog -ში და ახდენს მათ
პრიორიტეტიზაიას.
• Sprint planning -ზე, პრიორიტეტული მოთხოვნები product backlog -დან გადმოდის sprint backlog -
ში.
• Development team მუშაობს sprint backlog -ში არსებულ მოთხოვნებზე, მინიმუმ 1 და მაქსიმუმ 4
კვირის მანძილზე.
• Sprint review -ზე, ხდება მიღებული ინკრემენტის წარდგენა დამკვეთთან.

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

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

ასევე აქვს უარყოფითი მხარეებიც:

● რთულია საჭირო რესურსების და ბიუჯეტის შეფასება
 როდის გამოვიყენოთ Scrum framework

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

2. როდესაც დამკვეთს უნდა, რომ პროდუქტი გაეშვას რაც შეიძლება მალე, თუნდაც მინიმალური
ფუნქციონალით (Minimum Viable Product - MVP) და შემდეგ ყოველ 1 - 4 კვირაში მოხდეს მისი განვითარება
და ახალი ფუნქციონალის დამატება.

P.S კონკურენტულ გარემოში მნიშვნელოვანია, რომ პროდუქტი გაეშვას რაც შეიძლება მალე, რადგან ფრაზა“
„პირველები ვართ ბაზარზე“ ძალიან ღირებულია.