Tài liệu luyện thi Agile and Scrum Process

Agile Testing, Unit Test và TDD

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.

Download tài liệu