Những vấn đề thường gặp của team kiểm thử lớn và cách giải quyết

Bài viết này được phát triển theo tư tưởng của bài viết trong link sau:

http://www.softwaretestinghelp.com/problems-with-large-qa-testing-teams-and-remedies/

Khi làm việc trong một team kiểm thử lớn, bạn cần phải đảm bảo chất lượng cho một sản phẩm lớn. Và dù ít hay nhiều thì bạn cũng sẽ phải đối mặt với những vấn đề của một team lớn. Vậy những thách thức đó là gì? Làm thế nào để giải quyết được chúng? Hãy để chúng tôi chỉ cho bạn thấy những vấn đề bạn dễ gặp phải nhất và một số gợi ý để giải quyết chúng trong nội dung tiếp theo sau đây.

Trước tiên, để biết được vấn đề gì sẽ xảy ra, chúng ta hãy cùng tìm hiểu như thế nào là một team kiểm thử lớn.

Đã có rất nhiều tranh cãi xung quanh vấn đề 1 team có bao nhiêu người thì sẽ hoạt động tốt nhất. Khi mà hầu hết những người làm việc với mô hình agile đều đồng nhất với ý kiến một team nhỏ sẽ dễ quản lý và đạt được hiệu quả cao hơn khi vận hành 1 team lớn. Tuy nhiên, việc định nghĩa như thế nào là một team tối ưu vẫn còn là 1 thách thức. Và sau rất nhiều khảo sát thì người ta nhận ra một team tối ưu nhất khi có 5 thành viên. Scrum khuyến nghị 1 team nên nằm trong khoảng 5-9 người. Tuy nhiên 5 mới chính là con số chung nhất.

Vì vậy ở đây chúng ta sẽ tạm coi 1 team có trên 5 thành viên thì được coi là một team lớn. Và một team lớn thường sẽ gặp phải những vấn đề mà chúng tôi sẽ nêu ở dưới đây.

Vấn đề số 1: Đảm bảo chất lượng được duy trì tốt theo thời gian

Có bao nhiêu người trong chúng ta đã học được kinh nghiệm rằng khi kích thước của team tăng lên theo thời gian thì việc duy trì chất lượng sản phẩm tốt sẽ là một thách thức?

Lý do: Mỗi chúng ta có những kỹ năng khác nhau, có những điểm mạnh riêng, năng khiếu khác nhau, style hoặc cách tiếp cận test khác nhau và tất nhiên kinh nghiệm cũng khác nhau. Những khác biệt này gây ra ảnh hưởng lớn bởi vì không phải dễ dàng để dạy mọi người " Làm thế nào để kiểm thử " hoặc chỉ cho họ chi tiết những vấn đề trong quá trình kiểm thử. Việc kiểm thử phụ thuộc rất nhiều vào sự tự do suy nghĩ của mỗi người và cách họ thực hiện chúng. Nhất là khi thời gian càng dài, việc nắm bắt yêu cầu và thực hiện kiểm thử để có chất lượng tốt nhất lại càng trở thành 1 thách thức.

Hậu quả: Chính vì kỹ năng của mỗi thành viên trong team sẽ có sự khác biệt và chênh lệch nên có thể dẫn đến các hậu quả như sau:

• Phát sinh vấn đề với những module đã bàn giao
• Không cover hết được các case cần thiết
• Quá tập trung vào các case đặc biệt, bỏ lỡ các case normal
• Thiếu tự tin trong công việc

Phương pháp giải quyết:

• Tạo ra một quy trình làm việc xuyên suốt và có cải tiến ở các giai đoạn mà quy trình không còn phù hợp
• Duy trì sự tự tin và tính trách nhiệm trong công việc ở bất kỳ giai đoạn nào của dự án
• Leader phải đóng vai trò là người dẫn dắt các thành viên đi đúng hướng, đúng mục tiêu trong tất cả các giai đoạn

Vấn đề số 2: Phân chia công việc chuyên biệt hóa

Leader phân chia công việc chuyên biệt hóa phụ thuộc vào ưu thế của từng thành viên trong team.

VD: John, Jonhny, Janardan cùng ở 1 team. John rất xuất sắc ở kiểm thử bảo mật, John có nhiều kinh nghiệm trong business workflow, Janardan không thể thay thế trong team trong các vấn đề về kiểm thử hiệu năng và payment...

Lý do: Có chuyên gia về một lĩnh vực trong team giúp cho việc quản lý thuận lợi trong thời gian ngắn, vì người này có thể hoàn thành dễ dàng những việc mà họ giỏi và quản lý có thể yên tâm rằng mình sẽ nhận được kết quả có chất lượng tốt nhất có thể.

Hậu quả: Về kế hoạch dài hạn, phương pháp này làm giảm tính liên kết của dự án. Việc thiếu nhân lực chủ chốt sẽ gây ra nhiều vấn đề thậm chí gây bế tắc cho dự án.. Việc thiếu hụt này có thể đến từ nhiều nguyên nhân như nghỉ việc, ốm đau, thay đổi nội bộ…

Chúng ta đã bàn về trình độ chuyên môn, còn về việc chia sẻ kiến thức?

Quay trở lại ví dụ trên, nếu Johny biết được một chút việc Janardan đang làm thì có tốt hơn không? Kiến thức về workflow của John liệu có có ích với Janardan? Nếu hiểu được các tính năng mới và dự đoán được ảnh hưởng của nó đến các bộ phận khác có tốt hơn không? Và kiến thức chung về toàn bộ hệ thống có ích gì cho họ trong các task tiếp theo không?

Và tất nhiên câu trả lời là "CÓ".

Phương pháp giải quyết:

1. Vận hành con người theo quá trình:

Dưới đây là 1 chu trình chúng tôi đưa ra để các bạn tham khảo, có thể chu trình của team bạn đã cover được hết các bước dưới đây hoặc chưa. Tuy nhiên, theo kết quả nghiên cứu thì chúng tôi thấy phần lớn các nhóm kiểm thử chưa có được một số bước quan trọng. Vậy đó là gì? Trước tiên hãy cùng xem chu trình mà chúng tôi giới thiệu.

• Bước 1: Thu thập yêu cầu: Yêu cầu sẽ được thu thập bởi bên phân tích nghiệp vụ (BA: business analyst)
• Bước 2:Thảo luận về user story: thảo luận về yêu cầu ở cấp leader, ở đó có các bên phân tích nghiệp vụ , develop leader và test leader chuẩn bị user story. Mục đích của quá trình này là tìm kiếm các lỗ hổng, phần trùng lặp của user story và ghi chú lại để tiết kiện thời gian của cả team.
• Bước 3: Phổ biến yêu cầu chi tiết: Ở bước này bộ phận phân tích nghiệp vụ sẽ phổ biến requirement với cả team.
• Bước 4: Tạo TCs/ Scenario: Các thành viên trong team sẽ ngồi lại với nhau để trao đổi về user story, sau khi đã thống nhất rõ ràng bên đội phát triển sẽ thực hiện code, đội kiểm thử sẽ thực hiện viết TCs.
• Bước 5: Review TCs: Sau khi hoàn thành TCs, bên phân tích nghiệp vụ sẽ thực hiện review để kiểm tra xem quan điểm test đã khớp với yêu cầu hay chưa? Trong bước này, cũng có thể TCs sẽ được đánh giá bởi cả đội phát triển (developer) để xác nhận lại một lần nữa sự chính xác của quan điểm test.
• Bước 6: Execute test: Thực hiện test theo TCs đã được thông qua.
• Bước 7: Họp đánh giá kết quả test: Bộ phận kiểm thử hoặc tất cả các bộ phận trong team sẽ tiến hành họp đánh giá kết quả test.
• Bước 8: Thực hiện test chéo: Ở bước này, có thể bộ phận phân tích nghiệp vụ hoặc chính bộ phận kiểm thử sẽ chọn ra một số phần bất kỳ trong TCs để thực hiện test lại một lần nữa.

Bây giờ bạn đã có thể biết được đâu là bước mà mình còn thiếu. Tuy nhiên, theo đánh giá và nghiên cứu của chúng tôi, hầu hết các nhóm kiểm thử thường thiếu đi bước 3,7 và 8. Vậy tác dụng của mỗi bước trên là gì?

Với bước 3, trong quá trình phổ biến requirement, tất cả các thành viên trong team sẽ đều nắm được công việc và mục đích sắp tới của mình là gì. Không những vậy, ở bước này, đội phân tích nghiệp vụ còn có thể nhận được các phản hồi, góc nhìn khác nhau về những yêu cầu, chức năng sắp được triển khai, việc này giúp cho họ có thể tiếp cận sâu hơn với việc đánh giá kết quả đạt được sau khi các bộ phận tiến hành thực hiện task.

Với bước 7, việc đánh giá lại kết quả test giúp cho đội kiểm thử nhận ra những vấn đề đã, đang và sẽ gặp phải trong quá trình kiểm thử. Tránh được những sai sót trùng lặp hoặc những bug common. Nếu có sự tham gia của tất cả các bộ phận, việc này sẽ giúp các bộ phận tránh được những sai sót không đáng có ở những lần tiếp theo.

Với bước 8, đây là bước khá quan trọng nhưng không bắt buộc vì nó còn phụ thuộc vào nhân lực và thời gian. Bước này nhằm đảm bảo với những kỹ năng khác nhau, có thể sẽ phát hiện những bug chuyên sâu khó phát hiện và giải quyết kịp thời. Hoặc đảm bảo rằng chất lượng sản phẩm đã được đánh giá đúng.

2. Hợp tác theo tài liệu.

Như chúng tôi đã nhắc đến phía trên, vấn đề của chúng ta là khi mọi người được chuyên trách một phần nào đó, rất khó để thay thế vị trí của họ trong dự án. Vậy làm thế nào để tất cả mọi người đều có khả năng đảm nhiệm phần việc của người khác khi họ vắng mặt? Câu trả lời rất đơn giản, đó là hợp tác bằng tài liệu. Mỗi một người sẽ chia sẻ phần việc của mình với những thành viên khác trong team thông qua các buổi họp và tài liệu để tất cả mọi người đều nắm được phần việc của người cùng nhóm. Việc này sẽ hạn chế sự trì hoãn trong trường hợp có thành viên trong team nghỉ hoặc vắng mặt đột xuất.

Vấn đề số 3: Làm việc nhóm

Việc làm thế nào để các thành viên trong team hợp tác với nhau một cách vui vẻ và hòa thuận sẽ là một thách thức với một team kiểm thử lớn.

Lý do: Với một team lớn, số lượng thành viên có những cá tính khác nhau sẽ nhiều hơn một team thông thường. Sự khác biệt về cá tính, cách làm việc, khả năng nhìn nhận vấn đề sẽ dẫn đến những mâu thuẫn giữa các thành viên trong team. Ngoài ra, việc quản lý không quan tâm đến các thành viên trong team mà chỉ đơn giản là ném cho mỗi người một công việc cũng có thể gây ra sự chán nản trong team.

Hậu quả: Không khí làm việc trong nhóm căng thẳng, chất lượng công việc không tốt.

Phương pháp giải quyết: Có rất nhiều các cách để gắn kết các thành viên trong team. Với nhóm chúng tôi, cách mà chúng tôi sử dụng là

Vào mỗi thứ Tư, tất cả các thành viên tester họp lại trong một vài giờ, gọi là Q&A Session. Đây là những việc mà chúng tôi làm trong cuộc họp:

• Bất cứ ai cũng có thể đặt câu hỏi về mọi thứ không chỉ là trong giới hạn công việc và những người khác có thể trả lời.
• Bất cứ ai cũng có thể chia sẽ ý tưởng, phương pháp cải thiện, mục tiêu cá nhân với tất cả mọi người. Có thể chia sẻ bất cứ điều gì.
• Từng người lần lượt theo vòng sẽ trình bày về một đề tài về Kiểm thử mà mọi người có thể không biết. Nhờ đó mà chúng tôi có thể nâng cao kiến thức của bản thân.
• Không chỉ bàn về công việc, chúng tôi còn cùng xem tranh ảnh, chơi game hoặc xem phim

Vấn đề số 4: Bàn giao và phân chia công việc

Một trong những vấn đề trong một đội dự án lớn là việc phân chia và bàn giao công việc giữa các thành viên. Nếu bạn chỉ đơn giản là phân công nhiệm vụ cho từng người theo lựa chọn của bạn thì có khả năng đội dự án sẽ tan rã.

Lý do:

• Một người nhận lại tiếp tục nhận được nhiệm vụ phức tạp và quá sức đối với họ. Hoặc, một người lại nhận được modulde cũ để test lại.
• Bạn ngẫu nhiên gán một module đơn giản cho một chuyên viên kỹ thuật để công việc đạt hiệu quả cao nhất trong khi các vấn đề cần đến chuyên môn cao thì lại giao cho một người thiếu kinh nghiệm.
• Chia task theo quan điểm cá nhân.

Hậu quả:

• Chất lượng công việc không được đảm bảo.
• Gây ức chế cho thành viên trong team.

Phương pháp giải quyết: Một phương pháp giải quyết mà chúng tôi giới thiệu tới bạn ở đây là thay vì việc leader là người quyết định giao task nào cho ai thì những thành viên trong nhóm sẽ được phép chọn phần công việc mà họ muốn làm. Bằng cách này thì vấn đề bên trên sẽ được giải quyết một cách nhanh chóng. Mỗi người sẽ nhận được phần công việc trong khả năng của mình và được quyền thực hiện nó trong thời gian cho phép. Như vậy họ sẽ cảm nhận được đóng góp của họ có ý nghĩa như thế nào trong dự án.

Đương nhiên, bạn sẽ thắc mắc là nếu thành viên trong nhóm đánh giá sai khả năng của mình thì sao? Lúc này leader sẽ phát huy vai trò dẫn dắt của mình để cho các thành viên trong team có thể nhìn nhận đúng vấn đề và kịp thời sửa sai đúng lúc.

Vấn đề số 5: Sự công nhận và động lực thúc đẩy

Một số thành viên trong team không được đánh giá đúng khả năng khi bị so sánh với những thành viên khác.

Lý do: Hãy thử tưởng tượng bạn có thể phân loại mỗi thành viên trong team vào các nhóm- ngôi sao, người biểu diễn hoặc nhóm dưới những người biểu diễn. Vấn đề xảy ra khi bạn có quá nhiều ngôi sao, người biểu diễn nhưng lại ko có những người thuộc nhóm dưới. Điều đó khiến cho những người biểu diễn của bạn trông có vẻ giống những người thuộc nhóm dưới khi bị so sánh với những người thuộc nhóm ngôi sao.

Hậu quả: Việc đánh giá không đúng khả năng của thành viên trong team sẽ dẫn đến rất nhiều hệ lụy, đặc biệt là việc khiến cho những thành viên bị đánh giá sai cảm thấy thiếu động lực làm việc và đương nhiên, chất lượng công việc đi xuống sẽ là hậu quả tất yếu.

Tuy nhiên là một leader của team lớn, bạn không thể có đủ thời gian như nhau để dành cho tất cả các thành viên trong team. Vậy làm thế nào để có thể vừa hoàn thành được công việc của mình, vừa có thể giúp các thành viên trong team tự tin và phát triển được khả năng của bản thân? Chúng tôi xin gợi ý cho bạn một cách giải quyết dưới đây.

Phương pháp giải quyết:

Vâng, cách khắc phục bắt đầu bằng việc bạn phải học cách chấp nhận rằng bạn không thể có tất cả mọi ngôi sao ở trong team của mình. Mọi người có những tài năng thiên bẩm khác nhau, khả năng và tốc độ học hỏi khác nhau và cách làm việc cũng khác nhau.

Bạn có thể giúp người biểu diễn trở thành ngôi sao nhưng không thể làm điều đó 1 mình. Đầu tiên, bạn sẽ phải tìm một người trưởng nhóm (không nhất thiết là một người đã được chỉ định mà có thể là một người có tố chất lãnh đạo) trong team và sau đó đưa họ vào vị trí lãnh đạo.

Là một người quản lý hoặc trưởng nhóm, bạn không thể dành đủ hoặc chia đều thời gian cho tất cả mọi người trong team. Bạn cần phải ủy thác trách nhiệm cho đúng người sau khi khiến họ tin vào tầm nhìn của bạn.

Bạn có thể kết nối với nhiều người nhất có thể, nhưng bạn phải không ngừng nói chuyện với những người bạn đã chọn, hướng dẫn họ, nhìn nhận những gì họ làm đc và chia sẻ định hướng với họ. Họ sẽ là người trực tiếp thực hiện công việc và bạn chỉ cần là người giám sát.

Đương nhiên, viết những email khen thưởng, đưa ra các buổi nói chuyện để thúc đẩy cũng như công khai khen thưởng những thành viên của team mình là một điều mà bạn cần phải thực hiện thường xuyên nếu như muốn phương pháp này đạt được hiệu quả.

Tóm lại, với một team có nhiều thành viên, sẽ có rất nhiều vấn đề bạn cần phải đối mặt. Ở đây chúng tôi chỉ nêu ra một số vấn đề mà chúng ta hay gặp phải, đồng thời đưa ra những cách giải quyết mà chúng tôi đã áp dụng và có hiệu quả. Mong rằng nó sẽ giúp ích phần nào cho team của bạn.