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

1 გაკვეთილი
მე ვარ დარეჯან უსანეთაშვილი

▸GeoSTQB-ის წევრი უნივერსიტეტებთან ურთიერთობის

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

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

გვაწვდის ინფორმაციას ამ ყველაფრის შესახებ.

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

კომპიუტერში, ტელევიზორში, ბრაუზერში …

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

▸ადამიანებს (თვითმფრინავის, სამედიცინო აპარატურის გაუმართავად მუშაობა)

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

რადიაციული თერაპიის აპარატი Therac-25

- რადიაციის ორმაგი დოზა:

1985-1987 წლებში კანადაში რადიაციის აპარატი Therac-25

გახდა მინიმუმ 6 ადამიანის გადაჭარბებული დოზით
დასხვების და 2 ადამიანის გარდაცვალების მიზეზი.

მაშინ როდესაც სტანდარტული დასხივების მაქსიმალური

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

თუ პროგრაის ინტერფეისში თერაპიის ტიპის მონაცემებს

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

მიზეზი იყო აპარატის პროგრამული გაუმართაობა (კერძოდ

უსაფრთხოების არასწორი სტრატეგია).
მსოფლიოში ყველაზე ცნობილი
ხარვეზების მაგალითები:

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

ათასწლეულის პრობლემა Y2K:

Y2K ასევე ცნობილია, როგორც ‘’2000 წლის პრობლემა’’.

პროგრამისტები ხშირად წლების აღსანიშნავად იყენებდნენ

ორ ციფრს ოთხის ნაცვლად, მაგ: 1994 წლის 4 აპრილს
წერდნენ, როგორ ‘’07.04.94’’. ამით ვითომ ბაზაში ნაკლებ
მეხსიერებას იკავებდნენ.

მაგრამ 2000 წლის 1 იანვარს მთელ მსოფლიოში დაიწყო

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

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

შეუსაბამიც კი გვხვდება, მაგ:

· Quality assurance manager

· Quality control manager
· Software tester
· Test engineer
· Manual tester
· ტესტერი
· ხარისხის უზრუნველყოფის სპეციალისტი და ა.შ
 პროფესია ტესტერი
მაგრამ მოვალეობებს თუ გადავხედავთ, თითქმის ერთნაირი მოთხოვნებია და შეგვიძლია ძირითადად რამდენიმე
როლად დავაჯგუფოდ:
რა უნარები უნდა ჰქონდეს ტესტერს
 ტესტერის როლი კომპანიაში და მოვალეობები

● ამოცანის და დიზაინის გარჩევა / გაანალიზება

● ამოცანის და დიზაინის მიხედვით ტესტ ქეისების მოფიქრება და შექმნა
● პროექტის შინაარსიდან გამომდინარე ტესტირების მეთოდების და ტექნიკების შერჩევა
● სატესტო მონაცემების შექმნა და შეგროვება (test data)
● უშუალოდ პროგრამული პროდუქტის ტესტირება სხვადასხვა ოპერაციულ სისტემებზე, ბრაუზერებში და
მოწყობილობებზე
● ტესტირების დროს აღმოჩენილი ხარვეზების აღწერა
● გასწორებული ხარვეზების კიდევ ერთხელ შემოწმება (re-testing)
● რეგრესიული ტესტირების განხორციელება (regression testing)
● პროდუქტის დანერგვის შემდეგ რეალურ გარემოზე ტესტირება
● საჭიროების შემთხვევაში რეპორტების მომზადება
● გუნდის სხვა წევრებთან ხშირი და მჭიდრო კომუნიკაცია
● სხვადასხვა შეხვედრებზე დასწრება და ასე შემდეგ
 რა არის ტესტირება

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

საშუალებას გვაძლევს მივაღწიოთ პროდუქტის სასურველ ხარისხს და შევამციროთ რეალურ
გარემოში მისი გაუმართავად მუშაობის რისკი (Software testing is a way to assess the quality of
the software and to reduce the risk of software failure in operation).

ტესტირების განმარტება გლოსარიდან:

The process consisting of all lifecycle activities, both static and dynamic, concerned with planning,
preparation and evaluation of a component or system and related work products to determine
that they satisfy specified requirements, to demonstrate that they are fit for purpose and to
detect defects.
 ვერიფიკაცია და ვალიდაცია

ტესტირება შედგება 2 ნაწილისგან: ვერიფიკაცია და ვალიდაცია.

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

(Confirmation by examination and through provision of objective evidence that specified requirements have
been fulfilled.)

ვალიდაცია, ეს არის ტესტირების პროცესი, როდესაც ხდება შემოწმება იმისა, თუ რამდენად აკმაყოფილებს ის
მომხმარებლის სურვილებს, საჭიროებებს და მოთხოვნებს (user vishes, needs and expectations).

(Confirmation by examination and through provision of objective evidence that the requirements for a
specific intended use or application have been fulfilled.)
 ვერიფიკაცია და ვალიდაცია

სიტყვა ვალიდაცია არ უნდა აგვერიოს

ვალიდაციის მესიჯში, მაგალითად პაროლის
ველში, რომ არასწორად შეგვყავს მონაცემები
და წითელი ტექსტი გამოდის შეტყობინებით
‘პაროლი უნდა შედგებოდეს...’
 ტესტირების მიზნები (Objectives of Testing )
● To prevent defects by evaluate work products such as requirements, user stories, design,
and code.

დეფექტების პრევენცია ტესტირებისთვის საჭირო პროდუქტების (work products) ადრეულ ეტაპზე

ტესტირებით ან გამოცდილების მიხედვით (lessons learned). work product-ებია მაგ: ამოცანა, დიზაინი,
პროგრამული პროდუქტის კოდი...

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

Work products - ეს არის მუშაობის შედეგი. მაგ: ანალიტიკოსისთვის ეს არის მოთხოვნები ნებისმიერ
ფორმატში, დეველოპერისთვის - კოდი, ტესტერისთვის - ტესტირების სტრატეგის, ტესტ-ქეისები, ჩეკ-
ლისტები, ავტოტესტები, ბაგ რეპორტი.
 ტესტირების მიზნები (Objectives of Testing )
● To verify whether all specified requirements have been fulfilled

ვერიფიკაცია, ანუ შემოწმება იმისა, რომ ყველა სპეციფიური მოთხოვნა არის შესრულებული.

● To check whether the test object is complete and validate if it works as the users and other
stakeholders expect

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

მოლოდინებს

● To build confidence in the level of quality of the test object

დავრწმუნდეთ პროგრამული პროდუქტის ხარისხში.
ეს ერთ-ერთი ყველაზე კარგი განმარტებაა იმისა, თუ რისთვის გვჭირდება ტესტირება და ტესტერი
კომანიაში, ანუ , რომ შეიქმნას ხარისხიანი პროდუქტი.
 ტესტირების მიზნები (Objectives of Testing )
● To find defects and failures thus reduce the level of risk of inadequate software quality
დეფექტების ძებნა , იმისთვის რომ შევამციროთ გაუმართავად მუშაობის რისკები.
მაგალითად, იმისათვის, რომ ვთქვათ პროდუქტი მზადაა თუ არა, ან რამდენად არ არის მზად რელიზისთვის,
უნდა მოვძებნოთ მასში ხარვეზები.

● To provide sufficient information to stakeholders to allow them to make informed decisions,

especially regarding the level of quality of the test object

· სტეიკჰოლდერებს(დამკვეთებს) მივაწოდოთ საკმარისი ინფორმაცია პროდუქტის ხარისხთან დაკავშირებით,

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

● To comply with contractual, legal, or regulatory requirements or standards, and/or to verify

the test object’s compliance with such requirements or standards

· პროდუქტი უნდა აკმაყოფილებდეს სახელშეკრულებო, იურიდიულ ან მარეგულირებლის მიერ დადგენილ

მოთხოვნებს და სტანდარტებს
 Testing and Debugging

ტესტირება და დებაგინგი განსხვავდება ერთმანეთისგან.

Debugging is the development activity that finds, analyzes, and fixes such defects.

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

თუმცა, ISTQB გვეუბენბა რომ ტესტერი შესაძლოა ჩართული იყოს დებაგინგის პროცესში, ანუ
ხარვეზის გასწორების პროცესში და ასევე component testing -ში, მაგრამ თუ გამოცდაში შეგვხვდება
კითხვა, სადაც ერთი-ერთი პასუხი იქნება რომ ტესტერს თუ შეუძლია გააკეთოს დებაგინგი? სწორი
პასუხია არა, რადგან ISTQB -ის მიხედვით ტესტერი არ ახორციელებს აღმოჩენილი ხარვეზების
გასწორებას (fix), რომელიც დებაგინგის განმარტებაში შედის.
 Quality Assurance and Testing
QA და Testing ერთი და იგივე არ არის, თუმცა ორივე
ერთმანთან დაკავშირებულია ხარისხის მენეჯმენტის
ფარგლებში (Quality management).

QA (Quality Assurance)-ის მიზანია:

● უზრუნველყოს პროცესების მაღალი ხარისხი პროგრამული

პროდუქტის შექმნის ყოველ ეტაპზე, ეს თავის მხრივ ხელს
უწყობს ხარვეზების პრევენციას;
● ახდენს ხარვეზების პრევენციას წინა პროექტებში მიღებული
ცოდნის გამოყენებით (გარკვეულწილად გავს
რეტროსპექტივას);
● იკვლევს და აანალიზებს ხარვეზების გამომწვევ მიზეზებს
(root cause analysis);
 QA, QC, Testing

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

Testing კი არის უშუალოდ ტესტირების ეტაპი, როდესაც უკვე მზა ტესტ ქეისების ან ჩექ ლისტის
მიხედვით ვტესტავთ პროგრამულ პროდუქტს, ანუ ვახორცეიელბთ test execution -ს.
 ტესტირების 7 პრინციპი
1. Testing shows the presence of defects, not their absence

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

2. Exhaustive testing is impossible

ამომწურავი ტესტირება შეუძლებელია. (All combinations of inputs and preconditions)

პირველი და მეორე პრინციპის მიხედვთ შეგვიძლია ვთქვათ, რომ პროგრამულ პროდუქტში ყოველთვის
არსებობს დეფექქტები.
მაგ: ვებ-გვერდების ტესტირებისას გასატესტი შემთხვევებია: ყველანაირი ბრაუზერი, ბრაუზერების ვერსიები,
ამას დავამატოთ სხვადასხვა გარემო და წინაპირობა. ეს სრულიად წარმოუდგენელია.
მაგ: შესაძლოა გასატესტი იყოს ველი, რომელშიც დასაშვებია ლათინური ანბანის ყველა ასო, სპეციალური
სიმბოლოები და ციფრები 1-1000 ჩათვლით. წაარმოიდგინეთ ამომწურავი ტესტირება რომ ჩავატაროთ
რამდენი კომბინაციის სხვადასხვა შემავალი პარამეტრი შეიძლება არსებობდეს, ამ ყველა კომბინაციის
ტესტირება რა თქმა უნდა შეუძლებელია.
 ტესტირების 7 პრინციპი
3. Early testing saves time and money
ადრეული ტესტირება ზოგავს დროს და თანხებს.
ვიცით, რომ არსებობს დინამიური და სტატიკური ტესტირება, სტატიკური ტესტირება ეს არის არა მარტო კოდის
ტესტირება, არამედ ასევე მოთხოვნების ტესტირება კოდის დაწერამდე. და თუ ასე ადრე ტესტირების დროს მოთხოვნებში
აღმოვაჩენთ შეუსაბამობას ან წინააღმდეგობას, ვაზუსტებთ და ცვლილება შსეგვაქვს დოკუმენტაციაში , ასეთი დეფექტები
არ ხვდება კოდში და ეს გაცილებით იაფია, რადგან არ გვჭირდება კოდის ხელმეორედ გადაწერა, რეგრესიული ტესტირება
და ა.შ.

აქვე შეგვიძლია განვიხილოთ კითხვა, როდის უნდა დავიწყოთ

ტესტირება? როგორც კი მოთხოვნები მზად იქნება, უკვე
საჭიროა ტესტერის ჩართვა პროცესში. ამ ეტაპზე შესაძლებელია
გაიტესტოს მოთხოვნების დოკუმენტები, სპეციფიკაციები ან
ნებისმიერი სახის დოკუმენტები. თუ რაიმე ხარვეზს ან
შეუსაბამობას აღმოვაჩენთ, უმჯობესია დაუყოვნებლივ
გადაიჭრას, ვიდრე შემდეგ დეველოპმენტის პროცესში.
 ტესტირების 7 პრინციპი
4. Defects cluster together

დეფექტები არსებობენ ჯგუფურად. არსებობს ასეთი

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

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

ტესტირებისას, რომ გვხვდება დუბლირებული დეფექტები,
ვიზუალურად ტესტერისთვის შეიძლება სხადასხვაგვარად
გამოიყურებოდეს, მაგრამ დებაგის შემდეგ დეველოპერმა
შეიძლება მას დუბლირებულის სტატუსი მიანიჭის, რადგან
ერთი და იგივე მეთოდს იყენებდეს ეს ორი განსხვავებული
ბაგ რეპორტი.
 ტესტირების 7 პრინციპი
5. Beware of the pesticide paradox

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

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

მაგ: ტესტირებაში არის ასეთი გაგება ‘ტესტებთან შეჩვევა’. განსაუთრებით ეს ეხება რეგრესიულ და
დეტალურ ტესტ-ქეისებს. თუ ჩვენ ვწერთ დეტალურ ტესტ-ქეისებს (არა ჩეკ-ლისტებს) და ვუთითებთ
კონკრეტულ სატესტო მონაცემებს, თქვენს პროდუქტს დაემართება სწორედ პესტიციდ პარადოქსი. Ეს
ნიშნავს, რომ ამ ტესტებით პროდუქტის გატესტვისას, ვეღარ აღმოაჩენთ ხოლმე ხარვეზებს.

ამიტომ რეგულარულად უნდა მოხდეს ახალი Test Case -ბის დამატება, რათა შევძლოთ იმ ხარვეზების
გამოვლენა, რომლებიც ვერ აღმოაჩინა არსებულმა Test Case -ბმა. ასევე კარგია high-level test-case ების
წერაც.
 ტესტირების 7 პრინციპი
6. Testing is context dependent
დამკვეთის მოთხოვნების საფუძველზე და პროგრამული უზრუნველყოფის შინაარსიდან გამომდინარე უნდა
მოხდეს საჭირო და მნიშნვნელოვანი ტესტირების მეთოდების და ტექნიკების შერჩევა და გამოყენება,
მაგალითად:
ინფორმაცილუი სახის ვებ საიტი, სადაც მხოლოდ ტექსტი, ფოტო და ვიდეო არის განთავსებული სხვა
მიდგომებით და მეთოდებით უნდა გაიტესტოს ვიდრე ელექტრონული კომერციის საიტი, საიდანაც
მომხმარებელს შეუძლია შეიძინოს ნივთი სხვადასხვა საბანკო ბარათების გამოყენებით.
ფინანსურ აპლიკაციებს სჭირდებათ მაღალი დონის და ხშირი უსაფრთხოების ტესტირება ვიდრე მარტივ
ინფორმაციულ საიტებს, სადაც განთავსებულია მაგალითად კომპანიის საქმიანობა, განხორციელებული
პროექტები, ინფორმაცია თანამშრომლებზე, კომპანიის მისამართი და ასე შემდეგ.
ასევე შიდა მოხმარების პროდუქტებს არ სჭირდებათ ტესტირება სხვადასხვა ბრაუზერებში, საჯარო საიტისგან
განსხვავებით

7. Absence-of-errors is a fallacy (მცდარია წარმოდგენა ხარვეზების არარსებობის შესახებ)

თუ თქვენ ჩაატარეთ ვერიფიკავიის პროცესი და გატესტეთ პროდუქტი მოთხოვნების მიხედვით და ვეღარ

პოულობთ ხარვეზებს, ეს არ ნიშნავს იმას, რომ ეს პროდუქტი აკმაყოფილებს მომხმარებლის მოთხოვნებს.
 Human Psychology and Testing
როდესაც ხარვეზს ვპოულობთ სტატიკური (static) ან დინამიური (dynamic) ტესტირების დროს ეს
შეიძლება აღიქვან როგორც პროდუქტის ან ავტორის კრიტიკად, ამიტომ უკეთესია თუ ვიტყვით, რომ
ჩვენ გვაქვს პრობლემა, ან რომელიღაც მოდულს აქვს პრობლემა და არა კონკრეტული დეველოპერის
მიერ შექმნილ მოდულს აქვს პრობლემა.

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

გუნდის წევრებმა ერთმანეთს უნდა შევახსენოთ ხოლმე, რომ ჩვენ გვაქვს საერთო მიზანი - პროდუქტის
ხარისხი და არა იმის დამტკიცება , თუ ვინ არის მართალი.
 Tester’s and Developer’s Mindsets
A tester’s mindset should include:

●Curiosity - არ უნდა ასვენებდეს ცნობისმოყვარეობა, უნდა აინტერესებდეს დეტალები, შეეძლოს

კითხვების დასმა …
●professional pessimism
●a critical eye
●attention detail
●a motivation for good and positive communications and relationships.

A developer’s mindset may include:

some of the elements of a tester’s mindset, but successful developers are often more interested in designing
and building solutions than in contemplating what might be wrong with those solutions.
 დავალება
1. ნებისმიერი მობილური აპლიკაცია ან ვებ-გვერდი გატესტეთ ვალიდაციის
კუთხით, ანუ გადაამოწმეთ რამდენად მოსახერხებელი, ადვილად გამოსაყენებელი
და თქვენს საჭიროებებზე მორგებულია ეს ვებ გვერდი.

2. რაიმე ხარვეზებს თუ აღმოაჩენთ, ჩაინიშნეთ და ერთად გავივლით, მომავალ

ექციებზე დაგვჭირდება.

3. გთხოვთ დარეგისტრირდით ვებ-გვერდზე https://qase.io/

4. https://www.youtube.com/watch?v=Ct-lOOUqmyY

5. https://www.youtube.com/watch?v=BKorP55Aqvg
 მადლობა
ყურადღებისთვის
კითხვები