5 khác biệt về kiểm thử trong mô hình Agile và mô hình truyền thống
Bài đăng này đã không được cập nhật trong 7 năm
Điều gì là khác biệt về kiểm thử trong mô hình Agile và mô hình truyền thống? Đó không chỉ là sự phân biệt giữa các phương pháp phát triển phần mềm linh hoạt và truyền thống, mà còn là khả năng thích ứng của người kiểm thử trong môi trường rất khác nhau. Hãy cùng xem 5 điểm khác biệt chính là gì nhé:
Sự tham gia liên tục
Trong các dự án truyền thống, nhóm kiểm thử hoạt động chủ yếu ở nội bộ team, và có rất ít hoặc không có sự tương tác cần thiết với các deverloper hoặc các đội khác thông suốt quá trình xây dựng phần mềm. Nhưng trong mô hình Agile, nhóm kiểm thử được tích hợp với các đội Scrum thay vì là một đơn vị riêng biệt. Họ được tham gia vào tất cả các giai đoạn để có thể nhìn thấy mọi khía cạnh của dự án, tham gia từ giai đoạn phân tích các yêu cầu và thiết kế của mỗi tính năng. Điều này làm cho công việc của họ trở nên bận rộn với các cuộc thảo luận, hội họp, và các tương tác mà họ cần tham gia để đưa ra ý kiến của họ.
Công cụ cần thiết
Agile là mô hình cần công cụ hỗ trợ hơn các dự án theo mô hình truyền thống làm vì tốc độ phát triển rất nhanh và lặp đi lặp lại liên tục. Mỗi lần lặp lại như vậy sẽ mang theo một số công việc hồi quy do vậy khối lượng công việc cần thực hiện trong 1 sprint tương đối lớn.
Trong mô hình agile rất cần những công cụ cho kỹ thuật kiểm thử động và kiểm thử tĩnh. Do việc hạn chế về thời gian vì vậy muốn đạt chất lượng chúng ta phải thực hiện các bài kiểm tra hộp trắng sử dụng flow về mặt nghiệp vụ, phân tích flow về dữ liệu , review source code và tài liệu. Đó là một nhiệm vụ để ngăn ngừa bug và biến động về chỉ số chất lượng của mỗi sản phẩm qua từng sprint.
Trong khi các dự án truyền thống, các công cụ có thể là một điều xa xỉ vì chúng ta không có đủ khả năng để giải quyết bài toán lớn, khối lượng lớn. Tuy nhiên trong dự án agile thì những đề xuất này là cần thiết để đạt được mục tiêu chất lượng của dự án.
Khi bắt đầu dự án, trong đội sẽ có những tester thực hiện automation test cho toàn bộ dự án . Nhưng khi tới giai đoạn nước rút, chúng ta có thể nhanh chóng nhận ra rằng automation test cũng không thể theo kịp tốc độ cần hoàn thành của tất cả các tính năng. Vì vậy, tất cả mọi người bắt đầu thay bày bằng manual test. Automation test chỉ được sử dụng trong một khuôn khổ , phạm vi nhất định.
Do có sự thay đổi thường xuyên liên tục trong các ứng dụng , chúng ta sẽ làm theo (n-1) phương pháp để tự động hóa các sản phẩm. Tự động hoá tính năng chạy nước rút thứ n trong chạy nước rút tiếp theo, rồi sau đó sử dụng chúng để hồi quy. Nhưng do tình trạng quá tải của khối lượng công việc hồi quy nên trong mô hình agile chúng ta phải thực hiện và sử dụng những công cụ làm sao phải rất hiệu quả.
Kỹ năng đa chiều
Một dự án truyền thống đã thiết lập những kỳ vọng từ các hoạt động thử nghiệm. Mỗi giai đoạn thử nghiệm cho bộ kết quả đầu ra, chẳng hạn như thiết kế thử nghiệm và thông số kỹ thuật trong giai đoạn thiết kế, các vấn đề chức năng và báo cáo lỗi trong giai đoạn thực hiện, kiểm tra hồi quy và kiểm tra lại kết quả trong chiếu lại, và các báo cáo nghiệm thu trong giai đoạn cuối. Mô hình này không để lại nhiều chỗ cho bất cứ điều gì khác bởi vì dự án đã được fix thời hạn để thực hiện deliver.
Nhưng quan điểm trong mô hình Agile là không chỉ bao gồm các khía cạnh chức năng của những gì đã kiểm thử mà bao gồm nhiều khía cạnh rộng lớn hơn của các ứng dụng.
- Không cần phải là một tester pro trong việc kiểm tra sự đúng đắn các thiết kế mà thiết kế có hỗ trợ và thân thiện với nhiều người sử dụng không ?
- Không cần phải là một chuyên gia về những trải nghiệm ứng dụng nhưng lại có khả năng đề xuất những cách tốt hơn để thiết kế các ứng dụng tốt hơn.
- Không cần phải là một nhà văn, nhưng vẫn thể xây dựng được tài liệu cài đặt hướng dẫn ác bước sử dụng một cách chính xác.
Trong mô hình Agile đã cho chúng ta có một cái nhìn rộng hơn về chất lượng trong bối cảnh của dự án của mình và có kỹ năng trong tất cả các lĩnh vực.
Giao tiếp hiệu quả
Agile đòi hỏi thông tin hiệu quả giữa các thành viên trong nhóm vào mọi lúc và test dạo đóng vai trò quan trọng trong việc thiết lập và duy trì điều đó. Ví dụ, như một phần của một nhóm deverloper, Tester có yêu cầu phai đóng vai trò ở nhiều vi trí khác nhau: đó là một nhà phê bình yêu cầu đối với các chủ sở hữu sản phẩm, của một nhà phê bình thiết kế cho các nhà phát triển và kiến trúc sư, các chuyên gia về các chức năng như là một thử nghiệm, và của một cố vấn phát hành cho người quản lý. Kiểm thử có thể cung cấp các ý kiến và ý tưởng của họ ở tất cả các giai đoạn của dự án, điều này có thể không cần thiết trong một dự án truyền thống.
Kiểm thử đóng vai trò là bắt buộc và họ làm việc theo cặp với các nhà phát triển để chia sẻ trường hợp thử nghiệm và ý tưởng của họ. Nghệ thuật giao tiếp bằng lời nói và bằng văn bản là cần thiết trong một dự án Agile.
Phản hồi nhanh chóng
Sự khác biệt quan trọng nhất cho các mô hình Agile là nhận những phản hồi nhanh chóng dưới các case kiểm thử ở mọi điểm. Các khung thời gian ngắn hơn so với mô hình truyền thống. Các thử nghiệm cần phải cung cấp thông tin phản hồi về chất lượng dự án trên cơ sở thường xuyên: họp hàng ngày, cuộc họp thảo luận thiết kế hoặc review.....Có một số áp lực bởi vì các hướng đi của dự án được xác định dựa trên bởi thông tin phản hồi này.
Làm việc trong một dự án Agile mà môi trường đầy thử thách so với các dự án truyền thống. Ở đó rất cần sự linh hoạt và thích ứng, ai cũng sẽ thấy rằng Agile là một nơi tuyệt vời để trải nghiệm.
All rights reserved