facebook    T: 598 944448 
1111 QA ტესტირების საფუძვლების თეორიულ-პრაქტიკული კურსის დაწყება დაგეგმილია 11 აპრილიდან. კურსი გრძელდება 1 თვის მანძილზე კვირაში 5 დღე, დღეში 2 საათიანი თეორიულ-პრაქტიკული მეცადინეობით და სულ 40 საათი ხანგრძლივობით. კურსი მოიცავს QA ტესტირების ყველა საბაზისო საკითხს რაც ვებსაიტების შემუშავებისთვის და ტესტირებისთვის არის საჭირო. მოგვწერეთ ფეისბუქის გვერდზე Frontend კერძო კურსები ასევე შეგიძლიათ ჩაერთოთ ფეისბუქის Manual ტესტირების ჯგუფში. Manual ტესტირება QA ტესტირების საფუძვლების თეორიულ-პრაქტიკული კურსის დაწყება დაგეგმილია 3 აპრილიდან.
კონსპექტები
QA ტესტირება,  FRONTEND პროგრამირება
კონსპექტები მოიცავს ყველა იმ საკითხს, რისი შესწავლაც მოხდება კურსებზე
ზოგიერთი საკითხის კონსპექტი შემუშავების პროცესშია
1. Manual ტესტირება 2. საიტების სრული ტესტირება 3. ტესტირების მეთოდოლოგიები 4. საიტის ელემენტების ტესტირება 5. საიტების კლასიფიკაცია 6. საიტის შემუშავება, ანალიტიკა 7. ტექნიკური დავალება, დოკუმენტაცია 8. საიტების სტრუქტურა და სტილები 9. საიტების დიზაინი და ინტერფეისი 10. ლენდინგ საიტის პრინციპები 11. HTML, CSS, JS პროგრამირება 12. markup კოდის პრინციპები 13. საიტების SEO ოპტიმიზაცია 14. ინსტრუმენტები - DevTools 15. ინსტრუმენტები - Figma 16. ინსტრუმენტები - Jira 17. ინსტრუმენტები - Trello, asana 18. ინსტრუმენტები - HTTP 19. ინსტრუმენტები - SQL 20. ინსტრუმენტები - GIT 21. ინსტრუმენტები - Zephyr, TestRail 22. ინსტრუმენტები - Selenium, Jmeter, Postman 23. ინსტრუმენტები - ზოგადი 24. მობილური აპლიკაციის ტესტირება 25. აგილე-სკრამ მეთოდოლოგიები 26. API ტესტირება
3.

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

 
                  Quality Control(QC) = ხარისხის კონტროლი, პროდუქტის ხარისხზე ორიენტირებული მიდგომა
  Quality Assurance(QA) = ხარისხის უზრუნველყოფა, ტესტირების ეფექტურ მეთოდებზე ორიენტირებული მიდგომა, გრძელვადიანი და სრული უზრუნველყოფა(შეიცავს QC-საც)
  ISTQB (International Software Testing Qualifications Board) = საერთაშორისო ორგანიზაცია, რომელიც მუშაობს QA სფეროს განვითარებაზე და ტესტირების სერტიფიცირებაზე

  ===== ტესტირების საკითხები =====

  -- რატომ არის საჭირო ტესტირება = ხარვეზები არის არამარტო შეცდომების გამო, არამედ  გაუთვალისწინებელი საკითხებისა და ლოგიკური შეუსაბამობების გამოც.
  -- განსხვავება ტესტერს, QC და QA შორის = ტესტერი მხოლოდ კონკრეტულ ტესტირებაზე მუშაობს, QC არის პროდუქტის ხარისხის კონტროლი, QA კი ხარისხის უზრუნველყოფაა პროდუქტის მთელი სასიცოცხლო ციკლის განმავლობაში.
  -- ტესტირების მიზანი = პროგრამული უზრუნველყოფისადმი წაყენებულ მოთხოვნებთან შესაბამისობის შემოწმება, შეცდომების აღმოფხვრა და ხარვეზების გასწორება. 
  -- დებაგინგი = პროგრამული ხარვეზების აღმოფხვრა 
  -- პოზიტიური ტესტირება = პროგრამული პროდუქტის მოთხოვნებთან შესაბამისობის დადასტურება კორექტული(სწორი) მონაცემებით
  -- ნეგატიური ტესტირება = პროგრამული პროდუქტის გამართული მუშაობის ტესტირება არასტანდარტული და გაუთვალისწინებელი მონაცემების შემთხვევებში. 
  -- დესტრუქციული ტესტირება = სტრესული ვითარების შექმნა, გადატვირთვა, უსაფრთხოების გარღვევა და ა.შ.
  -- სტატიკური ტესტირება = თეთრი ყუთის ტიპის ტესტირება, როცა ტესტირება ხდება პროგრამული კოდის გაშვების გარეშე, პროგრამული უზრუნველყოფის შექმნის ადრეულ ეტაპზე(ვერიფიკაციის ეტაპი)
  -- დინამიური ტესტირება = როცა ტესტირება ხდება კოდის გაშვებით/პროგრამის მუშაობისას(ფუნქციონალის ტესტირება, ვალიდაციის ეტაპზე).
  -- ხარვეზის სასიცოცხლო ციკლი = ხარვეზის დაფიქსირება-> გასწორება-> ხელმეორე გატესტვა-> დახურვა
  -- ხარვეზების პრიორიტეტები = მოგვარების რიგითობა, რამდენად სასწრაფო გადასაჭრელია
  -- ხარვეზების სერიოზულობა[вug severity]  = კრიტიკულობა, რამდენად სერიოზული ხარვეზია
  -- ტესტირების მონიტორინგი და კონტროლი = ტესტირების მიმდინარეობისას სტატისტიკისა და მეტრიკის წარმოება  
  -- SDLC მოდელები = პროგრამული პროდუქტის შემუშავების მოდელები. მთავარი ეტაპებია: 
  1. დაგეგმვა-ანალიზი
  2. დიზაინი
  3. პროგრამირება
  4. ტესტირება
  5. მომსახურება
  შესაძლებელია ეტაპობრივი შემუშავება მიმდევრობით: ანალიზი-დიზაინი-კოდირება-ტესტირება-მომსახურება. 
  ასევე შეიძლება მთელი გუნდის ერთობლივი მუშაობით და ყოველ ეტაპზე ტესტირებით, არის შერეული ტიპებიც.
  -- STLC = პროგრამული უზრუნველყოფის ტესტირების სასიცოცხლო ციკლი, Software Testing Life Cycle:
  1. მოთხოვნების ანალიზი 
  2. ტესტირების დაგეგმვა 
  3. ტესტური ნიმუშების შემუშავება 
  4. ტესტირება 
  5. დახურვა  
    
    - ვერიფიკაცია: ვქმნით ჩვენ სწორად პროდუქტს? = (ჩანაფიქრი, გეგმა)
    - ვალიდაცია: ვახორციელებთ ჩანაფიქრს სწორად? = (შესრულება, დამკვეთის მოთხოვნებთან შესაბამისობა)
  -- ვერიფიკაცია = კოდის გარეშე პროცესი(მანამდე), პასუხობს კითხვაზე: სწორად ვაკეთებთ თუ არა?
  -- ვერიფიკაციის მეთოდები: reviews, walkthroughs, inspections განსაზღვრაცს არის თუ არა პროგრამული უზრუნველყოფა მაღალი ხარისხის,  ვერიფიკაცია მთავრდება Validation-ით
  -- ვალიდაცია = ითვალისწინებს პროგრამის გაშვებას, ხდება ვერიფიკაციის შემდეგ, პასუხობს კითხვაზე = სწორ პროდუქტს ვაკეთებთ თუ არა? არის თუ არა დამკვეთის/მომხმარებლის მოთხოვნების შესაბამისი?
  -- ვალიდაციის მეთოდები: Black Box, White Box და ფუნქციონალური ტესტირება.

  ===== ტესტირების ტერმინოლოგიები =====

  -- Alfa-test = დეველოპერების ან ტესტერების მიერ განხორციელებული ტესტირებას ეწოდება ალფა-ტესტირება, ტარდება პროგრამული პროდუქტის გაშვებამდე, დეველოპინგის ეტაპზე.
  -- Beta-test = მომხმარებელთა მიერ განხორციელებულ ტესტირებას ეწოდება ბეტა-ტესტირება, ტარდება პროგრამული პროდუქტის გაშვების შემდგომ, მოხმარების ეტაპზე.
  -- Experience-based Test Techniques (Exploratory Testing) = გამოცდილებაზე დაფუძნებული ტესტირება, როცა ტესტერი თვითონ წყვეტს რა გატესტოს
  -- Smoke = ზოგადი(ზედაპირული, სწრაფი) ტიპის ტესტირება, ხდება პროექტის ყოველ ახალ ვერსიაზე, ხარვეზების ადრეული აღმოჩენისათვის
  -- Severity = ბაგის გავლენის სერიოზულობა
  -- Priority = ბაგის გასწორების რიგითობა
  -- Sanity = კონკრეტული ფუნქციონალის ტესტირება, ხდება Smoke-ს შემდეგ, ძირითადად ხელით
  -- Regression = განმეორებითი ტესტირებები ახალი ფუნქციონალის დამატებისას, რათა დავრწმუნდეთ ცვლილებებმა მოახდინა თუ არა გავლენა არსებულ და გატესტილ ნაწილზე
  -- Re-test = განმეორებითი ტესტირება ხარვეზების გასწორების შემდეგ
  -- black box = ტესტირება კოდთან წვდომის გარეშე, გარეგანი ტესტირებით
  -- white box = ტესტირება კოდთან წვდომით, როცა ვიცით რისგან შედგება 
  -- End-to-end = სრული ტესტირება ყველა დონეზე(ბექენდი, ფრონტი, ინტერფეისი)
  -- Monkey Testing = დაუგეგმავი, შემთხვევითობის პრინციპით ტესტრიება
  -- Test summary report = ტესტირების შედეგების ანგარიში ცხრილის(ან სიის) სახით. ანგარიშში იწერება: ტესტის ნომერი(ტესტ-კეისის ID), სახელწოდება, ოპერაციის/პროცედურის აღწერა, მოსალოდნელი(სწორი) შედეგი, ტესტირების შედეგი, ხარვეზის სიმძიმე. ანგარიშში შეიძლება იყოს შეტანილი სტატისტიკური მონაცემები ტესტების რაოდენობაზე და ტიპზე, შენიშვნები, რჩევები და ა.შ. 
  -- test data სატესტო მონაცემები, ტესტირებამდე ხდება მათი წინასწარი შეგროვება ხელით ან გენერაცია პროგრამულად
  -- Test Scenario = გატესტვის სცენარი, შეიცავს რამოდენიმე საფეხურს(პროცედურებს)
  -- Test Suite = შესრულების მიხედვით დალაგებული ტესტ-კეისების გაერთიანება
  -- State Transition Technique = მდგომარეობის გადასვლის ტექნიკა. გამოიყენება იმ შემთხვევებში, როცა ხდება სისტემის მდგომარეობის შეცვლა, მაგალითად პაროლის 3-ჯერ არასწორად შეყვანის შემდეგ სისტემა იბლოკება.
  -- Shift Left Testing = ტესტირების გადაწევა პროდუქტის შემუშავების ადრეული ეტაპებისაკენ. 
  -- RTM (Requirements Traceability Matrix) = მოთხოვნილებათა თვალყურის(შესაბამისობის) 2 განზომილებიანი მატრიცა, სადაც ყველა სახის მოთხოვნათა ერთობლიობა(დიზაინის, ბიზნესის, სისტემური, უსაფრთხოების და ა.შ.) დაკავშირებულია ტესტ-კეისებთან(ყველა-ყველაზე). ხშირად არის ტესტ-გეგმის ნაწილი, გამოიყენება მოთხოვნილებათა შესრულებისა და მათი შესაბამისი ტესტირების კონტროლისათვის.
  -- ტესტ-დიზაინი(Test Design) = ტესტების დაგეგმვა და შემუშავება
  -- ტესტ-სტრატეგია(Test strategy) = ტესტირების პროცესის მიმდინარეობის სტრატეგია
  -- ტესტ-გეგმა(Test plan) = ტესტირების პროცესის დეტალური გეგმა, აღწერა
  -- ჩეკ-ლისტი(Check list) = გასატესტი საკითხების და ტესტირების იდეების ჩამონათვალი(სია), მოკლე აღწერებით
  -- ტესტ-კეისი(Test case) = კონკრეტული ფუნქციონალის ტესტირებისთვის საჭირო მოქმედებათა დეტალური აღწერა 
  -- ბაგ-რეპორტი(Bug report) = ანგარიში ხარვეზებზე, ივსება ტესტ-კეისების შესრულებისას. რეპორტში დეტალურად იწერება გასატესტი საკითხი, მოსალოდნელი შედეგი და აღმოჩენილი ხარვეზი, ასევე ხარვეზის აღმოფხვრაზე პასუხისმგებელი პირი.
  -- ტესტ-რეპორტი(Test report) = ანგარიში ტესტ-კეისების შესრულებაზე, კეისების შესრულებისა და აღმოჩენილი ხარვეზების  ზოგადი სტატისტიკა   
  -- Inspection in software engineering = ინსპექცია პროგრამული უზრუნველყოფის შემუშავების დროს მცოდნე სპეციალისტების მიერ, რომლებიც ეძებენ დეფექტებს მკაფიოდ განსაზღვრული პროცედურებით.
  -- Walkthroughs In software engineering = პროგრამული უზრუნველყოფის ეტაპობრივი განხილვის სახელმძღვანელო ექსპერტული შეფასებისათვის, რომლითაც დიზაინერი ან პროგრამისტი ჯგუფის წევრებთან განიხილავს ეტაპობრივად პროგრამულ პროდუქტს, წევრები კი სვავენ კითხვებს და აკეთებენ კომენტარებს შესაძლო შეცდომებსა და პრობლემებზე.
  -- Reviews In software development = პროგრამული პროდუქტის რეცენზირების ტიპი, რომლის დროსაც ხდება მისი შესწავლა ავტორის ან მისი კოლეგების მიერ პროდუქტის ხარისხისა და ტექნიკური შემადგენლობის შესაფასებლად.
  -- BrowserStack = სხვადასხვა ბრაუზერებისა და ოპერაციული სისტემების ემულატორი. 
  -- შავი ყუთის ტექნიკები: Equivalence Partitioning, Boundary Value Analysis, Decision Table Testing, State Transition Testing, Case Testing);
  -- თეთრი ყუთის ტექნიკები: Statement Testing and Coverage, Decision Testing and Coverage, The Value of Statement and Decision Testing);
  -- გამოცდილებაზე დაფუძნებული ტექნიკებით ტესტირება: Error guessing, Exploretory testing, Checklist-based Testing. 
  
  ==== ტესტირების 7 პრინციპი ====
 1. დეფექტების ვერპოვნა არ ნიშნავს რომ ისინი არ არსებობს.
 2. სრული ტესტირება ყველა შესაძლო შემთხვევისთვის ხშირად არ არსებობს, მთავარია სწორი პრიორიტეტების განსაზღვრა
 3. ტესტირების დაწყება უმჯობესია ადრეულ ეტაპზე, ხარვეზების დროული გასწორებისთვის
 4. შეცდომების უმრავლესობა მცირე ადგილზეა ერთად დაგროვებული 
 5. მუდმივად ერთი ტიპის ტესტირების გამოყენებისას შეცდომების აღმოჩენა მცირდება და ვეღარ ხდება
 6. სხვადასხვა ტიპის პროდუქტი სხვადასხვანაირად იტესტება, ტესტირების ტიპი დამოკიდებულია კონტენტზე
 7. პრობლემების პოვნა და გასწორება არ არის ეფექტური, თუ პროდუქტი არ აკმაყოფილებს წაყენებულ მოთხოვნებს.
   
   ტესტირება შეიძლება მოხდეს პროექტის დასრულების შემდეგ სრულად, ან დასრულებამდე ეტაპობრივად(იტერაციულად), პროექტის მზადების პარალელურ რეჟიმში. ტესტირება არსებობს მრავალი ტიპის: ფუნქციონალური, უსაფრთხოების, თავსებადობის, სისტემური, სტრესული, მწარმოებლური(სისწრაფე/დატვირთვაზე), ინტეგრაციული, საინსტალაციო, ინტერფეისის(უსაბილიტი), საკონფიგურაციო და ა.შ.

   ტესტირების დონეები Test Levels შეიძლება დავყოთ:
 1. მოდულური(Unit, ერთეულის) ტესტირება, პროდუქტის ცალკეული ნაწილის ტესტირება
 2. ინტეგრაციული/კომპლექსური(Integration, მოდულების ერთობლივი მუშაობის) ტესტირება
 3. სისტემური(System, მთელი სისტემის) ტესტირება
 4. გამოყენებითი, მოთხოვნებთან(Acceptance, სპეციფიკაციები) შესაბამისობის ტესტირება

  ==== ტესტირების უნივერსალური მეთოდოლოგია ====
 1. გასატესტი პროდუქტის ანალიზი, მთავარი და მეორეხარისხოვანი საკითხების განსაზღვრა, ფუნქციონალის შესწავლა, დამახასიათებელი ნიუანსები.
 2. ტესტირების მოთხოვნების ჩამოყალიბება, მნიშვნელოვანი საკითხების გამოყოფა და ტესტირების ზოგადი გეგმის გაწერა.
 3. ტესტირების გეგმის დეტალიზაცია, ჩეკ-ლისტებისა და ტესტ-კეისების შედგენა.
 4. დეტალური ტესტირება გეგმაში გაწერილი პრიორიტეტების მიხედვით, ბაგ-რეპორტინგი. 
 5. ზოგადი გეგმისა და ჩეკ-ლისტების კორექტირება საჭიროების მიხედვით.
 6. განმეორებითი ტესტირება, ბაგ-რეპორტინგი. 
 -- ტესტირების შედეგის აღწერა უნდა იყოს დეტალური და კონკრეტული!
 -- ტესტირების გეგმას აუცილებლად უნდა გაუკეთდეს აღწერა მნიშვნელოვან საკითხებზე: წაყენებულ მოთხოვნებზე, ვადებზე, რისკებზე, გამოყენებულ რესურსებზე, საჭირო დოკუმენტაციაზე, მონაცემთა შეგროვებაზე, ტესტირების სტრატეგიაზე და ა.შ.

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

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

   ტესტ-კეისის შემადგენლობა(ასეთივე შეიძლება იყოს ბაგ-რეპორტის შაბლონიც):
 1. ტესტ-კეისის ID ნომერი 
 2. ტესტ-კეისის სახელწოდება(სათაური)
 3. წინასიტყვაობა, ტესტირებისთვის საჭირო წინაპირობების მოკლე აღწერა
 4. შესასრულებელ მოქმედებათა(პროცედურები) დეტალური აღწერა, თანამიმდევრობა
 5. მოსალოდნელი შედეგი, რას ველოდებით ტესტირებისაგან
 6. სტატუსი, ტესტირების შედეგი(Success, Failed, Blocked)
 7. სერიოზულობა: რამდენად კრიტიკულია
 8. პრიორიტეტი:  რამდენად სასწრაფოდ მოსაგვარებელია
 9. დამატებითი ინფორმაცია(საჭიროების მიხედვით): ავტორი, თარიღი, კომენტარი, სკრინშოტი, ფაილი და ა.შ.

   ბაგ-რეპორტის შაბლონი
 1. ID
 2. ხარვეზის სათაური
 3. ხარვეზის აღწერა 
 4. შესასრულებელი პროცედურები
 5. მოსალოდნელი შედეგი
 6. ფაქტიური შედეგი
 7. დასკვნა 

  ხარვეზის სერიოზულობა
 1. Blocker = ბლოკავს აპლიკაციას, შეუძლებელია მუშაობა
 2. Critical = მნიშვნელოვანი და დამაზიანებელი ხარვეზი 
 3. Major = მნიშვნელოვანი ხარვეზი
 4. Minor = ნაკლებად მნიშვნელოვანი ხარვეზი
 5. Trivial = უმნიშვნელო ხარვეზი

  ხარვეზის პრიორიტეტი
 1. High = მაღალი
 2. Medium = საშუალო
 3. Low = დაბალი

  ხარვეზის სტატუსი
 1. Passed = გაიარა ტესტი
 2. Failed = ჩავარდა ტესტი
 3. Skipped = გამოტოვებულია
 4. In progress = მიმდინარეობს ტესტირება
 5. Blocked = ტესტირება შეუძლებელია

   ტესტ-კეისის შედგენის წესები
 1. ერთი ტესტ-კეისი მხოლოდ ერთ კონკრეტულ ფუნქციონალს ამოწმებს
 2. ტესტ-კეისი არ უნდა იყოს დამოკიდებული სხვა ტესტ-კეისებზე
 3. პროცედურების თანამიმდევრობა უნდა იყოს მკაფიოდ გაწერილი
 4. ტესტ-კეისები სრულად უნდა შეიცავდნენ ტესტირებისთვის საკმარის ინფორმაციას  
  
   რა უნდა იცოდეს ტესტერმა
 1. კომპიუტერული და პროგრამული საკითხები
 2. ტესტირების თეორია
 3. ტესტირების ინსტრუმენტები 
 
  ==== მოსამზადებელი სამუშაოები ====
1. Figma დაინსტალირება
2. Notepad რედაქტორი
3. Sublime Text დაინსტალირება
4. lightshot სკრინშოტერი
5. word საოფისე პროგრამა
6. Trello რეგისტრაცია, შესწავლა
7. Jira სამუშაო გარემოს შესწავლა
8. HTML, CSS, JS ზოგადად შესწავლა