چگونه مطمئن شویم که محصول با کیفیتی ساخته‌ایم یا داریم می‌سازیم؟ واقعیت این است که «تست» سازوکار و شیوه‌ای است برای اطمینان از کیفیت مورد انتظار از محصول. اما، «کیفیت» مفهومی است که تشخیص آن بسیار دشوار است. کاربران بیشتر به ویژگی‌های قابل مشاهده از بیرون، مانند سرعت و قابلیت استفاده، نگاه می‌کنند. ذینفعان کسب‌وکار به عملکرد مالی توجه می‌کنند. توسعه‌دهندگان بیشتر به ساختار کُد و آنچه درون کُدهای محصول است، اهمیت می‌دهند. وقتی در نقش یک کارشناس تست قرار می‌گیریم باید خودمان را جایی بین این دو سر طیف قرار دهیم و سعی کنیم همه‌ی نقاط را به هم وصل کنیم. سطوح مختلف کیفیت و دیدگاه‌های متفاوت، اغلب منجر به اختلاف نظر می‌شود. یک کاربر ممکن است چیزی را یک اشکال (باگ) در نظر بگیرد، اما توسعه‌دهندگان ممکن است آن را به عنوان یک درخواست بهبود طبقه‌بندی کنند. چیزی که یک نفر آن را حیاتی می‌داند ممکن است حتی در مقیاس اهمیت برای فردی از گروهی دیگر این طور تلقی نشود. به همین دلیل است که می‌توان انتظار داشت یک نقص به‌ظاهر حیاتی برای ماه‌ها در یک محصول نرم‌افزاری باقی بماند. همچنین به همین دلیل است که می‌توان نرم‌افزار را برای مشتریان عرضه کرد، حتی زمانی که افراد تیم تحویل بدانند که محصول‌شان حاوی «بدهی فنی» زیادی است.
چنین موقعیت‌هایی ممکن است فضای دشواری را ایجاد کند به خصوص ممکن است با شرایطی مواجه شویم که در آن کسانی که مسئولیت تست محصول را برعهده دارند، احساس کنند به آنها گوش داده نمی‌شود و توسعه‌دهندگانی که احساس می‌کنند تست‌کنندگان محصول توجهی به بی‌اهمیت بودن یکسری مسائل ندارند و پیوسته مسائلی را مطرح می‌کنند که اهمیت کمتری دارند. ذینفعان کسب‌وکار هم در حالی‌که زمان در حال سپری شدن است، شروع به ابراز نارضایتی از افراد و تیم‌های مسئول تحویل محصول می‌کنند و این تیم‌های تحویل نیز به دلیل اصرار بر سرعت که ممکن است تحویل را ناپایدار کند، نسبت به ذینفعان کسب‌وکار ابراز نارضایتی می‌کنند. وجود چنین اختلافاتی مشکل‌ساز است.
به راحتی می‌توان افراد و گروه‌های دیگر را به دلیل عدم اطلاع و ایجاد این سوء تفاهم سرزنش کرد، اما مسئله واقعی این است که ما اغلب دیدگاهی ساده نسبت به کیفیت داریم و به ندرت تصویر بزرگ را می‌بینیم. یک راه حل خوب برای رفع این سوء تفاهم، ایجاد یک دید چند لایه و چند وجهی از کیفیت است که گروه‌های مختلف بتوانند در مورد آن توافق کنند.
برای این منظور می‌توانیم به مدل سلسله‌مراتب نیازهای انسانی مازلو متوسل شویم. سلسله‌مراتب معروف مازلو نیازهای انسان را به صورت یک هرم توصیف می‌کند که در آن نیازهای ضروری برای کارکردهای اساسی (مانند غذا، آب) در سطح پایین، ایمنی (امنیت شخصی، سلامت، امنیت مالی)، عشق و تعلق (دوستی، صمیمیت) و احترام (شایستگی، احترام) در سطوح میانه‌ی این سلسله‌مراتب جای می‌گیرد و خودشکوفایی (توانایی به انجام رساندن پتانسیل خود) در رأس این سلسله‌مراتب قرار دارد. پیش‌فرض سلسله مراتب نیازها این است که وقتی نیاز سطح پایین‌تر برآورده نمی‌شود، نیازهای سطح بالاتر را نادیده می‌گیریم. به عنوان مثال، وقتی فردی غذا، صمیمیت و احترام کافی ندارد، غذا مهم‌ترین چیز است. فرض دیگر این است که ارضای نیازها در سطوح پایین هرم پس از مدتی بازدهی کاهشی را به همراه دارد. خوردن غذای بیشتر از نیاز ما باعث چاقی می‌شود. امنیت فرودگاه بیش از حد نیاز، به دردسر تبدیل می‌شود. کیفیت زندگی ما با ارضای نیازهای سطح بالاتر پس از ارضای نیازهای سطح پایین بهبود می‌یابد. البته، باید توجه داشته باشیم که مانند هر مدل دیگری، این مدل نیز یک انتزاع است و به راحتی می‌توان انواع استثناها را برای آن پیدا کرد، اما به طور کلی وضعیت را به خوبی نشان می‌دهد. ما می‌توانیم کاری مشابه برای نرم‌افزار انجام دهیم.
با ترسیم یک مدل به موازات سطوح مختلف نیازها، می‌توانیم هرمی از سطوح کیفیت نرم‌افزار ایجاد کنیم. نتیجه، چیزی شبیه تصویر زیر می‌شود:
بر اساس این مدل، از پایین‌ترین سطح هرم به سمت سطوح بالاتر، به ترتیب با پرسش‌های زیر در خصوص کیفیت محصول مواجه هستیم:
- آیا محصول اصلاً کار می‌کند؟ ویژگی‌های کلیدی، ویژگی‌های فنی کلیدی محصول چیست؟
- آیا محصول خوب کار می‌کند؟ جنبه‌های کلیدی عملکرد، امنیت و مقیاس‌پذیری محصول چیست؟
- آیا محصول قابل استفاده (usable) هست؟ سناریوهای کلیدی قابلیت استفاده (usability) چیست؟
- آیا محصول مفید (useful) است؟ چه معیارهای عملیاتی‌ای (production metrics) نشان می‌دهد که در کار واقعی استفاده می‌شود؟
- آیا محصول موفق (successful) است؟ چه معیارهای کسب‌وکاری (business metrics) نشان می‌دهد که این کار ارزش انجام را داشت؟ آیا در چارچوب قیدها و محدودیت‌های مالی عمل می‌کند؟
اولین سطح سلسله مراتب مازلو نیازهای فیزیولوژیکی است و همانطور که این‌ها اساسی‌ترین نیازهای انسان هستند، در مورد یک محصول نرم‌افزار نیز می‌توان چنین گفت که اگر اساسی‌ترین چیزها برآورده نشود، نرم‌افزار کاملاً بی‌فایده خواهد بود. برای این وضعیت خاص، ما دو نیاز کلیدی و بنیادی را می‌توانیم مورد توجه قرار دهیم: اینکه نرم‌افزار باید قابل استقرار باشد و اینکه باید حداقل عملکرد (فانکشنالیتی) را برآورده کند تا «کار کند». فعالیت‌هایی مانند TDD، تست عملکردی (اتوماتیک + دستی)، تست پس از استقرار و موارد مشابه به ما کمک می‌کند ثابت کنیم که این دسته از نیازها برآورده شده است. اندازه‌گیری تعداد اشکالات (باگ‌ها) و روندشان، میزان پوشش کُد و مانند آن نیز به همین سطح مرتبط است. همانند نیازهای فیزیولوژیکی انسان، حداقل‌های ضروری کافی است (به اصطلاح، enough is enough) و پس از یک حدی، دیگر ارزش افزوده‌ای به دست نمی‌آید! به عنوان مثال، نسخه‌های جدیدتر مایکروسافت آفیس دارای صدها ویژگی هستند که هیچ کس هرگز از آنها استفاده نمی‌کند، زیرا حتی نسخه‌های پیشین هم بیشتر نیازها را برآورده می‌کردند و به اندازه کافی بودند. سرمایه‌گذاری روی ویژگی‌های بیشتر، توسعه، آزمایش و نگهداری آنها، بی‌فایده و حتی آسیب‌رسان است! و می‌تواند موجب شکست پروژه شود.
هنگامی که نرم‌افزار «کار می‌کند»، به سطح دوم سلسله‌مراتب می‌رسیم که دومین چیزی است که به آن نیاز داریم و آن این است که محصول باید «به خوبی کار کند». با نگاهی مشابه بین نیازهای امنیتی انسان و آنچه ما از محصول نرم‌افزاری نیاز داریم، اینجا جایی است که آنچه عموماً تحت عنوان نیازهای «غیر عملکردی (Non-functionals)» (یا به عبارت دیگر، ویژگی‌های کیفی) از آنها یاد می‌شود، مطرح می‌شوند – مواردی نظیر کارایی (performance)، قابلیت اطمینان (reliability)، امنیت (security) و مانند آن. در این سطح، فعالیت‌هایی مانند طراحی معماری و بهینه‌سازی کارایی محصول مورد توجه قرار می‌گیرند و تست کارایی (performance testing)، تجزیه و تحلیل نفوذ (penetration analysis)، تست‌های استرس (stress tests) و مانند آن ممکن است ثابت کنند که ما به اندازه‌ی کافی نیازهای مشتری را برآورده کرده‌ایم. و باید توجه داشته باشیم که در تناظر با نیازهای امنیتی انسان، باز هم باید این ملاحظات به اندازه‌ی کافی مورد توجه قرار گیرد (در این مورد هم، به اصطلاح، enough is enough). برای مثال، پرسش‌های امنیتی که در فروشگاه اپل آیتونز درنظر گرفته شده بود نشان داد که داشتن ویژگی‌های امنیتی بیشتر از آنچه در این فضا نیاز است، کاربران را آزار می‌دهد یا موجب هدر رفتن منابع مالی می‌شود. ساختن سیستمی که بتواند میلیون‌ها کاربر همزمان را مدیریت کند، در حالی که در سال آینده نهایتاً حدود هزار کاربر خواهیم داشت، اتلاف وقت وحشتناکی است که باید از آن پرهیز کنیم. متأسفانه، بسیاری از شرکت‌ها به جای اینکه تمرکز روی ارزش‌هایی که به منجر به تداوم کار و درآمدزایی می‌شوند، روی بهینه‌سازی مواردی تمرکز می‌کنند که موجب به هدر رفتن منابع و از دست دادن فرصت‌ها شده و موجبات شکست محصول را ایجاد می‌کنند.
چنانچه محصول نرم‌افزاری عملکرد خوبی داشته باشد و به اندازه‌ی کافی ایمن باشد، سطح بعدی (سطح سوم) توجه ما به نیازهای عشق و تعلق است! – و اکنون باید به سراغ کاربران نرم‌افزار برویم. فعالیت‌هایی مانند طراحی تجربه‌ی کاربری، طراحی گرافیکی، مشارکت اجتماعی و پشتیبانی برای رفع نیازهای کاربران در سطح عشق/ تعلق قرار می‌گیرد. تست کاربردپذیری (usability testing) می‌تواند در این سطح برای اثبات کیفیت مورد انتظار به کار گرفته شود. البته نرم‌افزارهای مختلف به سطوح مختلفی از این نیازهای مورد توجه در این سطح، نیاز دارند.
نیازهای مطرح تا این سطح، در بیشتر پروژه‌ها مورد توجه قرار می‌گیرند. در واقع، این سه سطح جایی هستند که بیشتر سرمایه‌گذاری در توصیف، توسعه و تست محصول‌های نرم‌افزاری انجام می‌شود و تقریباً با سطوح سلسله‌مراتب نیازهای مازلو نیز متناسب است. کمی دقیق‌تر توجه کنیم می‌بینیم که بیشتر سرمایه‌گذاری صرف ایجاد کارکردها (functionality) و تست آن می‌شود. برای نیازهایی نظیر کارایی (performance) و مواردی از این قبیل، گاهی اوقات برنامه‌ریزی‌هایی انجام می‌شود، اغلب تیم‌ها رویکردی واکنشی (reactive) به این جنبه‌ها دارند و در نتیجه، چنین جنبه‌هایی از نیازهای محصول کمتر مورد تست و آزمایش قرار می‌گیرد. با در نظر گرفتن مدل هرمی، می‌توان امیدوار بود که تیم‌ها به برقراری توازن و تعادلی در سرمایه‌گذاری‌های‌شان در سطوح مختلف نیازهای سلسله‌مراتبی توجه داشته باشند. اما، نکته‌ی کلیدی دیگر این است که توجه به دو سطح بالاتر در سلسله‌مراتب نیازهای کیفی محصول نیز می‌تواند ارزش قابل توجهی برای ذینفعان ایجاد کند. واقعیت این است که عدم توجه به سطوح بالاتر حتی ممکن است با وجود کیفیت مطلوب در سطوح پایین‌تر، منجر به شکست محصول در بازار شود! این موضوع را دست کم نگیرید.
در سال 2009، نوکیا شروع به کار بر روی یک سرویس جدید به نام Ovi کرد تا با کمک آن ایمیل، چت، پیامهای فوری (IM) و سایر خدمات فعلی و آینده را با هم ادغام کند. نوکیا پول زیادی برای توسعه این محصول خرج کردند. نوکیا – یک پیشرو در فناوری – این طور بیان می‌کرد که «ما خود را به عنوان یک ارائه‌دهنده خدمات، دوباره بازتعریف (reinvent) کرده‌ایم»؛ اما هیچ‌کس خدمات آنها را نمی‌خواست. اشتباه نکنید، طراحی تعامل با کاربر بد نبود، یا حتی تفکر طراحی اشتباهی نداشتند – فقط این نکته هست که این پایان کار نیست. این‌ها نیازهایی هستند که باید برآورده شوند، اما پس از آن، به یک نقطه‌ی بازدهی کاهشی می‌رسیم. در واقع، مسأله این است که نیازهایی در سطوح بالاتر وجود دارد.
نکته‌ی کلیدی که در داستان Nokia Ovi مورد توجه قرار نگرفته بود، نیاز به تحقق پتانسیل (fulfillment of potential) است. کاربردپذیری پتانسیل (یا ظرفیت بالقوه) را نشان می‌دهد ولی اگر کسی از آن استفاده نمی‌کند، آیا برای ما مهم است؟ سطح بالاتر از قابلیت استفاده (usability)، مفید بودن (usefulness) است. بهتر است در اینجا یادی کنیم از قانون 20/80 یا اصل پارتو. واقعیت این است که به طور متوسط، 20 درصد از کارکردها و ویژگی‌های محصول هستند که واقعاً برای کاربران بالقوه، مفید واقع می‌شوند و همین 20 درصد برای توجیه سرمایه‌گذاری در توسعه و نگهداری بیشتر محصول باید مورد توجه قرار گیرند. آیا بهتر نیست که به جای سرمایه‌گذاری هنگفت برای تست کارکردی (functional testing)، روی اندازه‌گیری سودمندی محصول نرم‌افزار سرمایه‌گذاری کنیم؟ این موضوعی است که باید در سطح چهارم سلسله‌مراتب نیازهای کیفیت محصول مورد توجه قرار دهیم. اتفاقاً، امروزه بسیاری از کسب‌وکارهای پیشرو کیفیت خود را بیشتر در سطح چهارم تعریف می‌کنند تا سطح اول، و در نتیجه این کسب‌وکارها قادر خواهند بود تا بهره‌وری بسیار بیشتری داشته باشند. اگر شاخص‌های مورد انتظار کاربران سطح کسب‌وکار وجود نداشته باشد یا مورد توجه قرار نگیرد، پس دیگر ویژگی‌های محصول چه اهمیتی خواهند داشت. به این موضوع می‌توان مانند یک باگ کسب‌وکاری (business bug) فکر کرد!
در نهایت، این واقعیت که شخصی از یک ویژگی استفاده می‌کند، لزوماً به این معنی نیست که این ویژگی در وهله‌ی اول برای کسب‌وکار مناسب بوده است. این پنجمین سطح و در واقع، آخرین سطح در سلسله مراتب نیازها است که متناظر با خودشکوفایی (self-actualization) است. آیا نرم‌افزار به آنچه در ابتدا در نظر گرفته شده بود (یعنی، مقصود تعریف شده برای ایجاد محصول)، دست یافته است؟ آیا باعث صرفه‌جویی مالی، کسب درآمد یا رشد کسب‌وکار شده است یا خواهد شد؟ یا هر آنچه که اهداف کلیدی کسب‌وکار در ابتدا بودند. اگر نه، پس واقعاً مهم نیست که افراد از آن استفاده می‌کنند، قابل استفاده یا کارآمد است یا اینکه تمام تست‌های کارکردی آن موفق هستند. این سطح بالا از سلسله‌مراتب نیازهای کیفیت محصول، جایی است که به معنای واقعی با «بیشتر بهتر است (یا به اصطلاح، more is better)» روبرو هستیم.
چنین هرمی می‌تواند به تیم‌های توسعه‌دهنده‌ی محصول کمک کند تا معیارهای پذیرش را در هر یک از سطوح تعریف کنند و توافق مشترکی را در مورد آنچه که کل گروه در مورد کیفیت محصول بدان فکر می‌کنند، ایجاد کند.
تجسم مشترک جنبه‌های مختلف کیفیت به همه‌ی ما کمک می‌کند تصویر بزرگ را ببینیم. بدین ترتیب، می‌توانیم از صرف زمان زیاد برای بهبود جنبه‌هایی که در حال حاضر به میزان رضایت بخشی هستند و در معرض خطر نیستند، اجتناب کنیم.
اگرچه سطوح بالاتر هرم – که معمولاً با معیارهای عملیاتی (production metrics)، سناریوهای استفاده (usage scenarios) و محدودیت‌های عملیاتی (operational constraints) مشخص می‌شوند – ممکن است در طول فرایند توسعه‌ی محصول به طور کامل قابل تست نباشند، اما زمینه‌ی مفیدی برای طراحی راه‌حل مناسب فراهم می‌کنند و ممکن است برای جلسات تست اکتشافی نکات مفیدی در بر داشته باشند.
بسیاری از تیم‌ها بدون داشتن یک تعریف کل‌نگرانه از کیفیت، مواردی مانند روند اشکالات، پوشش کُد و مانند آن را (که عمدتاً به کیفیت کُد مرتبط می‌شود) اندازه‌گیری می‌کنند. واقعیت این است که آنچه اندازه‌گیری می‌شود، بهینه می‌شود، بنابراین در نهایت به اینجا می‌رسیم که چیزهایی بیش از حد، بهینه شده‌اند. در قیاس با سلسله‌مراتب مازلو، درست است که هوا و غذا یک ضرورت است، اما داشتن هوا و غذای بیشتر از نیاز ما، واقعاً کیفیت زندگی را بهبود نمی‌بخشد (و حتی ممکن است آسیب رسان هم باشد!). مشابه آن، صحت فنی و عملکرد ضروری است، اما فراتر رفتن از یک نقطه خاص، بازدهی کمتری به ما می‌دهد.
در نهایت، هدف کلی از ایجاد یک تصویر بزرگ مشترک، همسو کردن انتظارات در میان گروه‌های مختلف است. و البته برای رسیدن به این توافق، باید در یک محیط متقابل و مشارکتی، ذینفعان انتظارات‌شان از جنبه‌های مختلف کیفیت در هر یک از سطوح سلسه‌مراتب را شفاف و قابل‌اندازه‌گیری کنند.
بنابراین، به تدریج باید برای همه‌ی سطوح، مجموعه‌ای از سناریوهای تست تعریف شود.
در پایان، خوب است توجه داشته باشیم که جدول زمانی یا بودجه‌ی یک پروژه هرچه که باشد، همیشه بهتر است که یک مدل واضح و یک مبنای پایه‌ای برای کیفیت محصول داشته باشیم. این به برنامه‌ریزی درست فرایند توسعه‌ی محصول و نهایتاً ارائه‌ی یک محصول بهتر و مشتری‌مدار کمک می‌کند.