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

Câu chuyện của chúng tôi

Cách đây 4 năm, chúng tôi cùng làm một dự án phát triển ứng dụng trên Mac OS X. Đó là lần đầu tiên tôi đảm nhiệm vị trí PM dự án. Test leader của nhóm trước đó đã từng tham gia một vài dự án phát triển ứng dụng tương tự với Khách hàng này, nhưng với vai trò SQA. Đây quả là một thử thách với cả tôi và Test leader. Team chúng tôi được thành lập dựa trên một số members đã có kinh nghiệm làm việc với nhau, ngoài ra còn có một số em sinh viên thực tập. Toàn người trẻ, chúng tôi đã có những khởi đầu thuận lợi, tưởng như chả có gì là khó khăn cả.

Sau những bước đầu tiên của dự án, dev team tập trung vào việc phát triển các tính năng theo yêu cầu của Khách hàng, test team thì làm test design, tạo test case. Hôm đó đẹp giời, dự án còn độ 10 ngày nữa thì tới hạn release LF (các chức năng được implement đầy đủ hoặc một phần, chấp nhận lỗi) thì PTL nói: đã xong về cơ bản, build cho team 1 bản xem qua nhé. Chúng tôi đứa nào cũng hồ hởi, cười nói với nhau qua lại. Đến khi test team cài đặt xong, họ nhóm lại một góc, nhỏ to, nhưng phần lớn là nói khá to: Cái này sai rồi này! Cái này anh Z làm không đúng spec! Chỗ này kiểu gì ấy nhỉ?!!… Tất nhiên cũng có những câu kiểu như: Chỗ này mình chưa viết test case này! Cái flow này mình viết test case không đúng rồi… Đột nhiên thấy PTL bực mình thái độ bỏ ra ngoài, nhiều người ngạc nhiên không hiểu chuyện gì. Lúc sau thì cậu ấy vào, cậu ấy nói rằng: Đây không phải là là bản build để test, mục đích của cậu ấy chỉ là build 1 bản để mọi người hình dung về app như thế nào. Và cách các bạn SQA phản ứng với bản build đó đã khiến developer cảm thấy bị "dìm hàng". Hôm đó chúng tôi đã kết thúc một ngày một cách tồi tệ.

Chuyện gì đã xảy ra?

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à SQA. 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ó.

Hãy thử tưởng tượng bạn đang tham gia sát hạch lái xe. Bạn ngồi trên xe và được yêu cầu thực hiện bài thi. Đương nhiên, bạn sẽ cố gắng hết sức để hoàn thành tốt nhất đường đi của mình, chú ý đến các đoạn rẽ, giữ khoảng cách với các xe đang lưu thông, kiểm soát tốc độ, cách lùi xe, đỗ vào bãi. Giám thị ngồi bên cạnh bạn. Ông ta sẽ lưu ý tới tất cả những điểm cộng của bạn, tuy nhiên cũng không bỏ qua những điểm trừ, những lỗi bạn có thể mắc phải trên đường đi. Tương tự như vậy với phát triển phần mềm, developing và testing là hai lối tư duy hoàn toàn khác nhau.

Những ai tham gia vào việc kiểm thử?

Công việc kiểm thử thoạt nghe giống như việc mà SQA phải làm trong dự án. Tuy nhiên không hoàn toàn như vậy. Mỗi developer chính là một SQA. 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à họ mắc phải, khắc phục lỗi lầm trước khi người khác phát hiện ra. Họ cũng có thể giúp kiểm tra phần phát triển 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. Cũng tương tự như vậy, công việc của SQA hay BA và các tài liệu 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 SQA khác, BA khác, QA và những thành viên khác trong dự án. Tuy nhiên, chúng ta đều biết rằng, rất khó để tự tìm ra sai lầm cá nhân. 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.

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 tìm ra defect trước khi coding bắt đầu và 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 SQA 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ử được 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. (VD: outsource)

Với ý nghĩa của "độc lập", việc tách biệt trách nhiệm của SQA 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 testing đượ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

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, SQA hay developer. Vì vậy, nếu là một SQA, 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, designer, 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à QA 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à SQA 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 SQA thất bại nếu không ai nghe điều chúng ta nói.

Kết luận

Quay trở lại với câu chuyện ban đầu. Sau đó còn tiếp diễn một loạt diễn biến khác đẩy cao xung đột giữa test leader và PTL dự án. Tôi còn nhớ, test leader của chúng tôi đã từng vào nhà vệ sinh khóc vì không chịu nổi áp lực. Rồi có lần cô ấy đã thức khuya, dùng tablet và 3G (do tình trạng cắt điện luân phiên trong thành phố) viết một email dài cỡ 3 trang A4 gửi cho PTL và CC cho tôi với mong muốn hoà giải mâu thuẫn. Sau này mọi thứ đều ổn thoả. Dự án của chúng tôi đã thành công tốt đẹp, nhận được 96 điểm CSS từ khách hàng, sản phẩm được release ra thị trường đúng hạn. Issue xảy ra này, chúng tôi đã cùng ngồi lại trong Retrospective Meeting và nhìn nhận như một bài học trong Team Communication. Mối quan hệ của chúng tôi sau này trở nên tốt đẹp hơn, cả trong quá trình làm dự án hay cuộc sống đời thường.

Vì vậy, nếu bạn là SQA, hãy để ý đến điều mà developer cảm thấy khi bạn bắt bug của người ta, đừng bao giờ để họ thấy như đang bị "dìm hàng". Và nếu bạn là một developer, khi cảm thấy bị "dìm hàng", hãy hít 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.

Tài liệu tham khảo: Foundations of software testing - Rex Black, Erik Van Veenendaal,  Dorothy Graham (2 012) Theo tạp chí Geek and Tech, Nguyên (LM)