Nhắc đến kiểm thử phần mềm, chúng ta không còn quá xa lạ với các dự án Agile và khái niệm Agile Testing. Nhưng làm thế nào để trở thành một Agile giỏi, thành công thì không phải ai cũng biết. Trong cuốn “Agile Testing A Practical Guide for Testers and Agile Teams” xuất bản năm 2009, Addison Wesley đã đề cập đến 7 yếu tố cốt lõi làm nên thành công cho AgileTesting. Bài viết này sẽ chỉ rõ 7 yếu tố làm nên thành công của Agile Testing dựa trên những tham khảo từ tác giả cuốn sách nói trên.

Bảy yếu tố làm nên thành công của Agile Testing bao gồm:

1. Sử dụng phương pháp tiến cận toàn nhóm 2. Thích nghi với mind set của Agile Testing 3. Tự động hóa kiểm thử hồi quy 4. Đưa ra và nhận lại phản hồi 5. Xây dựng nền móng thực hành các giá trị Agile 6. Phối hợp hợp tác với khách hàng 7. Nhìn vào bức tranh tổng thể

Chúng ta sẽ cùng nhau tìm hiểu 7 yếu tố này ngay sau đây.

1.Yếu tố 1: Sử dụng phương pháp tiếp cận toàn nhóm

Khi cả nhóm phát triển tham gia vào quá trình kiểm thử, chúng ta sẽ có một tập hợp các kỹ năng, kinh nghiệm khác nhau.

• Kiểm thử tự động không phải vấn đề quá lớn với nhóm lập trình.
• Khi kiểm thử có mức độ ưu tiên cao, bất cứ ai cũng có thể nhận công việc kiểm thử, và nhóm sẽ thiết kế ra mã nguồn có thể kiểm thử được.

Để thực hiện được điều này, trước hết hãy để kiểm thử viên trở thành 1 phần thực sự của nhóm phát triển.

• Giúp họ có thể thích nghi nhanh chóng với quy trình phát triển Agile.
• Cho họ thời gian để có được những kỹ năng mới, có thể cộng tác chặt chẽ với các thành viên của nhóm phát triển và khách hàng.

Nếu bạn quản lý một nhóm Agile, để nhóm phát triển, bạn nên thực hiện phương pháp toàn nhóm. Hãy nhớ rằng chất lượng chứ không phải tốc độ mới là mục tiêu mục tiêu của Agile. Nhóm cần các kiểm thử viên để giúp làm rõ yêu cầu, biến chúng trở thành các kiểm thử điều hướng phát triển - quan điểm duy nhất tạo ra 1 sản phẩm tốt.

• Hãy chắc chắn rằng các kiểm thử viên có thể chuyển giao các kỹ năng và chuyên môn của họ cho những người còn lại trong nhóm.
• Hãy chắc chắn họ không bị đóng khung trong một vai trò như khi thực hiện kiểm thử thủ công.
• Hãy chắc chắn khi họ có nhu cầu giúp đỡ, các thành viên trong nhóm sẵn sàng giúp họ.
• Ngược lại, một kiểm thử viên sẽ không ngần ngại giúp đỡ khi có ai đó cần sự giúp đỡ trong khả năng của họ.

2. Yếu tố 2: Thích nghi với mind set của Agile Testing

Theo tư duy của Agile Testing, chúng ta có thể đặt các câu hỏi như sau:

• Làm như thế nào để sản phẩm tốt hơn?
• Thái độ kiểm thử Agile ra sao?
• Các Agile tester phải như thế nào?

Thái độ kiểm thử Agile là chủ động, sáng tạo, cởi mở với các ý tưởng mới, sẵn sàng chấp nhận bất cứ công việc nào. Các Agile tester luôn rèn luyện và cải thiện các khả năng của mình, luôn sẵn sàng hợp tác, tin tưởng vào khả năng bản thân, cũng như đam mê với việc giúp team và công ty thành công. Họ cũng là những người luôn chia sẻ niềm đam mê về chất lượng với những người cùng nhóm, tập trung vào các mục tiêu của nhóm và thực hiện những gì trong khả năng để giúp mọi người hoàn thành công việc tốt nhất trong khả năng của mình.

Các yếu tố để trở thành Agile giỏi:

• Điều hướng liên tục tìm kiếm các cách để làm việc tốt hơn, liên tục nâng cao kĩ năng của mình.
• Đọc sách, blogs, các bài báo hay để tiếp thu các ý tưởng và kĩ năng mới.
• Tham dự các cuộc họp nhóm với người cùng nội bộ.
• Tham gia vào các cuộc thảo luận qua mail list để lấy được các phản hồi về các vấn đề hay ý tưởng mới.

Các cách thực hiện:

• Thử nghiệm với các phương thức thực hành, công cụ, và kỹ thuật mới.
• Khuyến khích nhóm cố gắng thực hiện các phương pháp tiếp cận mới.
• Các vòng lặp ngắn là lý tưởng để thực hiện thử nghiệm.
• Nên trao đổi với nhóm khi gặp bất cứ vấn đề gì có thể ảnh hưởng tới kiểm thử.
• Giữ 1 danh sách trở ngại và giải quyết 1 hoặc 2 trong mỗi vòng lặp
• Sử dụng các biểu đồ để tất cả mọi người có thể biết được các vấn đề phát sinh và theo dõi tiến độ viết code và kiểm thử.

3. Yếu tố 3: Tự động hóa kiểm thử hồi quy

Một nhóm Agile có thể thành công khi không có kiểm thử tự động? Có thể, nhưng hầu hết các nhóm kiểm thử thành công đều có sự có mặt của kiểm thử tự động. Nếu bạn sử dụng toàn bộ thời gian của bạn vào kiểm thử hồi quy thủ công, bạn sẽ không bao giờ có thời gian để thực hiện các kiểm thử thăm dò quan trọng - việc có thể sẽ đưa ra các hành vi nguy hiểm đang tiềm ẩn trong mã nguồn.

Ta hoàn toàn có thể phát triển Agile sử dụng kiểm thử tự động để điều hướng phát triển. Nếu không có chu kỳ phản hồi ngắn và mạng lưới an toàn mà các bộ hồi quy mang lại, nhóm của bạn sẽ sớm trở nên ngập ngụa trong đám nợ kỹ thuật với hàng dài defect và tốc độ ngày càng chậm. Nhóm nên chọn các công cụ thích hợp tùy cho mỗi loại kiểm thử. Nghĩ về các kiểm thử trước đó sẽ cho phép các lập trình viên thiết kế mã dễ dàng cho kiểm thử tự động. Sử dụng các góc phần tư của kiểm thử Agile (Agile testing quadrants) và kim tự tháp kiểm thử tự động (test automation pyramid) để giúp bạn quyết định kiểu kiểm thử sao cho hiệu quả. Hãy bắt đầu từ việc kiểm thử đơn giản, bạn sẽ ngạc nhiên về giá trị mà việc smoke test tự động hay các kiểm thử đơn vị tự động mang lại. Tuy nhiên, khi mới bắt đầu việc kiểm thử tự động, thường có một “hump of pain” lớn cần vượt qua, hãy cố gắng vượt qua nó. Nếu bạn quản lý một nhóm phát triển hay nhóm kiểm thử, hãy chắc rằng bạn đã cung cấp đủ sự hỗ trợ về mặt thời gian, đào tạo và động lực cho họ. Nếu bạn là một tester trong nhóm không có tự động hóa và các lập trình viên quá điên cuồng để cố gắng viết mã nguồn thì có thể bạn đang phải đối mặt với một thách thức lớn. Hãy thử nghiệm các cách khác nhau để nhận sự hỗ trợ từ quản lý và từ các thành viên nhóm để tiến hành tự động hóa kiểm thử, điều này có thể sẽ giúp ích cho bạn.

4.Yếu tố 4: Đưa và nhận lại phản hồi

Phản hồi là giá trị cốt lõi của Agile. Các vòng lặp ngắn của agile được thiết kế để thực hiện phản hồi liên tục nhằm giúp team làm việc theo đúng kế hoạch. Kiểm thử viên là người duy nhất đưa ra phản hồi dưới dạng kết quả kiểm thử tự động, các phát hiện trong quá trình kiểm thử thăm dò và các quan sát của người dùng thực của hệ thống Bret Pettichord, CTO của WatirCraf, đồng tác giả của cuốn sách "Lessons Learned in Software Testing" đã có những chia sẻ về tầm quan trọng của việc phản hồi trong Agile:

“Phương pháp Agile cho phép team nhận phản hồi liên quan đến phần mềm mà chúng ta đang phát triển . Đó chính là điểm mấu chốt. Phản hồi làm việc trên một số mức độ. Pair programing giúp lập trình viên phản hồi liên tục trên code của họ. Stories là đại diện cho các đơn vị công việc nơi mà kiểm thử viên và người phân tích đưa ra các phản hồi cho các lập trình viên. Vòng lặp phát hành tạo điều kiện nhận các phản hồi từ bên ngoài team. Các hình thái của Agile đều rất có giá trị bởi vì chúng tạo ra các vòng lặp phản hồi giúp team thích nghi."

Rất nhiều team đã làm theo mô hình Agile bằng phương pháp tiếp cận grab-bag mà không nhận ra các điểm mấu chốt của từng mô hình. Họ thực hiện pair- program mà không cần thảo luận. Họ gửi code đến QA nhưng kiểm thử viên lại không thể kiểm thử bởi các giá trị biên không thống nhất, họ không thể nói liệu họ đã tìm ra bug hay kết thúc kiểm thử. Các vòng lặp trở thành các mốc lịch trình hơn là các cơ hội thực tế để cải thiện liên kết và điều chỉnh mục tiêu.

Lí do mà team Agile có thể làm mà không cần hoặc ít lên kế hoạch đó là phản hồi cho phép bạn chắc chắn một điều là bạn vẫn đang đi đúng đường. Nếu bạn không có phản hồi thực sự ý nghĩa thì bạn không phải là agile.

Để có thể đưa ra và nhận lại những phản hồi có ý nghĩa thực sự là thử thách với mỗi cá nhân. Tuy nhiên đó lại là điểm quan trọng để thành công với Agile. Agile có thể sẽ gặp khó khăn khi giám đốc điều hành hoặc khách hàng giao cho team danh sách các yêu cầu khi mới bắt đầu, và yêu cầu team sử dụng Agile (vì nó nhanh hơn), và sau đó không muốn tham gia và quá trình phản hồi. Bản thân Agile không nhanh hơn. Nó chỉ thực sự có ích khi mà team biết chấp nhận giá trị của sự thích nghi. Khả năng thích nghi này cần sử dụng mọi cách để tiếp cận tới bất cứ ai đang tham gia vào dự án. Chỉ team thực hiện Agile chưa đủ, những người liên quan cũng cần phải thực hiện Agile. Nhưng có phải thực sự tất cả chức năng đều cần thiết? Liệu rằng chúng ta có biết chính xác phần mềm cần phải như thế nào khi mới bắt đầu?

Agile sẽ nhanh hơn bởi vì phản hồi cho phép bạn tìm ra và tập trung vào chức năng có giá trị nhất. Nếu bạn chắc chắn bạn biết cần phải xây dụng cái gì, thì đừng sử dụng Agile. Nếu bạn không có thời gian để tập hợp và thực hiện theo phản hồi của khách hàng, thì cũng đừng sử dụng agile. Nếu bạn chắc chắn tất cả mọi người đều hiểu chính xác khi bắt đầu cần thực hiện những gì thì cũng không nên sử dụng Agile.

5. Yếu tố 5: Xây dựng nền móng các giá trị thực hành Agile

Các giá trị thực hành Agile bao gồm: Tích hợp liên tục Các môi trường kiểm thử Quản lý các Technical Debt (Các khoản nợ kỹ thuật) Tăng trưởng công việc Coding và Testing là 2 phần của một quy trình Tương tác giữa các phần thực hành

5.1. Tích hợp liên tục

Mỗi nhóm phát triển cần quản lý mã nguồn và tích hợp liên tục để thành công. Sẽ khó để có thể kiểm thử hiệu quả nếu ta không biết mình đang kiểm thử cái gì, chúng ta cũng không thể kiểm thử toàn bộ nếu không có mã nguồn có thể triển khai. Toàn bộ thành viên nhóm có thể kiểm tra công việc của chúng ta mỗi ngày một lần. Mỗi tích hợp nên được xác định bởi một build tự động mà nó bao hàm cả các kiểm thử để cung cấp phản hồi nhanh về tình trạng của phần mềm. Thực hiện quy trình tích hợp liên tục sẽ là một trong những ưu tiên hàng đầu của bất kỳ nhóm phát triển phần mềm nào. Nếu nhóm của bạn không có ít nhất một verified build hằng ngày thì hãy dừng ngay những việc bạn đang làm và hãy bắt đầu với việc tạo ra nó.

5.2. Các môi trường kiểm thử

Chúng ta không thể kiểm thử hiệu quả nếu không có một môi trường kiểm thử có khả năng kiểm soát tốt. Ta cần biết build gì đã được triển khai, schema dữ liệu nào đã được sử dụng, ai đang cập nhật schema đó, và các tiến trình nào đang chạy trên máy. Nên đầu tư nhiều vào phần cứng bởi nó là phần ít tốn kém nhất, có nhiều phần mềm mã nguồn mở có sẵn cho các môi trường kiểm thử, ta cũng nên đầu tư để có thể tiến hành các kiểm thử tự động và thăm dò nhanh chóng và hiệu quả.

5.3. Quản lý các Technical Debt (Các khoản nợ kỹ thuật)

Có rất nhiều cách để đo mã nguồn và tỷ lệ defects (chuyển nợ kỹ thuật thành các ảnh hưởng ở cuối chu kỳ). Các doanh nghiệp cần các nhóm phát triển phần mềm của họ vẫn hiệu quả như mong muốn. Họ có thể phải giảm phạm vi (scope) hay các tính năng mong muốn để đủ thời gian cho việc thiết kế mã nguồn hướng kiểm thử tốt và các thực hành hiệu quả như tái cấu trúc nhỏ liên tục. Độ bao phủ tốt từ các kiểm thử hồi quy tự động là chìa khóa để giảm thiểu nợ kỹ thuật. Nếu thiếu độ bao phủ này, thời gian ngân sách trong mỗi vòng lặp sẽ được dùng để xây dựng các kiểm thử tự động. Ngoài ra, ta cần lên kế hoạch một “vòng lặp tái cấu trúc (refactoring interation)” để nâng cấp và thêm các công cụ cần thiết nhằm viết các kịch bản kiểm thử, và thực hiện các khả năng tái cấu trúc chính.

5.4. Tăng trưởng công việc

Một lý do mà các nhóm Agile có thể tạo ra một sản phẩm chất lượng là họ làm việc với quy mô nhỏ. Các stories được đưa ra trong một vài ngày làm việc, và mỗi story có thể được chia thành nhiều phần nhỏ và được xây dựng từng bước. Điều này cho phép kiểm thử từng phần nhỏ và sau đó thực hiện kiểm thử ở mức độ cao hơn. Nếu các thành viên trong team đang bị cám dỗ để đưa vào một mảng lớn các chức năng cùng một lúc, hãy khuyến khích họ tìm kiếm một phương pháp để tiếp cận từng bước. Ví dụ: Đặt câu hỏi: “Giá trị thương mại tập trung vào cái gì với story này? Hướng cơ bản nhất thông qua mã nguồn là gì? Điều gì xảy ra tiếp theo?”

5.5. Coding và Testing là 2 phần của cùng một quy trình

Các tester viết kịch bản kiểm thử, dựa vào example được cung cấp bởi customer để giúp programmers hiểu story và bắt đầu. Các kiểm thử và examples cung cấp một ngôn ngữ chung mà tất cả mọi người tham gia vào sản phẩm phần mềm đều hiểu được. Tester và programmer hợp tác chặt chẽ như mã nguồn tiếp diễn, và họ cũng hợp tác chặt chẽ với customer. Programmer cho tester thấy chức năng mà họ đã viết, và tester cho programmer thấy các hành vi không mong muốn mà họ tìm thấy. Mỗi vòng lặp Agile chứa hàng chục vòng lặp test-code-test-code-test liên tục, nhanh chóng và tăng trưởng.

Khi chu kỳ hợp tác và phản hồi này bị phá vỡ, kiểm thử bị tách ra khỏi sự phát triển, nguy cơ rủi ro sẽ xảy ra. Nếu một story được kiểm thử trong vòng lặp sau khi nó được viết mã và các lỗi được tìm thấy, programmer phải dừng công việc ở story mới, phải nhớ lại mã nguồn đã làm việc như thế nào với story của vòng lặp cũ, sửa nó và đợi ai đó kiểm thử việc sửa chữa đó.

5.6. Tương tác giữa các phần thực hành

Một thực hành phát triển Agile như tích hợp liên tục có thể có một chút khác biệt, nhưng sự kết hợp của nhiều thực hành Agile sẽ trở nên rất hoàn hảo. Thiết kế điều hướng kiểm thử (test-driven design), tập hợp các mã nguồn riêng, và tích hợp liên tục cùng với nhau để đưa ra phản hồi nhanh chóng, liên tục cải tiến thiết kế mã và khả năng phân phối nhanh giá trị thương mại. Tự động hóa các kiểm thử là tốt, nhưng sử dụng các kiểm thử tự động để điều hướng phát triển, theo sau bởi các kiểm thử thăm dò để phát hiện những khoảng trống hoặc điểm điếu, là các mức độ to lớn hơn. Một số thực hành không làm việc tốt khi thực hiện cô lập. Ví dụ như không thể thực hiện tái cấu trúc nếu không có kiểm thử tự động. Các thực hành Agile được thiết kế để bổ sung cho nhau. Hãy dành thời gian để hiểu được mục đích của nhiều phần trong chúng, xem xét những gì cần thiết để tận dụng lợi thế đầy đủ của mỗi thực hành và đưa ra các quyết định chu đáo về những việc làm cho nhóm.

6. Yếu tố 6: Phối hợp hợp tác với khách hàng

Một trong những giá trị lớn nhất mà Tester mang lại cho Agile team là giúp khách hàng:

• Phân loại, đánh mức ưu tiên cho các yêu cầu
• Minh họa những yêu cầu đó thành những ví dụ cụ thể về hành vi mong muốn và những kịch bản người dùng như:

• How will you use this?
• What's the worst that can happen? Từ các ví dụ cụ thể đó chuyển vào các Kiểm thử thực thi.

Chưa bao giờ có một con đường trực tiếp trong việc giao tiếp giữa người lập trình và khách hàng. Công việc của tester là khuyến khích việc giao tiếp trực tiếp giữa người lập trình và khách hàng càng nhiều càng tốt. Nguyên tắc của việc này là sử dụng “Sức mạnh của bộ ba - Power of Three”, vậy bản chất của “Sức mạnh của bộ ba - Power of Three” là gì ? Có thể định nghĩa "Power of Three" như sau: “Sức mạnh của bộ ba - Power of Three” bản chất là khách hàng, người lập trình và tester phải làm việc cùng nhau để đảm bảo khi có bất cứ yêu cầu nào bị bỏ quên hoặc không hiểu thì sẽ đều có câu trả lời đúng nhất. Để thực hiện được điều này cần liên tục nói chuyện với khách hàng và để khách hàng trao đổi thông qua “bảng trắng thật” hoặc những “công cụ ảo” tương đương (https://awwapp.com/b/uu8b1xmtx/ ) thường xuyên nhất có thể và tốt nhất là cần tương tác hàng ngày với khách hàng.

Để đảm bảo thường xuyên cập nhật được các yêu cầu từ phía khách hàng để làm việc tốt với khách hàng thì điều cần thiết là cần học hỏi về văn hóa (văn hóa đất nước, văn hoá ứng xử, văn hóa công việc,...) Nếu những khách hàng nằm rải rác ở những vùng khác nhau hoặc những đất nước khác nhau, chúng ta cần sử dụng tất cả những công cụ có thể tìm được để nâng cao khả năng giao tiếp và tương tác. Exp: Video call, công cụ nhắn tin trực tiếp (Chatword, skype,...). Những công cụ này không thể thay thế lý tưởng cho việc trao đổi trực tiếp nhưng ít nhất chúng cũng tốt hơn việc chỉ gửi email hoặc không nói gì cả. Và hãy ghi nhớ một điều quan trọng: Để đảm bảo một sản phẩm có chất lượng tốt thì đòi hỏi liên tục nâng cấp về mặt chức năng, để làm được điều này thì cả khách hàng, tester và người lập trình không được phép ngồi và đợi mà phải linh hoạt, không ngừng đưa ra các ý tưởng.

7. Yếu tố 7: Nhìn vào bức tranh tổng thể

Tester thường có xu hướng nhìn vào bức tranh tổng thể, và thường là nhìn từ quan điểm của khách hàng. Các lập trình viên luôn phải tập trung vào những tính năng mà họ đang phát triển. Họ có thể cũng kiểm thử, tuy nhiên họ vẫn phải tập trung vào kĩ thuật mà họ đang làm. Phát triển hướng kiểm thử (test-driven development) nếu hoàn thành tốt thì sẽ không gây ra lỗi đối với những đoạn code phát triển độc lập.

• Điều gì xảy ra nếu chức năng mới làm phá vỡ những phần liên quan đến nhau của ứng dụng?
• Điều gì xảy ra nếu chúng ta bỏ qua một vài chi tiết nhỏ làm khách hàng không hài lòng?

Ví dụ: Giao diện người dùng mới có thể được xây dựng một cách hoàn hảo nhưng nếu màu nền làm cho văn bản khó có thể đọc, nó sẽ làm cho người dùng cuối (end user) cảm thấy khó chịu. Vì vậy, cần phải đó ai đó xem xét ảnh hưởng rộng hơn đối với hệ thống và truyền đạt cho cả đội dự án.

Ngoài ra, chúng ta có thể sử dụng các Agile testing quadrants như một hướng dẫn để hỗ trợ việc lên kế hoạch kiểm thử:

• Sử dụng ý tưởng test pyramid để đảm bảo ROI tốt từ kiểm thử tự động của bạn.
• Phát triển hướng kiểm thử (test driven development ) giúp đảm bảo không quên bất cứ thứ gì lớn.
• Sử dụng kiểm thử thăm dò để tìm hiểu nhiều hơn về ứng dụng sẽ làm việc như thế nào, và kiểm thử của bạn phải thực hiện theo hướng nào.
• Tạo môi trường kiểm thử tương tự với production nhất có thể, sử dụng dữ liệu được phản ánh từ thế giới thực.

Trên đây là 7 yếu tố cốt lõi làm nên thành công của một Agile Testing. Hi vọng rằng bài viết này sẽ giúp các bạn có một cái nhìn tổng quan hơn và áp dụng được nó trong quá trình làm việc với team của mình.

Nguồn tham khảo: “Agile Testing A Practical Guide for Testers and Agile Teams" - Addison Wesley, 2009