ტესტირება QA რესურსის გარეშე

შესაძლებელია მხოლოდ პროგრამული უზრუნველყოფის პროგრამის საკმარისი ტესტირება დეველოპერებისა და BA– ების გარეშე და QA– ს რესურსის გარეშე?

აქ ორი აზროვნების სკოლაა:

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


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

ორივე ეს რწმენა უკიდურესია.


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

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

შემქმნელის ტესტირება საკმარისია?

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

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


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

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

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

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


რატომ მაინცდამაინც გვჭირდება QA?

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

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

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

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


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

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

საინტერესო სტატიები