Làm thế nào để đưa kiểm tra QA vào quy trình phát triển phần mềm của bạn

Ngay cả những nhóm phát triển sáng tạo và được tài trợ tốt nhất cũng gặp phải những thách thức về phần mềm. Chỉ cần nhìn vào gần đây trục trặc phần mềm không lường trước được điều đó đã làm trì hoãn chuyến bay thử nghiệm được chờ đợi từ lâu và tạm thời giữ chiếc Mars rover Ingenuity trên mặt đất.

Nếu điều đó có thể xảy ra với hàng chục triệu đô la được đầu tư và con mắt của thế giới đang theo dõi, bạn dám cá rằng điều đó có thể xảy ra với các công ty khởi nghiệp và doanh nghiệp nhỏ. Mặc dù họ có thể không kinh doanh khám phá thế giới ngoài hành tinh, nhưng phần mềm của họ, cho dù là bản thân sản phẩm hay một phần của hệ sinh thái hỗ trợ, đều có thể coi trọng sứ mệnh như vậy. Nhưng nếu NASA thậm chí không thể ngăn chặn một vụ phóng không thành công, thì làm sao các doanh nghiệp nhỏ có thể mong đợi được?

Câu trả lời là một chiến lược kiểm tra đảm bảo chất lượng kỹ lưỡng và chi tiết. Đó là cách duy nhất để đảm bảo phần mềm mà bạn bỏ thời gian, tiền bạc và danh tiếng của mình (và của các nhà đầu tư) vào có thể cất cánh thành công.

Tại sao kiểm tra QA thường rơi vào tình thế

Nhiều công ty bỏ qua các quy trình kiểm tra QA đầy đủ nhằm mục đích đưa các sản phẩm sáng tạo ra thị trường một cách nhanh chóng. Các công ty khởi nghiệp đặc biệt có xu hướng bỏ kiểm tra phần mềm trên ổ ghi sau, và vì những lý do dễ hiểu: Thứ nhất, hầu hết các công ty mới đều muốn phá vỡ. Trò chơi của họ là di chuyển nhanh, phá vỡ mọi thứ và tạo sóng. Họ đang phát triển và lặp lại nhanh chóng trên phần mềm của họ. Và một quá trình kiểm tra QA kỹ lưỡng có thể làm chậm đà đó.

Hơn nữa, kiểm thử phần mềm có thể giống như chỉ là một thứ nữa để thêm vào danh sách kiểm tra ngày càng tăng. Các nhà phát triển bận rộn và thường xuyên sa lầy với danh sách trách nhiệm và thời hạn cao. Khi các công ty cho rằng các nhà phát triển hoặc nhóm sản phẩm bận rộn sẽ xử lý thử nghiệm, họ chỉ tạo một hộp kiểm khác trên các danh sách đã khổng lồ này. Hầu hết các nhà phát triển và nhóm sản phẩm sẽ không có khả năng kiểm tra mọi chi tiết và chạy qua kiểm tra QA kỹ lưỡng như họ cần.
Điều này không có nghĩa là những người sáng lập startup và nhà phát triển phần mềm không quan tâm đến phần mềm có lỗi. Họ đã từng gặp sự cố phần mềm trước đây và biết rằng họ không muốn đốt cháy danh tiếng của mình bằng cách tạo ra trải nghiệm người dùng kém. Đồng thời, họ không quen với việc thiết lập bộ phận QA hoặc đưa các chiến lược kiểm thử phần mềm vào nhịp điệu hàng ngày của họ. Tuy nhiên, nếu không có những biện pháp và phân tích đó, họ sẽ đặt công ty của họ và thậm chí cả người dùng, trong một số trường hợp, gặp rủi ro nghiêm trọng.

Liên quan: “Tại sao Kiểm tra QA có thể là một vấn đề đối với Doanh nghiệp của bạn”

Chi phí bỏ ưu tiên kiểm tra thích hợp

Từ góc độ tài chính, việc thiếu sự kiểm tra của một nhóm QA chuyên dụng tương đương với việc phân bổ sai nguồn lực thuần túy. Để các nhà phát triển thực hiện một chiến lược QA là cực kỳ tốn kém, bởi vì các nhà phát triển có xu hướng được trả tiền hậu hĩnh. Mong đợi họ dành thời gian thực hiện các bài kiểm tra QA khi họ có thể đang phát triển không có ý nghĩa gì về mặt tài chính. (Nói rộng ra, họ cũng bực bội với công việc này.)

Một rủi ro khác liên quan đến thương hiệu và chất lượng. Các công ty phát hành các sản phẩm subpar thường bị báo chí chê bai, đánh giá xấu và mang tiếng xấu. Điều đó khiến việc kiếm được đô la đầu tư trong tương lai hoặc tự tin đưa nhiều sản phẩm ra thị trường trở nên khó khăn hơn nhiều. Nếu sản phẩm có lỗi dẫn đến sự cố lớn của người dùng, việc thiếu kiểm tra phần mềm cũng có thể trở thành trách nhiệm pháp lý.

Lấy ví dụ về đạo đức máy tính nổi tiếng về Therac-25. Máy được thiết kế để tiến hành điều trị bức xạ cho bệnh nhân ung thư với sự trợ giúp của một máy tính tích hợp. Trong khi các mô hình thành công trước đó phụ thuộc nhiều hơn vào phần cứng để kiểm soát an toàn, tuy nhiên, Therac-25 lại dựa vào phần mềm. Các nhà phát triển đã phát hành sản phẩm này vào năm 1982, nhưng chỉ 5 năm sau, nó đã bị thu hồi khi các bệnh nhân báo cáo bị “đốt cháy” bởi chiếc máy. Hóa ra, Therac-25 đã khiến 6 bệnh nhân bị nhiễm phóng xạ quá liều, khiến 4 người thiệt mạng và 2 người bị thương nặng. Đánh giá sau đó từ các cơ quan quản lý cho thấy việc kiểm tra phần mềm không đầy đủ là một phần của vấn đề.

Liên quan: “Trường hợp tò mò về AI và trách nhiệm pháp lý”

Tất nhiên, là một trong những lỗi phần mềm tai hại nhất trong lịch sử, Therac-25 là một ví dụ điển hình cho những gì có thể xảy ra sai sót. Nhưng nó làm nổi bật rằng ngay cả những lỗi nhỏ trong phần mềm cũng có thể gây ra sự cố lớn. Tuy nhiên, nhiều công ty không biết bắt đầu từ đâu để tạo ra một chiến lược kiểm thử phần mềm hiệu quả. Các bước sau có thể giúp:

1. Ưu tiên kiểm tra QA trong các giai đoạn lập kế hoạch

Việc chồng chéo các bài kiểm tra QA lên một chiến lược phát triển phần mềm hiện có có thể đưa ra những thách thức đáng kể. Sẽ dễ dàng hơn để thêm QA ở giai đoạn đầu, ngay cả khi trò chơi kết thúc không thuê một người, nhóm QA hoặc đại lý thuê ngoài chuyên dụng. Thực sự, có một quy trình nhất quán và bài bản là hơn một nửa trận chiến khi nói đến kiểm tra QA.

Tại công ty phát triển phần mềm của tôi, chúng tôi bắt đầu thử nghiệm đưa vào quá trình phát triển với các câu chuyện của người dùng. Về cơ bản, đây chỉ là những mô tả cấp cao về các yêu cầu cụ thể. Chúng tôi xây dựng câu chuyện của người dùng vào mọi dự án mới để giúp mọi người hiểu rõ về kỳ vọng. Những câu chuyện của người dùng này bao gồm các tiêu chí chấp nhận khách quan mà chúng tôi phải đáp ứng trước khi xem xét câu chuyện hoàn chỉnh. Không có câu chuyện của người dùng và tiêu chí chấp nhận, các yêu cầu về sản phẩm trở nên khó xác định và có vấn đề. Có sẵn các câu chuyện của người dùng để tránh thông tin sai lệch về thời điểm một sản phẩm thực sự hoàn thành và liệu sản phẩm đó có đang làm những gì nó phải làm hay không.

Hãy xem xét trường hợp người quản lý sản phẩm viết một câu chuyện người dùng mô tả chức năng của sản phẩm nhưng không xác định bất kỳ tiêu chí chấp nhận nào. Kỹ sư có thể hiểu sai câu chuyện của người dùng, phát triển một sản phẩm không phù hợp với tầm nhìn của giám đốc sản phẩm. Không có ai và không có cách nào để xác nhận rằng sản phẩm đã đáp ứng các yêu cầu ban đầu, sản phẩm tiếp tục được thông qua mà không có sự đảm bảo rằng nó thực sự đang đi đúng hướng. Tiêu chí chấp nhận cung cấp một tập hợp các kỳ vọng rõ ràng để kiểm tra.

2. Xây dựng kế hoạch kiểm tra QA và danh sách kiểm tra sớm

Trong giai đoạn đầu của công ty tôi, chúng tôi dựa vào các nhà phát triển (hoặc tệ hơn là khách hàng của chúng tôi) để thử nghiệm sản phẩm của chúng tôi. Đây là trước khi chúng tôi có một nhóm QA hoặc bất kỳ loại quy trình kiểm thử phần mềm nào. Một đêm, một khách hàng gọi điện nói rằng trang web của anh ta là một trang trắng, trống rỗng. Sau khi điều tra, chúng tôi đã phát hiện ra gốc rễ của vấn đề: Bản dựng mà chúng tôi triển khai sẽ chỉ hoạt động khi mọi người đã đăng nhập vào trang web. Những người đã đăng xuất gặp thất bại ngay lập tức. Nhà phát triển của chúng tôi chỉ kiểm tra trang web trong thời gian ngắn khi đăng nhập.

Công ty của chúng tôi không phải là một cái nhìn tốt vào thời điểm đó, nhưng trải nghiệm đã đóng vai trò là động lực tuyệt vời để tạo danh sách kiểm tra thử nghiệm QA. Rốt cuộc, nếu chúng tôi đã trải qua một quá trình thử nghiệm, chúng tôi sẽ không bao giờ triển khai một trang web có thể phá vỡ đối với hầu hết mọi người dùng.

Người quản lý sản phẩm cần đặt cả danh sách kiểm tra trước khi triển khai và sau khi triển khai để giữ cho mọi thứ hoạt động như mong đợi. Nếu bạn không quen với việc thực hành các danh sách kiểm tra hiệu quả sáng tạo, hãy xem Sách của Atul Gawande Tuyên ngôn danh sách kiểm tra. Gawande phác thảo cách các ngành công nghiệp chính, bao gồm y học, sử dụng danh sách kiểm tra để ngăn chặn sự tự mãn và thực thi chất lượng. Đồng thời, anh ấy đưa ra lời khuyên tuyệt vời khi nói đến việc đảm bảo danh sách kiểm tra kiểm tra phần mềm QA không bị chìm trong các chi tiết nhỏ và trở nên không thể kiểm tra được.

Liên quan: “Danh sách kiểm tra của Lực lượng Không quân sẽ giúp bạn xây dựng một đội bền lâu”

3. Thiết lập một đường dẫn để báo cáo và theo dõi các vấn đề

Không có quy trình kiểm tra QA nào hoàn chỉnh nếu không có khuôn khổ vững chắc để báo cáo và theo dõi các vấn đề và bản sửa lỗi. Các nhà phát triển cần một cách thuận tiện để xem các lỗi do người thử nghiệm và khách hàng báo cáo cũng như các vấn đề khác và theo dõi tiến trình khắc phục chúng.

Một trình theo dõi vấn đề như Jira, GitLab hoặc GitHub có thể giúp mọi người biết về các vấn đề được báo cáo và phản hồi. GitHub thực sự có một công cụ quét mã để cảnh báo cho các nhà phát triển về các vấn đề trong công việc của họ. Các công cụ này cũng duy trì toàn bộ lịch sử thảo luận xung quanh câu chuyện của người dùng hoặc lỗi đang được xử lý. Điều này đảm bảo rằng bạn sẽ luôn có kiến ​​thức kế thừa và bối cảnh của phạm vi đầy đủ của quá trình phát triển và đổi mới.

Bất kể nhóm phát triển của bạn có xuất sắc đến đâu, đơn giản là không có thứ gì gọi là mã không có lỗi. Nhưng một chiến lược kiểm tra QA chi tiết và kỹ lưỡng được đưa vào quy trình ngay từ đầu có thể giúp bảo vệ danh tiếng của bạn và đảm bảo các khoản đầu tư của bạn được đền đáp.