Mục lục
Viết code chỉ là một giai đoạn của quá trình phát triển phần mềm. Một trong những khó khăn thách thức nhất đối với developer là kiểm tra source code của mình để xác nhận nó đã đáp ứng đúng và đủ theo các tiêu chí và tiêu chuẩn yêu cầu.
Đây là lúc các phương pháp kiểm thử như Test Driven Development (TDD) – Phát triển theo hướng kiểm thử và Behavioral Driven Development (BDD) – Phát triển theo hướng hành vi có thể trợ giúp. Ngoài ra, Acceptance Test Driven Development (ATDD) – Phát triển dựa trên kiểm thử chấp nhận là một phương pháp kiểm thử mở rộng của TDD, có thể được sử dụng để đảm bảo rằng source code đáp ứng mong đợi của người dùng cuối.
TDD là phương pháp viết các trường hợp kiểm thử (Testcase) trước khi viết code. Trong khi BDD tập trung vào việc xác định hành vi của hệ thống thông qua kiểm thử. ATDD lại tập trung vào việc hệ thống đáp ứng được các tiêu chí chấp nhận của người dùng cuối.
TDD vs BDD vs ATDD, tất cả các chiến lược này đều được sử dụng phổ biến và có thể hỗ trợ developer vượt qua những thách thức trong việc dự báo yêu cầu của người dùng và phát triển các bài kiểm thử đơn giản.
A. Test Driven Development (TDD) – Phát triển theo hướng kiểm thử là gì?
Phát triển dựa trên kiểm thử (TDD) là một phương pháp chúng ta sẽ viết Testcase trước khi developer bắt đầu viết code. Các Testcase sẽ được chia nhỏ ở mức đơn vị (unit) theo đặc tả yêu cầu phần mềm.
TDD tập trung vào việc triển khai unit test. Mục tiêu của việc viết code ở đây là để đáp ứng được Testcase. Sau đó, code sẽ được tái cấu trúc và tối ưu để đảm bảo chất lượng của code và loại bỏ các thiếu sót về kỹ thuật. Chu trình trong TDD để kiểm tra và tái cấu trúc code được viết tắt là Red-Green-Ref (Red, Green and Refactor)
TDD cải thiện sự trao đổi làm việc giữa các thành viên trong dự án (từ QA, developer, khách hàng,…). Một khái niệm quan trọng của TDD là “làm cho thứ gì đó hoạt động và sẽ hoàn thiện sau”. Sau mỗi lần thực hiện kiểm thử theo testcase xong, code sẽ được tái cấu trúc. Quy trình này sẽ lại đến khi từng unit hoạt động đúng như đặc tả yêu cầu.
1. Lợi ích của TDD
-
- Đảm bảo kiểm tra chính xác và linh hoạt dựa trên code
- Thúc đẩy sự phát triển tối ưu hóa code
- Đơn giản hóa việc kiểm thử cho các chức năng mới
- Đơn giản hóa việc tái cấu trúc code
- Viết tài liệu hợp lý hơn
2. Ưu nhược điểm
- Ưu điểm
- Chỉ viết code cần thiết
- Dễ dàng bảo trì và tái cấu trúc
- Cho phép viết tài liệu chi tiết
- Cho phép thêm và kiểm thử các chức năng mới
- Độ chính xác kiểm thử cao
- Phạm vi kiểm thử cao
- Tiết kiệm thời gian vì ít phải sửa lỗi hơn
- Nhược điểm
- Developer cần nhiều thời gian hơn để hiểu giao diện và viết mã kiểm tra (test codes)
- Kiểm thử phải được thực hiện khi có các yêu cầu được thay đổi
- Đòi hỏi sự tham gia của toàn bộ các thành viên
-
B. Behavioral Driven Development (BDD) – Phát triển theo hướng hành vi là gì?
Phát triển theo hướng hành vi (BDD) là một kỹ thuật phát triển tập trung vào cách hệ thống cần hoạt động theo quan điểm từ phía người dùng. Nói một cách đơn giản, việc kiểm thử sẽ dựa trên hành vi được mong đợi của hệ thống.
Ngoài ra, BDD được định nghĩa là một phương pháp kiểm thử nhằm thúc đẩy sự hợp tác giữa tất cả các nhóm làm việc trong quá trình phát triển dự án. Nó xác định và xác nhận hành vi của hệ thống bằng ngôn ngữ mà tất cả các bên liên quan đều dễ hiểu. Định nghĩa này được sử dụng làm nền tảng cho quy trình lấy TDD làm trung tâm.
Một trong những khác biệt quan trọng giữa TDD và BDD là BDD dựa trên hành vi được mong đợi của hệ thống trong khi TDD dựa trên việc triển khai các tính năng của kiểm thử thành phần. Thay vì kiểm thử việc viết code, mục đích của BDD là xác thực các hành vi và kịch bản sử dụng.
Kỹ thuật kiểm thử dựa trên BDD được mong đợi sẽ cung cấp phạm vi kiểm thử đầy đủ, và sẽ sử dụng một ngôn ngữ chung để mình họa cho hành vi hệ thống một cách toàn diện nhất, được thống nhất trong tất cả các nhóm làm việc. Vì testcase thường được viết bằng tiếng Anh đơn giản nên phương pháp này sẽ loại bỏ khoảng cách giữa các nhóm biết kỹ thuật và không biết kỹ thuật.
1. Lợi ích của BDD
-
- Tạo điều kiện cho sự hợp tác giữa các bên liên quan đến hệ thống
- Cung cấp khả năng hiển thị cao
- Đáp ứng được yêu cầu của người dùng
- Tài liệu đầy đủ
- Tiết kiệm chi phí
2. Ưu nhược điểm
- Ưu điểm
- Thời gian tìm hiểu ngắn
- Tiếp cận nhiều đối tượng
- Cải thiện giao tiếp giữa PO, tester và developer
- Không cần giải quyết các lỗi sau sửa đổi và sau triển khai. Chất lượng code được cải thiện dẫn đến giảm chi phí bảo trì và giảm thiểu rủi ro dự án
- Việc sử dụng ngôn ngữ phổ biến đảm bảo tất cả các nhóm đều có cái nhìn đầy đủ về tiến độ của dự án
- Nhược điểm
- Không hỗ trợ cho dự án theo mô hình waterfall
- Cần có kinh nghiệm làm việc TDD
- Hiệu quả không cao khi sử dụng cho nhóm nhỏ
- Phải thực hiện ở giai đoạn đầu của dự án
C. Acceptance Test Driven Development (ATDD) – Phát triển dựa trên kiểm thử chấp nhận là gì?
Phát triển dựa trên thử nghiệm chấp nhận (ATDD) là một phương pháp phát triển phần mềm tập trung vào tự động hóa kiểm thử. Nó được mở rộng theo phương pháp TDD để tạo điều kiện cải thiện sự hợp tác giữa tester, developers và bên nghiệp vụ. Cách tiếp cận thử nghiệm đầu tiên này thường liên quan đến các phương pháp Agile.
Nó làm cho các trường hợp kiểm thử chấp nhận (acceptance test cases) trở thành nền tảng của quá trình phát triển để tập trung vào các yêu cầu của người dùng cuối. Mục đích là cung cấp hành vi/chức năng đã được thống nhất của hệ thống. Trong quá trình triển khai, các bài test được viết theo quan điểm của người dùng và testcase được phát triển trước khi quá trình mã hóa bắt đầu.
Có một số điểm tương đồng giữa phương pháp ATDD và BDD. Tuy nhiên, BDD chủ yếu tập trung vào hành vi của hệ thống trong khi ATDD tập trung vào yêu cầu của người dùng.
1. Lợi ích của ATDD
- Ưu tiên nhu cầu của khách hàng
- Dễ dàng quản lý
- Xác định và giải quyết vấn đề nhanh chóng
- Sự hợp tác được cải thiện
2. Ưu nhược điểm
- Ưu điểm
- Sự hợp tác được cải thiện giữa các thành viên trong nhóm và mọi người có thể hiểu biết kỹ càng các yêu cầu của hệ thống
- Hỗ trợ chuyển tài liệu về code được kỳ vọng của kỹ sư phần mềm sang định dạng có thể thực thi được
- Phân tích và thảo luận về các tình huống thực tế
- Xác định tiêu chí chấp nhận cho các kịch bản kiểm thử
- Kiểm thử chấp nhận hướng dẫn toàn bộ quá trình phát triển phần mềm
- Tất cả các yêu cầu đều được phân tích chính xác, không để xảy ra sự mơ hồ
- Nhược điểm
- Cần có chuyên môn đặc biệt trong việc đưa tất cả các thành viên trong nhóm vào hội đồng quản trị và thuyết phục họ thực hiện phương pháp này
- Khó để học
Có nên áp dụng cách thức này vào việc kiểm thử cho các trang web nền tảng e-commerce không?
Dưới đây là bảng so sánh ngắn cho 3 cách thức trên
| TDD | BDD | ATDD | |
| Mục đích | Tập trung vào sự triển khai của 1 tính năng | Tập trung vào các hành vi của hệ thống | Tập trung vào việc nắm bắt chính xác các yêu cầu |
| Người tham gia | Developer chịu trách nhiệm chính để viết Unit test | Developer, Tester và khách hàng tham gia vào quy trình | Developer, Tester và khách hàng tham gia vào quy trình |
| Ngôn ngữ sử dụng | Viết bằng ngôn ngữ lập trình như Python, Java,… | Viết bằng tiếng Anh đơn giản, Gherkin | Viết bằng tiếng Anh đơn giản, Gherkin |
| Đặc điểm | Những bài test mang tính kỹ thuật, nhưng sẽ khó hiểu cho những người không có kỹ thuật | Những người không có kỹ thuật dễ dàng hiểu được | Những người không có kỹ thuật dễ dàng hiểu được |
| Tài liệu output | Tập trung vào viết Unit test | Tập trung vào việc hiểu được các yêu cầu | Tập trung vào việc viết write Acceptance Test |
| Công cụ hỗ trợ | JDave, Cucumber, JBehave, Spec Flow, BeanSpec, Gherkin Concordian, FitNesse, Junit, TestNG, NUnit frameworks, Selenium tool (hoặc bất kỳ công cụ nào có mã nguồn mở) | Gherkin, Dave, Cucumber, RSpec, Behat, Lettuce, JBehave, Specflow, BeanSpec, Concordian, MSpec, Cucumber with Selenium/Serenity | TestNG, FitNesse, EasyB, Spectacular, Concordian, Thucydides, Robot Framework, FIT |
| Dự án nên dùng | Những dự án không cần sự tham gia của người dùng cuối (API, server,…) | Những dự án liên quan đến TMĐT hoặc các loại ứng dụng mà người dùng sẽ tham gia xử lý luồng | Những dự án có mục tiêu về trải nghiệm khách hàng, có tính cạnh tranh cao như ứng dụng và các trang web TMĐT |
| Lỗi | Có thể dễ dàng truy vết và giảm thiểu tần số tái xuất hiện | Khó truy vết hơn nếu so sánh với TDD | Developer sẽ khó để truy vết hơn TDD và BDD |
Liên hệ ngay với chúng tôi để được tư vấn về các Dịch vụ Kiểm thử hoặc khám phá các Dịch vụ phát triển của CO-WELL Asia để bắt đầu phát triển doanh nghiệp của bạn.
