هی هابر!
ما یک موضوع مهم جدید داریم - توسعه با کیفیت بالا محصولات فناوری اطلاعات. در HighLoad++ ما اغلب در مورد چگونگی ایجاد سریع سرویس‌های پرمشغله صحبت می‌کنیم، و در Frontend Conf درباره یک رابط کاربری جالب صحبت می‌کنیم که سرعتش را کاهش نمی‌دهد. ما مرتباً موضوعاتی درباره آزمایش و DevOpsConf درباره ترکیب فرآیندهای مختلف از جمله آزمایش داریم. اما در مورد آنچه که می توان به طور کلی کیفیت نامید و چگونه به طور جامع روی آن کار کرد - خیر.
بیایید این را برطرف کنیم - ما در هر مرحله از توسعه، فرهنگ تفکر در مورد کیفیت محصول نهایی را برای کاربر ایجاد خواهیم کرد. عادت به عدم تمرکز بر حوزه مسئولیت خود، و مرتبط کردن کیفیت نه تنها با آزمایش کنندگان.
در زیر برش با رئیس کمیته برنامه، رئیس تست Tinkoff.Business، خالق جامعه روسی زبان QA صحبت خواهیم کرد. آناستازیا آسیوا-نگوین در مورد وضعیت صنعت QA و ماموریت کنفرانس جدید.
- نستیا سلام. لطفا در مورد خودتان به ما بگویید.
آناستازیا: من تست را در یک بانک مدیریت می کنم، من مسئول یک تیم بسیار بزرگ هستم - ما بیش از 90 نفر هستیم. ما یک خط تجاری مهم داریم؛ ما مسئول اکوسیستم برای اشخاص حقوقی هستیم.
من مکانیک و ریاضی خواندم و در ابتدا می خواستم برنامه نویس شوم. اما وقتی پیشنهاد جالبی دریافت کردم، تصمیم گرفتم خودم را به عنوان یک آزمایشگر امتحان کنم. به اندازه کافی عجیب، معلوم شد که این تماس من بود. الان همه کارهایم را در این صنعت می بینم.
من از پیروان سرسخت رشته تضمین کیفیت هستم. من نسبت به محصولاتی که ایجاد می شوند، نحوه برخورد با کیفیت در شرکت، تیم و اصولاً در فرآیند توسعه بی تفاوت نیستم.
برای من واضح است که جامعه در این مسیر به اندازه کافی بالغ نیستحداقل در روسیه. ما همیشه نمی دانیم که تضمین کیفیت فقط آزمایش یک برنامه کاربردی برای انطباق با الزامات نیست. من دوست دارم این وضعیت را تغییر دهم.
- شما از کلمات Quality Assurance و Testing استفاده می کنید. در نگاه افراد معمولی، این دو اصطلاح اغلب با هم همپوشانی دارند. اگر عمیق بگردید چه تفاوتی با هم دارند؟
آناستازیا: بلکه تفاوتی با هم ندارند. تست بخشی از نظم و انضباط تضمین کیفیت است؛ این یک فعالیت مستقیم است - این واقعیت است که من چیزی را آزمایش می کنم. در واقع انواع مختلفی از آزمایش وجود دارد و افراد مختلفی مسئول انواع مختلف آزمایش هستند. اما در اینجا در روسیه، هنگامی که موجی از برون سپاری ها ظاهر شد که تسترها را به شرکت ها عرضه می کردند، آزمایش به یک نوع واحد کاهش یافت.
در بیشتر موارد، آنها فقط به آزمایش عملکردی محدود می شوند: آنها بررسی می کنند که آنچه توسعه دهندگان کدگذاری کرده اند با مشخصات مطابقت دارد و بس.
- لطفاً به ما بگویید چه رشته های دیگری برای تضمین کیفیت وجود دارد؟ چه چیز دیگری، علاوه بر آزمایش، در اینجا گنجانده شده است؟
آناستازیا: تضمین کیفیت قبل از هر چیز ایجاد یک محصول با کیفیت است. یعنی از خود می پرسیم که محصول ما باید چه ویژگی های کیفی داشته باشد. بر این اساس، اگر این را بفهمیم، می‌توانیم مقایسه کنیم که چه کسی بر این ویژگی‌های کیفی تأثیر می‌گذارد. مهم نیست، توسعه دهنده، مدیر پروژه یا متخصص محصول شخصی است که بر توسعه یک محصول، عقب ماندگی آن و استراتژی آن تأثیر می گذارد.
آزمایش کننده بیشتر از نقش خود آگاه می شود. او می‌داند که وظیفه‌اش فقط آزمایش انطباق با الزامات نیست، بلکه آزمایش الزامات، زیر سوال بردن فرمول‌های ارائه شده از متخصص محصول و آشکار کردن تمام الزامات و انتظارات ضمنی مشتری است. وقتی عملکرد جدیدی را به مشتری خود ارائه می دهیم، باید واقعاً انتظارات آنها را برآورده کنیم و درد آنها را برطرف کنیم. اگر به تمام ویژگی‌های کیفیت فکر کنیم، مشتری راضی خواهد شد و متوجه می‌شود که شرکتی که از محصولش استفاده می‌کند واقعاً به علایق او اهمیت می‌دهد و بر اساس اصل "فقط برای انتشار یک ویژگی" کار نمی‌کند.
- به نظر می رسد آنچه که شما توضیح دادید وظیفه یک متخصص محصول است. این، در اصل، مربوط به آزمایش و کیفیت نیست - به طور کلی در مورد مدیریت محصول است، نه؟
آناستازیا: شامل. تضمین کیفیت رشته ای نیست که یک شخص خاص مسئول آن باشد. اکنون یک جهت محبوب در آزمایش وجود دارد، رویکردی به نام تست چابک. تعریف او به وضوح بیان می کند که این یک رویکرد تیمی برای آزمایش است که شامل مجموعه خاصی از اقدامات است. کل تیم مسئول اجرای این رویکرد است؛ حتی لازم نیست یک آزمایش کننده در تیم وجود داشته باشد. کل تیم بر ارائه ارزش به مشتری و حصول اطمینان از اینکه ارزش مطابق انتظارات مشتری است متمرکز است.
- معلوم می شود که کیفیت تقریباً با تمام رشته های اطراف تلاقی می کند و چارچوبی را بر همه چیز در اطراف تحمیل می کند؟
آناستازیا: درست. وقتی به این فکر می کنیم که چگونه می خواهیم یک محصول با کیفیت ایجاد کنیم، شروع به فکر کردن در مورد ویژگی های مختلف کیفیت می کنیم. به عنوان مثال، چگونه بررسی کنیم که ما واقعاً ویژگی مورد نیاز مشتری را ایجاد کرده ایم.
اینجاست که این نوع آزمایش وارد می شود: UAT (تست پذیرش کاربر). متأسفانه، به ندرت در روسیه انجام می شود، اما گاهی اوقات در تیم های SCRUM به عنوان نسخه نمایشی برای مشتری نهایی وجود دارد. این یک نوع آزمایش نسبتاً رایج در شرکت های خارجی است. قبل از باز کردن عملکرد برای همه مشتریان، ابتدا UAT را انجام می‌دهیم، یعنی از کاربر نهایی که آزمایش می‌کند و بلافاصله بازخورد می‌دهد دعوت می‌کنیم - آیا محصول واقعاً انتظارات را برآورده می‌کند و درد را برطرف می‌کند. تنها پس از این، مقیاس‌بندی برای همه مشتریان دیگر رخ می‌دهد.
یعنی ما روی تجارت تمرکز می کنیم، روی مشتری نهایی، اما در عین حال تکنولوژی را فراموش نکنید. کیفیت محصول نیز تا حد زیادی به تکنولوژی بستگی دارد. اگر معماری بدی داشته باشیم، نمی توانیم به سرعت ویژگی ها را منتشر کنیم و انتظارات مشتری را برآورده کنیم. ممکن است هنگام تلاش برای مقیاس‌بندی، اشکالات زیادی وجود داشته باشد، یا هنگام تلاش برای بازسازی، ممکن است چیزی را بشکنیم. همه اینها بر رضایت مشتری تأثیر می گذارد.
از این منظر، معماری باید به گونه ای باشد که بتوانیم کدهای تمیزی بنویسیم که به ما امکان می دهد سریع تغییرات را ایجاد کنیم و نترسید که همه چیز را خراب کنیم. به طوری که تکرارهای تجدید نظر فقط به دلیل اینکه میراث بسیار زیادی داریم و باید مراحل آزمایش طولانی را انجام دهیم، بیش از چند ماه طول نکشند.
- در مجموع، توسعه‌دهندگان، معماران، دانشمندان محصول، مدیران محصول و آزمایش‌کنندگان خود قبلاً درگیر هستند. چه کسی دیگری در فرآیند تضمین کیفیت دخیل است؟
آناستازیا: حالا بیایید تصور کنیم که ویژگی را قبلاً به مشتری تحویل داده ایم. بدیهی است که کیفیت محصول حتی زمانی که در حال تولید است نیاز به نظارت دارد. در این مرحله ممکن است موقعیت هایی با سناریوهای غیر مشهود ظاهر شوند که اصطلاحا باگ نامیده می شوند.
اولین سوال این است که پس از انتشار محصول، چگونه با این اشکالات مقابله کنیم؟ به عنوان مثال، ما چگونه به استرس واکنش نشان می دهیم؟ اگر بارگذاری صفحه بیش از 30 ثانیه طول بکشد، مشتری خیلی خوشحال نخواهد شد.
اینجاست که استثمار وارد عمل می شود یا به قول آنها اکنون، DevOps. در واقع، اینها افرادی هستند که در زمانی که محصول در حال تولید است، مسئول بهره برداری از آن هستند. این شامل انواع مختلفی از نظارت است. حتی یک نوع فرعی از آزمایش وجود دارد - آزمایش در تولید، زمانی که به خود اجازه می دهیم چیزی را قبل از عرضه آزمایش نکنیم و بلافاصله آن را در زمان تولید آزمایش کنیم. این مجموعه ای از اقدامات از نقطه نظر سازماندهی زیرساخت است که به شما امکان می دهد به سرعت به یک حادثه واکنش نشان دهید، آن را تحت تأثیر قرار دهید و آن را اصلاح کنید.
زیرساخت نیز مهم است. اغلب مواقعی وجود دارد که در طول یک آزمایش، نمی توان مطمئن شد که ما واقعاً همه چیزهایی را که می خواهیم به مشتری ارائه دهیم، داریم. ما آن را در مرحله تولید قرار می دهیم و شروع به گرفتن موقعیت های غیر واضح می کنیم. و همه به این دلیل است که زیرساخت در آزمایش با زیرساخت در تولید مطابقت ندارد. این منجر به نوع جدیدی از آزمایش می شود - تست زیرساخت. اینها تنظیمات مختلف، تنظیمات، مهاجرت پایگاه داده و غیره هستند.
این سوال را ایجاد می کند - شاید تیم باید از زیرساخت به عنوان کد استفاده کند.
من معتقدم زیرساخت ها به طور مستقیم بر کیفیت محصول تأثیر می گذارد.
امیدوارم در کنفرانس گزارشی با یک پرونده واقعی ارائه شود. اگر آماده‌اید از تجربه خودتان به ما بگویید که چگونه زیرساخت به عنوان کد بر کیفیت تأثیر می‌گذارد، برای ما بنویسید. زیرساخت به عنوان کد، بررسی همه تنظیمات و آزمایش مواردی را که در غیر این صورت به سادگی امکان پذیر نیست، آسان تر می کند. بنابراین، عملیات نیز در فرآیند توسعه یک محصول با کیفیت دخیل است.
- در مورد تجزیه و تحلیل و مستندسازی چطور؟
آناستازیا: این بیشتر در مورد سیستم های سازمانی صدق می کند. وقتی در مورد سازمانی صحبت می کنیم، افرادی مانند تحلیلگران و تحلیلگران سیستم بلافاصله به ذهن متبادر می شوند. آنها را گاهی نویسندگان فنی می نامند. آنها وظیفه می گیرند که مشخصات بنویسند و مثلاً یک ماه آن را تکمیل کنند.
بارها ثابت شده است که نوشتن چنین اسنادی منجر به تکرارهای توسعه بسیار طولانی و تکرارهای طولانی اصلاح می شود، زیرا در طول فرآیند آزمایش اشکالات شناسایی شده و بازگشت شروع می شود. در نتیجه، حلقه های زیادی وجود دارد که هزینه های توسعه را افزایش می دهد. علاوه بر این، این ممکن است آسیب پذیری هایی را ایجاد کند. به نظر می‌رسد که ما کد مرجع نوشته‌ایم، اما سپس تغییراتی ایجاد کردیم که معماری کاملاً فکر شده را شکست.
نتیجه نهایی یک محصول کاملاً باکیفیت نیست، زیرا وصله‌ها قبلاً در معماری ظاهر شده‌اند، کد در برخی مکان‌ها به اندازه کافی تحت آزمایش قرار نمی‌گیرد، زیرا ضرب‌الاجل‌ها در حال اتمام است، همه باگ‌ها باید به سرعت بسته شوند. و همه به این دلیل که مشخصات اصلی تمام نکاتی را که باید اجرا شوند در نظر نگرفته است.
توسعه دهندگان آفت نیستند و کدهایی را با خطا نمی نویسند.
اگر در ابتدا به مشخصاتی فکر می‌کردیم که تمام نکات لازم را پوشش می‌داد، همه چیز دقیقاً همانطور که لازم بود پیاده‌سازی می‌شد. اما این یک مدینه فاضله است.
احتمالا نوشتن یک مشخصات کامل ۱۰۰ صفحه ای غیرممکن است. از همین رو باید به روش های جایگزین برای نوشتن اسناد فکر کرد، مشخصات، تعیین وظایفی که ما را به اطمینان از اینکه توسعه دهنده دقیقاً آنچه را که لازم است انجام می دهد، نزدیک تر می کند.
در اینجا رویکردهای Agile به ذهن می رسد - داستان های کاربر با معیارهای پذیرش. این بیشتر برای تیم هایی که در تکرارهای کوچک توسعه می یابند کاربرد دارد.
- تست قابلیت استفاده، قابلیت استفاده محصول، طراحی چطور؟
آناستازیا: این نکته بسیار مهمی است، زیرا طراحانی در تیم حضور دارند. اغلب، طراحان به عنوان یک سرویس استفاده می شوند - یا توسط یک بخش طراحی یا توسط یک طراح برون سپاری. اغلب موقعیت هایی وجود دارد که به نظر می رسد طراح به صحبت های متخصص محصول گوش داده و آنچه را که او درک کرده انجام داده است. اما وقتی تکرار را شروع می‌کنیم، معلوم می‌شود که آنچه در واقع انجام شده است آن چیزی نبوده است که انتظار می‌رفت: طراح چیزی را فراموش کرده است، به طور کامل به رفتار فکر نکرده است، زیرا او در تیم نیست و در زمینه یا جلو نیست. توسعه دهنده end به طور کامل طرح آن را درک نکرده است. ممکن است چندین بار تکرار شود فقط به این دلیل که در درک طراحی توسط توسعه‌دهنده فرانت‌اند مشکل وجود دارد.
به علاوه یک مشکل دیگر وجود دارد. سیستم های طراحی در حال حاضر محبوبیت پیدا می کنند. آنها تبلیغاتی هستند، اما مزایای آنها کاملاً آشکار نیست.
من با این عقیده مواجه می شوم که سیستم های طراحی از یک طرف توسعه را ساده می کنند، اما از طرف دیگر محدودیت های زیادی را برای رابط ایجاد می کنند.
در نتیجه، ما ویژگی مورد نظر مشتری را نمی‌سازیم، بلکه ویژگی مناسبی را برای ما ایجاد می‌کنیم، زیرا ما از قبل مکعب‌های خاصی داریم که می‌توانیم آن را بسازیم.
من فکر می‌کنم این موضوعی است که ارزش دارد به آن نگاهی بیندازیم و بدانیم که آیا در تلاش برای آسان‌تر کردن طراحی، واقعاً مشکل مشتری را حل می‌کنیم.
- تعداد شگفت انگیزی از موضوعات مرتبط با تضمین کیفیت وجود دارد. آیا کنفرانسی در روسیه وجود دارد که بتوان همه آنها را مورد بحث قرار داد؟
آناستازیا: قدیمی ترین کنفرانس تست وجود دارد که امسال برای بیست و پنجمین بار برگزار می شود و کنفرانس تضمین کیفیت SQA Days نام دارد. این عمدتاً ابزارها و رویکردهای آزمایشی خاص را برای آزمایشگرهای عملکردی مورد بحث قرار می دهد. به عنوان یک قاعده، گزارش‌های SQA Days عمیقاً حوزه‌های خاصی را در حوزه مسئولیت خود آزمایش‌کنندگان بررسی می‌کنند، اما نه فعالیت‌های پیچیده.
این به درک ابزارها و رویکردهای مختلف، نحوه آزمایش پایگاه داده ها، API ها و غیره کمک زیادی می کند. اما در عین حال، از یک سو، انگیزه ای برای مشارکت بیشتر از آزمایش در ایجاد یک محصول بهتر ایجاد نمی کند. از سوی دیگر، آزمایش کنندگان بیشتر درگیر این فرآیند نمی شوند تا به هدف جهانی محصول و مؤلفه تجاری آن فکر کنند.
من بخش بزرگی را اداره می‌کنم و مصاحبه‌های زیادی انجام می‌دهم که واقعاً بینشی از وضعیت صنعت به عنوان یک کل ارائه می‌کند. به عنوان یک قاعده، بچه های ما در شرکت ها کار می کنند، و آنها مسئولیت روشنی دارند. همکارانی که در پروژه های خارجی کار می کنند از انواع مختلف تست استفاده می کنند: آنها خودشان می توانند تست بارگذاری، تست عملکرد و حتی گاهی اوقات تست امنیتی انجام دهند، زیرا آنها واقعاً به تیم کمک می کنند تا از کیفیت محصول اطمینان حاصل کنند.
من دوست دارم بچه‌های روسیه نیز فکر کنند که این صنعت با آزمایش عملکردی به پایان نمی‌رسد.
— برای این منظور، ما در حال سازماندهی کنفرانس جدیدی به نام QualityConf هستیم که به کیفیت به عنوان یک رشته جدایی ناپذیر اختصاص دارد. در مورد ایده بیشتر بگویید، هدف اصلی کنفرانس چیست؟
آناستازیا: ما می خواهیم جامعه ای از افراد علاقه مند به تولید محصولات با کیفیت ایجاد کنیم. بستری را ارائه دهید که بتوانند بیایند، به گزارش ها گوش دهند و بعد از کنفرانس با درک خاصی از آنچه برای بهبود کیفیت باید تغییر کند، آنجا را ترک کنند.
این روزها اغلب درخواستی از مشاوره می شنوم که در صورت بروز مشکل در تست و کیفیت چه کاری باید انجام دهم. وقتی شروع به برقراری ارتباط با تیم‌ها می‌کنید، می‌بینید که مشکل مربوط به خود آزمایش‌کننده‌ها نیست، بلکه مشکل ساختار فرآیند است. به عنوان مثال، زمانی که توسعه دهندگان بر این باورند که آنها فقط مسئولیت نوشتن کد را بر عهده دارند، مسئولیت آنها دقیقاً در همان لحظه ای که کار را به آزمایش تحویل می دهند به پایان می رسد.
همه به این واقعیت فکر نمی کنند که کد نوشته شده ضعیف و با کیفیت پایین با معماری ضعیف مشکلات بزرگی را برای پروژه تهدید می کند. آنها به هزینه خطاها فکر نمی کنند، زیرا اشکالاتی که به تولید ختم می شوند می توانند هزینه های زیادی برای شرکت و تیم داشته باشند. هیچ فرهنگی برای فکر کردن به این موضوع وجود ندارد. من می خواهم که توزیع آن را در کنفرانس شروع کنیم.
من درک می کنم که این یک نوآوری نیست.ادوارد دمینگ، نویسنده 14 اصل کیفیت، در مورد هزینه یک خطا در قرن گذشته نوشت. تضمین کیفیت به عنوان یک رشته بر اساس این کتاب است، اما، متأسفانه، توسعه مدرن آن را فراموش کرده است.
- آیا قصد دارید مستقیماً موضوعات مربوط به آزمایش و ابزارها را لمس کنید؟
آناستازیا: اعتراف می کنم که گزارش هایی در مورد ابزارها وجود خواهد داشت. ابزارهای کاملاً جهانی وجود دارد که شرکت ها و تیم ها می توانند بر روی محصول تأثیر بگذارند.
همه گزارش ها در سطح جهانی با یک ماموریت مشترک متحد می شوند: انتقال به مخاطب که با کمک این رویکرد، ابزار، روش، فرآیند، نوع آزمایش، کیفیت محصول را تحت تاثیر قرار داده و زندگی مشتری را بهبود بخشیده ایم.
ما قطعا گزارشی در مورد یک ابزار به خاطر یک ابزار نخواهیم داشت. همه گزارش های موجود در برنامه با یک هدف مشترک متحد می شوند.
- چه کسی به آنچه شما در مورد آن صحبت می کنید علاقه مند خواهد شد، چه کسانی را مهمان کنفرانس می بینید؟
آناستازیا: ما گزارش هایی برای توسعه دهندگان خواهیم داشت که به سرنوشت پروژه، محصول، سیستم خود اهمیت می دهند. به همین ترتیب، برای آزمایش کنندگان و به نظر من، به ویژه برای مدیران، جالب خواهد بود. منظور من از مدیران افرادی است که تصمیم می گیرند و می توانند بر سرنوشت و توسعه یک محصول، سیستم، تیم نیز تأثیر بگذارند.
اینها افرادی هستند که تعجب می کنند که چگونه کیفیت یک محصول یا سیستم را بهبود بخشند. در کنفرانس ما، آنها با مجموعه‌های مختلف اقدامات آشنا می‌شوند و می‌توانند بفهمند که اکنون چه اشکالی دارد و چه چیزی باید تغییر کند.
من فکر می کنم معیار اصلی این است که بفهمیم یک چیزی با کیفیت اشتباه است و بخواهیم روی آن تأثیر بگذاریم. ما احتمالاً نخواهیم توانست به افرادی دسترسی پیدا کنیم که فکر می کنند این کار برای اولین بار انجام می شود.
- آیا فکر می کنید صنعت به عنوان یک کل آماده است که نه فقط در مورد آزمایش، بلکه در مورد فرهنگ کیفیت صحبت کند؟
آناستازیا: فکر می کنم بالغ شده ام. اکنون بسیاری از شرکت ها از رویکرد سنتی Waterfall به سمت چابک دور می شوند. تمرکز مشتری وجود دارد، افراد در تیم ها واقعاً شروع به فکر کردن در مورد چگونگی ایجاد یک محصول با کیفیت می کنند. حتی شرکت های سازمانی نیز بر روی بهبود کیفیت تمرکز می کنند.
با قضاوت بر اساس تعداد درخواست هایی که در جامعه مطرح می شود، معتقدم که زمان آن فرا رسیده است. البته مطمئن نیستم که این انقلابی در مقیاس بزرگ باشد، اما دوست دارم این انقلاب در آگاهی اتفاق بیفتد.
- موافقم! ما فرهنگ را القا خواهیم کرد و آگاهی را تغییر خواهیم داد.
کنفرانس توسعه با کیفیت محصولات فناوری اطلاعات برگزار خواهد شد در 7 ژوئن در مسکو. شما می دانید که چه مراحلی یک محصول با کیفیت را تشکیل می دهد، ما مواردی از مبارزه موفقیت آمیز با اشکالات در تولید داریم، ما روش های محبوب را در عمل خود آزمایش کرده ایم - به تجربه شما نیاز داریم. شان درخواست های قبل از 1 میو کمیته برنامه به تمرکز موضوع برای یکپارچگی کلی کنفرانس کمک خواهد کرد.
اتصال به ، که در آن در مورد مسائل کیفیت و کنفرانس بحث می کنیم، مشترک شوید برای به روز بودن از اخبار برنامه
منبع: www.habr.com