Bên cạnh selenium webdriver, log Bug thì mô hình chữ V cũng là một khái niệm cần quan tâm khi bắt đầu với sự nghiệp kiểm thử. Vậy, bạn đã biết đây là mô hình gì và cách thức hoạt động ra sao chưa? Tìm hiểu ngay trong nội dung bài viết dưới đây của chúng tôi.
Tìm hiểu về mô hình chữ V
Trong kiểm thử phần mềm, mô hình chữ V được biết đến với tên gọi là mô hình xác minh (Verification Model) hay mô hình xác thực (Validation Model). Đây là một kiểu mở rộng của mô hình thác nước. Theo đó, việc kiểm thử sẽ được thực hiện trên từng giai đoạn một cách tuần tự để đảm bảo chất lượng của phần mềm khi đến tay khách hàng.
Mô hình chữ V được ra đời nhằm khắc phục nhược điểm của mô hình thác nước chỉ diễn ra khi mã nguồn đã được triển khai xong. Điều đó sẽ rất bất lợi, nhất là khi tham gia các dự án lớn với hệ thống phức tạp. Việc bỏ lỡ một chi tiết nào đó sẽ khiến cho công sức của toàn team có thể bị đổ sông đổ biển.
Theo đánh giá của hàng nghìn dự án được áp dụng mô hình thác nước thì các defects được tìm thấy trong quá trình yêu cầu & thiết kế thường chiếm đến phân nửa. Trong khi đó, đây lại là giai đoạn rất sớm mà mô hình thác nước bỏ qua. Đấy là lý do tại sao mô hình chữ V được ra đời như một giải pháp để giải quyết vấn đề này. Mô hình này đang được sử dụng khá rộng rãi trong từng giai đoạn và song song với chu kỳ phát triển phần mềm.
Nguyên lý hoạt động của V-Model
Vì là một biến thể của mô hình thác nước nên mô hình chữ V cũng có cách thức hoạt động tương tự. Điều đó có nghĩa là các giai đoạn sẽ được hoàn thiện rồi mới sang công đoạn kế tiếp. Các hoạt động sẽ được diễn ra đồng thời, không có pha rời rạc. Thay vào đấy, kiểm thử sẽ được bắt đầu ngay từ giai đoạn lấy yêu cầu để đảm bảo tìm ra tất cả lỗi có thể phát sinh.
Step 1: BRS
BRS là viết tắt của Business requirement Specification hay còn được hiểu là các yêu cầu kỹ thuật của công việc. Ở giai đoạn này, chuyên viên kiểm thử sẽ tìm hiểu tài liệu một cách kỹ lưỡng để biết được mục đích ra đời của phần mềm, các tiêu chuẩn để đánh giá về chất lượng… Hoàn thành bước này, chúng ta sẽ đến với một bước được gọi là Acceptance test.
Step 2: SRS
SRS là viết tắt của System requirement Specification. Dịch ra tiếng việt có nghĩa là phân tích yêu cầu hệ thống. Vì vậy, bản chất của step 2 chính là phân tích tính chất của công việc. Đi kèm với đó sẽ là quá trình System Testing.
Trong giai đoạn này, chúng ta sẽ cần xác minh các yêu cầu và xác nhận đầu ra cần có, các tài liệu cũng như UAT test case. Đặc biệt nhấn mạnh vào chức năng hoạt động của hệ thống.
Step 3: HLD
Đến với bước 3 – High Level Design hay còn được gọi là HLD. Giai đoạn này được thực hiện dựa trên kỹ thuật hệ thống và thiết kế. Mục đích chính là cung cấp các giải pháp giúp xử lý tổng quan về hệ thống sản phẩm cũng như các dịch vụ. Ở bước này, chúng ta sẽ phải thực hiện Integration Test.
Hoạt động xác minh ở đây bao gồm các đánh giá thiết kế còn xác nhận thì thiên về Test plan, test case và các ma trận truy vết. Đầu ra sau khi kết thúc step 3 gồm có System test cases, Feasibility reports, System test plan, các mô đun và tài liệu yêu cầu phần cứng liên quan…
Step 4: LLD
Ở bước tiếp theo, LLD – Low Level Design, phần mềm sẽ được xác định các yếu tố logic, các sơ đồ với mọi phương thức hay các mối liên quan. Trong quá trình đó, sẽ có nhiều mâu thuẫn phát sinh gây ảnh hưởng đến chất lượng sản phẩm. Và tất nhiên, nhiệm vụ của các chuyên viên kiểm thử chính là xác định lỗi để khắc phục kịp thời.
Khi thực hiện thành công bước này, chúng ta sẽ đến với công đoạn test Component Test. Các hoạt động xác minh, xác nhận cũng được thực hiện song song. Trong đó, chuyên viên kiểm thử sẽ đánh giá các thiết kế để xác nhận với các trường hợp kiểm tra đơn vị. Đầu ra đạt được sẽ gồm các đơn vị kiểm tra đơn vị đã được kiểm thử.
Step 5: Coding
Khi đã có đủ các yêu cầu triển khai sản phẩm rồi, vậy thì đây sẽ là lúc bắt đầu phát triển phần mềm. Mỗi thành viên trong nhóm sẽ được phân công với những nhiệm vụ cụ thể. Họ sẽ sử dụng các ngôn ngữ lập trình và các thuật toán để code phần mềm. Cuối step 5, chúng ta sẽ đến với một công đoạn test được gọi là Unit Test.
Ở bước quan trọng này, người ta sẽ xác minh các mã và kiểm tra các trường hợp test. Hoạt động xác nhận sẽ xoay quanh việc tạo các trường hợp kiểm tra chức năng. Sau đấy, xác nhận lại về các trường hợp kiểm tra chức năng. Đầu ra nhận được sẽ gồm danh sách các trường hợp thử nghiệm hay những vấn đề cần kiểm tra lại.
Step 6: Code/Testing
Bước này thực chất là để review lại Low Level Design ở Step 4. Sau khi việc thiết kế phần mềm với các yêu cầu cụ thể được hoàn tất thì các chuyên viên kiểm thử sẽ kiểm tra lại tính tối ưu của các đoạn Code. Lúc này việc Unit Test sẽ được thực hiện lại để đảm bảo chất lượng của phần mềm đáp ứng với các yêu cầu đã được đặt ra.
Đánh giá ưu nhược điểm của mô hình chữ V
Về cơ bản, mô hình chữ V cũng có những ưu và nhược điểm riêng biệt. Do đó, để có thể sử dụng một cách hiệu quả, chúng ta sẽ phải phân tích rõ về 2 khía cạnh này. Cụ thể:
Về ưu điểm:
- V Model có cơ chế hoạt động đơn giản, dễ sử dụng.
- Lên kế hoạch cụ thể cho việc triển khai dự án, test phần mềm.
- Giúp tester dễ dàng phát hiện defect ngay từ những bước đầu tiên, tránh việc “sai cả dây”.
- Tiết kiệm kha khá thời gian khi kiểm tra kỹ lưỡng ở từng giai đoạn phát triển phần mềm. Mang đến nhiều cơ hội thành công hơn cho các dự án đang được triển khai.
Về nhược điểm:
- Mô hình chữ V vẫn khá cứng nhắc khi yêu cầu công đoạn kiểm tra xác nhận ở từng bước.
- Nếu sử dụng với các dự án đơn giản thì sẽ gây tốn kém về thời gian cũng như nhân lực cho các công đoạn xác minh.
- Nếu xuất hiện sự thay đổi về kỹ thuật ở giữa chừng, tester sẽ phải thực hiện lại, chuẩn bị tài liệu mới, gây tốn kém về thời gian, chi phí.
- Không thể sử dụng để vừa phát triển song song với vừa bán sản phẩm.
- Sản phẩm của dự án sẽ không có nguyên mẫu ban đầu. Thay vào đó, sản phẩm chỉ xuất hiện khi tất cả các bước hoàn thành xong.
Khi nào sử dụng mô hình chữ V?
Dựa vào những ưu nhược điểm kể trên, chúng ta có thể biết được khi nào nên dùng mô hình chữ V để mang đến hiệu quả cao nhất. Cụ thể nên dùng V Model cho các trường hợp như sau:
- Dự án có kích thước nhỏ và trung bình khi có yêu cầu rõ ràng, cụ thể, không thay đổi.
- Tem có đội ngũ kỹ thuật tốt với nguồn tài nguyên phong phú, sẵn có. Từ đấy có thể đảm bảo được các yêu cầu.
- Nên sử dụng mô hình chữ V cho các dự án mà khách hàng có sự tự tin cao trong yêu cầu thiết kế. Hiểu một cách đơn giản là không có nhiều thay đổi hay dao động trong quá trình phát triển phần mềm.
Trên đây là những thông tin cơ bản về mô hình chữ V hay còn gọi là mô hình xác minh hay mô hình xác thực. Đây là một kỹ thuật kiểm thử rất phù hợp cho các dự án có yêu cầu cụ thể, ít thay đổi. Vì vậy, có thể là một công cụ đắc lực cho việc phát triển, hoàn thiện phần mềm trước khi đến tay khách hàng.
