Các kiểm thử kỹ thuật hỗ trợ Developmet Team tạo thành nền tảng của phát triển và kiểm thử agile. Nội dung Quadrant 1 không chỉ là về kiểm thử. Các bài unit test và component test mà chúng ta nói đến trong Quadrant 1 không phải là bài kiểm thử đầu tiên được viết cho mỗi user story, nhưng chúng giúp định hướng thiết kế và phát triển. Nếu không có nền tảng về test-driven design (thiết kế được dẫn dắt bởi kiểm thử), các unit test và component test tự động cũng như quy trình continuous integration (tích hợp code liên tục) để chạy kiểm thử, thì thật khó để cung cấp giá trị một cách kịp thời. Tất cả các kiểm thử ở các Quadrant khác không thể bù đắp cho những bất cập trong phần này.

Team cần các công cụ và quy trình phù hợp để tạo và thực hiện các bài kiểm thử kỹ thuật dẫn dắt quá trình phát triển. Chúng ta sẽ nêu ra một số ví dụ về công cụ cần thiết trong phần cuối của chương này.

Mục đích của Kiểm thử thuộc Quadrant 1

Các bài unit test và bài component test đảm bảo chất lượng bằng cách giúp developer hiểu chính xác những gì code cần thực hiện và cung cấp hướng dẫn cho một thiết kế phù hợp. Chúng giúp team tập trung vào user story đang được phát triển và áp dụng cách tiếp cận đơn giản nhất mà vẫn có hiệu quả. Unit testing xác minh hành vi của các bộ phận nhỏ, chẳng hạn như một đối tượng (object) hoặc một phương thức (method). Component testing giúp củng cố thiết kế tổng thể của một phần có thể triển khai của hệ thống bằng cách kiểm tra sự tương tác giữa các lớp (class) hoặc phương thức (method).

Phát triển các bài unit test có thể được coi là một công cụ thiết kế thiết yếu khi team áp dụng TDD (Test-Driven Development). Khi một developer bắt đầu một nhiệm vụ viết code, cô ta sẽ viết một bài kiểm thử để nắm bắt hành vi của một đoạn mã nhỏ và sau đó làm việc trên code cho đến khi bài kiểm thử được pass. Bằng cách xây dựng code theo từng vòng lặp nhỏ test-code-test, developer có cơ hội suy nghĩ về chức năng mà khách hàng cần. Khi có câu hỏi nảy sinh, developer có thể hỏi Customer/Product owner. Developer có thể cặp đôi (pairing) với một chuyên viên kiểm thử để đảm bảo rằng tất cả các khía cạnh của đoạn code đó và giao tiếp của nó với các unit khác, đều được kiểm thử.

Thuật ngữ “test-driven development” (phát triển được dẫn dắt bởi kiểm thử) dễ làm những người thực hành hiểu nhầm và không biết rằng nó liên quan nhiều đến thiết kế hơn là kiểm thử. Code được phát triển theo cách viết kiểm thử trước (test-first) được thiết kế một cách tự nhiên để thỏa mãn tính có thể kiểm thử (testability). Các kiểm thử thuộc Quadrant 1 đều nhằm đạt đến phần mềm chuyên nghiệp với chất lượng nội bộ (internal quality) cao nhất có thể.

Khi team thực hành TDD số lượng lỗi phát sinh sau này được giảm thiểu. Hầu hết các lỗi cấp đơn vị được ngăn chặn bằng cách viết bài kiểm thử trước khi viết code. Suy nghĩ thông qua thiết kế bằng cách viết bài unit test có nghĩa là hệ thống có nhiều khả năng đáp ứng các yêu cầu của khách hàng hơn. Nếu như thời gian kiểm thử sau phát triển bị chiếm đầy bởi việc tìm và sửa lỗi (mà phần lớn những lỗi này lẽ ra đã được phát hiện sớm bởi các bài kiểm thử unit test của developer), thì team sẽ không còn thời gian để tìm ra các vấn đề nghiêm trọng hơn có thể ảnh hưởng xấu đến các chức năng nghiệp vụ. Càng có nhiều lỗi rò rỉ ra khỏi quá trình coding của chúng ta, việc nghiệm thu và phân phối sản phẩm sẽ càng chậm hơn và cuối cùng, chất lượng sẽ bị ảnh hưởng. Đó là lý do tại sao các bài kiểm thử bởi developer trong Quadrant 1 rất quan trọng. Mặc dù team nên áp dụng các phương pháp phù hợp với tình hình của mình, nhưng các team nếu không áp dụng các thực hành agile cốt lõi như nói trên rất khó hưởng lợi nhiều từ các giá trị và nguyên tắc agile.

Cơ sở hạ tầng hỗ trợ

Kiểm soát mã nguồn (source code control) vững chắc, quản lý cấu hình (configuration management) và tích hợp liên tục (continuous integration) là điều cần thiết để nhận được giá trị từ các bài kiểm thử hướng dẫn phát triển của developer. Chúng cho phép team luôn biết chính xác những gì đang được kiểm thử. Continuous integration cung cấp một phương tiện để chạy kiểm thử mỗi khi có code mới. Khi kiểm thử không thành công, chúng ta biết ai đã check-in các thay đổi code gây ra lỗi và developer đó có thể nhanh chóng khắc phục lỗi. Continuous integration giúp tiết kiệm thời gian và thúc đẩy các developer chạy các bài kiểm thử mỗi khi check-in code. Quá trình tích hợp và xây dựng liên tục cung cấp một code package có thể triển khai để chúng ta thực hiện kiểm thử.

Các dự án agile mà thiếu các thực hành cốt lõi này sẽ có xu hướng trở thành dự án “waterfall” thu nhỏ. Các chu kỳ phát triển thì ngắn hơn, nhưng code vẫn bị “ném qua tường” cho những chuyên viên kiểm thử luôn cạn kiệt thời gian để kiểm thử vì code bàn giao có chất lượng kém. Chúng tôi đã làm việc trong các dự án thành công được quản lý theo phương pháp waterfall trong đó các developer tự động hóa các bài unit test, thực hành continuous integration và sử dụng các bản build tự động (automated build) để chạy các bài kiểm thử. Những dự án “waterfall” thành công này cũng có sự tham gia của khách hàng và người kiểm thử trong suốt chu kỳ phát triển. Khi chúng ta viết code mà không có các phương pháp và công cụ thích hợp, thì bất kể chúng ta gọi là quy trình gì, chúng ta sẽ không thể cung cấp code chất lượng cao một cách kịp thời.

Cho phép chúng ta đi nhanh hơn và làm được nhiều hơn

Tốc độ không bao giờ là mục tiêu cuối cùng của một agile team. Cố gắng làm mọi việc nhanh chóng và đáp ứng các thời hạn chặt chẽ mà không nghĩ đến chất lượng khiến chúng ta cắt giảm phạm vi kiểm thử và quay lại các thói quen cũ. Chúng ta sẽ tích tụ ngày càng nhiều technical debt và cuối cùng có thể sẽ lỡ thời hạn. Điều đáng mừng là tốc độ là tác dụng phụ lâu dài của việc viết code với chất lượng nội bộ cao nhất có thể. Các bài unit test liên tục chạy thông báo cho team về lỗi trong vòng vài phút. Sự cố và lỗi có thể được tìm thấy và khắc phục nhanh chóng. Một mạng lưới an toàn gồm các bài unit test và code integration test chạy tự động cho phép các developer làm refactoring thường xuyên. Điều này giữ cho code một tiêu chuẩn hợp lý về khả năng bảo trì. Technical debt được giữ ở mức thấp nhất có thể.

Nếu bạn đã từng làm việc với tư cách là người kiểm thử trong một dự án mà unit test bị bỏ qua, bạn biết việc dành toàn bộ thời gian của mình để tìm ra các khiếm khuyết cấp đơn vị dễ dàng như thế nào. Bạn có thể tìm thấy rất nhiều lỗi khi kiểm thử theo “con đường hạnh phúc” (the happy path) mà vì thế bạn không bao giờ có thời gian để kiểm thử các tình huống phức tạp hơn và các trường hợp cực đoan (edge case). Thời hạn phát hành bị lùi lại khi chu kỳ “tìm và sửa” kéo dài, hoặc quá trình kiểm thử chỉ vừa mới dừng lại đã thấy xuất hiện lỗi ở sản phẩm phát hành cho những khách hàng vốn không nghi ngờ gì.

Thực hành viết code dựa trên các bài kiểm thử có nghĩa là các developer có thể hiểu các yêu cầu của user story một cách thỏa đáng. Họ đã phải nói chuyện thường xuyên với khách hàng và chuyên gia kiểm thử để làm rõ các hành vi mong muốn. Tất cả các bên hiểu những thay đổi đang được thực hiện. Vào thời điểm team hoàn thành tất cả các nhiệm vụ (task cards) để coding một user story hoặc một phần nhỏ có thể kiểm thử của user story, tính năng này đã được bao phủ tốt bởi các bài unit test và component test. Thông thường các developer đã chắc chắn rằng có ít nhất một con đường end-to-end chạy tốt của user story đó.

Điều này có nghĩa là chúng ta, với tư cách là chuyên viên kiểm thử, chỉ tốn ít thời gian để tìm ra các lỗi cấp thấp. Chúng ta có thể sẽ thử các tình huống mà các developer không nghĩ đến và dành thời gian cho việc kiểm thử chức năng nghiệp vụ cấp cao hơn. Code được thiết kế tốt thường mạnh và có thể kiểm thử. Nếu chúng ta tìm thấy một lỗi, chúng ta sẽ thông báo nó cho developer, người này sẽ viết một bài unit test để tái tạo lỗi và sau đó sửa nó nhanh chóng. Chúng ta thực sự có thời gian để tập trung vào làm exploratory test và các loại kiểm tra chuyên sâu khác để cung cấp cho code một bài kiểm thử tốt và tìm hiểu thêm về cách thức code hoạt động. Thông thường, “lỗi” duy nhất mà chúng ta tìm thấy là các yêu cầu mà mọi người trong team đã bỏ qua hoặc hiểu sai. Ngay cả những lỗi như vậy cũng được tìm thấy nhanh chóng nếu khách hàng tham gia các hoạt động kiểm thử và demo thường xuyên. Sau khi một team đã thành thạo thực hành TDD (test-driven development), trọng tâm cải tiến sẽ chuyển từ việc ngăn ngừa lỗi sang việc tìm ra những cách tốt hơn để khơi gợi và nắm bắt các yêu cầu nghiệp vụ trước khi viết code.

Có một số quan điểm khác nhau về thời điểm viết bài kiểm thử và cho mục đích gì. Mỗi team phải thống nhất về cách tiếp cận giúp đạt được các mục tiêu chất lượng. Tuy nhiên có sự nhất chí trong cộng đồng Agile rằng TDD chắc chắn giúp làm ra phần mềm chất lượng tốt hơn.

Công việc của chuyên viên kiểm thử trở nên dễ dàng hơn

Các thực hành cốt lõi liên quan đến các bài kiểm thử của developer làm cho rất nhiều hoạt động kiểm thử trở nên dễ dàng hơn. Các developer làm việc trong môi trường phát triển (sandbox) của riêng họ, nơi họ có thể kiểm tra code mới mà không ảnh hưởng đến công việc của người khác. Họ sẽ không check-in code chừng nào code còn chưa vượt qua một tập các bài kiểm thử hồi quy (regression tests) trên môi trường phát triển của họ.

Team cần suy nghĩ về môi trường kiểm thử và dữ liệu dùng cho kiểm thử. Các bài unit test thường hoạt động trên các đối tượng giả lập hoặc mô phỏng (mock object) thay vì chạy trên cơ sở dữ liệu thực để cho mau chóng, nhưng các developer vẫn cần kiểm tra dựa trên dữ liệu thực. Chuyên viên kiểm thử có thể giúp họ xác định dữ liệu phù hợp dùng cho kiểm thử. Nếu các bài unit test được chạy trên dữ liệu thực, sẽ càng có ít vấn đề/lỗi phát sinh sau đó.

Viết trước những bài kiểm thử và viết code theo những bài kiểm thử đó có nghĩa là các developer luôn có ý thức làm cho code có thể kiểm thử được. Tất cả những phẩm chất này sẽ lan tỏa sang các bài kiểm thử nghiệp vụ (ở Quadrant 2) và các bài kiểm thử nhằm đánh giá sản phẩm (Quandrant 3 và 4). Toàn bộ team liên tục nghĩ về các cách để cải tiến thiết kế và làm cho việc kiểm thử dễ dàng hơn.

Câu chuyện của Lisa

Khi team của tôi lần đầu tiên áp dụng phương pháp agile, chúng tôi không có bất kỳ kiểm thử tự động nào. Chúng tôi không có cách nào để tạo ra một gói mã có thể triển khai (deployable package of code) và chúng tôi không có môi trường kiểm thử sơ bộ hoặc cơ sở dữ liệu dành cho kiểm thử. Tôi cũng không có bất kỳ phương tiện nào để tự mình tạo ra một bản build. Chúng tôi quyết định bắt đầu bằng việc viết test trước khi viết code và cam kết sẽ tự động hóa kiểm thử ở tất cả các cấp độ mà chúng tôi thấy phù hợp. Chúng tôi cần một cơ sở hạ tầng mới để đáp ứng yêu cầu này. Ưu tiên đầu tiên của chúng tôi là triển khai quy trình xây dựng liên tục (continuous build process), và đã thực hiện xong trong vài ngày. Mỗi bản build đã tự động gửi một email với danh sách các tệp đã đăng ký (checked-in files) và thông báo về các bản cập nhật (updates). Giờ đây tôi có thể chọn ra một bản build tôi muốn triển khai và kiểm thử. Ưu tiên tiếp theo là cung cấp các môi trường kiểm thử độc lập để các kiểm thử do một người thực hiện sẽ không can thiệp vào các kiểm thử khác. Một chuyên gia cơ sở dữ liệu đã tạo ra các scheme mới để đáp ứng nhu cầu kiểm thử và dựng một cơ sở dữ liệu “hạt giống” chứa dữ liệu chuẩn, tương tự như dữ liệu ở môi trường production. Các scheme này có thể được làm mới (refresh) theo yêu cầu một cách nhanh chóng với một bộ dữ liệu sạch. Kết quả là từng thành viên trong team, bao gồm cả tôi, có một môi trường kiểm thử độc lập của riêng mình.

Ngay cả trước khi team thành thạo TDD, cơ sở hạ tầng mới này đã được sử dụng để hỗ trợ thực hiện các bài kiểm thử. Cơ sở hạ tầng này cho phép team làm kiểm thử hiệu quả hơn nhiều. Một khía cạnh khác của việc cố gắng tự động hóa kiểm thử là phải xử lý một ứng dụng cũ (legacy application) khó kiểm thử. Các quyết định của team để thực thi qui trình TDD cũng giúp ích cho các bài kiểm thử liên quan đến khách hàng (Quadrant 2 và 3). Chúng tôi quyết định viết lại hệ thống ứng dụng theo một kiến ​​trúc mới tạo điều kiện thuận lợi cho việc kiểm thử và tự động hóa kiểm thử, không chỉ ở cấp unit test mà ở tất cả các cấp kiểm thử khác.

Thiết kế với kiểm thử trong tâm trí

Một lợi thế của TDD là code được viết với mục đích rõ ràng là để pass các bài kiểm thử. Team phải suy nghĩ ngay từ đầu về cách sẽ thực thi và tự động hóa các bài kiểm thử cho mọi user story họ phải coding. TDD có nghĩa là các developer sẽ viết từng bài kiểm thử trước khi họ viết code.

Code có thể kiểm thử (testable code) là một khái niệm đơn giản nhưng không phải là một nhiệm vụ dễ dàng, đặc biệt nếu bạn đang làm việc trên code base cũ không có kiểm thử tự động và không được thiết kế để có thể kiểm thử. Các hệ thống di sản (legacy) thường có logic nghiệp vụ, I/O, cơ sở dữ liệu và các lớp giao diện người dùng đan xen với nhau. Không có cách nào dễ dàng để bắt đầu tự động kiểm thử bên dưới lớp GUI hoặc làm unit test.

Một cách tiếp cận phổ biến trong việc thiết kế một kiến ​​trúc có thể kiểm thử là tách biệt các lớp khác nhau thực hiện các chức năng khác nhau trong ứng dụng. Lý tưởng nhất là bạn muốn có khả năng truy cập trực tiếp vào từng lớp bằng một “bộ gá” kiểm thử (test fixture) và các thuật toán kiểm thử thông qua các đầu vào khác nhau. Để làm điều này, bạn tách logic nghiệp vụ thành lớp riêng của nó, sử dụng các đối tượng giả (fake object) thay vì cố gắng truy cập các ứng dụng khác hoặc truy cập cơ sở dữ liệu thực. Nếu lớp trình bày (presentation layer) có thể được tách biệt khỏi lớp logic nghiệp vụ bên dưới và lớp truy cập cơ sở dữ liệu, bạn có thể nhanh chóng kiểm tra hợp lệ đầu vào (input validation) mà không cần kiểm thử logic chạy bên dưới.

Một ví dụ khác về cách tiếp cận đối với thiết kế có thể kiểm thử là hình mẫu “Ports và Adapters” của Alistair Cockburn (Cockburn, 2005). Mục đích của hình mẫu này là “tạo ra ứng dụng của bạn hoạt động mà không cần có giao diện người dùng hoặc không có cơ sở dữ liệu để bạn có thể chạy kiểm thử hồi quy (regression test) tự động, hoạt động cả khi cơ sở dữ liệu không truy cập được, và liên kết các ứng dụng với nhau mà không có sự tham gia nào của người dùng”. Các port chấp nhận các sự kiện bên ngoài (outside event) và một adapter thiết kế riêng cho từng công nghệ sẽ chuyển đổi thành một thông báo (message) mà ứng dụng có thể hiểu được. Tiếp đó, ứng dụng sẽ gửi đầu ra qua một port cho một adapter khác để tạo ra các tín hiệu (signal) cần thiết cho người dùng thực tiếp nhận hoặc cho người dùng tự động (automated user). Các ứng dụng được thiết kế theo hình mẫu này có thể được điều khiển bởi các script kiểm thử tự động một cách dễ dàng giống như cách điều khiển của người dùng thực.

Với một dự án hoàn toàn mới tinh thì thực hành viết test trước viết code sau (code test-first) là hiển nhiên. Các hệ thống di sản, mà chưa từng trải qua các unit test chạy tự động, đặt ra một thách thức lớn. Thật khó để viết các bài unit test cho code không được thiết kế để có thể kiểm thử và cũng thật khó để sửa đổi code mà trước đó không được kiểm thử bằng các unit test. Một số team đã làm theo các kỹ thuật “giải cứu code di sản” được Michael Feathers chỉ dẫn trong cuốn “Working Effectively with Legacy Code” (Feathers, 2005). Một số team khác, chẳng hạn như team của Lisa, tiếp cận theo cách “bóp nghẹt” (strangle) code di sản. Chiến lược này bắt nguồn từ cách “bóp nghẹt ứng dụng” của Martin Fowler (Fowler, 2004). Các user story mới được code theo cách viết test trước sử dụng một kiến ​​trúc mới trong khi hệ thống cũ vẫn được duy trì. Theo thời gian, phần lớn hệ thống được chuyển đổi sang kiến ​​trúc mới, với mục tiêu cuối cùng là loại bỏ hoàn toàn hệ thống di sản.

Kiểm thử agile trong môi trường ứng dụng chạy trên các hệ thống mainframe đặt ra những thách thức riêng, ví như là thiếu các ấn phẩm và thông tin về cách thực hiện thành công agile. COBOL, mainframe và các loại tương tự vẫn đang được sử dụng rộng rãi. Hãy để các nguyên tắc và giá trị agile hướng dẫn team của bạn khi bạn tìm cách áp dụng kiểm thử tự động trong ứng dụng của mình. Bạn có thể phải điều chỉnh một số kỹ thuật. Ví dụ: có thể bạn không thể viết test trước viết code sau, nhưng bạn có thể kiểm thử ngay sau khi viết code. Đó là vấn đề của cả team cần giải quyết, không chỉ là của riêng các chuyên viên kiểm thử.

Bí quyết là toàn đội cam kết vào kiểm thử và chất lượng. Khi một team liên tục làm việc để viết các bài kiểm thử và khiến chúng pass, team sẽ tìm ra cách để hoàn thành công việc. Team nên dành thời gian để xem xét cách họ có thể tạo ra một kiến trúc giúp tạo các bài kiểm thử tự động dễ dàng, không tốn kém để bảo trì và tồn tại lâu dài.

Kiến trúc phân lớp và tính có thể kiểm thử

Nhóm của Lisa đã sử dụng cách tiếp cận “bóp nghẹt ứng dụng” để tạo ra một hệ thống có thể kiểm thử được, nơi các bài kiểm thử được sử dụng để thúc đẩy coding. Mike Thomas, kiến ​​trúc sư cấp cao của team, giải thích cách kiến ​​trúc phân lớp mới cho phép tạo ra một thiết kế có thể kiểm thử.

Kiến trúc phân lớp chia code base thành các lớp có chức năng tương tự nhau, thường liên quan đến một công nghệ. Các lớp ở mức cao nhất thì cụ thể nhất (the most specific) và phụ thuộc vào các lớp bên dưới, có tính khái quát hơn. Ví dụ, nhiều code base phân lớp như sau: lớp giao diện người dùng, lớp logic nghiệp vụ và lớp truy cập dữ liệu.

Xếp lớp theo chiều ngang chỉ là một cách để tổ chức code base. Một cách khác là phân các lớp theo domain (chẳng hạn như lớp bảng lương payroll hoặc lớp nhập đơn hàng order entry), được coi là các lớp “chiều dọc”. Tất nhiên, hai cách tiếp cận phân lớp này có thể được sử dụng kết hợp với nhau để nâng cao tính có thể kiểm thử. Phân lớp có lợi cho việc kiểm thử, nhưng chỉ khi cơ chế “kết nối” các lớp mang lại sự linh hoạt. Nếu một code base có các lớp được kết hợp chặt với nhau thông qua các cơ chế như sự phụ thuộc lẫn nhau trực tiếp giữa các class (direct concrete class dependencies) và các phương thức tĩnh (static methods), thì rất khó để tách riêng một unit để kiểm thử. Điều này khiến cho cho hầu hết các kiểm thử tự động chỉ có thể là loại kiểm thử tích hợp (integration test) vốn phức tạp và chạy chậm. Trong nhiều trường hợp, việc kiểm thử chỉ có thể được thực hiện khi chạy toàn bộ hệ thống. Tương phản với điều này là một code base trong đó các lớp được phân tách bằng các interface. Mỗi lớp chỉ phụ thuộc vào các interface được định nghĩa trong lớp bên dưới nó mà không phụ thuộc vào các class cụ thể. Các phụ thuộc (dependency) vào các interface như vậy dễ dàng được thỏa mãn với sự gấp đôi các bài kiểm thử tại thời điểm kiểm thử. Nhờ đó unit test được đơn giản hóa vì mỗi unit có thể thực sự được cô lập. Ví dụ: giao diện người dùng có thể được kiểm thử trên các đối tượng lớp nghiệp vụ giả lập và lớp nghiệp vụ có thể được kiểm thử trên các đối tượng truy cập dữ liệu giả lập, tránh việc truy cập cơ sở dữ liệu trực tiếp.

Cách tiếp cận phân lớp đã cho phép nhóm của Lisa thành công trong việc tự động hóa các bài kiểm thử ở mọi cấp độ và thúc đẩy sự phát triển với cả các bài kiểm thử kỹ thuật (technology-facing test) và kiểm thử nghiệp vụ (business-facing test).

Phản hồi kịp thời

Giá trị lớn nhất của các bài unit test là ở tốc độ phản hồi của chúng. Quá trình tích hợp và xây dựng liên tục mà tự động chạy các unit test nên kết thúc trong vòng mười phút. Giả sử các developer kiểm thử code nhiều lần trong ngày, thì nếu quá trình xây dựng và kiểm thử càng ké dài sẽ khiến các thay đổi bắt đầu dẫm chân lên nhau. Là một chuyên viên kiểm thử bạn có thể khó chịu khi phải đợi một thời gian dài để có chức năng mới hoặc bản sửa lỗi. Nếu có lỗi xuất hiện khi biên dịch hoặc khi chạy unit test, sự chờ đợi còn tồi tệ hơn, đặc biệt khi bạn gần đến giờ về!

Quá trình xây dựng và kiểm thử chạy các bài kiểm thử ở cấp độ cao hơn unit test, chẳng hạn như kiểm thử API theo cấp độ chức năng hoặc kiểm thử GUI, sẽ mất nhiều thời gian hơn. Nên có ít nhất một quy trình build chạy nhanh và một quy trình thứ hai chạy các kiểm thử tốn thời gian hơn. Cần có ít nhất một bản build cuối mỗi ngày để bạn chạy tất cả các kiểm thử chức năng (tốn nhiều thời gian hơn). Tuy nhiên, ngay cả điều đó cũng có thể khó chấp nhận. Thử hỏi sau khi một bài kiểm thử không thành công và lỗi được khắc phục, bạn sẽ mất bao lâu để biết chắc chắn rằng bản build sẽ pass?

Nếu quá trình xây dựng và kiểm tra của bạn mất quá nhiều thời gian, hãy yêu cầu nhóm của bạn phân tích nguyên nhân gây ra sự chậm trễ và thực hiện các bước để tăng tốc quá trình xây dựng. Dưới đây là một vài ví dụ.

■ Việc truy cập cơ sở dữ liệu thường tốn nhiều thời gian, vì vậy hãy cân nhắc sử dụng các đối tượng giả lập, nếu có thể, để thay thế cơ sở dữ liệu, đặc biệt là ở cấp độ unit test.

■ Sử dụng quy trình xây dựng và kiểm thử thứ hai để chạy các bài kiểm thử tích hợp và truy cập cơ sở dữ liệu tốn thời gian.

■ Cân nhắc xem liệu các bài kiểm thử có thể chạy song song để chúng kết thúc nhanh hơn hay không.

■ Chạy các kiểm thử tối thiểu cần thiết để kiểm tra hồi quy (regression test) hệ thống của bạn.

■ Phân tải nhiệm vụ build trên nhiều build servers.

■ Nâng cấp phần cứng và phần mềm máy chủ chạy build process

■ Tìm hiểu khu vực nào mất nhiều thời gian nhất và thực hiện từng bước cải tiến để tăng tốc.

Có đồng thời vài quá trình xây dựng và kiểm thử liên tục để cung cấp luồng phản hồi kết quả thường xuyên — điều này nghe có vẻ như là một giấc mơ đối với rất nhiều chuyên viên kiểm thử! Lỗi kiểm thử hồi quy sẽ được phát hiện sớm, cho phép bạn tốn ít công sức để sửa lỗi. Đây là lý do tuyệt vời để viết các bài kiểm thử kỹ thuật. Chúng ta hãy cùng xem xét ranh giới giữa kiểm thử kỹ thuật (technology-facing) và kiểm thử nghiệp vụ (business-facing).

Câu chuyện của Lisa

Ban đầu trong quá trình phát triển agile chúng tôi chỉ có rất ít các unit test, vì vậy chúng tôi đã bao gồm một số kiểm thử GUI (kiểu smoke test) trong qui trình build liên tục, mà được khởi động mỗi lần check-in code vào hệ thống kiểm soát mã nguồn. Khi chúng tôi đã viết đủ các bài unit test, chúng tôi đã chuyển các bài kiểm thử GUI và các bài kiểm thử chức năng FitNesse sang một quá trình build và kiểm thử riêng biệt chạy vào ban đêm trên cùng một máy chủ với quá trình build liên tục của chúng tôi.

Quá trình build liên tục của chúng tôi lúc đầu mất chưa đầy 10 phút, nhưng sau đó mất hơn 15 phút để hoàn thành. Chúng tôi đã viết thẻ nhiệm vụ (task card) để chẩn đoán và khắc phục sự cố. Các bài unit test mà các developer đã viết lúc đầu không được thiết kế tốt, bởi vì không ai chắc chắn về cách tốt nhất để viết các bài unit test. Team đã dành thời gian để cấu trúc lại các bài unit test, sử dụng các đối tượng truy cập dữ liệu giả thay vì cơ sở dữ liệu thực và thiết kế lại các bài kiểm thử để tăng tốc độ. Điều này đã giúp quá trình build chạy hết khoảng tám phút. Mỗi khi thời gian quá trình build bắt đầu tăng lên, chúng tôi xử lý vấn đề bằng cách tái cấu trúc, xóa các bài kiểm thử không cần thiết, nâng cấp phần cứng và chọn phần mềm khác nhau giúp cho quá trình build chạy nhanh hơn. Khi các kiểm thử chức năng của chúng tôi bao gồm nhiều dòng code hơn, bản build hàng đêm bị hỏng thường xuyên hơn. Vì quá trình xây dựng hàng đêm chạy trên cùng một máy chủ chạy quá trình build liên tục đang diễn ra, cách duy nhất để xác minh rằng bản build đã “xanh” trở lại là dừng quá trình build đang diễn ra, mà điều này khiến cho vòng phản hồi nhanh của chúng tôi mất tác dụng. Thời gian của cả team bắt đầu bị lãng phí. Chúng tôi sau đó mua và thiết lập một máy chủ build khác cho phiên bản chạy dài hơn, và cũng chạy quá trình build liên tục. Điều này ít tốn kém hơn nhiều so với việc dành quá nhiều thời gian để duy trì hai quá trình build chạy trên cùng một máy chủ và giờ đây chúng tôi đã nhận được vòng phản hồi nhanh chóng từ các bài kiểm thử chức năng.

Có lo ngại rằng các bài kiểm thử định hướng khách hàng (customer-facing test) sẽ trùng lặp rất nhiều với các bài kiểm thử kỹ thuật (technology-facing test) khiến team sẽ lãng phí thời gian. Chúng ta biết rằng các bài kiểm thử chức năng nghiệp vụ có thể dựa trên cơ sở giống như các bài kiểm thử unit test hoặc code integration test, nhưng do chúng có các mục đích khác nhau nên bạn không cần lo ngại.

Ví dụ: chúng ta có một user story để tính toán lịch trình khấu hao khoản vay và hiển thị nó cho một người dùng đang trong quá trình nộp đơn vay tín dụng. Một bài unit test cho user story này có thể sẽ kiểm thử với các biến số bất hợp lệ, chẳng hạn như tần suất thanh toán hàng năm nằm ngoài dải cho phép. Có thể có một bài unit test để tính ra ngày bắt đầu thanh toán khoản vay dự kiến ​​dựa trên định nghĩa về số tiền vay, lãi suất, ngày bắt đầu và tần suất thanh toán. Các unit test có thể bao gồm các kết hợp khác nhau của tần suất thanh toán, số tiền, lãi suất, kỳ hạn và ngày bắt đầu để chứng thực rằng cách tính khấu hao viết trong code là chính xác. Chúng có thể bao gồm các kịch bản test như năm nhuận. Khi các bài kiểm thử này được pass, developer cảm thấy tự tin về code.

Mỗi bài unit test là độc lập và kiểm thử một khía cạnh tại một thời điểm. Điều này có nghĩa là khi một bài unit test không thành công, developer có thể xác định vấn đề nhanh chóng và giải quyết vấn đề cũng nhanh chóng. Các bài kiểm thử nghiệp vụ rất hiếm khi chỉ bao gồm một khía cạnh, bởi vì chúng được giải quyết từ quan điểm kinh doanh.

Các bài kiểm thử nghiệp vụ cho user story này sẽ xác định chi tiết hơn cho các quy tắc kinh doanh, cách hiển thị trong giao diện người dùng và cách xử lý lỗi. Các bài kiểm thử sẽ nhằm xác minh rằng các chi tiết thanh toán, chẳng hạn như tiền gốc và tiền lãi, hiển thị chính xác trong giao diện người dùng. Họ sẽ kiểm tra xác thực cho từng trường trên giao diện người dùng và chỉ định xử lý lỗi cho các tình huống như không đủ số dư hoặc không đủ điều kiện. Họ có thể kiểm thử một tình huống trong đó một quản trị viên xử lý hai giao dịch thanh toán khoản vay trong cùng một ngày, mà điều này có thể khó mô phỏng ở cấp unit test.

Các kiểm thử nghiệp vụ bao gồm các tình huống người dùng phức tạp hơn và xác minh rằng người dùng cuối sẽ có trải nghiệm tốt. Hãy đẩy các bài kiểm thử xuống mức thấp hơn bất cứ khi nào có thể; nếu bạn xác định một test case có thể được tự động hóa ở cấp unit test, thì hầu như luôn có lợi ích tốt hơn.

Nếu bài kiểm thử mà liên quan đến nhiều vùng hoặc nhiều lớp của ứng dụng, thì có thể không khả thi để tự động hóa ở cấp độ unit test. Kiểm thử kỹ thuật lẫn kiểm thử nghiệp vụ đều có thể có các bài kiểm thử xung quanh ngày thanh toán khoản vay đầu tiên, nhưng chúng kiểm tra vì các lý do khác nhau. Unit test sẽ kiểm tra việc tính toán ngày tháng và kiểm thử nghiệp vụ sẽ xác minh rằng nó hiển thị chính xác trong báo cáo khoản vay của người đi vay.

Học cách viết các bài kiểm thử thuộc Quadrant 1 là nhiệm vụ khó. Nhiều team thực hiện quá trình chuyển đổi sang phát triển agile đã bắt đầu mà không có các unit test tự động, thậm chí không có quá trình tích hợp và xây dựng liên tục.

Nhiều tổ chức đã quyết định thử phương pháp agile mà không hiểu cách thực hiện chuyển đổi thành công. Trong vai trò chuyên viên kiểm thử, chúng ta có thể làm gì để giúp development team triển khai TDD, continuous integration và các thực hành khác vốn là chìa khóa để thành công?

Kinh nghiệm của chúng tôi là nếu bản thân chúng ta không phải là developer, chúng ta không cần phải đứng mũi chịu sào để thúc giục những developer áp dụng các phương pháp như TDD. Nếu chúng ta có thể chỉ cho họ cách thực hành TDD, điều đó sẽ rất thuyết phục. Nhưng nhiều chuyên viên kiểm thử chúng ta không có kinh nghiệm như vậy. Chúng ta cũng nhận thấy rằng việc truyền giáo suông không có tác dụng. Không khó để thuyết phục ai đó về mặt lý thuyết rằng TDD là một ý tưởng hay. Nhưng sẽ khó hơn nhiều để giúp họ có được động lực thực sự để thực hành TDD.

Chuyên viên kiểm thử có thể làm gì?

Nếu bạn là chuyên viên kiểm thử trong một nhóm được gọi là “agile team” mà thậm chí team không tự động hóa các unit test hoặc tạo ra các bản build liên tục — hoặc tối thiểu là thực hiện các bản build hàng ngày — bạn sẽ nhanh chóng cảm thấy thất vọng. Đừng bỏ cuộc! Hãy tiếp tục động não tìm cách để có được động lực trong quá trình chuyển đổi tích cực. Hãy thử tận dụng cơ hội ở các hoạt động xã hội hoặc các hoạt động team building khác để xem bạn có thể tạo ra những ý tưởng mới thu hút tất cả các thành viên trong team.

Một cái bẫy cần tránh là yêu cầu chuyên viên kiểm thử viết các bài unit test. Bởi vì TDD thực sự là một hoạt động thiết kế, điều cần thiết là người viết code phải tự mình viết các bài kiểm thử trước khi viết code. Các developer cũng cần sự phản hồi ngay lập tức do các bài unit test tự động cung cấp. Các bài unit test được viết bởi người khác sau khi code được viết có thể vẫn bảo vệ khỏi các lỗi hồi quy, nhưng chúng sẽ không có những lợi ích có giá trị nhất của các bài kiểm thử do chính developer viết ra.

Là một người kiểm thử trong một agile team, bạn có thể làm rất nhiều điều để hoạt động như một tác nhân thay đổi, nhưng tác động tiềm năng của bạn bị hạn chế. Trong một số trường hợp, hỗ trợ mạnh mẽ của cấp quản lý là chìa khóa để thúc đẩy team tham gia vào viết các bài kiểm thử thuộc Quadrant I.

Câu chuyện của Lisa

Bất cứ khi nào tôi muốn tác động đến sự thay đổi, tôi tham khảo các mô hình trong cuốn “Fearless Change” của Mary Lynn Manns và Linda Rising (2004). Sau khi làm việc với hai nhóm XP, tôi đã tham gia một team tuyên bố mong muốn áp dụng phương pháp agile nhưng không đạt được những bước tiến vững chắc. Tôi đã tìm thấy một số gợi ý trong “Fearless Change” để cố gắng đưa team theo hướng thực hành agile.

“Yêu cầu trợ giúp” là một hình mẫu như vậy.Theo đó “Vì việc áp dụng một ý tưởng mới vào một tổ chức là một Công việc lớn, hãy tìm kiếm những đồng nghiệp và các nguồn lực để giúp đỡ những nỗ lực đổi mới của bạn”. Tôi muốn team của mình bắt đầu sử dụng FitNesse, tôi đã xác định được một developer là người có chủ kiến ​​rõ ràng nhất đối với mục đích của tôi và đề nghị anh ta cùng tham gia với tôi để viết các bài kiểm thử FitNesse cho user story mà anh ấy đang làm. Anh ấy kể lại với các developer khác về những lợi ích thu được từ các bài kiểm thử FitNesse, và điều này khuyến khích họ cũng muốn thử. Hầu hết mọi người đều muốn giúp đỡ. Tư duy agile chính là về tất cả team làm việc cùng nhau, vì vậy không cần phải làm việc một mình. “Brown Bag” là một hình mẫu thay đổi khác mà các team của tôi đã áp dụng tốt. Ví dụ, team của tôi đã tổ chức một số buổi học về “Brown Bag”, trong đó họ viết các bài unit test cùng nhau. “Chuyên gia ở bên bạn” là một mô hình hiệu quả trong đó bạn tranh thủ sự giúp đỡ của một thành viên trong nhóm được tôn trọng, người hiểu rõ và có thể hỗ trợ những điều bạn đang cố gắng đạt được. Một team của tôi ban đầu không có động lực để viết các bài unit test. Developer có kinh nghiệm nhất trong nhóm đồng ý với tôi rằng TDD là một ý tưởng hay và anh ấy đã làm gương cho những người còn lại trong nhóm. Bạn sẽ thấy rằng luôn có một ai đó trong một agile team thông cảm cho mục đích của bạn. Hãy tranh thủ sự hỗ trợ của người đó, đặc biệt nếu team coi người đó là chuyên gia cấp cao.

Người quản lý có thể làm gì?

Nếu bạn đang quản lý một development team, bạn có thể làm rất nhiều điều để khuyến khích thực hành TDD và tự động hóa unit test. Làm việc với product owner để biến nâng cao chất lượng thành mục tiêu của team và truyền đạt tiêu chí chất lượng cho team. Khuyến khích các developer dành thời gian để làm việc có chất lượng tốt nhất thay vì phải lo lắng về đáp ứng thời hạn. Nếu ngày giao sản phẩm đang gặp nguy cơ trễ, hãy cố gắng giảm phạm vi công việc chứ không phải nhượng bộ chất lượng. Công việc của bạn là giải thích cho các bên nghiệp vụ liên quan rằng ưu tiên chất lượng sẽ đảm bảo cho họ nhận được giá trị kinh doanh tối ưu.

Cho team thời gian để học hỏi và cung cấp khóa đào tạo thực hành có chuyên gia hướng dẫn. Mời một agile coach có kinh nghiệm hoặc thuê một chuyên gia có năng lực có thể chuyển giao những kỹ năng thực hành cho team. Dành thời gian cho những refactoring quan trọng, suy nghĩ về cách tiếp cận tốt nhất để viết các bài unit test và code integration test cũng như lựa chọn các công cụ kiểm thử, cài đặt và nâng cấp. Người quản lý kiểm thử (test manager) nên làm việc với người quản lý phát triển (development manager) để khuyến khích các thực hành nâng cao tính có thể kiểm thử và cho phép người kiểm thử viết các bài kiểm thử có thể chạy được. Test manager cũng nên đảm bảo các chuyên viên kiểm thử có thời gian để học cách sử dụng các công cụ và hệ thống tự động hóa mà team đã quyết định thực hiện.

Đó là vấn đề của toàn bộ team

Mặc dù bạn có thể là một tác nhân thay đổi hiệu quả, nhưng điều tốt nhất là để cả team tham gia giải quyết vấn đề. Nếu bạn vẫn chưa thực hiện retrospective (họp rút kinh nghiệm) sau mỗi iteration, hãy đề xuất thử thực hành này hoặc áp dụng một số cải tiến quy trình khác.Trong buổi retrospective, hãy nêu ra các vấn đề đang cản trở việc bàn giao thành công. Ví dụ: “Chúng ta không hoàn thành các nhiệm vụ kiểm thử trước khi kết thúc iteration” là một vấn đề mà cả team phải giải quyết. Nếu một lý do không hoàn thành là do số lượng lỗi unit test cao, hãy đề xuất kiểm thử với TDD, nhưng cũng cần các developer đề xuất các cách riêng của họ để giải quyết vấn đề. Khuyến khích team thử một cách tiếp cận mới trong một vài iteration và quan sát xem giải pháp hoạt động như thế nào.

Các kiểm thử kỹ thuật hỗ trợ quá trình phát triển của team là nền tảng quan trọng cho tất cả các kiểm thử khác. Nếu team không thực hiện đúng công việc với các bài kiểm thử trong Quadrant 1 này, các loại kiểm thử kia (thuộc Quadrant 2, 3) sẽ khó khăn hơn nhiều. Điều này không có nghĩa là bạn không thể nhận được giá trị từ các kiểm thử thuộc Quadrant 2, 3, 4. Chỉ là sẽ khó làm hơn vì code của team thiếu chất lượng nội bộ khiến cho mọi hoạt động kiểm thử và fix lỗi sẽ mất nhiều thời gian hơn.

Các kiểm thử kỹ thuật không thể được thực hiện nếu không có các công cụ và cơ sở hạ tầng phù hợp. Trong phần tiếp theo, chúng ta xem xét các ví dụ về các loại công cụ cần thiết để team đạt được hiệu quả với các bài kiểm thử thuộc Quadrant 1.

Không có công cụ kỳ diệu nào đảm bảo thành công. Tuy nhiên, các công cụ có thể giúp những người giỏi giang làm việc tốt nhất của họ. Xây dựng cơ sở hạ tầng phù hợp cho các kiểm thử kỹ thuật là rất quan trọng. Có rất nhiều công cụ tuyệt vời có sẵn và chúng luôn được cải tiến. Team của bạn phải lựa chọn ra các công cụ phù hợp nhất với tình huống cụ thể.

Công cụ kiểm soát mã nguồn

Kiểm soát mã nguồn (source code control) cũng được biết đến với các tên khác, chẳng hạn như kiểm soát phiên bản (version control) hoặc kiểm soát sửa đổi (revision control). Nó chắc chắn không phải là mới, hoặc là duy nhất đối với phương pháp agile, nhưng không development team nào có thể thành công nếu thiếu công cụ kiểm soát mã nguồn. Nếu không có kiểm soát mã nguồn, bạn sẽ không bao giờ chắc chắn những gì bạn đang kiểm thử. Liệu developer chỉ thay đổi ở các mô-đun mà anh ta nói, hay anh ta đã quên không nói đến những thay đổi anh ta đã thực hiện đối với các mô-đun khác? Bạn không thể undo những thay đổi không mong muốn hoặc những dòng code lỗi nếu không có một hệ thống kiểm soát phiên bản. Kiểm soát mã nguồn giữ cho các developer khác nhau không thực hiện chồng lấn lên nhau các thay đổi đối với cùng một mô-đun. Nếu không lập phiên bản, bạn không thể biết chắc chắn code nào là để phát hành cho môi trường sản xuất.

“Software Configuration Management Patterns: Effective Teamwork, Practical Integrations” (2003), của Stephen Berczuk và Brad Appleton, là một nguồn tư liệu tốt để bạn tìm hiểu cách thức và lý do sử dụng kiểm soát mã nguồn. Kiểm soát mã nguồn là điều cần thiết đối với bất kỳ phương pháp phát triển phần mềm nào.

Hãy áp dụng kiểm soát mã nguồn cho các script kiểm thử tự động. Điều quan trọng là phải gắn các bài kiểm thử tự động với phiên bản code tương ứng mà chúng đã kiểm tra, phòng trường hợp bạn cần chạy lại các bài kiểm thử với phiên bản đó trong tương lai. Khi bạn gắn nhãn hoặc gắn thẻ cho một bản build, hãy đảm bảo rằng bạn cũng gắn nhãn hoặc gắn thẻ cho code kiểm thử, ngay cả khi bản build đó không được phát hành chính thức.

Team có thể tổ chức một hệ thống phân cấp code để cung cấp một kho lưu trữ các production code, các bài unit test tương ứng và các script kiểm tra cấp cao hơn. Làm điều này có thể đòi hỏi team một số brainstorming và thử nghiệm để tìm ra được cấu trúc phân cấp code phù hợp nhất.

Có rất nhiều option tuyệt vời để bạn lựa chọn. Các hệ thống mã nguồn mở như CVS và Subversion (SVN) dễ thực hiện, tích hợp với quy trình xây dựng liên tục và môi trường IDE (integrated development environment) , và rất tin cậy. Các công cụ khác như Rational ClearCase và Perforce của IBM có thể bổ sung các tính năng tốt, bù đắp cho chi phí gia tăng mà team phải đầu tư.

Hệ thống kiểm soát mã nguồn được tích hợp chặt chẽ với các môi trường phát triển IDE. Hãy xem xét một số IDE được sử dụng bởi các agile team.

IDE

Một IDE tốt (môi trường phát triển tích hợp) có thể hữu ích cho người lập trình và chuyên viên kiểm thử trong một agile team. IDE tích hợp với hệ thống kiểm soát mã nguồn để giúp ngăn ngừa các vấn đề về kiểm soát phiên bản và các thay đổi chồng lấn. Các trình soạn thảo bên trong IDE dành riêng cho từng ngôn ngữ lập trình và dựng cờ báo các lỗi cả khi bạn đang viết code. Quan trọng nhất, IDE cung cấp công cụ hỗ trợ refactoring.

Các developer sử dụng IDE có xu hướng có cá nhân hóa mạnh mẽ. Tuy nhiên, đôi khi một tổ chức quy định rằng tất cả các developer phải sử dụng một IDE cụ thể. Điều này có thể là do cấp giấy phép hoặc có thể nhằm khuyến khích lập trình cặp pair-programming. Việc ghép nối với một developer khác sẽ dễ dàng hơn nếu hai người sử dụng cùng một IDE, nhưng nói chung thì không nhất thiết phải sử dụng cùng một IDE. Hầu hết các công cụ hoạt động tương tự nhau, vì vậy không khó để thay đổi từ IDE này sang IDE khác để đáp ứng nhu cầu mới hoặc tận dụng các tính năng mới. Một số developer cứng nhắc vẫn thích sử dụng công nghệ đã được kiểm chứng như VI, VIM hoặc EMACS với tạo tệp hơn là dùng IDE.

Các IDE mã nguồn mở như Eclipse và NetBeans được sử dụng rộng rãi bởi agile team, cùng với các hệ thống độc quyền như Visual Studio và Wall IDEA. IDE có các plug-in để hỗ trợ các ngôn ngữ và công cụ khác nhau. Chúng hoạt động tốt với các test script cũng như với production code.

Những chuyên viên kiểm thử không chạy tự động kiểm thử thông qua IDE, nhưng muốn có thể xem các đoạn code đã thay đổi, thì có thể sử dụng các công cụ như FishEye cho phép truy cập vào code thông qua bản build tự động.

Kể từ khi viết bài này, các IDE đã hỗ trợ thêm các ngôn ngữ như Ruby, Groovy và Python. Các developer sử dụng ngôn ngữ động có thể thích các công cụ nhẹ hơn, nhưng họ vẫn cần các công cụ tốt hỗ trợ thực hành TDD và refactoring.

Bất kể môi trường phát triển và các công cụ đang được sử dụng, các agile team cần một khuôn khổ (framework) để tích hợp các thay đổi code từ các developer khác nhau, chạy các bài unit test để xác minh không có lỗi hồi quy (regression bugs) nào xảy ra và cung cấp code ở định dạng có thể triển khai.

Câu chuyện của Lisa

Trong nhóm của tôi, một số developer đang sử dụng IntelliJ IDEA, trong khi những người khác sử dụng Eclipse. Sự khác biệt về môi trường trong một số trường hợp khá hiếm hoi đã gây ra sự cố, chẳng hạn như các bài kiểm thử đã pass trong IDE nhưng không pass với bản build đầy đủ, hoặc check-in thông qua IDE gây ra sự hư hỏng trong hệ thống kiểm soát mã nguồn. Tuy nhiên, nói chung việc sử dụng các IDE khác nhau sẽ không gây ra vấn đề gì. Điều thú vị là theo thời gian, hầu hết người dùng Eclipse đã chuyển đổi sang IntelliJ IDEA. Vì sự kết hợp với developer dùng IntelliJ IDEA khiến họ thích hơn. Cá nhân tôi sử dụng Eclipse để làm việc với các script kiểm thử tự động cũng như để nghiên cứu các vấn đề với production code. Ruby plug-in giúp chúng tôi làm việc với các script viết bằng Ruby và Watir, và trình chỉnh sửa XML giúp làm việc với các script Canoo WebTest. Chúng tôi có thể chạy unit test và build thông qua IDE. Các developer trong team đã giúp tôi thiết lập và bắt đầu sử dụng Eclipse, và tôi đã tiết kiệm được rất nhiều thời gian. Việc duy trì các bài kiểm thử tự động dễ dàng hơn nhiều và chế độ view “đồng bộ hóa” của IDE giúp tôi nhớ để kiểm thử tất cả các mô-đun mà tôi đã thay đổi. Các công cụ kiểm thử mới xuất hiện tích hợp với IDE hoặc thông qua plug-in của riêng chúng để có thể hoạt động được với các IDE hiện có như Eclipse. Hãy tận dụng những công cụ thúc đẩy chất lượng, tiết kiệm thời gian và có tính năng mạnh mẽ này.

Build Tool

Team của bạn cần một số cách để build phần mềm, tức là tạo ra tệp jar, war hoặc loại tệp khác có thể triển khai. Điều này có thể được thực hiện với các công cụ shell-based như Make, nhưng những công cụ đó có những hạn chế, chẳng hạn như nền tảng mà chúng hoạt động. Các agile team mà tôi biết sử dụng các công cụ như Ant, Nant và Maven để build các dự án của họ. Các công cụ này không chỉ quản lý quá trình build mà còn cung cấp dễ dàng các báo cáo và lập tài liệu về kết quả build, đồng thời chúng tích hợp dễ dàng với các công cụ kiểm thử và build tự động. Chúng cũng tích hợp với các IDE.

Công cụ build tự động hóa

Continuous integration là một thực tiễn cốt lõi cho agile team. Bạn cần một cách để không chỉ build dự án mà còn chạy các bài kiểm thử tự động trên mỗi bản build để đảm bảo không có gì bị hỏng. Một hệ thống build hoàn toàn tự động và có thể tái tạo chạy nhiều lần trong ngày là yếu tố thành công chính cho agile team. Các công cụ build tự động cung cấp các tính năng như thông báo qua email về kết quả build và chúng tích hợp với hệ thống kiểm soát mã nguồn và quản lý bản build.

Các công cụ thường được sử dụng khi viết cuốn sách này bao gồm các công cụ nguồn mở CruiseControl, CruiseControl.net, CruiseControl.rb và Hudson. Các công cụ mã nguồn mở và độc quyền khác có sẵn tại thời điểm xuất bản là AnthillPro, Bamboo, BuildBeat, CI Factory, Team City và Pulse, là vài ví dụ.

Nếu không có quy trình buid tự động, bạn sẽ gặp khó khăn khi triển khai code để kiểm thử cũng như để phát hành. Xây dựng các công cụ quản lý và xây dựng tự động hóa rất dễ thực hiện và cần thiết cho các dự án agile thành công. Bạn nên bắt đầu quá trình xây dựng sớm, ngay cả trước khi bạn bắt đầu viết mã. Hãy thử với các công cụ khác nhau nếu bạn thấy cần nhiều tính năng hơn quy trình hiện tại của bạn.

Unit Test Tool

Các công cụ unit test dành riêng cho ngôn ngữ mà bạn đang dùng để viết code. Các công cụ “xUnit” thường được sử dụng bởi agile team và có một “flavor”cho nhiều ngôn ngữ khác nhau, bao gồm JUnit cho Java, NUnit cho .NET, Test :: Unit cho Perl, Ruby và PyUnit cho Python.

Phát triển theo hướng hành vi (behavior-driven development) là một biến thể khác của TDD, chỉ ra các hành vi mong đợi để dẫn dắt kiểm thử bằng các công cụ như RSpec và Easyb.

Mã cho GUI cũng có thể và nên được phát triển bằng phương pháp TDD. Một số công cụ để làm unit test giao diện khách hàng là TestNG, Abbot và SWTBot.

Các công cụ như EasyMock và Ruby / Mock giúp triển khai các object giả và lưu vết kiểm thử, một phần không thể thiếu của các bài unit test được thiết kế tốt.

Các công cụ mà developer sử dụng để viết các bài kiểm thử kỹ thuật cũng có thể được sử dụng cho các bài kiểm thử nghiệp vụ. Các công cụ đó có phù hợp với mục đích kiểm thử nghiệp vụ trong dự án của bạn hay không phụ thuộc vào nhu cầu của team và khách hàng.

Chúng ta đã giải thích mục đích của các kiểm thử kỹ thuật hỗ trợ Developmet Team và chúng ta nói về những công cụ team cần để cho phép chạy kiểm thử kỹ thuật một cách hiệu quả.

■ Các bài kiểm thử kỹ thuật hỗ trợ lập trình cho phép team tạo ra code chất lượng cao nhất có thể; và là nền tảng cho tất cả các loại kiểm thử khác.

■ Các lợi ích của các bài kiểm thử của Quadrant 1 bao gồm cả việc cho phép team chạy nhanh hơn và làm được nhiều việc hơn, nhưng tốc độ và số lượng không bao giờ được là mục tiêu cuối cùng của team.

■ Developer viết các bài kiểm thử kỹ thuật để hỗ trợ team và cung cấp giá trị lớn cho chuyên viên kiểm thử bằng cách nâng cao chất lượng nội bộ và tính có thể kiểm thử của hệ thống.

■ Các hệ thống legacy thường gây ra những trở ngại lớn nhất đối với việc thực hành TDD, nhưng những vấn đề này có thể được khắc phục dần theo từng bước.