ვინ არის პასუხისმგებელი ხარისხზე?

ჰეი ჰაბრ!

ჩვენ გვაქვს ახალი მნიშვნელოვანი თემა - IT პროდუქტების მაღალი ხარისხის განვითარება. HighLoad++-ზე ხშირად ვსაუბრობთ იმაზე, თუ როგორ გავხადოთ დატვირთული სერვისები სწრაფად, ხოლო Frontend Conf-ზე ვსაუბრობთ მაგარი მომხმარებლის ინტერფეისზე, რომელიც არ ანელებს. ჩვენ რეგულარულად გვაქვს თემები ტესტირების შესახებ და DevOpsConf სხვადასხვა პროცესების, მათ შორის ტესტირების, გაერთიანების შესახებ. მაგრამ იმის შესახებ, თუ რას შეიძლება ეწოდოს ზოგადად ხარისხი და როგორ ვიმუშაოთ მასზე ყოვლისმომცველი - არა.

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

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

-ნასტია გამარჯობა. გთხოვთ მოგვიყევით თქვენს შესახებ.

Анастасия: მე ვმართავ ტესტირებას ბანკში, პასუხისმგებელი ვარ ძალიან დიდ გუნდზე - 90-ზე მეტი ადამიანი ვართ. ჩვენ გვაქვს მნიშვნელოვანი ბიზნეს ხაზი, ჩვენ ვართ პასუხისმგებელი იურიდიული პირების ეკოსისტემაზე.

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

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

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

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

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

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

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

Анастасия: ხარისხის უზრუნველყოფა, პირველ რიგში, არის ხარისხიანი პროდუქტის შექმნა. ანუ საკუთარ თავს ვეკითხებით, რა ხარისხის ატრიბუტები უნდა ჰქონდეს ჩვენს პროდუქტს. შესაბამისად, თუ ამას გავიგებთ, შეგვიძლია შევადაროთ ვინ ახდენს გავლენას ამ ხარისხის ატრიბუტებზე. არ აქვს მნიშვნელობა, დეველოპერი, პროექტის მენეჯერი ან პროდუქტის სპეციალისტი არის ადამიანი, რომელიც გავლენას ახდენს პროდუქტის განვითარებაზე, მის ჩამორჩენაზე და მის სტრატეგიაზე.

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

— როგორც ჩანს, ის, რაც ახლა აღწერეთ, პროდუქტის სპეციალისტის ამოცანაა. ეს, პრინციპში, არ ეხება ტესტირებას და არა ხარისხს - ეს ზოგადად პროდუქტის მენეჯმენტს ეხება, არა?

Анастасия: მათ შორის. ხარისხის უზრუნველყოფა არ არის დისციპლინა, რომელზეც პასუხისმგებელია ერთი კონკრეტული პირი. ახლა არის ტესტირების პოპულარული მიმართულება, მიდგომა ე.წ სწრაფი ტესტირება. მისი განმარტება ნათლად წერს, რომ ეს არის ტესტირების გუნდური მიდგომა, რომელიც მოიცავს პრაქტიკის გარკვეულ კომპლექსს. მთელი გუნდი პასუხისმგებელია ამ მიდგომის განხორციელებაზე, არც კი არის აუცილებელი, რომ გუნდში იყოს ტესტერი. მთელი გუნდი ორიენტირებულია მომხმარებლისთვის ღირებულების მიწოდებაზე და იმის უზრუნველსაყოფად, რომ ღირებულება აკმაყოფილებს მომხმარებლის მოლოდინებს.

— გამოდის, რომ ხარისხი კვეთს თითქმის ყველა მიმდებარე დისციპლინას, აწესებს ჩარჩოს გარშემო ყველაფერს?

Анастасия: მართალია. როდესაც ვფიქრობთ იმაზე, თუ როგორ გვინდა შევქმნათ ხარისხიანი პროდუქტი, ვიწყებთ ფიქრს ხარისხის სხვადასხვა ატრიბუტებზე. მაგალითად, როგორ შევამოწმოთ, რომ ჩვენ ნამდვილად შევქმენით ის ფუნქცია, რომელიც ჩვენს კლიენტს სჭირდება.

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

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

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

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

Анастасия: ახლა წარმოვიდგინოთ, რომ ჩვენ უკვე მივაწოდეთ ფუნქცია კლიენტს. ცხადია, პროდუქციის ხარისხს მონიტორინგი სჭირდება მაშინაც კი, როცა ის უკვე წარმოებაშია. ამ ეტაპზე შეიძლება გამოჩნდეს სიტუაციები არა აშკარა სცენარით, ე.წ.

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

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

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

ეს აჩენს კითხვას - შესაძლოა გუნდს ინფრასტრუქტურის კოდის სახით გამოყენება სჭირდება.

მიმაჩნია, რომ ინფრასტრუქტურა პირდაპირ გავლენას ახდენს პროდუქტის ხარისხზე.

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

- რაც შეეხება ანალიტიკასა და დოკუმენტაციას?

Анастасия: ეს უფრო მეტად ეხება საწარმოთა სისტემებს. როდესაც ვსაუბრობთ საწარმოზე, მაშინვე მახსენდება ისეთი ადამიანები, როგორიცაა ანალიტიკოსები და სისტემის ანალიტიკოსები. მათ ზოგჯერ ტექნიკურ მწერლებსაც უწოდებენ. ისინი იღებენ დავალებას დაწერონ სპეციფიკაცია და დაასრულონ, მაგალითად, ერთი თვის განმავლობაში.

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

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

დეველოპერები არ არიან მავნებლები და არ წერენ კოდს შეცდომით.

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

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

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

— რაც შეეხება გამოყენებადობის ტესტირებას, პროდუქტის გამოყენებადობას, დიზაინს?

Анастасия: ეს ძალიან მნიშვნელოვანი პუნქტია, რადგან გუნდში არიან დიზაინერები. ყველაზე ხშირად დიზაინერებს სერვისად იყენებენ - ან დიზაინის განყოფილების ან აუთსორსირებული დიზაინერის მიერ. ხშირად არის სიტუაციები, როდესაც ჩანს, რომ დიზაინერმა მოუსმინა პროდუქტის სპეციალისტს და გააკეთა ის, რაც მას ესმოდა. მაგრამ როდესაც ვიწყებთ გამეორებას, აღმოჩნდება, რომ ის, რაც რეალურად გაკეთდა, არ იყო ის, რაც მოსალოდნელი იყო: დიზაინერს დაავიწყდა რაღაც, ბოლომდე არ დაფიქრებულა ქცევაზე, რადგან ის არ არის გუნდში და არც კონტექსტში, ან წინა მხარეს. -ბოლო დეველოპერმა ბოლომდე ვერ გაიგო მისი განლაგება. მას შეიძლება დასჭირდეს რამდენიმე გამეორება მხოლოდ იმიტომ, რომ არსებობს პრობლემა წინა დეველოპერთან დიზაინის გაგებაში.

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

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

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

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

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

Анастасия: არის ყველაზე ძველი ტესტირების კონფერენცია, რომელიც წელს 25-ედ გაიმართება და სახელწოდებით SQA Days Quality Assurance Conference. ძირითადად განიხილება ინსტრუმენტები და სპეციფიკური ტესტირების მიდგომები ფუნქციონალური ტესტერებისთვის. როგორც წესი, SQA Days-ის მოხსენებები ღრმად იკვლევს კონკრეტულ სფეროებს თავად ტესტერების პასუხისმგებლობის არეალში, მაგრამ არა კომპლექსურ საქმიანობას.

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

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

ვისურვებდი, რომ რუსეთში ბიჭებმაც დაიწყეს ფიქრი, რომ ინდუსტრია არ მთავრდება ფუნქციური ტესტირებით.

— ამ მიზნით ვაწყობთ ახალ კონფერენციას QualityConf, რომელიც ეძღვნება ხარისხს, როგორც განუყოფელ დისციპლინას. გვითხარით დაწვრილებით იდეაზე, რა არის კონფერენციის მთავარი მიზანი?

Анастасия: გვინდა შევქმნათ ხარისხიანი პროდუქციის დამზადებით დაინტერესებული ადამიანების საზოგადოება. შესთავაზეთ პლატფორმა, სადაც მათ შეუძლიათ მოვიდნენ, მოუსმინონ მოხსენებებს და დატოვონ კონფერენციის შემდეგ კონკრეტული გაგებით, თუ რა უნდა შეიცვალოს ხარისხის გასაუმჯობესებლად.

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

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

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

— გეგმავთ უშუალოდ ტესტირებისა და ხელსაწყოების თემებზე შეხებას?

Анастасия: ვაღიარებ, რომ იქნება ცნობები ხელსაწყოების შესახებ. არსებობს საკმაოდ უნივერსალური ინსტრუმენტები, რომლითაც კომპანიებსა და გუნდებს შეუძლიათ გავლენა მოახდინონ პროდუქტზე.

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

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

— ვის დააინტერესებს რაზეა საუბარი, ვის ხედავთ კონფერენციის სტუმრად?

Анастасия: გვექნება მოხსენებები დეველოპერებისთვის, რომლებიც ზრუნავენ თავიანთი პროექტის, პროდუქტის, სისტემის ბედზე. ანალოგიურად, ეს საინტერესო იქნება ტესტერებისთვის და, მეჩვენება, განსაკუთრებით მენეჯერებისთვის. მენეჯერებში ვგულისხმობ ადამიანებს, რომლებიც იღებენ გადაწყვეტილებებს და შეუძლიათ გავლენა მოახდინონ პროდუქტის, სისტემის, გუნდის ბედზე და განვითარებაზე.

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

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

— როგორ ფიქრობთ, მთლიანობაში ინდუსტრია მომწიფებულია სასაუბროდ არა მხოლოდ ტესტირებაზე, არამედ ხარისხის კულტურაზე?

Анастасия: მგონი მომწიფებული ვარ. ახლა ბევრი კომპანია შორდება ტრადიციული ჩანჩქერის მიდგომას Agile-ის მიმართ. არის მომხმარებელზე ფოკუსირება, გუნდებში ადამიანები ნამდვილად იწყებენ ფიქრს, როგორ შექმნან ხარისხიანი პროდუქტი. საწარმო კომპანიებიც კი ხელახლა ამახვილებენ ყურადღებას ხარისხის გაუმჯობესებაზე.

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

- შევთანხმდით! ჩვენ დავნერგავთ კულტურას და შევცვლით ცნობიერებას.

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

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

წყარო: www.habr.com