Thuật ngữ “Không khiếm khuyết” là một khái niệm QA/QC nhằm mục đích giảm thiểu số lượng lỗi và sự cố trong một quy trình và thực hiện mọi việc đúng ngay lần đầu tiên. Ý tưởng chính là ngăn ngừa sai sót xảy ra hơn là sửa chúng sau khi chúng xảy ra. Khái niệm này lần đầu tiên được Philip Crosby giới thiệu trong cuốn sách “Chất lượng là miễn phí” năm 1979 của ông.
Điểm chính của việc không có lỗi không phải là đạt được sự hoàn hảo mà là thiết lập tiêu chuẩn cho các cơ chế thực hiện để đáp ứng các tiêu chuẩn đó một cách nhất quán. Không khiếm khuyết không phải là một quy trình cụ thể với các bước xác định mà là tư duy hoặc văn hóa nhà phát triển/công nghệ cần được áp dụng trong toàn bộ nhóm/công ty. Nó bao gồm các quy trình cải tiến liên tục, nhận ra chi phí cao của các vấn đề về chất lượng và chủ động làm việc để xác định và sửa lỗi trong ứng dụng và quy trình phát triển.
Khái niệm đạt được việc không có sai sót nào vẫn mang tính lý tưởng hơn là thực tế trong các trường hợp dự án thực tế. Thay vào đó, trọng tâm chuyển sang giảm thiểu các lỗi có ảnh hưởng đến doanh nghiệp/người dùng/hệ thống, đặc biệt là những lỗi đủ nghiêm trọng để phá vỡ chức năng của ứng dụng. Cách tiếp cận này nhấn mạnh tầm quan trọng của việc ưu tiên chất lượng ngay từ đầu dự án để giảm thiểu các lỗi gây tốn kém về sau.
Làm thế nào để đạt được tiêu chuẩn chất lượng cao?
- Thực hiện kiểm tra hồi quy bởi các chuyên gia QA.
Kiểm tra hồi quy có quan trọng không?
- Đúng.
Đủ chưa?
- Đó là điểm khởi đầu tốt nhưng có thể làm được nhiều việc hơn để có chất lượng phần mềm cao hơn và quy trình hiệu quả hơn.
Tự động kiểm tra/tập lệnh được kích hoạt tự động với mỗi lần triển khai bản dựng/cam kết/dàn dựng mới đảm bảo rằng các thay đổi/bản sửa lỗi đều được kiểm tra và xác thực. Sự tích hợp như vậy mang lại văn hóa cải tiến liên tục và kết quả nhanh chóng - các nhóm có thể phát hiện và giải quyết sớm các vấn đề/lỗi trong SDLC. Nó giúp cung cấp phần mềm chất lượng cao với tốc độ nhanh hơn, giới thiệu các quy trình phương pháp linh hoạt.
Việc đảm bảo tính sẵn có của các bộ dữ liệu thử nghiệm đa dạng/thực tế sẽ cải thiện phạm vi thử nghiệm và xác thực các tính năng của ứng dụng. Việc sử dụng các công cụ tạo dữ liệu (được tùy chỉnh hoặc tự viết) hoặc dữ liệu sản phẩm (của người dùng thực) bị xáo trộn để thử nghiệm có thể cải thiện việc tạo ra các kịch bản thử nghiệm hiệu quả. Việc sử dụng tính năng che giấu/làm xáo trộn dữ liệu sẽ bảo vệ thông tin nhạy cảm trong quá trình thử nghiệm, đảm bảo tuân thủ các chính sách bảo mật và bảo vệ dữ liệu.
Kết hợp hoặc thay thế thử nghiệm hồi quy bằng thử nghiệm thăm dò có thể cải thiện phạm vi thử nghiệm và phát hiện ra các lỗi hồi quy bất thường. Các kỹ sư QA có thể sử dụng kiến thức và trực giác về lĩnh vực của mình để khám phá ứng dụng nhằm tìm ra các vấn đề/lỗi “ẩn” có thể bị bỏ sót trong các thử nghiệm hồi quy (kiểm tra tự động). Cách tiếp cận kết hợp linh hoạt này giúp các nhóm tìm ra các vấn đề phức tạp phức tạp và các trường hợp góc cạnh mà các bài kiểm tra hồi quy tiêu chuẩn có thể dễ dàng bỏ qua.
Việc kết hợp kiểm tra hiệu suất và bảo mật với kiểm tra hồi quy chức năng là điều quan trọng để không bỏ sót các vấn đề về hiệu suất và bảo mật ứng dụng. Đây là tiêu chuẩn để kiểm tra hiệu suất và bảo mật ứng dụng của bạn, nhưng chúng được thực hiện dưới dạng kiểm tra hồi quy trong trường hợp khi có những thay đổi đáng kể được thực hiện và hiệu suất ứng dụng có thể bị ảnh hưởng hoặc các lỗ hổng mới có thể xuất hiện trong hệ thống của bạn.
Việc sử dụng thử nghiệm trên nhiều trình duyệt (đa nền tảng/thiết bị) cho phép kỹ sư QA xác thực chức năng và bố cục ứng dụng trên các trình duyệt, phiên bản, hệ điều hành, thiết bị (phần cứng) và độ phân giải màn hình khác nhau. Điều quan trọng là phải hiểu phạm vi hợp lý và chỉ thực hiện các thử nghiệm cần thiết vì loại thử nghiệm này có thể tốn thời gian nhưng có thể nhanh hơn bằng cách sử dụng các nền tảng như BrowserStack hoặc trang trại thiết bị + tự động hóa của riêng bạn. Tuy nhiên, việc này tốn nhiều tài nguyên hơn, chẳng hạn như kiểm thử hồi quy API hoặc hồi quy chức năng, vì vậy hãy cẩn thận và tối ưu hóa phạm vi theo những thay đổi đã thực hiện và các rủi ro đã được chứng minh.
Xác định các rủi ro hồi quy tiềm ẩn và lập kế hoạch cho các hoạt động kiểm tra hồi quy ở các giai đoạn triển khai tính năng/thay đổi mã trước đó. Sự tham gia sớm này đã thiết lập sự hợp tác giữa nhóm phát triển và nhóm QA, giảm thiểu việc làm lại, sửa lỗi, số lần lặp lại thử nghiệm, thử nghiệm hồi quy bổ sung và tăng tốc thời gian đưa sản phẩm ra thị trường.
Có cái gì khác có thể hữu ích?
- Tất nhiên rồi! Luôn có điều gì đó khác hoặc mới mà bạn có thể sử dụng để cải thiện cách tiếp cận và chất lượng sản phẩm của mình ngay cả khi bạn sử dụng các phương pháp hay nhất. Bất kỳ cách tiếp cận nào cũng cần được điều chỉnh và điều chỉnh cho phù hợp với dự án, nhóm và tình huống cụ thể của bạn.
Đó là từ lĩnh vực hệ thống phân tán; nó liên quan đến việc cố tình đưa sự hỗn loạn có kiểm soát vào một hệ thống để phát hiện ra những điểm yếu và thất bại. Theo truyền thống, nó được sử dụng để thử nghiệm khả năng phục hồi, nhưng kỹ thuật hỗn loạn có thể được điều chỉnh để thử nghiệm hồi quy.
Trong thử nghiệm hồi quy, kỹ thuật hỗn loạn đặt phần mềm vào các điều kiện/bộ dữ liệu khác nhau và không thể đoán trước tương tự như prod envs. Bằng cách cố tình làm gián đoạn/thay đổi một số thành phần, chẳng hạn như kết nối mạng, phần phụ thuộc hoặc cơ sở hạ tầng, người thử nghiệm/nhà phát triển có thể biết cách ứng dụng phản hồi với đầu vào không mong muốn.
Việc tích hợp Kỹ thuật hỗn loạn vào các quy trình kiểm tra hồi quy sẽ cung cấp thêm các cách để xác định và khắc phục các rủi ro/lỗi hồi quy tiềm ẩn trước khi chúng ảnh hưởng đến người dùng cuối hoặc quy trình kiểm tra ở các giai đoạn sau.
Kiểm tra đột biến là một kỹ thuật trong đó những thay đổi nhỏ được thực hiện đối với mã nguồn để mô phỏng các lỗi tiềm ẩn. Bằng cách đánh giá danh sách kiểm tra/trường hợp kiểm thử phát hiện những thay đổi/lỗi này tốt đến mức nào, kỹ sư QA có thể đánh giá tính hiệu quả của các bài kiểm tra hồi quy của họ. Cách tiếp cận này cung cấp thông tin về tính hiệu quả của bộ thử nghiệm và hiển thị các trường hợp/lĩnh vực cần thay đổi bổ sung.
Các công cụ sử dụng thuật toán học máy để xác định nguyên nhân cơ bản gây ra lỗi hồi quy có thể khá hữu ích cho chiến lược kiểm tra hồi quy. Bằng cách phân tích các thay đổi mã, kết quả kiểm tra và nhật ký hệ thống, những công cụ này có thể gợi ý nguồn hồi quy. Cách tiếp cận này tăng tốc độ ngăn ngừa và giải quyết lỗi, đồng thời giảm thời gian điều tra, cải thiện năng suất tổng thể và thời gian đưa ra thị trường. Các công cụ/thuật toán dựa trên AI cũng có thể phân tích các thay đổi mã và kết quả kiểm tra (số liệu thống kê) để xác định các kiểm tra phù hợp nhất để thực thi.
Luôn nhớ rằng bạn cần hiểu những rủi ro và biết số liệu thống kê của mình về các lỗi hồi quy. Trong nhóm sản phẩm, cộng tác giữa tất cả các thành viên trong nhóm (nhà phát triển, QA, PM, PdM/PO/FO, DevOps, v.v.), bạn có thể đánh giá các rủi ro tiềm ẩn một cách hiệu quả và thu hẹp các khu vực hồi quy đến mức tối thiểu. Điều quan trọng nữa là phải chấp nhận một số mức độ rủi ro để vận chuyển nhanh hơn (lỗi hồi quy trong các tính năng hiếm khi được sử dụng hoặc không quan trọng có thể được chấp nhận và sửa chữa sau này).
Tránh kiểm tra quá mức chỉ vì “chất lượng lý tưởng” hoặc khái niệm Không khiếm khuyết.