განახლებულია აგვისტო 28, 2019
ტესტირება ფართოდ იქნა მიღებული როგორც პროგრამული უზრუნველყოფის შემუშავების ნაწილი მას შემდეგ რაც შემუშავდა პროგრამული უზრუნველყოფა. თუმცა, Business Intelligence (BI) უფრო ნელა ატარებს ტესტირებას, როგორც განვითარების ინტეგრირებულ ნაწილს BI პროგრამულ უზრუნველყოფაში, როგორიცაა IBM Cognos. მოდით განვსაზღვროთ, თუ რატომ არის BI უფრო ნელა ტესტირების პრაქტიკის მიღება და მისი შედეგები არა ტესტირება.
რატომ არ გამოსცდიან ორგანიზაციებს BI…
- დროის შეზღუდვებირა BI პროექტები მუდმივი ზეწოლის ქვეშაა, რომ უფრო სწრაფად განხორციელდეს. ის, რაც ზოგიერთმა ორგანიზაციამ არ იცის, არის ის, რომ დროის შემცირების ყველაზე მარტივი ეტაპი არის ტესტირება.
- ბიუჯეტის შეზღუდვებირა ფიქრობენ, რომ ტესტირება ძალიან ძვირია და მას არ შეუძლია გამოყოს ტესტირების ჯგუფი.
- უფრო სწრაფად ჯობიარა ეს სულაც არ არის "სწრაფი" მიდგომა და შეიძლება უფრო სწრაფად მიგიყვანოთ არასწორ ადგილას.
- მენტალიტეტი "მხოლოდ ამის გაკეთება პირველად"რა ეს გულუბრყვილო მიდგომა ამტკიცებს, რომ ხარისხის კონტროლის არსებობამ უნდა შეამციროს ტესტირების საჭიროება.
- საკუთრების ნაკლებობარა ეს წინა ტყვიის მსგავსია. ფიქრობენ, რომ "ჩვენი მომხმარებლები შეამოწმებენ მას". ამ მიდგომამ შეიძლება გამოიწვიოს უკმაყოფილო მომხმარებლები და უამრავი დამხმარე ბილეთი.
- ინსტრუმენტების ნაკლებობარა მცდარი წარმოდგენა იმის შესახებ, რომ მათ არ აქვთ ტესტირების სწორი ტექნოლოგია.
- ტესტირების გაგების ნაკლებობარა Მაგალითად,
- ტესტირებამ უნდა შეაფასოს მონაცემების სიზუსტე და ვალიდობა, მონაცემთა თანმიმდევრულობა, მონაცემების დროულობა, მიწოდების შესრულება და მიწოდების მექანიზმის გამოყენების სიმარტივე.
- BI პროექტის დროს ტესტირება შეიძლება შეიცავდეს რეგრესის ტესტირებას, ერთეულის ტესტირებას, კვამლის ტესტირებას, ინტეგრაციის ტესტირებას, მომხმარებლის მიღების ტესტირებას, დროებით ტესტირებას, სტრესის/მასშტაბურობის ტესტირებას, სისტემის მუშაობის ტესტირებას.
რა ღირს BI– ის არ ტესტირება?
- არაეფექტური დიზაინებირა ცუდი არქიტექტურა შეიძლება არ აღმოჩნდეს, თუ ტესტირება იგნორირებულია. დიზაინის საკითხებმა შეიძლება ხელი შეუწყოს გამოყენებადობას, შესრულებას, ხელახლა გამოყენებას, ასევე შენარჩუნებას და შენარჩუნებას.
- მონაცემთა მთლიანობის საკითხებირა მონაცემთა კორუფციამ ან მონაცემთა წარმომავლობის გამოწვევებმა შეიძლება გამოიწვიოს რიცხვების ნდობა.
- მონაცემთა ვალიდაციის საკითხებირა ცუდ მონაცემებზე მიღებული გადაწყვეტილებები შეიძლება დამღუპველი იყოს ბიზნესისთვის. არაფერია იმაზე უარესი, ვიდრე მცდელობა მართოთ მეტრიკით, რომელიც ემყარება არასწორ ინფორმაციას.
- შემცირდა მომხმარებლის მიღებარა თუ რიცხვები არ არის სწორი, ან თუ პროგრამა არ არის მოსახერხებელი, თქვენი მომხმარებლის საზოგადოება უბრალოდ არ გამოიყენებს თქვენს ბრწყინვალე ახალ საწარმოს BI პროგრამულ უზრუნველყოფას.
- გაიზარდა ხარჯები სტანდარტიზაციის არარსებობის გამო.
- გაზრდილი ხარჯები დეფექტების აღმოსაფხვრელად BI განვითარების სასიცოცხლო ციკლის შემდგომ ეტაპებზერა მოთხოვნების ფაზის მიღმა აღმოჩენილი ნებისმიერი საკითხი უფრო ძვირი დაჯდება, ვიდრე ადრე აღმოჩენილი.
ახლა, როდესაც ჩვენ განვსაზღვრეთ, თუ რატომ არ შეიძლება ორგანიზაციებმა ტესტირება და ის პრობლემები, რომლებიც წარმოიქმნება, როდესაც თქვენ არ შეამოწმებთ BI– ს, მოდით შევხედოთ რამდენიმე კვლევას პროგრამული უზრუნველყოფის შემუშავების ტესტირების შესახებ.
კვლევები აჩვენებს თქვენი BI პლატფორმის ტესტირება დაზოგავს ფულს!
ჩრდილოეთ ამერიკის 139 კომპანიის ერთი კვლევა 250 -დან 10,000 5.2 -მდე თანამშრომლის მოცულობით, წლიური ხარვეზის ხარჯი 22 მილიონი დოლარიდან XNUMX მილიონ დოლარამდეა. ხარჯების ეს დიაპაზონი ასახავს ორგანიზაციებს, რომლებიც არ აქვს ერთეულის ავტომატური ტესტირება. ცალკე, IBM- ისა და Microsoft- ის კვლევამ დაადგინა, რომ ერთად ავტომატური ერთეულის ტესტირება ადგილზე, დეფექტების რაოდენობა შეიძლება შემცირდეს 62% -დან 91% -მდერა ეს ნიშნავს, რომ გამართვისთვის დახარჯული დოლარი შეიძლება შემცირდეს $ 5 მილიონიდან $ 22 მილიონამდე $ 0.5 მილიონიდან $ 8.4 მილიონამდე. ეს არის უზარმაზარი დანაზოგი!
შეცდომების სწრაფად დაფიქსირების ხარჯები.
ნაშრომი პროგრამული უზრუნველყოფის განვითარების წარმატებული ტაქტიკის შესახებ აჩვენებს, რომ შეცდომების უმეტესობა დაშვებულია განვითარების ციკლის დასაწყისში და რაც უფრო დიდხანს დაელოდებით გამოვლენას და გამოსწორებას, მით უფრო ძვირი დაგიჯდებათ გამოსწორება. ასე რომ, სარაკეტო მეცნიერს არ სჭირდება აშკარა დასკვნის გაკეთება, რომ რაც უფრო ადრე აღმოჩენილი და დაფიქსირებული იქნება შეცდომები, მით უკეთესი. სარაკეტო მეცნიერებაზე საუბრისას, ეს ხდება ისე, რომ NASA– მ გამოაქვეყნა ნაშრომი სწორედ ამის შესახებ - "შეცდომის ხარჯების ესკალაცია პროექტის სიცოცხლის ციკლის განმავლობაში."
ინტუიციურია, რომ შეცდომების გამოსწორების ხარჯები იზრდება განვითარების ციკლის პროგრესირებასთან ერთად. ნასას კვლევა ჩატარდა იმის დასადგენად, თუ რამდენად სწრაფად პროგრესირებს აღმოჩენილი შეცდომების დაფიქსირების ფარდობითი ღირებულება. ამ კვლევამ გამოიყენა სამი მიდგომა ფარდობითი ხარჯების დასადგენად: ქვემოდან ხარჯების მეთოდი, მთლიანი ხარჯების განაწილების მეთოდი და ზემოდან ქვემოთ ჰიპოთეტური პროექტის მეთოდი. ამ ნაშრომში აღწერილი მიდგომები და შედეგები ვარაუდობენ აპარატურის/პროგრამული სისტემის შემუშავებას, რომელსაც აქვს პროექტის მახასიათებლები მსგავსი დიდი, რთული კოსმოსური ხომალდის, სამხედრო თვითმფრინავის ან მცირე საკომუნიკაციო თანამგზავრის შემუშავებაში. შედეგები აჩვენებს ხარჯების გაზრდის ხარისხს, რადგან შეცდომები აღმოჩენილი და დაფიქსირებულია პროექტის სასიცოცხლო ციკლის შემდგომ და შემდგომ ფაზებზე. ეს კვლევა წარმოადგენს სხვა კვლევებს, რომლებიც ჩატარდა.
ზემოთ მოყვანილი გრაფიკიდან, TRW, IBM, GTE, Bell Labs, TDC და სხვა კვლევები აჩვენებს შეცდომების დაფიქსირების ღირებულებას განვითარების სხვადასხვა ფაზაში:
- მოთხოვნების ფაზაში აღმოჩენილი შეცდომის დაფიქსირების ღირებულება განისაზღვრება, როგორც 1 ერთეულის
- ამ შეცდომის გამოსწორების ღირებულება დიზაინის ფაზაშია გაორმაგება ეს
- კოდისა და გამართვის ეტაპზე შეცდომის გამოსწორების ღირებულებაა 3 ერთეული
- ერთეულის გამოცდისა და ინტეგრაციის ფაზაში ხდება ხარვეზის გამოსწორების ღირებულება 5
- სისტემების გამოცდის ფაზაში, ხარვეზის გამოსწორების ღირებულება 20 -მდე იზრდება
- და როგორც კი სისტემა ოპერაციის ფაზაშია, შეცდომის გამოსწორების ფარდობითი ღირებულება გაიზარდა 98 -მდე, თითქმის 100 -ჯერ შეცდომის გამოსწორების ღირებულებაზე, თუ აღმოჩნდება მოთხოვნების ფაზაში!
დედააზრი ის არის, რომ გაცილებით ძვირი ჯდება დეფექტების აღმოფხვრა, თუ ისინი ადრე არ იქნა აღმოჩენილი.
დასკვნები
ჩატარდა მნიშვნელოვანი კვლევა, რომელიც აჩვენებს ადრეული და უწყვეტი ტესტირების ღირებულებას პროგრამული უზრუნველყოფის შემუშავებაში. ჩვენ, BI საზოგადოებაში, შეგვიძლია ვისწავლოთ ჩვენი მეგობრებისგან პროგრამული უზრუნველყოფის შემუშავებაში. მიუხედავად იმისა, რომ ყველაზე მეტი ოფიციალური კვლევა გაკეთდა პროგრამული უზრუნველყოფის შემუშავებასთან დაკავშირებით, მსგავსი დასკვნების გაკეთება შესაძლებელია BI განვითარების შესახებ. ტესტირების ღირებულება უდავოა, მაგრამ ბევრი ორგანიზაცია ნელნელა ისარგებლებს BI გარემოს ფორმალური ტესტირებით და ინტეგრირებას ახდენს მათი BI განვითარების პროცესებში. ხარჯები არ ტესტირება რეალურია. რისკებთან დაკავშირებული არ ტესტირება რეალურია.
გსურთ ნახოთ ზოგიერთი ავტომატური Cognos ტესტირება მოქმედებაში? უყურეთ ვიდეოებს ჩვენს დასაკრავი სიის მიხედვით დააჭირეთ აქ!
