តើអ្នកណាទទួលខុសត្រូវចំពោះគុណភាព?

ហេហេ!

យើងមានប្រធានបទសំខាន់ថ្មីមួយ - ការអភិវឌ្ឍន៍គុណភាពខ្ពស់នៃផលិតផល IT ។ នៅ HighLoad++ យើងច្រើនតែនិយាយអំពីរបៀបធ្វើឱ្យសេវារវល់លឿន ហើយនៅ Frontend Conf យើងនិយាយអំពីចំណុចប្រទាក់អ្នកប្រើដ៏ត្រជាក់ដែលមិនបន្ថយល្បឿន។ យើងមានប្រធានបទជាទៀងទាត់អំពីការធ្វើតេស្ត និង DevOpsConf អំពីការរួមបញ្ចូលដំណើរការផ្សេងៗគ្នា រួមទាំងការធ្វើតេស្តផងដែរ។ ប៉ុន្តែអំពីអ្វីដែលអាចហៅថាគុណភាពជាទូទៅនិងរបៀបធ្វើការលើវាឱ្យបានទូលំទូលាយ - ទេ។

តោះជួសជុលវាដោយ QualityConf — យើងនឹងអភិវឌ្ឍវប្បធម៌នៃការគិតអំពីគុណភាពនៃផលិតផលចុងក្រោយសម្រាប់អ្នកប្រើប្រាស់នៅគ្រប់ដំណាក់កាលនៃការអភិវឌ្ឍន៍។ ទំលាប់នៃការមិនផ្តោតលើតំបន់ទទួលខុសត្រូវរបស់អ្នក ហើយការភ្ជាប់គុណភាពមិនត្រឹមតែជាមួយអ្នកសាកល្បងប៉ុណ្ណោះទេ។

ខាងក្រោមការកាត់នេះ យើងនឹងពិភាក្សាជាមួយប្រធានគណៈកម្មាធិការកម្មវិធី ប្រធានផ្នែកធ្វើតេស្តនៅ Tinkoff.Business ដែលជាអ្នកបង្កើតសហគមន៍ QA ដែលនិយាយភាសារុស្សី នាង Anastasia Aseeva-Nguyen អំពីស្ថានភាពនៃឧស្សាហកម្ម QA និងបេសកកម្មនៃសន្និសីទថ្មី។

- Nastia ជំរាបសួរ។ សូមប្រាប់យើងអំពីខ្លួនអ្នក។

នាង Anastasia៖ ខ្ញុំ​គ្រប់​គ្រង​ការ​ធ្វើ​តេស្ត​នៅ​ធនាគារ​មួយ ខ្ញុំ​ទទួល​ខុស​ត្រូវ​សម្រាប់​ក្រុម​ដ៏​ធំ​មួយ - យើង​មាន​មនុស្ស​ច្រើន​ជាង 90 នាក់។ យើងមានខ្សែអាជីវកម្មដ៏សំខាន់មួយ យើងទទួលខុសត្រូវចំពោះប្រព័ន្ធអេកូឡូស៊ីសម្រាប់នីតិបុគ្គល។

ខ្ញុំបានសិក្សាផ្នែកមេកានិច និងគណិតវិទ្យា ហើយដំបូងឡើយចង់ក្លាយជាអ្នកសរសេរកម្មវិធី។ ប៉ុន្តែនៅពេលដែលខ្ញុំទទួលបានការផ្តល់ជូនដ៏គួរឱ្យចាប់អារម្មណ៍ ខ្ញុំបានសម្រេចចិត្តសាកល្បងខ្លួនឯងជាអ្នកសាកល្បង។ ចម្លែកគ្រប់គ្រាន់ហើយ នេះបានក្លាយជាការហៅរបស់ខ្ញុំ។ ឥឡូវនេះខ្ញុំឃើញការងាររបស់ខ្ញុំទាំងអស់នៅក្នុងឧស្សាហកម្មនេះ។

ខ្ញុំជាអ្នកប្រកាន់ខ្ជាប់យ៉ាងខ្ជាប់ខ្ជួននូវវិន័យធានាគុណភាព។ ខ្ញុំមិនព្រងើយកន្តើយចំពោះអ្វីដែលផលិតផលត្រូវបានបង្កើត របៀបដែលគុណភាពត្រូវបានព្យាបាលនៅក្នុងក្រុមហ៊ុន ក្នុងក្រុម និងជាគោលការណ៍នៅក្នុងដំណើរការអភិវឌ្ឍន៍។

វាច្បាស់ណាស់សម្រាប់ខ្ញុំ សហគមន៍ក្នុងទិសដៅនេះមិនមានភាពចាស់ទុំគ្រប់គ្រាន់ទេ។យ៉ាងហោចណាស់នៅក្នុងប្រទេសរុស្ស៊ី។ យើងមិនតែងតែយល់ថាការធានាគុណភាពមិនត្រឹមតែជាការពិតនៃការធ្វើតេស្តកម្មវិធីសម្រាប់ការអនុលោមតាមតម្រូវការប៉ុណ្ណោះទេ។ ខ្ញុំចង់ផ្លាស់ប្តូរស្ថានភាពនេះ។

- អ្នកប្រើពាក្យ ការធានាគុណភាព និងការធ្វើតេស្ត។ នៅក្នុងក្រសែភ្នែករបស់មនុស្សជាមធ្យម ពាក្យទាំងពីរនេះច្រើនតែត្រួតលើគ្នា។ តើវាខុសគ្នាយ៉ាងណាបើអ្នកជីកជ្រៅ?

Anastasia: ផ្ទុយទៅវិញ ពួកគេក៏មិនខុសគ្នាដែរ។ ការ​ធ្វើ​តេស្ត​គឺ​ជា​ផ្នែក​មួយ​នៃ​វិន័យ​ធានា​គុណភាព វា​ជា​សកម្មភាព​ផ្ទាល់​ដែល​ខ្ញុំ​កំពុង​ធ្វើ​តេស្ត​អ្វី​មួយ។ ការធ្វើតេស្តមានច្រើនប្រភេទ ហើយមនុស្សច្រើនប្រភេទត្រូវទទួលខុសត្រូវចំពោះប្រភេទផ្សេងៗនៃការធ្វើតេស្ត។ ប៉ុន្តែនៅទីនេះនៅក្នុងប្រទេសរុស្ស៊ី នៅពេលដែលរលកនៃប្រភពខាងក្រៅបានលេចឡើងដែលផ្គត់ផ្គង់អ្នកសាកល្បងដល់ក្រុមហ៊ុន ការធ្វើតេស្តត្រូវបានកាត់បន្ថយទៅជាប្រភេទតែមួយ។

ក្នុងករណីភាគច្រើន ពួកវាត្រូវបានកំណត់ត្រឹមតែការធ្វើតេស្តមុខងារប៉ុណ្ណោះ៖ ពួកគេពិនិត្យមើលថាអ្វីដែលអ្នកអភិវឌ្ឍន៍បានសរសេរកូដនោះ អនុលោមតាមលក្ខណៈជាក់លាក់ ហើយនោះជាអ្វីទាំងអស់។

- សូមប្រាប់ពួកយើងថាតើវិញ្ញាសាធានាគុណភាពផ្សេងទៀតមានអ្វីខ្លះ? តើមានអ្វីផ្សេងទៀតក្រៅពីការធ្វើតេស្តត្រូវបានរួមបញ្ចូលនៅទីនេះ?

នាង Anastasia៖ ការធានាគុណភាពជាដំបូងនៃការទាំងអស់អំពីការបង្កើតផលិតផលដែលមានគុណភាព។ នោះគឺយើងសួរខ្លួនឯងថាតើគុណលក្ខណៈគុណភាពផលិតផលរបស់យើងគួរមានអ្វីខ្លះ? ដូច្នោះហើយ ប្រសិនបើយើងយល់អំពីចំណុចនេះ យើងអាចប្រៀបធៀបថាអ្នកណាមានឥទ្ធិពលលើគុណលក្ខណៈគុណភាពទាំងនេះ។ មិន​សំខាន់, អ្នកអភិវឌ្ឍន៍ អ្នកគ្រប់គ្រងគម្រោង ឬអ្នកឯកទេសផលិតផល គឺជាបុគ្គលដែលមានឥទ្ធិពលលើការអភិវឌ្ឍន៍ផលិតផល ដំណើរថយក្រោយ និងយុទ្ធសាស្ត្ររបស់វា។

អ្នកសាកល្បងកាន់តែដឹងពីតួនាទីរបស់គាត់។ គាត់យល់ថាភារកិច្ចរបស់គាត់មិនត្រឹមតែធ្វើតេស្តសម្រាប់ការអនុលោមតាមតម្រូវការប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងសាកល្បងតម្រូវការ សួរសំណួរអំពីរូបមន្តដែលមកពីអ្នកឯកទេសផលិតផល និងបង្ហាញពីតម្រូវការជាក់ស្តែង និងការរំពឹងទុករបស់អតិថិជន។ នៅពេលដែលយើងផ្តល់មុខងារថ្មីដល់អតិថិជនរបស់យើង យើងត្រូវតែបំពេញតាមការរំពឹងទុករបស់ពួកគេ និងដោះស្រាយការឈឺចាប់របស់ពួកគេ។ ប្រសិនបើយើងគិតពីគុណលក្ខណៈគុណភាពទាំងអស់ នោះអតិថិជននឹងពេញចិត្ត ហើយនឹងយល់ថាក្រុមហ៊ុនដែលផលិតផលរបស់គាត់ប្រើប្រាស់ពិតជាយកចិត្តទុកដាក់ចំពោះផលប្រយោជន៍របស់គាត់ ហើយមិនដំណើរការលើគោលការណ៍ "គ្រាន់តែបញ្ចេញមុខងារមួយ" នោះទេ។

— វាហាក់បីដូចជាអ្វីដែលអ្នកទើបតែបានពិពណ៌នាគឺជាភារកិច្ចរបស់អ្នកឯកទេសផលិតផល។ ជាគោលការណ៍ នេះមិនមែននិយាយអំពីការសាកល្បង និងមិនមែនអំពីគុណភាពទេ ជាទូទៅវានិយាយអំពីការគ្រប់គ្រងផលិតផលមែនទេ?

នាង Anastasia៖ រួមទាំង។ ការធានាគុណភាពមិនមែនជាវិន័យដែលបុគ្គលជាក់លាក់ណាមួយទទួលខុសត្រូវនោះទេ។ ឥឡូវនេះមានទិសដៅដ៏ពេញនិយមមួយក្នុងការធ្វើតេស្ត ដែលជាវិធីសាស្រ្តមួយហៅថា ការធ្វើតេស្តរហ័ស. និយមន័យរបស់គាត់បញ្ជាក់យ៉ាងច្បាស់ថា នេះគឺជាវិធីសាស្រ្តក្រុមក្នុងការសាកល្បង ដែលរួមបញ្ចូលនូវការអនុវត្តជាក់លាក់មួយ។ ក្រុមទាំងមូលមានទំនួលខុសត្រូវក្នុងការអនុវត្តវិធីសាស្រ្តនេះ វាមិនចាំបាច់សូម្បីតែមានអ្នកសាកល្បងនៅក្នុងក្រុមក៏ដោយ។ ក្រុមទាំងមូលផ្តោតលើការផ្តល់តម្លៃដល់អតិថិជន និងធានាថាតម្លៃនោះត្រូវនឹងការរំពឹងទុករបស់អតិថិជន។

- វាប្រែថាគុណភាពប្រសព្វជាមួយវិញ្ញាសាជុំវិញស្ទើរតែទាំងអស់ ដោយដាក់ក្របខ័ណ្ឌលើអ្វីៗទាំងអស់ជុំវិញ?

នាង Anastasia៖ ត្រូវហើយ។ នៅពេលយើងគិតអំពីរបៀបដែលយើងចង់បង្កើតផលិតផលដែលមានគុណភាព យើងចាប់ផ្តើមគិតអំពីគុណលក្ខណៈផ្សេងៗនៃគុណភាព។ ឧទាហរណ៍ របៀបពិនិត្យមើលថាយើងពិតជាបានបង្កើតលក្ខណៈពិសេសដែលអតិថិជនរបស់យើងត្រូវការ។

នេះជាកន្លែងដែលការធ្វើតេស្តប្រភេទនេះចូលមក៖ UAT (ការធ្វើតេស្តទទួលយកអ្នកប្រើប្រាស់) ។ ជាអកុសល វាកម្រត្រូវបានអនុវត្តនៅក្នុងប្រទេសរុស្ស៊ី ប៉ុន្តែជួនកាលមានវត្តមាននៅក្នុងក្រុម SCRUM ជាការបង្ហាញសម្រាប់អតិថិជនចុងក្រោយ។ នេះគឺជាប្រភេទនៃការធ្វើតេស្តធម្មតានៅក្នុងក្រុមហ៊ុនបរទេស។ មុននឹងបើកមុខងារដល់អតិថិជនទាំងអស់ យើងធ្វើ UAT ជាមុនសិន ពោលគឺយើងអញ្ជើញអ្នកប្រើប្រាស់ចុងក្រោយដែលធ្វើតេស្ត និងផ្តល់មតិកែលម្អភ្លាមៗ ថាតើផលិតផលពិតជាបំពេញតាមការរំពឹងទុក និងដោះស្រាយការឈឺចាប់ដែរឬទេ។ មានតែបន្ទាប់ពីវាធ្វើមាត្រដ្ឋានដល់អតិថិជនផ្សេងទៀតទាំងអស់កើតឡើង។

នោះគឺយើងផ្តោតលើអាជីវកម្ម អតិថិជនចុងក្រោយ ប៉ុន្តែក្នុងពេលតែមួយ កុំភ្លេចអំពីបច្ចេកវិទ្យា. គុណភាពនៃផលិតផលក៏អាស្រ័យលើបច្ចេកវិទ្យាផងដែរ។ ប្រសិនបើយើងមានស្ថាបត្យកម្មមិនល្អ យើងនឹងមិនអាចបញ្ចេញលក្ខណៈពិសេស និងបំពេញតាមការរំពឹងទុករបស់អតិថិជនបានឆាប់រហ័សនោះទេ។ វាអាចមានកំហុសជាច្រើននៅពេលព្យាយាមធ្វើមាត្រដ្ឋាន ឬនៅពេលព្យាយាមកែតម្រូវ យើងអាចបំបែកអ្វីមួយ។ ទាំងអស់នេះនឹងប៉ះពាល់ដល់ការពេញចិត្តរបស់អតិថិជន។

តាមទស្សនៈនេះ ស្ថាបត្យកម្មគួរតែមានលក្ខណៈបែបនេះដែលយើងអាចសរសេរកូដស្អាតដែលនឹងអនុញ្ញាតឱ្យយើងធ្វើការផ្លាស់ប្តូរយ៉ាងឆាប់រហ័ស ហើយមិនខ្លាចថាយើងនឹងបំបែកអ្វីៗទាំងអស់។ ដូច្នេះ​ការ​កែប្រែ​នោះ​មិន​អូស​បន្លាយ​ច្រើន​ខែ​ទេ ដោយសារ​យើង​មាន​កេរដំណែល​ច្រើន ហើយ​យើង​ត្រូវ​ធ្វើ​ដំណាក់​កាល​សាកល្បង​យូរ។

- សរុបមក អ្នកអភិវឌ្ឍន៍ ស្ថាបត្យករ អ្នកវិទ្យាសាស្ត្រផលិតផល អ្នកគ្រប់គ្រងផលិតផល និងអ្នកសាកល្បងខ្លួនឯងបានចូលរួមរួចហើយ។ តើអ្នកណាទៀតដែលចូលរួមក្នុងដំណើរការធានាគុណភាព?

នាង Anastasia៖ ឥឡូវ​នេះ​សូម​ស្រមៃ​ថា​យើង​បាន​បញ្ជូន​មុខងារ​នេះ​ទៅ​អតិថិជន​រួច​ហើយ។ ជាក់ស្តែង គុណភាព​ផលិតផល​ត្រូវ​ត្រួតពិនិត្យ ទោះបី​វា​កំពុង​ផលិត​រួចហើយ​ក៏ដោយ។ នៅដំណាក់កាលនេះ ស្ថានភាពដែលមានសេណារីយ៉ូមិនច្បាស់លាស់ ឬហៅថាកំហុសអាចលេចឡើង។

សំណួរទីមួយគឺ តើយើងដោះស្រាយជាមួយកំហុសទាំងនេះដោយរបៀបណា បន្ទាប់ពីយើងបានបញ្ចេញផលិតផលរួចហើយ? ជាឧទាហរណ៍ តើយើងប្រតិកម្មយ៉ាងណាចំពោះភាពតានតឹង? អតិថិជននឹងមិនសប្បាយចិត្តទេប្រសិនបើទំព័រត្រូវចំណាយពេលលើសពី 30 វិនាទីដើម្បីផ្ទុក។

នេះគឺជាកន្លែងដែលការកេងប្រវ័ញ្ចចូលមកលេង ឬគេហៅវាថាឥឡូវនេះ។ DevOps. តាមពិតទៅ ទាំងនេះគឺជាមនុស្សដែលមានទំនួលខុសត្រូវក្នុងប្រតិបត្តិការផលិតផលនៅពេលដែលវាស្ថិតនៅក្នុងការផលិតរួចហើយ។ នេះរួមបញ្ចូលទាំងប្រភេទផ្សេងៗនៃការត្រួតពិនិត្យ។ មានសូម្បីតែប្រភេទរងនៃការធ្វើតេស្ត - ការធ្វើតេស្តលើការផលិតនៅពេលដែលយើងអនុញ្ញាតឱ្យខ្លួនយើងមិនសាកល្បងអ្វីមួយមុនពេលចាប់ផ្តើមហើយសាកល្បងវាភ្លាមៗលើការផលិត។ នេះគឺជាវិធានការជាបន្តបន្ទាប់ពីទស្សនៈនៃការរៀបចំហេដ្ឋារចនាសម្ព័ន្ធដែលអនុញ្ញាតឱ្យអ្នកឆ្លើយតបយ៉ាងឆាប់រហ័សចំពោះឧប្បត្តិហេតុមួយ មានឥទ្ធិពលលើវា និងកែតម្រូវវា។

ហេដ្ឋារចនាសម្ព័ន្ធក៏សំខាន់ផងដែរ។ ជារឿយៗមានស្ថានភាពនៅពេលដែលក្នុងអំឡុងពេលធ្វើតេស្ត វាមិនអាចទៅរួចទេក្នុងការធ្វើឱ្យប្រាកដថាយើងពិតជាមានអ្វីគ្រប់យ៉ាងដែលយើងចង់ផ្តល់ឱ្យអតិថិជន។ យើងរមៀលវាចូលទៅក្នុងផលិតកម្ម ហើយចាប់ផ្តើមចាប់យកស្ថានភាពដែលមិនច្បាស់លាស់។ ហើយទាំងអស់ដោយសារតែហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងការធ្វើតេស្តនេះមិនត្រូវគ្នាទៅនឹងហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងផលិតកម្ម។ នេះនាំទៅរកប្រភេទថ្មីនៃការធ្វើតេស្ត - ការធ្វើតេស្តហេដ្ឋារចនាសម្ព័ន្ធ. ទាំងនេះគឺជាការកំណត់រចនាសម្ព័ន្ធផ្សេងៗ ការកំណត់ ការផ្ទេរទិន្នន័យ ជាដើម។

នេះធ្វើឱ្យមានសំណួរ - ប្រហែលជាក្រុមត្រូវការប្រើហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។

ខ្ញុំជឿថាហេដ្ឋារចនាសម្ព័ន្ធប៉ះពាល់ដោយផ្ទាល់ដល់គុណភាពនៃផលិតផល។

ខ្ញុំសង្ឃឹមថានឹងមានរបាយការណ៍នៅក្នុងសន្និសីទជាមួយនឹងករណីពិតប្រាកដមួយ។ សរសេរមកយើងប្រសិនបើអ្នកត្រៀមខ្លួនប្រាប់យើងពីបទពិសោធន៍ផ្ទាល់ខ្លួនរបស់អ្នកអំពីរបៀបដែលហេដ្ឋារចនាសម្ព័ន្ធជាកូដប៉ះពាល់ដល់គុណភាព។ ហេដ្ឋារចនាសម្ព័ន្ធជាកូដធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការត្រួតពិនិត្យការកំណត់ទាំងអស់ និងសាកល្បងអ្វីដែលមិនអាចទៅរួច ដូច្នេះ ប្រតិបត្តិការ​ក៏​ត្រូវ​បាន​ចូល​រួម​ក្នុង​ដំណើរ​ការ​នៃ​ការ​បង្កើត​ផលិតផល​ដែល​មាន​គុណភាព។

- ចុះការវិភាគ និងឯកសារ?

នាង Anastasia៖ នេះអនុវត្តកាន់តែច្រើនចំពោះប្រព័ន្ធសហគ្រាស។ នៅពេលដែលយើងនិយាយអំពីសហគ្រាស មនុស្សដូចជាអ្នកវិភាគ និងអ្នកវិភាគប្រព័ន្ធនឹងមកក្នុងគំនិតភ្លាមៗ។ ពួកគេត្រូវបានគេហៅថាពេលខ្លះអ្នកនិពន្ធបច្ចេកទេស។ ពួកគេទទួលបានភារកិច្ចមួយដើម្បីសរសេរការបញ្ជាក់ និងបំពេញវា ឧទាហរណ៍រយៈពេលមួយខែ។

វាត្រូវបានបញ្ជាក់ម្តងហើយម្តងទៀតថាការសរសេរឯកសារបែបនេះនាំឱ្យមានការវិវឌ្ឍន៍ដ៏វែងឆ្ងាយ និងការកែលម្អឡើងវិញរយៈពេលយូរ ពីព្រោះក្នុងអំឡុងពេលនៃដំណើរការសាកល្បងត្រូវបានកំណត់អត្តសញ្ញាណ ហើយការត្រឡប់មកវិញចាប់ផ្តើម។ ជាលទ្ធផលមានរង្វិលជុំជាច្រើនដែលបង្កើនការចំណាយលើការអភិវឌ្ឍន៍។ លើសពីនេះទៀត នេះអាចណែនាំពីភាពងាយរងគ្រោះ។ យើងហាក់ដូចជាបានសរសេរកូដយោង ប៉ុន្តែបន្ទាប់មកយើងបានធ្វើការផ្លាស់ប្តូរដែលបំបែកស្ថាបត្យកម្មដែលបានគិតយ៉ាងល្អឥតខ្ចោះ។

លទ្ធផលចុងក្រោយគឺមិនមែនជាផលិតផលដែលមានគុណភាពខ្ពស់ទាំងស្រុងនោះទេ ដោយសារតែបំណះបានបង្ហាញខ្លួននៅក្នុងស្ថាបត្យកម្មរួចហើយ កូដនៅកន្លែងខ្លះមិនត្រូវបានគ្របដណ្តប់គ្រប់គ្រាន់ដោយការធ្វើតេស្តទេ ដោយសារពេលវេលាផុតកំណត់កំពុងអស់ហើយ កំហុសទាំងអស់ត្រូវបិទយ៉ាងឆាប់រហ័ស។ ហើយទាំងអស់ដោយសារតែការបញ្ជាក់ដើមមិនបានគិតពីចំណុចទាំងអស់ដែលត្រូវអនុវត្ត។

អ្នកអភិវឌ្ឍន៍មិនមែនជាសត្វល្អិត ហើយមិនសរសេរកូដដោយមានកំហុសតាមគោលបំណង។

ប្រសិនបើ​យើង​គិត​ពី​ដំបូង​តាម​រយៈ​ការ​បញ្ជាក់​ដែល​នឹង​គ្រប​ដណ្តប់​លើ​ចំណុច​ចាំបាច់​ទាំងអស់ នោះ​អ្វីៗ​នឹង​ត្រូវ​បាន​អនុវត្ត​យ៉ាង​ពិតប្រាកដ​តាម​តម្រូវការ។ ប៉ុន្តែនេះគឺជា utopia ។

វាប្រហែលជាមិនអាចទៅរួចទេក្នុងការសរសេរការបញ្ជាក់ 100 ទំព័រដ៏ល្អឥតខ្ចោះ។ នោះ​ហើយ​ជា​មូល​ហេតុ​ដែល ត្រូវគិតអំពីវិធីជំនួសនៃការសរសេរឯកសារលក្ខណៈបច្ចេកទេស ការកំណត់ភារកិច្ចដែលនឹងនាំយើងឱ្យកាន់តែខិតជិតដើម្បីធានាថាអ្នកអភិវឌ្ឍន៍ធ្វើនូវអ្វីដែលចាំបាច់។

ខាងក្រោមនេះជាវិធីសាស្រ្តពី Agile មកក្នុងចិត្ត - រឿងអ្នកប្រើប្រាស់ដែលមានលក្ខខណ្ឌទទួលយក។ នេះ​គឺ​អាច​អនុវត្ត​បាន​កាន់​តែ​ច្រើន​សម្រាប់​ក្រុម​ដែល​អភិវឌ្ឍ​ជា​បន្តបន្ទាប់​តូច។

- ចុះ​ការ​ធ្វើ​តេស្ត​សមត្ថភាព​ប្រើ​ប្រាស់​ផលិតផល​ ការរចនា?

នាង Anastasia៖ នេះ​ជា​ចំណុច​សំខាន់​ណាស់ ព្រោះ​មាន​អ្នក​រចនា​ក្នុង​ក្រុម។ ភាគច្រើនជាញឹកញាប់ អ្នករចនាត្រូវបានប្រើជាសេវាកម្ម - ទាំងដោយនាយកដ្ឋានរចនា ឬដោយអ្នករចនាខាងក្រៅ។ ជារឿយៗមានស្ថានភាពដែលវាហាក់ដូចជាអ្នករចនាបានស្តាប់អ្នកឯកទេសផលិតផលហើយបានធ្វើអ្វីដែលគាត់បានយល់។ ប៉ុន្តែនៅពេលដែលយើងចាប់ផ្តើមការនិយាយឡើងវិញ វាប្រែថាអ្វីដែលបានធ្វើគឺមិនមែនជាអ្វីដែលរំពឹងទុកនោះទេ៖ អ្នករចនាភ្លេចអ្វីមួយ មិនបានគិតទាំងស្រុងពីអាកប្បកិរិយានោះទេ ព្រោះគាត់មិននៅក្នុងក្រុម និងមិនមែននៅក្នុងបរិបទ ឬផ្នែកខាងមុខ។ -end developer មិនយល់ច្បាស់ពីប្លង់របស់វាទេ។ វា​អាច​នឹង​ត្រូវ​ចំណាយ​ពេល​ច្រើន​ដង​ដោយ​សារ​តែ​មាន​បញ្ហា​ជាមួយ​អ្នក​អភិវឌ្ឍន៍​ផ្នែក​ខាង​មុខ​ដែល​យល់​ពី​ការ​រចនា។

បូកមានបញ្ហាមួយទៀត។ ប្រព័ន្ធរចនាឥឡូវនេះកំពុងទទួលបានប្រជាប្រិយភាព។ ពួកគេកំពុងមានការឃោសនាបំផ្លើស ប៉ុន្តែអត្ថប្រយោជន៍ពីពួកគេគឺមិនជាក់ស្តែងទាំងស្រុងនោះទេ។

ខ្ញុំយល់ឃើញថា ប្រព័ន្ធឌីហ្សាញ ម្យ៉ាងវិញទៀតធ្វើឱ្យការអភិវឌ្ឍន៍មានភាពសាមញ្ញ ប៉ុន្តែម្យ៉ាងវិញទៀត ពួកគេដាក់កម្រិតជាច្រើនលើចំណុចប្រទាក់។

ជាលទ្ធផល យើងមិនបង្កើតលក្ខណៈពិសេសដែលអតិថិជនចង់បាននោះទេ ប៉ុន្តែជាអ្វីដែលងាយស្រួលសម្រាប់យើង ព្រោះយើងមានគូបមួយចំនួនដែលយើងអាចបង្កើតវាបាន។

ខ្ញុំ​គិត​ថា​នេះ​ជា​ប្រធាន​បទ​មួយ​ដែល​គួរ​មើល​ហើយ​ឆ្ងល់​ថា​តើ​ក្នុង​ការ​ព្យាយាម​ធ្វើ​ឱ្យ​ការ​រចនា​កាន់​តែ​ងាយ​ស្រួល​យើង​ពិត​ជា​កំពុង​ដោះស្រាយ​ចំណុច​ឈឺ​ចាប់​របស់​អតិថិជន។

- មានប្រធានបទគួរឱ្យភ្ញាក់ផ្អើលជាច្រើនទាក់ទងនឹងការធានាគុណភាព។ តើមានសន្និសិទនៅប្រទេសរុស្ស៊ីដែលជាកន្លែងដែលពួកគេទាំងអស់អាចត្រូវបានពិភាក្សា?

នាង Anastasia៖ មានសន្និសិទការធ្វើតេស្តចាស់ជាងគេ ដែលនឹងប្រារព្ធឡើងជាលើកទី 25 ក្នុងឆ្នាំនេះ ហើយត្រូវបានគេហៅថា SQA Days Quality Assurance Conference។ វាពិភាក្សាជាចម្បងអំពីឧបករណ៍ និងវិធីសាស្រ្តធ្វើតេស្តជាក់លាក់សម្រាប់អ្នកសាកល្បងមុខងារ។ តាមក្បួនមួយរបាយការណ៍នៅ SQA Days ពិនិត្យយ៉ាងស៊ីជម្រៅលើផ្នែកជាក់លាក់នៅក្នុងតំបន់នៃការទទួលខុសត្រូវរបស់អ្នកសាកល្បងខ្លួនឯងប៉ុន្តែមិនមានសកម្មភាពស្មុគស្មាញទេ។

នេះជួយច្រើនក្នុងការយល់ដឹងអំពីឧបករណ៍ និងវិធីសាស្រ្តផ្សេងៗ របៀបសាកល្បងមូលដ្ឋានទិន្នន័យ APIs ជាដើម។ ប៉ុន្តែនៅពេលជាមួយគ្នានេះ នៅលើដៃម្ខាង វាមិនជំរុញឱ្យមានការពាក់ព័ន្ធច្រើនជាងការសាកល្បងក្នុងការបង្កើតផលិតផលដែលប្រសើរជាងមុននោះទេ។ ម្យ៉ាងវិញទៀត អ្នកសាកល្បងមិនចូលរួមកាន់តែច្រើនក្នុងដំណើរការដើម្បីគិតអំពីគោលដៅសកលនៃផលិតផល និងសមាសភាគអាជីវកម្មរបស់វានោះទេ។

ខ្ញុំដំណើរការនាយកដ្ឋានធំមួយ ហើយធ្វើការសម្ភាសន៍ជាច្រើន ដែលពិតជាផ្តល់ការយល់ដឹងអំពីស្ថានភាពនៃឧស្សាហកម្មទាំងមូល។ តាមក្បួនមួយបុរសរបស់យើងធ្វើការនៅក្នុងសហគ្រាសហើយពួកគេមានផ្នែកច្បាស់លាស់នៃការទទួលខុសត្រូវ។ សហសេវិកដែលធ្វើការក្នុងគម្រោងបរទេសប្រើប្រភេទផ្សេងគ្នានៃការធ្វើតេស្ត: ពួកគេខ្លួនឯងអាចធ្វើការធ្វើតេស្តផ្ទុក ការធ្វើតេស្តការអនុវត្ត និងសូម្បីតែពេលខ្លះការធ្វើតេស្តសុវត្ថិភាព ដោយសារតែពួកគេពិតជាជួយក្រុមធានានូវគុណភាពនៃផលិតផល។

ខ្ញុំចង់ឱ្យបុរសនៅក្នុងប្រទេសរុស្ស៊ីចាប់ផ្តើមគិតថាឧស្សាហកម្មនេះមិនបញ្ចប់ដោយការសាកល្បងមុខងារទេ។

- សម្រាប់គោលបំណងនេះ យើងកំពុងរៀបចំសន្និសិទថ្មី QualityConf ដែលត្រូវបានឧទ្ទិសដល់គុណភាពជាវិន័យសំខាន់មួយ។ ប្រាប់យើងបន្ថែមអំពីគំនិត តើអ្វីជាគោលដៅសំខាន់នៃសន្និសីទ?

នាង Anastasia៖ យើង​ចង់​បង្កើត​សហគមន៍​មនុស្ស​ដែល​ចាប់​អារម្មណ៍​ក្នុង​ការ​ផលិត​ផលិតផល​មាន​គុណភាព។ ផ្តល់ជូននូវវេទិកាមួយដែលពួកគេអាចមក ស្តាប់របាយការណ៍ និងចាកចេញបន្ទាប់ពីសន្និសីទជាមួយនឹងការយល់ដឹងជាក់លាក់អំពីអ្វីដែលត្រូវផ្លាស់ប្តូរដើម្បីបង្កើនគុណភាព។

សព្វថ្ងៃខ្ញុំតែងតែឮការស្នើសុំពីការប្រឹក្សាអំពីអ្វីដែលត្រូវធ្វើនៅពេលដែលមានបញ្ហាជាមួយនឹងការធ្វើតេស្ត និងគុណភាព។ នៅពេលអ្នកចាប់ផ្តើមទំនាក់ទំនងជាមួយក្រុម អ្នកឃើញថាបញ្ហាមិនមែនកើតឡើងជាមួយអ្នកសាកល្បងខ្លួនឯងទេ ប៉ុន្តែជាមួយនឹងរបៀបដែលដំណើរការត្រូវបានរៀបចំឡើង។ ជាឧទាហរណ៍ នៅពេលដែលអ្នកអភិវឌ្ឍន៍ជឿថាពួកគេទទួលខុសត្រូវលើការសរសេរកូដតែប៉ុណ្ណោះ ទំនួលខុសត្រូវរបស់ពួកគេនឹងបញ្ចប់ភ្លាមៗនៅពេលដែលពួកគេប្រគល់ភារកិច្ចទៅឱ្យការធ្វើតេស្ត។

មិនមែនគ្រប់គ្នាគិតអំពីការពិតដែលថាលេខកូដគុណភាពទាបដែលសរសេរមិនល្អជាមួយនឹងស្ថាបត្យកម្មមិនល្អគំរាមកំហែងដល់បញ្ហាធំសម្រាប់គម្រោងនោះទេ។ ពួកគេ​មិន​គិត​អំពី​តម្លៃ​នៃ​កំហុស​នោះ​ទេ កំហុស​ដែល​បញ្ចប់​ក្នុង​ការ​ផលិត​អាច​នាំ​ឱ្យ​មាន​ការ​ចំណាយ​ច្រើន​សម្រាប់​ក្រុមហ៊ុន និង​ក្រុម។ គ្មាន​វប្បធម៌​ណា​ដែល​ត្រូវ​គិត​អំពី​រឿង​នេះ​ទេ។ ខ្ញុំចង់ឱ្យយើងចាប់ផ្តើមចែកចាយវានៅក្នុងសន្និសីទ។

ខ្ញុំយល់ថានេះមិនមែនជាការច្នៃប្រឌិតនោះទេ។ Edward Deming ដែលជាអ្នកនិពន្ធនៃគោលការណ៍គុណភាពចំនួន 14 បានសរសេរអំពីតម្លៃនៃកំហុសមួយនៅក្នុងសតវត្សទីចុងក្រោយ។ ការធានាគុណភាពជាវិន័យគឺផ្អែកលើសៀវភៅនេះ ប៉ុន្តែជាអកុសល ការអភិវឌ្ឍន៍ទំនើបបំភ្លេចវាចោល។

- តើអ្នកមានគម្រោងប៉ះលើប្រធានបទដោយផ្ទាល់អំពីការធ្វើតេស្ត និងឧបករណ៍ទេ?

នាង Anastasia៖ ខ្ញុំទទួលស្គាល់ថានឹងមានរបាយការណ៍អំពីឧបករណ៍។ មានឧបករណ៍ជាសកលដែលក្រុមហ៊ុន និងក្រុមអាចមានឥទ្ធិពលលើផលិតផល។

របាយការណ៍ទាំងអស់នឹងត្រូវបានរួបរួមជាសកលដោយបេសកកម្មរួមមួយ៖ ដើម្បីបង្ហាញទៅកាន់ទស្សនិកជនថា ដោយមានជំនួយពីវិធីសាស្រ្តនេះ ឧបករណ៍ វិធីសាស្រ្ត ដំណើរការ ប្រភេទនៃការធ្វើតេស្ត យើងបានជះឥទ្ធិពលលើគុណភាពនៃផលិតផល និងធ្វើឱ្យជីវិតរបស់អតិថិជនប្រសើរឡើង។

យើងប្រាកដជាមិនមានរបាយការណ៍អំពីឧបករណ៍សម្រាប់ជាប្រយោជន៍ដល់ឧបករណ៍នោះទេ។ របាយការណ៍ទាំងអស់ដែលបានរួមបញ្ចូលនៅក្នុងកម្មវិធីនឹងត្រូវបានរួបរួមដោយគោលដៅរួមមួយ។

— តើអ្នកណានឹងចាប់អារម្មណ៍លើអ្វីដែលអ្នកកំពុងនិយាយ អ្នកណាដែលអ្នកឃើញជាភ្ញៀវនៃសន្និសីទ?

នាង Anastasia៖ យើងនឹងមានរបាយការណ៍សម្រាប់អ្នកអភិវឌ្ឍន៍ដែលយកចិត្តទុកដាក់អំពីជោគវាសនានៃគម្រោង ផលិតផល ប្រព័ន្ធរបស់ពួកគេ។ ដូចគ្នានេះដែរ វានឹងមានការចាប់អារម្មណ៍ចំពោះអ្នកសាកល្បង ហើយវាហាក់ដូចជាខ្ញុំ ជាពិសេសចំពោះអ្នកគ្រប់គ្រង។ តាម​រយៈ​អ្នក​គ្រប់​គ្រង ខ្ញុំ​មាន​ន័យ​ថា​អ្នក​ដែល​ធ្វើ​ការ​សម្រេច​ចិត្ត ហើយ​អាច​មាន​ឥទ្ធិពល​លើ​ជោគ​វាសនា និង​ការ​អភិវឌ្ឍ​ផលិតផល ប្រព័ន្ធ ក្រុម​ផង​ដែរ។

ទាំងនេះគឺជាមនុស្សដែលឆ្ងល់ពីរបៀបធ្វើអោយប្រសើរឡើងនូវគុណភាពនៃផលិតផល ឬប្រព័ន្ធ។ នៅក្នុងសន្និសិទរបស់យើង ពួកគេនឹងរៀនអំពីសំណុំវិធានការផ្សេងៗ ហើយនឹងអាចយល់ពីអ្វីដែលខុសជាមួយពួកគេឥឡូវនេះ និងអ្វីដែលត្រូវផ្លាស់ប្តូរ។

ខ្ញុំគិតថាលក្ខណៈវិនិច្ឆ័យសំខាន់គឺត្រូវយល់ថាអ្វីមួយខុសគុណភាព ហើយចង់មានឥទ្ធិពលលើវា។ យើងប្រហែលជាមិនអាចទៅដល់មនុស្សដែលគិតថានេះនឹងធ្វើជាលើកដំបូងនោះទេ។

- តើអ្នកគិតថាឧស្សាហកម្មទាំងមូលមានភាពទុំជោរក្នុងការនិយាយមិនត្រឹមតែអំពីការធ្វើតេស្តប៉ុណ្ណោះទេ ប៉ុន្តែអំពីវប្បធម៌នៃគុណភាព?

នាង Anastasia៖ ខ្ញុំគិតថាខ្ញុំចាស់ទុំហើយ។ ឥឡូវនេះក្រុមហ៊ុនជាច្រើនកំពុងផ្លាស់ប្តូរឆ្ងាយពីវិធីសាស្រ្តទឹកជ្រោះប្រពៃណីឆ្ពោះទៅរកក្រុមហ៊ុន Agile ។ មានការផ្តោតអារម្មណ៍អតិថិជន មនុស្សនៅក្នុងក្រុមពិតជាចាប់ផ្តើមគិតពីរបៀបបង្កើតផលិតផលដែលមានគុណភាព។ សូម្បីតែក្រុមហ៊ុនសហគ្រាសក៏កំពុងផ្តោតលើការកែលម្អគុណភាពផងដែរ។

ដោយវិនិច្ឆ័យតាមចំនួនសំណើដែលកើតឡើងនៅក្នុងសហគមន៍ ខ្ញុំជឿថាវាដល់ពេលហើយ។ ខ្ញុំមិនប្រាកដទេថា នេះនឹងក្លាយជាបដិវត្តន៍ទ្រង់ទ្រាយធំ ប៉ុន្តែខ្ញុំចង់ឱ្យបដិវត្តន៍ក្នុងស្មារតីនេះកើតឡើង។

- យល់ព្រម! យើងនឹងបណ្តុះវប្បធម៌ និងផ្លាស់ប្តូរស្មារតី។

សន្និសីទស្តីពីការអភិវឌ្ឍន៍គុណភាពខ្ពស់នៃផលិតផល IT QualityConf នឹងកើតឡើង។ នៅទីក្រុងម៉ូស្គូ ថ្ងៃទី 7 ខែមិថុនា. អ្នកដឹងថាដំណាក់កាលអ្វីខ្លះដែលបង្កើតបានជាផលិតផលដែលមានគុណភាពខ្ពស់ យើងមានករណីនៃការប្រយុទ្ធប្រឆាំងនឹងកំហុសដោយជោគជ័យនៅក្នុងការផលិត យើងបានសាកល្បងវិធីសាស្រ្តដ៏ពេញនិយមនៅក្នុងការអនុវត្តរបស់យើង - យើងត្រូវការបទពិសោធន៍របស់អ្នក។ ផ្ញើ របស់ខ្លួន ពាក្យសុំមុនថ្ងៃទី ១ ឧសភាហើយគណៈកម្មាធិការកម្មវិធីនឹងជួយផ្តោតលើប្រធានបទសម្រាប់សុចរិតភាពទាំងមូលនៃសន្និសីទ។

ភ្ជាប់ទៅ ជជែកដែលយើងពិភាក្សាអំពីបញ្ហាគុណភាព និងសន្និសីទ សូមជាវ ឆានែល Telegramដើម្បីតាមដានព័ត៌មានកម្មវិធី។

ប្រភព: www.habr.com