დღეს მინდა განვიხილოთ ტესტირების 7 პრინციპი რომელსაც გვთავაზობს ISTQB. მაშ ასე დავიწყოთ:
1) Testing shows the presence of defects, not their absence: ტესტირებას შეუძლია გამოავლინოს დეფექტები და შეამციროს პროგრამულ უზრუნველყოფაში არსებული დეფექტები, მაგრამ მაშინაც კი თუ ხარვეზები ვერ იქნება აღმოჩენილი ეს არ ნიშნავს იმას რომ პროგრამულ უზრუნველყოფას არ აქვს ხარვეზები.
2) Exhaustive testing is impossible: ხშირად თანამედროვე პროგრამული უზრუნველყოფა იმდენად კომპლექსურია რომ შეუძლებელია ყველა შესაძლო კომბინაციის ტესტირება, (ამ პროცესისთვის განკუთვნის დროში) ყველა შესაძლო გარემოზე (ბრაუზერი, დივაისი, ოპერაციული სისტემა და სხვ.). ასეთ დროს ამომწურავი ტესტირების მცდელობის ნაცვლად უმჯობესია მოხდეს რისკის ანალიზი, ტესტის ტექნიკა შერჩევა (შეცვლა) და პრიორიტეტების ორგანიზება უფრო მეტი შედეგიანობისთვის.
3) Early testing saves time and money: დეფექტების ადრეული გამოსავლენად, როგორც სტატიკური, ასევე დინამიური ტესტირების აქტივობები უნდა დაიწყოს რაც შეიძლება ადრე პროგრამული უზრუნველყოფის განვითარების სასიცოცხლო ციკლში. რაც უფრო ადრე ხდება დეფექტების აღმოჩენა მით უფრო მარტივია მისი მოგვარება და შესაბამისად უფრო იაფიც (გვიან აღმოჩენილი დეფექტს უფრო მეტი ზიანის მოტანა შეუძლია )
4) Defects cluster together: როგორც წესი, ხარვეზების უმეტესეობა ეკუთვნის ისეთ მოდულებს, რომლებიც გამოირჩევა რთული ლოგიკით, ან მათ დასაწერად გამოიყოფილი იყო შედარებით მცირე დრო (არ მოხდა შესაბამისი დროის დათმობა, ანალიზი, შეფასება).
5)Beware of the pesticide paradox: თუ ერთი და იგივე ტესტები განმეორდება არაერთხელ, საბოლოოდ ეს ტესტები ვეღარ აღმოაჩენს ახალ დეფექტებს. ახალი დეფექტების გამოსავლენად შესაძლოა საჭირო გახდეს არსებული ტესტები და მონაცემების შეცვლა და ახალი ტესტების დაწერა. ერთიდაიგივე ტესტები აღარ არის ეფექტური დეფექტების აღმოსაჩენად, ამიტომ უნდა მოხდეს მუდმივად მათი განახლება.
6)Testing is context dependent: ტესტირება უნდა მოხდეს სხვადასხვა გარემოში სხვადასხვა მიდგომებით და არა ყველგანგან და ყოველთვის ერთი მიდგომით. მაგალითად ზოგიერთ შემთხვევაში საჭიროა უფრო მეტი დატვირთვა მოდიოდეს უსაფრთხოების მიმართულებით ზოგიერთ შემთხვევაში კონტექსტის სიზუზტეზე.
7) Absence-of-errors is a fallacy: ხშირად დამკვეთს აქვს მოლოდინი, რომ ტესტერებს შეუძლიათ ყველა შესაძლო ტესტის ჩატარება და ყველა შესაძლო დეფექტის პოვნა, მაგრამ პრინციპები 1 და 2 თუ გადავხედავთ გაგვახსენდება რომ, რომ ეს შეუძლებელია. გარდა ამისა, მცდარია მოლოდინი, რომ მხოლოდ დიდი რაოდენობის დეფექტების აღმოჩენა და გამოსწორება უზრუნველყოფს სისტემის წარმატებას. მაგალითად, ყველა განსაზღვრული მოთხოვნის ზედმიწევნით ტესტირება და აღმოჩენილი ყველა დეფექტის გამოსწორებამ შეიძლება კვლავ წარმოქმნას სხვა ტიპის პრობლემა, მაგალითად მივიღოთ პროდუქტი რომელიც ძნელი გამოსაყენებელი, რომელიც არ აკმაყოფილებს მომხმარებლის მოთხოვნილებებსა და მოლოდინებს, ან სხვა კონკურენტ სისტემებთან შედარებით დაბალია.
