Thay đổi tư duy về kiểm thử theo Nguyên lý Agile

Bài viết được sự cho phép của vntesters.com

Nguyên lý Agile – QA ngày nay đã phát triển từ “Tim lỗi” đến “Ngăn ngừa lỗi”. Những kỹ sư kiểm thử cần thêm nhiều kỹ năng khác như kiểm thử tự động, TDD, BDD và kiểm thử hộp trắng (không chỉ làm duy nhất kiểm thử hộp đen). Kỹ sư kiểm thử cần hướng đến hướng-giải-pháp, cộng tác nhiều hơn với nhóm phát triển và các bên nghiệp vụ.

Thay đổi tư duy kỹ sư kiểm thử với Nguyên lý Agile

Agile nghĩa là “Linh động”, “khả năng thay đổi nhanh chóng”.

Kiểm thử trong Agile không có nghĩa là một kỹ thuật kiểm thử mới, mà đi theo Agile nghĩa là phát triển một khả năng thay đổi trong tư duy để triển khai/tiến hành những gì có thể kiểm thử.

Trước khi bàn luận về kiểm thử trong Agile, hãy nhìn lại và xem xét nguồn gốc và nguyên lý bên trong Agile.

Câu chuyện xưa cũ

Trước khi thế giới làm việc với Agile, Thác nước (Waterfall) là một phương pháp có ưu thế trong công nghiệp phần mềm. Ở đây, chúng ta không giải thích mô hình Thác nước, nhưng có ghi chú vài điểm đáng chú ý trong làm việc thực tế.

Những điểm này là dựa vào kinh nghiệm của cá nhân. Có thể có khác biệt đôi chút với mọi người.

• Kỹ sư phát triển (dev) và QA làm việc như những nhóm riêng lẻ (Đôi khi còn là đối thủ)
• Các tài liệu liên quan được cả kỹ sư phát triển và QA xem xét cùng một lúc. Kỹ sư phát triển thiết kế và viết mã trong khi QA làm các kịch bản kiểm thử cho các tài liệu đó. Kế hoạch và việc thực thi được làm tuần tự.
• Việc xem xét các kịch bản kiểm thử được tiến hành bởi trưởng nhóm QA. Việc chia sẻ các kịch bản kiểm thử cho kỹ sư phát triển không phải là một việc được khuyến khích. (Lý do: kỹ sư phát triển sẽ viết mã dựa trên các kịch bản kiểm thử và nhóm QA sẽ không thể tìm thấy lỗi).
• Việc kiểm thử được xem như là công việc cuối cùng trong vòng lặp phát triển phần mềm. Hầu hết mọi lúc, QA nhận phiên bản phần mềm ở giai đoạn cuối và được mong đợi sẽ hoàn thành việc kiểm thử trong một khoảng thời gian giới hạn. (Và tất nhiên, QA đã làm được việc đó).
• Mục tiêu duy nhất của QA là tìm lỗi và các khuyết điểm. Đồng thời, việc đánh giá hiệu suất làm việc của QA cũng dựa vào số lượng lỗi/khuyết điểm hợp lý mà QA tìm ra.
• Chu trình kiểm thử phần mềm (STLC) và vòng đời của lỗi (Bug lifecycle) được đi theo trong quá trình thực thi. Giao tiếp qua email được khuyến kích.
• Kiểm thử tự động được xem như là công việc cuối cùng và tập trung chủ yếu ở phần giao diện. Bộ kiểm thử qui hồi được xem như là ứng viên tốt nhất cho kiểm thử tự động.

Những điều trên cũng có những khuyến điểm của riêng nó

• Vì kỹ sư phát triển và QA làm việc độc lập nên việc giao tiếp giữa hai bên chỉ là lỗi và khuyết điểm.
• Phạm vi làm việc của QA bao gồm viết và thực thi các kịch bản kiểm thử trên sản phẩm hoàn chỉnh.
• Có rất ít (hoặc không có) cơ hội cho QA xem mã nguồn hay tương tác với kỹ sư phát triển hay nhóm nghiệp vụ.
• Bởi vì toàn bộ sản phẩm được đưa đến QA một lúc, trách nhiệm của QA là cực kỳ to lớn trên vòng đời của sản phẩm. QA thường được xem như “người gác đền”, và bất kể trên sản phẩm có vấn đề gì, mọi chỉ trích đều chỉ vào QA.
• Như một phần của kiểm thử chức năng, kiểm thử qui hồi trên toàn bộ sản phẩm cũng là một trách nhiệm của QA, nơi mà có một lượng khổng lồ kịch bản kiểm thử cần thực thi.
• Ngoài những khuyết điểm ở trên, vấn đề lớn nhất chính là “Thiếu sự tập trung vào việc cung cấp một sản phẩn với chất lượng tốt với một tốc độ hợp lý”.

Mục tiêu cuối cùng của nhóm

(cả kỹ sư phát triển và kỹ sư kiểm thử) là đưa ra một sản phẩm với chất lượng tốt, đáp ứng các yêu cầu nghiệp vụ của khách hàng và dễ sử dụng. Nhưng bởi vì những khoảng thời gian giữa những giai đoạn bị tăng lên khi đưa sản phẩm ra thị trường, trọng tâm đã bị xao lãng, mục tiêu duy nhất được duy trì là hoàn thành việc viết mã và chuyên giao cho nhóm kiểm thử để tiến hành UAT (User Acceptance Testing).

Khi đó, QA chỉ tập trung vào việc thực thi các kịch bản kiểm thử (đánh dấu vào một bảng kiểm tra), đảm bảo mọi lỗi/khuyết điểm đã được chỉnh sửa, và chuyển qua kiểm thử các chức năng khác trong hệ thống. Vậy nên, trên quan điểm của QA, trọng tâm không ở vấn đề tốc dộ và chất lượng của sản phẩm, mà là hoàn thành việc thực thi các kịch bản kiểm thử (và, tất nhiên là bao gồm cả các kiểm thử tự động, nếu có).

Nguyên lý Agile

Bắt đầu từ năm 2001, khi một nhóm gồm 17 chuyên gia gặp gỡ ở Utah (Mỹ) để trượt tuyết, ăn uống, nghĩ ngơi và có một thảo luận về chất lượng; kết quả chính là Nguyên lý Agile.

Là một chuyên gia về chất lượng, chúng ta cũng nên hiểu về bản chất của các Nguyên lý Agile và định hình lại cách suy nghĩ của chúng ta cho phù hợp với mô hình mới này.

Trước khi định hình lại cách suy nghĩ của chúng ta trong việc kiểm thử phần mềm với các nguyên lý Agile, hãy cùng làm rõ một việc: trong Agile, nhóm làm việc cần đa nhiệm và mỗi một thành viên trong nhóm đều đóng góp để phát triển sản phẩm/chức năng.

Do đó, nhóm thường được gọi là “Nhóm phát triển”, bao gồm cả lập trình viên, kỹ sư kiểm thử và phân tích nghiệp vụ. Và, các thuật ngữ lập trình viên và kỹ sư kiểm thử được dùng thay cho kỹ sư phát triển và QA.

Phần mềm hoạt động quan trọng hơn các tài liệu toàn diện về sản phẩm

Mục tiêu cuối cùng của nhóm phát triển Agile là chuyển giao ứng dụng/bản nâng cấp có khả năng sử dụng trong khoảng thời gian nhanh nhất, nghĩa là, thời gian là nhân tố chính. Nói vậy, không có nghĩa chất lượng không quan trọng. Bởi vì thời gian để đưa sản phẩm ra thị trường là giới hạn, điều quan trọng chính là một chiến lược và kế hoạch thực thi kiểm thử cần tập trung nhiều hơn vào chất lượng tổng quát của ứng dụng.

Kiểm thử là một công việc không có điểm dừng, nó có thể tiếp tục và tiếp tục, kỹ sư kiểm thử cần xác định các thông số chính mà họ có thể bật đèn xanh để sản phẩm có thể đưa ra thị trường. Để làm được điều đó, điều quan trọng là kỹ sư kiểm thử cảm thấy phù hợp khi quyết định các khái niệm “định nghĩa sự sẵn sàng” (Definition of Ready) và “định nghĩa sự hoàn thành” (Definition of Done – DoD), và cũng không nên bỏ qua “Tiêu chuẩn chấp nhận cho một tình huống/chức năng” (Acceptance Criteria of the story – AC).

Các chiến lược và kịch bản kiểm thử nên xoay quanh DoD và AC. Thay vì cố gắng viết đầy đủ các kịch bản cũng như bao gồm các thông tin mà hiếm khi được sử dụng, hãy tập trung hơn vào sự rõ ràng và các điểm chính yếu.

Điểm quan trọng ở đây là, chỉ bao gồm những thông tin mà kịch bản kiểm thử cần và có giá trị đối với kịch bản đó.

Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng

Nên có những cuộc tiếp xúc trực tiếp với khách hàng về cách tiếp cận kiểm thử và cố gắng minh bạch trong việc chia sẽ các kịch bản kiểm thử, dữ liệu kiểm thử và kết quả.

Cũng nên có những buổi họp mặt để lấy phản hồi từ khách hàng và chia sẽ kết quả kiểm thử. Hỏi khách hàng nếu họ đánh giá tốt các kết quả kiểm thử hay họ muốn có thêm những kịch bản đặc biệt. Đừng tự giới hạn bản thân trong việc đặt câu hỏi và tìm kiếm sự xác nhận từ khách hàng/nhóm nghiệp vụ để hiểu hơn về chức năng cũng như nghiệp vụ.

Càng hiểu sâu về chức năng, kỹ sư kiểm thử càng rõ ràng hơn trong việc kiểm thử.

Phản hồi với sự thay đổi quan trọng hơn bám theo kế hoạch

Thứ bất biến duy nhất chính là sự thay đổi.

Chúng ta không thể kiểm soát sự thay đổi và chúng ta hiểu và chấp nhận sự thật là, luôn luôn có sự thay đổi trong chức năng cũng như các yêu cầu; chúng ta phải thích ứng và thực hiện nó.

Tốc độ thay đổi yêu cầu được nhấn mạnh trong Agile, giống với thời trang, như một kỹ sư kiểm thử, chúng ta cần giữ cho kế hoạch kiểm thử và các kịch bản linh động đủ để thích ứng với sự thay đổi.

Theo truyền thống, chúng ta tạo kế hoạch kiểm thử và mọi thứ đi theo vòng đời của dự án. Ngược lại, trong Agile, kế hoạch cần linh động với từng yêu cầu. Một lần nữa, hãy tập trung vào DoD và AC.

Không cần thiết phải tạo ra kế hoạch kiểm thử cho từng tình huống/chức năng; thay vào đó, có thể tạo các kế hoạch kiểm thử ở mức độ Epic. Khi một Epic được thiết lập và tiến hành, có thể đồng thời tiến hành tạo ra kế hoạch kiểm thử cùng lúc. Quan trọng là, kỹ sư kiểm thử cần bao phủ chất lượng của toàn bộ Epic với kế hoạch kiểm thử đó.

Có thể sử dụng PI (Product Increment) để xác định các kịch bản kiểm thử tổng quát cho từng tình huống dựa vào DoD và AC.

Truyền thông giao tiếp và sự tương hỗ quan trọng hơn quy trình và công cụ

Kỹ sư kiểm thử thường có xu hướng nghiên về quá trình (process-oriented), nhưng chúng ta cần nhớ rằng, thay vì đi theo chu trình, thời gian đáp ứng không nên bị ảnh hưởng.

Với trường hợp nhóm làm việc cùng địa điểm, bất kỳ vấn đề nào cũng có thể giải quyển thông qua đối thoại trực tiếp. Có lẽ việc họp mặt hằng ngày (daily stand-ups) cung cấp một giải pháp tốt để giải quyết các vấn đề. Việc ghi nhận/tài liệu hóa lỗi/khuyết điểm là quan trong, nhưng nó chỉ nên được làm cho mục đích ghi dấu (tracking) mà thôi.

Tester nên làm việc chung với Dev và hợp tác để giải quyết các khuyết điểm. Nếu cần, khách hàng cũng nên tham gia chung. Kỹ sư kiểm thử nên chủ động tham gia vào quá trình TDD và cũng nên cộng tác với lập trình viên để chia sẽ các kịch bản và cố gắng xác định lỗi ở ngay mức độ đơn vị.

Kết luận

Kiểm thử trong Agile không phải là kỹ thuật mới. Nó là sự thay đổi trong suy nghĩ, và sự thay đổi diển ra một cách liên tục. Nó yêu cầu các kiến thức, kỹ năng và sự hướng dẫn đúng đắn.

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

• Agile là gì? Scrum là gì? Các công cụ quản lý dự án theo Agile mà bạn nên biết
• 32 cuốn sách học lập trình bạn nhất định phải đọc
• Những tựa sách nổi tiếng dành cho Software Developer – Phần 1

Xem thêm Việc làm agile hấp dẫn trên Station D