TẠI SAO ĐÔI KHI CHÚNG TA KHÔNG HÒA NHẬP VỚI PHẦN CÒN LẠI CỦA NHÓM?

Cũng như tính độc lập, việc tách vai trò người kiểm thử khỏi vai trò nhà phát triển cũng được thực hiện để giúp tập trung nỗ lực và mang lại lợi ích của các nguồn lực kiểm thử được đào tạo và chuyên nghiệp.

Trong nhiều tổ chức, các giai đoạn kiểm thử trước đó được thực hiện bởi các nhà phát triển và tích hợp và các giai đoạn sau một cách độc lập, bởi một nhóm chuyên gia kiểm thử hoặc bởi khách hàng.

Tuy nhiên, sự tách biệt này có thể dẫn đến các vấn đề như lợi thế của sự độc lập và tập trung có thể bị mất đi nếu mối quan hệ giữa các nhóm xấu đi.

Mỗi tổ chức và mỗi dự án sẽ có những mục tiêu ngắn hạn và mục tiêu dài hạn riêng. Các bên liên quan khác nhau, chẳng hạn như khách hàng, nhóm phát triển và các nhà quản lý của tổ chức, sẽ có quan điểm khác nhau về chất lượng và có mục tiêu riêng của họ.

Bởi vì con người và dự án được thúc đẩy bởi các mục tiêu, bên liên quan có quan điểm mạnh nhất hoặc ảnh hưởng lớn nhất đối với một nhóm sẽ xác định một cách có ý thức hoặc tiềm thức rằng các mục tiêu đó là gì. Mọi người có xu hướng sắp xếp kế hoạch của họ với những mục tiêu này.

Ví dụ

Tùy thuộc vào mục tiêu, tester có thể tập trung vào việc tìm ra lỗi hoặc xác nhận rằng phần mềm có hoạt động. Nhưng nếu một bên liên quan ít ảnh hưởng hơn trong quá trình thực hiện dự án nhưng lại ảnh hưởng nhiều hơn khi giao hàng, thì có thể xảy ra xung đột quan điểm về việc liệu kiểm thử có đáp ứng được các mục tiêu của nó hay không.

Một người quản lý có thể muốn xác nhận rằng phần mềm hoạt động và nó “đủ tốt” nếu đây được coi là cách chuyển giao nhanh nhất có thể.

Một người quản lý khác có thể muốn việc kiểm thử tìm ra càng nhiều lỗi càng tốt trước khi phần mềm được phát hành, việc này sẽ mất nhiều thời gian hơn để thực hiện và sẽ cần thời gian để sửa chữa, kiểm thử lại và kiểm thử hồi quy.

Nếu không có mục tiêu được nêu rõ ràng và tiêu chí dừng mà tất cả các bên liên quan đã đồng ý, thì các tranh luận có thể nảy sinh trong quá trình kiểm thử hoặc sau khi phát hành về việc liệu kiểm thử đã được thực hiện “đủ” hay chưa.

Chúng ta thường tin rằng mình đã cố gắng hết sức để tạo ra công việc (tài liệu, code, các bài kiểm thử, bất cứ điều gì) chính xác và hoàn chỉnh. Vì vậy, khi người khác tìm ra lỗi, chúng ta có thể nhận ra điều này một cách cá nhân và khó chịu, nhất là khi đang bị áp lực về thời gian. Điều này đúng với các nhà quản lý, nhân viên, tester và nhà phát triển. Tất cả chúng ta đều mắc sai lầm và cảm thấy khó chịu, bực bội hoặc chán nản khi ai đó chỉ ra chúng.

Vì vậy, với tư cách là người kiểm thử, họ sẽ chạy một bài kiểm thử (theo quan điểm của ho), đó là một bài kiểm thử tốt để tìm ra lỗi trong phần mềm.

Phản ứng của các bên liên quan?

Tester rất vui vì đã tìm ra một lỗi tốt! Nhưng BA, nhà thiết kế, nhà phát triển, người quản lý dự án và khách hàng sẽ phản ứng như thế nào?

Những người xây dựng sản phẩm có thể phản ứng bảo vệ và coi lỗi được báo cáo này là chỉ trích cá nhân chống lại sản phẩm và chống lại tác giả.

Người quản lý dự án có thể khó chịu với mọi người vì đã trì hoãn dự án. Khách hàng có thể mất niềm tin vào sản phẩm vì những gì họ có thể nhìn thấy  chỉ là lỗi.

Bởi vì kiểm thử có thể được coi là một hoạt động “phá hoại”, tester cần chú ý báo cáo về lỗi một cách khách quan và lịch sự nhất có thể.

Công việc của tester là mang tính xây dựng trong việc quản lý rủi ro sản phẩm, cần phải cẩn thận khi xem xét và khi kiểm thử:

Truyền đạt những phát hiện về sản phẩm một cách trung lập, tập trung vào sự thật mà không chỉ trích người đã tạo ra sản phẩm đó.

• Ví dụ, viết các báo cáo sự cố khách quan và thực tế và xem xét các phát hiện.
• Đừng hả hê, bạn cũng không hoàn hảo!
• Đừng đổ lỗi, mọi sai lầm có lẽ là của nhóm hơn là của một cá nhân.
• Phê bình một cách xây dựng và thảo luận vềlỗi và lưu vết nó.

Giải thích rằng bằng cách biết về điều này, có thể khắc phục hoặc sửa chữa nó để hệ thống được chuyển giao tốt hơn cho khách hàng.

• Nói những gì bạn thích và những gì hiệu quả, cũng như những gì không hiệu quả.
• Chi ra rủi ro một cách trung thực, không phải mọi thứ đều được ưu tiên cao.
• Đừng chỉ nhìn thấy mặt bi quan – hãy đưa ra lời khen ngợi cũng như phê bình.
• Chỉ ra những rủi ro nào đã được phát hiện và lợi ích của việc xem xét hoặc kiểm thử.

Bắt đầu bằng sự hợp tác hơn là trận chiến. Nhắc nhở mọi người vềmục tiêu chung của hệ thống  để mang lại chất lượng tốt hơn.

• Lịch sự và hữu ích, hợp tác với đồng nghiệp.
• Cố gắng hiểu đối phương cảm thấy như thế nào và tại sao họ phản ứng như vậy.
• Xác nhận rằng đối phương đã hiểu những gì bạn đã nói và ngược lại.
• Giải thích bài kiểm thử hoặc bài đánh giá giúp ích cho tác giả như thế nào.
• Đề nghị công việc của bạn cũng được đánh giá.

Nhiệm vụ của tester là cung cấp cho mọi người thông tin rõ ràng, khách quan và để làm điều này, tester tiến hành tìm kiếm lỗi, khai thác lỗi và sửa lỗi.

Người đánh giá và người kiểm thử giỏi có mong muốn và có khả năng tìm ra vấn đề, và điều này đúng cho dù việc kiểm thử là công việc chính của họ hay là một phần vai trò của họ với tư cách là nhà phát triển.

Những người có kinh nghiệm về việc tìm lỗi, được đặc trưng bởi sự tò mò, sự bi quan chuyên nghiệp, con mắt phê phán và sự chú ý chi tiết.  Tuy nhiên, trừ khi tester có kỹ năng giao tiếp tốt, lịch sự, thấu hiểu người khác và có thái độ tốt với đồng nghiệp, khách hàng, người quản lý và những người còn lại trong nhóm,  còn không tester sẽ thất bại với tư cách là người kiểm thử vì không ai chịu lắng nghe họ cả.

Giao tiếp nhóm như thế nào?

Tester và test leader cần có kỹ năng cá nhân tốt để truyền đạt thông tin thực tế về lỗi, tiến độ và rủi ro theo cách có tính xây dựng. Đối với tác giả của phần mềm hoặc của tài liệu, thông tin lỗi có thể giúp họ cải thiện kỹ năng của mình, nhưng chỉ khi nó được cung cấp theo cách có ích cho họ.

Một cuốn sách thú vị trong bối cảnh này là Six Thinking Hats (Sáu chiếc mũ tư duy). Nó không phải là về kiểm thử mà là mô tả một cách để truyền đạt thông tin khác nhau: sự kiện; cảm xúc; suy nghĩ bi quan, suy nghĩ lạc quan; và những ý tưởng sáng tạo.

Khi xem xét hoặc kiểm thử, cần truyền đạt sự thật một cách khách quan, nhưng các loại thông tin khác cũng rất hữu ích: “Điều này đã xảy ra; đây là cách mà tôi cảm thấy thế nào về nó; những gì đã tốt; những gì có thể xảy ra sai; đây là cách chúng tôi có thể giải quyết vấn đề”.

Là một phần của việc giúp cung cấp đánh giá rủi ro, tester có thể giúp các nhà quản lý và khách hàng đưa ra các quyết định dựa trên rủi ro dựa trên tác động chi phí và thời gian của lỗi.

Nếu họ kiểm thử và phát hiện ra lỗi sẽ phải tiêu tốn $ 15.000 để sửa và kiểm thử lại/kiểm thử hồi quy, nó có đáng để sửa không? Nếu nó có thể là nguyên nhân gây ra tác động kinh doanh $ 50.000 trong môi trường thật, khách hàng có thể muốn nó được khắc phục. Còn nếu nó chỉ gây ra tác động kinh doanh là $ 10.000 nhưng bất kỳ sửa chữa nào khó thực hiện và có khả năng gây tác động tiêu cực ở nơi khác, thì tốt hơn là không nên sửa.

Bằng cách cung cấp cho nhóm thông tin về lỗi mà họ thấy hữu ích, tester có thể giúp họ đưa ra quyết định đúng đắn về việc khắc phục hoặc không sửa chữa các vấn đề. Nói chung, lỗi được tìm thấy và sửa chữa trong quá trình kiểm thử sẽ tiết kiệm thời gian và tiền bạc sau này và giảm rủi ro, vì vậy cần chỉ ra rằng đó là trường hợp để kiểm thử có giá trị.

Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.

Syllabus tải về Tại đây