Hãy tập trung nhiều vào Hỗ Trợ Chất Lượng (Quality Assistance) chứ không chỉ Đảm Bảo Chất Lượng (Quality Assurance)

Leader dự án, developer, QA thường nghĩ vai trò của QA trong dự án là đảm bảo chất lượng. Khi QA được join vào dự án thì mọi người thường mong muốn QA thực hiện được các công việc:

1. Đảm bảo rằng các chức năng đang được built hoạt động đúng như mong đợi
2. Đảm bảo chức năng hoạt động không đúng như mong đợi được phát hiện ra, và xác nhận sau khi đã được sửa thì các chức năng đó và chức năng liên quan hoạt động đúng

Tuy nhiên tôi đã từng có cơ hội làm các dự án mà QA không chỉ bên phía mình, mà cả QA bên khách hàng. Tôi nhận ra rằng QA khách hàng làm rất nhiều việc, không đơn thuần là ngồi test... Và trong nhiều dự án, khách hàng cũng đề xuất ý kiến, mong muốn QA thực hiện được thêm nhiều công việc hơn nữa, ngoài việc chỉ báo cáo cho họ sản phẩm bị những lỗi gì... Ở đây tôi xin liệt kê một số công việc mà tôi nghĩ QA hoàn toàn có thể đảm nhận để Hỗ Trợ Chất Lượng cho dự án.

1. Thảo luận với BA (chuyên gia phân tích - Business Analyst)
2. Đặt câu hỏi với chủ sở hữu sản phẩm (nếu có thể thì đặt câu hỏi với người dùng cuối) về trải nghiệm người dùng và mục tiêu của từng bộ phận của sản phẩm
3. Hỗ trợ chủ sở hữu sản phẩm và BA với bất kỳ sự hiểu biết về kỹ thuật nào: xác định số lượng người dùng đồng thời dự kiến, giải thích làm thế nào để xác định khối lượng giao dịch cao nhất, cung cấp quyền truy cập vào môi trường và hiểu biết sâu sắc về cách thức nhóm đang xây dựng sản phẩm.

Thứ nhất, tôi xin làm rõ về việc thảo luận với BA.

Trong một dự án phần mềm, BA sẽ thực hiện các công việc sau:

1. Làm việc với khách hàng, từ việc khơi gợi / khai thác yêu cầu, phân tích và đề xuất những giải pháp phù hợp, mô hình hóa các quy trình, tài liệu hóa yêu cầu… và xác nhận thông tin với khách hàng

2. Chuyển giao thông tin cho nội bộ team, bao gồm cả team phát triển dự án như PM, DEV, QC, … hay những team liên quan đến dự án bạn đang thực hiện hoặc 1 module được nhúng hay tích hợp vào hệ thống mà bạn đang phụ trách.

3. Quản lý sự thay đổi của yêu cầu vì bản chất của Business là luôn thay đổi, vì vậy sẽ có những yêu cầu theo thời gian cần phải được cập nhật lại. Do đó, BA cần phải phân tích được những ảnh hưởng của sự thay đổi đó đến tổng thể hệ thống và phải quản lý được sự thay đổi đó qua từng phiên bản được cập nhật trong tài liệu

Bản thân QA cũng là người cần phải check tài liệu khách hàng cung cấp cho. Nếu không được tham gia từ giai đoạn sớm, những đóng góp ý kiến QA về việc làm rõ yêu cầu, hoặc có thể đề xuất thay đổi yêu cầu sẽ bị quá trễ... sẽ làm ảnh hưởng đến cả tiến độ và chất lượng của dự án. Trong quá trình trao đổi với BA, QA sẽ cùng BA phân tích tài liệu, cùng đề xuất giải pháp, đặt câu hỏi cho khách hàng... một cách đầy đủ nhất trong thời gian sớm nhất có thể. Những trường hợp BA còn chưa để ý tới, bị bỏ sót thì QA sẽ là người hỗ trợ để việc confirm được đầy đủ và rõ ràng hơn. QA cũng sẽ follow được những thay đổi của requirement, đồng thời hỗ trợ BA kiểm soát xem những thay đổi này đã được cập nhật trong tài liệu và những người thực hiện requirement này đã được phổ biến yêu cầu đầy đủ chưa.

Thứ hai, về việc đặt câu hỏi với chủ sở hữu sản phẩm, với người dùng cuối cùng, khi có cơ hội nhận được thông tin từ người dùng cuối cùng QA sẽ có các cơ hội sau

• hiểu được môi trường người dùng sẽ tác nghiệp, để xây dựng một môi trường kiểm thử sát thực nhất

• đưa ra những flow nghiệp vụ sát nhất với thao tác người dùng

• đề xuất thêm những tính năng mới, những chức năng mới, chủ động đáp ứng nhiều hơn nữa kỳ vọng của khách hàng về sản phẩm

• đề xuất thay đổi vị trí, diện mạo, cách thức xử lý... của các chức năng cũ cho dễ hiểu, dễ dùng, người dùng sẽ thao tác tiện hợi, nhanh chóng, giảm thời gian và tiền bạc

Đối với một số sản phẩm đã bán cho khách hàng, thì chính việc xác nhận feedback của khách hàng về sản phẩm: mong muốn được cải tiến chức năng hoặc confirm về chức năng nào đó không hoạt động như mong muốn... QA sẽ hiểu rõ hơn Khẩu Vị khách hàng của mình là gì, biết được những vấn đề mình đang còn bỏ sót... để tập trung nhiều hơn check các trường hợp đó. Đồng thơi trên cơ sở hiểu rõ hơn khẩu vị thì tự đưa ra những đề xuất cải tiến sản phẩm cho khách hàng.

Thứ ba về việc hỗ trợ BA và chủ sở hữu sản phẩm về các vấn đề kỹ thuật, QA chính là người nắm chắc spec của sản phẩm nhất. Với những vấn đề spec chưa rõ ràng, chính spec là người hỗ trợ để đưa ra đề xuất xem spec chỗ này... nên để là gì... trên cơ sở đã hiểu rõ nghiệp vụ của nó cũng như so sánh với các ứng dụng khác.

Như vậy QA sẽ không còn là người bị động nhận sản phẩm về, tìm lỗi để dev fix mà QA sẽ là người GIÚP CHO CÁC MEMBER TRONG TEAM CÓ TRÁCH NHIỆM VỚI CHẤT LƯỢNG SẢN PHẨM MÌNH TẠO RA, CÓ TRÁCH NHIỆM KHI RELEASE SẢN PHẨM CỦA MÌNH. QA là người đưa ra thông tin về tình trạng của sản phẩm, hơn là một "quality gatekeeper" - chỉ cố gắng chỉ ra lỗi của sản phẩm, cố gắng chỉ ra toàn bộ những cái dev đã cố gắng làm từ đầu đến giờ là sai. QA cần phải theo dõi, phân tích toàn bộ tiến trình delivery, hãy nhận thức được các vấn đề của dự án và giải quyết nó để cho toàn bộ team có thể chạy dự án một cách suôn sẻ nhất và delivery sản phẩm một cách ngon nghẻ nhất.

Trên một khía cạnh khác tôi cũng nhận được nhiều phàn nàn của DEV về QA. Họ cảm thấy như QA đang đứng ở một vị trí đối nghịch với họ. Thứ nhất do họ và QA ít trao đổi với nhau để làm rõ yêu cầu của sản phẩm trước khi bắt đầu thực hiện test nên có trường hợp khi vừa built sản phẩm lên thì họ bị QA comment luôn là làm sai yêu cầu khách hàng. Đến đây lại cần có leader dự án ra phân giải. Ở một trường hợp khác thì QA chỉ check một vài trường hợp, thấy có lỗi là trả lại sản phẩm cho DEV luôn, không test nữa. Vì thế sau khi sửa lỗi xong rồi, QA lại mới test tiếp và báo bug khác...sẽ mất nhiều thời gian cho cả DEV và QA.

Vì vậy điều quan trọng ở QA chính là hãy là cầu giao kết nối các member trong cả team. Hãy lắng nghe leader và DEV, hiểu được tình trạng công việc của họ cũng chính là hiểu được chất lượng của dự án. Hãy là người hỗ trợ các member làm việc thật tốt, để đạt được chất lượng công việc cao nhất. Hãy thôi chỉ yêu cầu hãy sửa lỗi nọ lỗi kia, hãy chấp nhận những lỗi mà nếu suy xét ra thì đó là những lỗi có thể không cần phải sửa, hoặc là sẽ sửa ở các lần release tiếp theo.

https://www.thoughtworks.com/insights/blog/becoming-qa-leftie-team-quality-indicator