Giao tiếp trong nhóm và kiểm thử độc lập

Bài viết được tham khảo từ tài liệu: http://istqbexamcertification.com/what-is-independent-testing-its-benefits-and-risks/

https://books.google.com.vn/books?id=Ss62LSqCa1MC&pg=PA128&lpg=PA128&dq=Independent+testing+-+who+is+a+tester&source=bl&ots=YKcCcKSoV7&sig=r0uTLhDBY7o53UB2mw69S_XHG5o&hl=vi&sa=X&redir_esc=y#v=onepage&q=Independent testing&f=false

Chúng ta hãy cùng xem cách mà Developer nghĩ và tester (QA) nghĩ như nào nhé?

Developer and tester (QA)

Lối tư duy của người phát triển và lối tư duy của người thực hiện viêc kiểm tra là rất khác biệt. Đó là khác biệt giữa người implement và người review, giữa developer và tester. Khi phát triển, xây dựng một cái gì đó (làm tài liệu, requirement, design, coding), chúng ta đang làm việc một cách tích cực để giải quyết vấn đề được yêu cầu. Tuy nhiên, khi thực hiện review hay test sản phẩm đồng nghĩa với việc chúng ta đang tìm kiếm lỗi trong đó, và do đó, trở nên khắt khe với nó.

Ai là người tham gia kiểm thử?

Công việc kiểm thử Testing thoạt nghe giống như việc của tester trong dự án. Tuy nhiên điều đó không hoàn toàn đúng. Mỗi developer chính là một tester. Họ kiểm tra những phần việc mà họ phát triển, sự tích hợp của các thành phần đó trong hệ thống. Với một tư duy đúng, một developer khi tự mình kiểm tra lại công việc của mình, họ có thể phát hiện những sai lầm mắc phải, khắc phục trước khi người khác phát hiện ra. Họ cũng có thể giúp kiểm tra phần việc của những người khác trong team (review chéo) hoặc tham gia vào các meeting để review nhóm (Review Meeting). Cũng tương tự như vậy, các tài liệu, sản phẩm khác trong dự án cũng cần được kiểm tra trước hết bởi chính người thực hiện, sau đó nhờ tới sự giúp đỡ của các thành viên khác trong dự án để review. Tuy nhiên, chúng ta đều biết rằng, rất khó có để tìm ra sai lầm cá nhân (1 trong 7 nguyên tắc test). Vì vậy việc nhờ một người khác giúp kiểm tra sản phẩm của mình là một cách hữu hiệu để phát hiện những sai lầm tồn tại và đưa ra sản phẩm cuối cùng hoàn thiện (Về cách đón nhận những phản hồi của những người khác tôi sẽ đề cập đến sau nhưng có một vài điểm như một vài comment về phần test case của mình kiểu dạng như: Cái này viết kiểu gì vậy? Chẳng hiểu gì cả? Viết thế này thì người test đánh failed hết à? Trong những trường hợp như vậy bạn cũng có cảm giác như bị “dìm hàng” nhưng hãy bình tĩnh đón nhận với một thái độ trung lập nhất cùng phân tích và nhận sai xót để update).

Trong một dự án phát triển phần mềm, rất nhiều review và kiểm thử được tiến hành. Ngay từ đầu, review requirement và tài liệu design bởi một người/ nhóm khác sẽ giúp chúng ta đi đúng theo yêu cầu khách hàng. Trong quá trình coding, review code và các unit test là cần thiết. Sau coding, phần mềm cần được kiểm tra độc lập bới những tester chuyên nghiệp, BA hoặc bởi chính khách hàng trước khi final release. Các mức độ độc lập là cần thiết để tránh các thiên kiến của người phát triển và thường hiệu quả hơn trong việc tìm ra các khiếm khuyết và sai sót.

Các mức độ kiểm thử độc lập?

Tuy nhiên, kiểm thử độc lập không phải là yếu tố quan trọng nhất để đảm bảo chất lượng sản phẩm. Một người phát triển làm việc cẩn thận, kiểm tra kỹ càng công việc của mình giúp ích rất nhiều trong việc đảm bảo chất lượng sản phẩm cũng như tiết kiệm chi phí. Nhớ rằng, kiểm thử độc lập có thể được tiến hành tại mọi level và việc chọn lựa mức độ độc lập phụ thuộc vào rủi ro trong hoàn cảnh cụ thể.

Các mức độ kiểm thử độc lập được sắp xếp từ thấp lên cao như sau:

- Kiểm thử được thực hiện bởi chính người viết chương trình. (Mức độ độc lập thấp nhất)

- Kiểm thử thực hiện bởi người khác trong nhóm.

- Kiểm thử được thực hiện bởi một nhóm kiểm thử độc lập hoặc chuyên gia kiểm thử.

- Kiểm thử được thực hiện bởi một người/ nhóm kiểm thử thuộc một công ty/ tổ chức khác.

Với ý nghĩa của “độc lập”, việc tách biệt trách nhiệm của tester ra khỏi phần việc của developer được thực hiện nhằm tập trung năng lực và để cung cấp những lợi ích của nguồn lực kiểm thử chuyên nghiệp được đào tạo. Trong các dự án, unit test được thực hiện bởi nhóm developer, còn các bước sau được làm độc lập bởi nhóm test team hoặc bởi khách hàng. Tuy nhiên, sự tách biệt này có cả nhược điểm và ưu điểm. Ưu điểm của độ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 trở nên xấu đi.

Hạn chế xung đột trong team (Hạn chế xung đột giữa Developer and Tester).

Nhiều người trong chúng ta nhận thấy việc chấp nhận những lời chỉ trích trong công việc không phải dễ dàng. Chúng ta thường tin rằng chúng ta đã làm tốt nhất để đưa ra các sản phẩm (các tài liệu, code, test, bất kỳ cái gì) chính xác và hoàn chỉnh. Do đó, khi có người tìm ra một lỗi lầm, một sai sót của chúng ta, ta sẽ nghĩ nó như một vấn đề cá nhân và tức giận với người đó, đặc biệt nếu chúng ta đang căng thẳng. Điều này đúng với cả quản lý hay nhân viên, tester hay developer. Vì vậy, nếu là một tester, khi phát hiện ra bug trong quá trình thực hiện kiểm thử, chúng ta cần cẩn trọng với thái độ của mình. Chúng ta sẽ cảm thấy hài lòng, đương nhiên, vì chúng ta tìm ra được bug. Nhưng khi đó thái độ của người làm requirement, design, developer, PM và khách hàng sẽ như thế nào? Developer có thể sẽ có thái độ phòng thủ và coi những bug report như một chỉ trích cá nhân chống lại họ và sản phẩm của họ. PM có thể khó chịu với tất cả những người kìm chân dự án. Khách hàng có thể mất niềm tin vào sản phẩm bởi họ thấy lỗi. Bởi vì kiểm thử có thể được nhìn nhận như một hoạt động “phá hoại”, do đó chúng ta cần hết sức cẩn thận với những bug report. Khi đó những điều chúng ta cần làm là:

• Trao đổi về những sai sót tìm thấy trong sản phẩm với một thái độ trung lập, tập trung vào sự vật, sự việc hơn là chỉ trích người đã gây ra sai sót này. Hãy mang tính xây dựng trong quá trình thẩm định và thảo luận về lỗi cũng như làm thế nào để ghi nhận nó.
• Giải thích rằng bằng cách nhận ra lỗi lầm và sai sót, chúng ta có thể xem lại công việc mình đã làm và sửa chữa nếu cần thiết để từ đó có thể bàn giao cho khách hàng sản phẩm tốt hơn. Chỉ ra những rủi ro tiềm tàng và những lợi ích của việc đánh giá và kiểm thử.
• Bắt đầu với tinh thần hợp tác thay vì đối đầu. Hãy nhớ mọi người đều làm việc vì mục tiêu chung là làm cho chất lượng sản phẩm trở nên tốt hơn. Nhiệm vụ của reviewer và tester là cung cấp cho mọi người các thông tin khách quan, rõ ràng về những sai sót, lỗi lầm phát sinh theo một cách thức mang tính xây dựng. Những người có thể trở thành reviewer và testing tốt đều có đam mê và khả năng tìm kiếm vấn đề. Họ được đặc trưng bởi tính tò mò, sự cầu toàn và chú ý đến tiểu tiết. Tuy nhiên, họ cần có kỹ năng về con người và giao tiếp tốt, sự lịch sự, thấu hiểu người khác và thái độ tốt với cộng sự, đồng nghiệp, khách hàng, quản lý cũng như phần còn lại của team. Chúng ta sẽ là những tester thất bại nếu không ai nghe điều chúng ta nói.

Kết luận

Vì vậy, nếu bạn là Tester, hãy để ý đến điều mà developer cảm thấy khi bạn bắt bug của họ, đừng bao giờ để họ thấy như đang bị dìm hàng. Và nếu bạn là một developer, khi bạn cảm thấy bị dìm hàng, hãy hít thở một hơi thật sâu rồi thở ra. Hãy tin rằng: Chúng ta (tất cả những người đang cùng chung một project) đang làm tất cả để hoàn thành tốt nhất yêu cầu của khách hàng, đưa đến cho thị trường một sản phẩm tốt nhất.