რა არის ტესტირების სხვადსხვა ტიპები და დონეები?

Question

Accepted Answer

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

## ტესტირების დონეები (ფარგლების მიხედვით)

```text
UNIT → individual functions/methods in isolation (smallest, fastest, most numerous)
INTEGRATION → multiple units/components working TOGETHER (e.g. code + database, services)
END-TO-END (E2E) → the WHOLE application from the user's perspective (full flows,
  through the real UI/system) — broadest, slowest
SYSTEM → the complete integrated system; ACCEPTANCE → meets business requirements
```

## ფუნქციური წ. არაფუნქციური

```text
FUNCTIONAL → does it do the RIGHT thing? (correct behavior, features work)
  → unit, integration, e2e, smoke, regression, sanity tests
NON-FUNCTIONAL → HOW WELL does it work? (qualities beyond correctness):
  PERFORMANCE (speed, load), SECURITY, USABILITY, RELIABILITY, COMPATIBILITY, etc.
```

## სხვა გავრცელებული ტესტის კატეგორიები

```text
REGRESSION → verify changes didn't break existing functionality (run after changes)
SMOKE → quick check that core functionality works (before deeper testing)
MANUAL → a human tests; AUTOMATED → code tests code (repeatable, fast)
WHITE-BOX (know the internals) vs BLACK-BOX (test behavior, not internals)
```

## რატომ აქვს ეს მნიშვნელობა

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

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

ამ კატეგორიების გაგება მნიშვნელოვანია, რადგან სრული ტესტირების სტრატეგია იყენებს მრავალ დონეს და ტიპებს — თქვენ ვერ უზრუნველყოფთ ხარისხს მხოლოდ ერთი სახის ტესტით (მხოლოდ ერთეულის ტესტები კი პропუску ინტეგრაციის პრობლემებს; მხოლოდ ფუნქციური ტესტები პროპუску წარმადობას და უსაფრთხოებას).

ამ დონეების გაგება (და რომ ისინი ყრის ფარგლებს სიჩქარის წინააღმდეგ — ერთეული ტესტები სწრაფი და მრავალი, e2e ტესტები ფართო მაგრამ ნელი) ტესტის პირამიდის კონცეფციას ჩარჩოვს.

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

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

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