თანამედროვე ტესტირება - QA როლის ევოლუცია

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

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

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


ტესტირება მხოლოდ უფრო საინტერესო გახდება!

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


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

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



ტრადიციული პროგრამული უზრუნველყოფის ტესტირება

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

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


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



QA ასაკის ასაკში

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

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

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


ამ ევოლუციასთან ერთად, ტესტის პასუხისმგებლობის ცვლა მოხდა განვითარების მარცხნივ, არსებითად საცხობი ხარისხის თავიდანვე.

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

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

დაკავშირებული:


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

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

თუ წარმოებაში რაიმე შეცდომა მოხდა, გამოძიება დიდხანს გაგრძელდება. დეველოპერებს არ ჰქონდათ იმის გაგება, თუ როგორ მოქმედებდა მათი პროგრამა წარმოებაში უფრო გრძელვადიან პერიოდში; ორ გუნდს შორის არ არსებობდა თანამშრომლობის გამჭვირვალობა და სიცხადე.



კეთილი იყოს თქვენი მობრძანება DevOps- ში

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


DevOps საშუალებას იძლევა უწყვეტი ინტეგრაციისა და საბოლოო მომხმარებლისთვის ღირებულების მიწოდების მეთოდები.

DevOps მოძრაობამ შემოიტანა ტესტირების ახალი პერსპექტივა და შექმნა ახალი შესაძლებლობები თავად ტესტერებისთვის.

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

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

უწყვეტი ინტეგრაცია (CI) და უწყვეტი მიწოდება (CD) გახდა ფაქტობრივი სტანდარტი პროგრამული უზრუნველყოფის შემუშავებასა და მიწოდების პროცესში და ამიტომ ტესტირების დიდი ნაწილი ახლა იხარჯება CI / CD მილსადენის, გარემოსა და ინფრასტრუქტურის უზრუნველყოფაში.

ეს არის ხერხემალი, რომელიც მხარს უჭერს როგორც განვითარებას, ასევე მიწოდებას.

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



თანამედროვე ტესტირება - ხარისხიანად განვითარებული განვითარება

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

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

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

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

თუ დეველოპერები უფრო შესაფერისი და უფრო საზრიანი არიან ავტომატიზირებული ტესტირებისთვის საჭირო კოდის დასაწერად, მაშინ საერთოდ რა საჭიროა გუნდში ტესტერი?

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

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

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



ვინ არის თანამედროვე QA

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

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

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

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

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

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

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

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

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

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

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