Kiểm thử Agile là một phương pháp tiến hành kiểm thử tuân theo các quy tắc và nguyên tắc phát triển phần mềm Agile.
Không giống như phương pháp Thác nước (Waterfall), Agile testing có thể bắt đầu khi bắt đầu dự án với sự tích hợp liên tục giữa phát triển và kiểm thử. Phương pháp kiểm thử Agile không tuần tự (theo nghĩa là nó chỉ được thực hiện sau giai đoạn mã hóa) mà là liên tục.
Nguyên tắc kiểm thử Agile
Trong mô hình kiểm thử Agile, phần mềm hoạt động được là thước đo chính cho sự tiến trình.
Các đội nhóm tự tổ chức có thể đạt được kết quả tốt nhất.
Cung cấp phần mềm có giá trị sớm và liên tục là ưu tiên cao nhất của chúng ta.
Người phát triển phần mềm phải hành động phối hợp hàng ngày trong suốt dự án.
Nâng cao tính linh hoạt thông qua cải tiến kỹ thuật liên tục và thiết kế tốt.
Kiểm thử Agile đảm bảo rằng sản phẩm cuối cùng đáp ứng mong đợi của doanh nghiệp bằng cách cung cấp phản hồi liên tục.
Trong quy trình Agile Test, chúng ta cần thực hiện quy trình kiểm thử trong quá trình triển khai, điều này giúp giảm thời gian phát triển.
Quá trình thử nghiệm trong Agile phải hoạt động theo nhịp độ phát triển nhất quán
Cung cấp những phản ánh thường xuyên về cách trở nên hiệu quả hơn.
Những kiến trúc, yêu cầu và thiết kế tốt nhất xuất hiện từ các nhóm tự tổ chức.
Mỗi lần nhóm họp, nhóm sẽ xem xét và điều chỉnh hành vi của mình để trở nên hiệu quả hơn.
Trò chuyện trực tiếp với nhóm phát triển là phương pháp truyền đạt thông tin hiệu quả và hiệu suất nhất trong nhóm.
Vòng đời kiểm thử Agile
Vòng đời Kiểm thử Agile được hoàn thành theo 5 giai đoạn (5 phases) khác nhau:
Phase 1: Đánh giá tác động (Impact Assessment): Trong giai đoạn đầu này, chúng ta sẽ thu thập thông tin đầu vào từ các bên liên quan và người dùng. Giai đoạn này còn được gọi là giai đoạn phản hồi vì nó hỗ trợ tester trong việc thiết lập các mục tiêu cho vòng đời tiếp theo.
Phase 2: Lập kế hoạch thử nghiệm Agile: Đây là giai đoạn thứ hai của vòng đời thử nghiệm Agile, trong đó tất cả các bên liên quan cùng nhau lên kế hoạch cho lịch trình của quá trình thử nghiệm và các sản phẩm phân phối.
Phase 3: Sẵn sàng phát hành: Ở giai đoạn này, chúng tôi xem xét các tính năng đã được phát triển/Triển khai đã sẵn sàng để đi vào hoạt động hay chưa. Trong giai đoạn này, người ta cũng quyết định xem cái nào cần quay lại giai đoạn phát triển trước đó.
Phase 4: Daily Scrums: Giai đoạn này bao gồm các cuộc họp đứng vào buổi sáng hàng ngày để nắm bắt tình hình kiểm thử và đặt mục tiêu cho cả ngày.
Phase 5: Kiểm tra đánh giá tính linh hoạt: Giai đoạn cuối cùng của vòng đời Agile là Cuộc họp đánh giá tính linh hoạt (Agility Review Meeting) . Nó bao gồm các cuộc họp hàng tuần với các bên liên quan để đánh giá định kì và đánh giá tiến độ so với mục tiêu.
Kế hoạch kiểm thử Agile (Agile Test Plan)
Kế hoạch kiểm thử linh hoạt bao gồm các loại thử nghiệm được thực hiện trong lần lặp đó như yêu cầu dữ liệu thử nghiệm, cơ sở hạ tầng, môi trường thử nghiệm và kết quả thử nghiệm. Không giống như mô hình thác nước, trong mô hình Agile, test plan được viết và cập nhật cho mỗi lần phát hành. Các kế hoạch kiểm tra điển hình trong Agile bao gồm:
Phạm vi kiểm thử (testing scope)
Các chức năng mới đang được test
Cấp độ hoặc loại test dựa trên độ phức tạp của tính năng
Kiểm tra tải và hiệu suất
Xem xét cơ sở hạ tầng
Kế hoạch giảm thiểu rủi ro
Nguồn lực
Sản phẩm bàn giao (Deliverables) và các cột mốc quan trọng (Milestones)
Chiến lược kiểm thử Agile (Agile Test Strategies)
Vòng đời kiểm thử linh hoạt trải qua 4 giai đoạn (4 stages):
Lần lặp 0 (Interation 0)
Trong giai đoạn đầu tiên hoặc lần lặp 0, bạn thực hiện các tác vụ thiết lập ban đầu. Nó bao gồm việc xác định người kiểm tra, cài đặt các công cụ kiểm tra, lập kế hoạch nguồn lực (phòng thí nghiệm kiểm tra khả năng sử dụng), v.v. Các bước sau đây được thiết lập để đạt được trong Lần lặp 0
Thiết lập trường hợp kinh doanh (business case) cho dự án
Thiết lập các điều kiện biên và phạm vi dự án
Phác thảo các yêu cầu chính và các trường hợp sử dụng sẽ thúc đẩy sự cân bằng trong thiết kế
Phác thảo một hoặc nhiều kiến trúc ứng cử viên
Xác định rủi ro
Dự toán chi phí và chuẩn bị dự án sơ bộ
Những lần lặp xây dựng
Giai đoạn 2 của phương pháp Agile Testing là Các lần lặp xây dựng, phần lớn quá trình kiểm tra diễn ra trong giai đoạn này. Giai đoạn này được quan sát như một tập hợp các lần lặp lại để xây dựng phần tăng dần của giải pháp. Để làm được điều đó, trong mỗi lần lặp lại, nhóm triển khai kết hợp các phương pháp thực hành từ XP, Scrum, mô hình hóa Agile và dữ liệu Agile v.v.
Trong lần lặp xây dựng, agile team sẽ tuân theo ưu tiên thực tế yêu cầu: Với mỗi lần lặp lại, họ lấy những yêu cầu thiết yếu nhất còn lại từ ngăn xếp hạng mục công việc và triển khai chúng.
Lần lặp xây dựng được phân thành hai loại: kiểm thử xác nhận và kiểm thử điều tra.
Kiểm thử xác nhận (Confirmatory test): tập trung vào việc xác minh rằng hệ thống có đáp ứng mục đích của các bên liên quan như được mô tả cho nhóm cho đến nay và được nhóm thực hiện hay không.
Kiểm thử điều tra (Investigative test): phát hiện vấn đề mà team xác nhận đã bỏ qua hoặc không nhận ra. Trong thử nghiệm điều tra, tester xác định các vấn đề tiềm ẩn dưới dạng các defect story. Thử nghiệm điều tra giải quyết các vấn đề phổ biến như kiểm thử tích hợp, thử nghiệm tải/căng thẳng và thử nghiệm bảo mật.
Một lần nữa, kiểm thử xác nhận có hai khía cạnh là developer testing và agile acceptance testing. Cả hai đều được tự động hóa để cho phép thử nghiệm hồi quy liên tục trong suốt vòng đời. Kiểm thử xác nhận là phương pháp linh hoạt tương đương với kiểm thử đặc tả.
Thử nghiệm chấp nhận linh hoạt là sự kết hợp giữa thử nghiệm chức năng truyền thống và thử nghiệm chấp nhận truyền thống khi nhóm phát triển và các bên liên quan đang thực hiện cùng nhau. Trong khi thử nghiệm dành cho nhà phát triển là sự kết hợp giữa thử nghiệm đơn vị truyền thống và thử nghiệm tích hợp dịch vụ truyền thống. Kiểm tra của nhà phát triển xác minh cả mã ứng dụng và lược đồ cơ sở dữ liệu.
Phát hành trò chơi kết thúc hoặc giai đoạn chuyển tiếp
Mục tiêu của “Phát hành, kết thúc trò chơi” là triển khai thành công hệ thống của bạn vào sản xuất. Các hoạt động bao gồm trong giai đoạn này là đào tạo người dùng cuối, người hỗ trợ và người vận hành. Ngoài ra, nó bao gồm tiếp thị phát hành sản phẩm, sao lưu và khôi phục, hoàn thiện hệ thống và tài liệu người dùng.
Giai đoạn thử nghiệm phương pháp linh hoạt cuối cùng bao gồm thử nghiệm toàn bộ hệ thống và thử nghiệm chấp nhận. Để hoàn thành giai đoạn thử nghiệm cuối cùng mà không gặp bất kỳ trở ngại nào, bạn phải kiểm tra sản phẩm một cách nghiêm ngặt hơn trong quá trình xây dựng. Trong quá trình trò chơi kết thúc, những người thử nghiệm sẽ nghiên cứu các câu chuyện khiếm khuyết của nó.
Sản xuất
Sau giai đoạn phát hành, sản phẩm sẽ chuyển sang giai đoạn sản xuất.
Các góc phần tư thử nghiệm Agile
Các góc phần tư thử nghiệm linh hoạt tách toàn bộ quá trình thành bốn Góc phần tư và giúp hiểu cách thực hiện thử nghiệm linh hoạt.
Góc phần tư linh hoạt I
Chất lượng mã nội bộ là trọng tâm chính trong góc phần tư này và nó bao gồm các trường hợp thử nghiệm được điều khiển bằng công nghệ và được triển khai để hỗ trợ nhóm, nó bao gồm
Kiểm tra đơn vị
Kiểm tra thành phần
Phần tư linh hoạt II
Nó chứa các trường hợp thử nghiệm được định hướng kinh doanh và được triển khai để hỗ trợ nhóm. Góc phần tư này tập trung vào các yêu cầu. Loại thử nghiệm được thực hiện trong giai đoạn này là
Kiểm tra các ví dụ về các tình huống và quy trình công việc có thể xảy ra
Kiểm tra trải nghiệm người dùng như nguyên mẫu
Kiểm tra cặp
Phần tư linh hoạt III
Góc phần tư này cung cấp phản hồi cho góc phần tư một và hai. Các trường hợp thử nghiệm có thể được sử dụng làm cơ sở để thực hiện thử nghiệm tự động hóa. Trong góc phần tư này, nhiều vòng đánh giá lặp đi lặp lại được thực hiện để tạo dựng niềm tin vào sản phẩm. Loại thử nghiệm được thực hiện trong góc phần tư này là
Kiểm tra khả năng sử dụng
Thử nghiệm thăm dò
Ghép nối thử nghiệm với khách hàng
Thử nghiệm hợp tác
Kiểm tra sự chấp nhận của người dùng
Góc phần tư linh hoạt IV
Góc phần tư này tập trung vào các yêu cầu phi chức năng như hiệu suất, bảo mật, tính ổn định, v.v. Với sự trợ giúp của góc phần tư này, ứng dụng được tạo ra để mang lại những phẩm chất phi chức năng và giá trị mong đợi.
Các bài kiểm tra phi chức năng như kiểm tra căng thẳng và hiệu suất
Kiểm tra bảo mật liên quan đến xác thực và hack
Kiểm tra cơ sở hạ tầng
Kiểm tra di chuyển dữ liệu
Kiểm tra khả năng mở rộng
Kiểm tra tải
Những thách thức của QA với việc phát triển phần mềm linh hoạt
Khả năng xảy ra lỗi cao hơn trong Agile, vì tài liệu được ưu tiên ít hơn, cuối cùng gây áp lực nhiều hơn cho nhóm QA
Các tính năng mới được giới thiệu nhanh chóng, giúp giảm thời gian dành cho nhóm thử nghiệm để xác định xem các tính năng mới nhất có phù hợp với yêu cầu hay không và nó có thực sự đáp ứng được nhu cầu kinh doanh hay không
Người kiểm tra thường được yêu cầu đóng vai trò là nhà phát triển bán phần
Chu kỳ thực hiện kiểm thử được nén ở mức độ cao
Rất ít thời gian để chuẩn bị kế hoạch kiểm tra
Để kiểm tra hồi quy, họ sẽ có thời gian tối thiểu
Thay đổi vai trò của họ từ người gác cổng chất lượng thành đối tác về Chất lượng
Những thay đổi và cập nhật yêu cầu vốn có trong một phương pháp linh hoạt, trở thành thách thức lớn nhất đối với QA
Rủi ro tự động hóa trong quy trình Agile
Giao diện người dùng tự động mang lại mức độ tin cậy cao nhưng chúng thực thi chậm, dễ bảo trì và xây dựng tốn kém. Tự động hóa có thể không cải thiện đáng kể năng suất kiểm tra trừ khi người kiểm tra biết cách kiểm tra
Các thử nghiệm không đáng tin cậy là mối quan tâm lớn trong thử nghiệm tự động. Việc khắc phục các thử nghiệm thất bại và giải quyết các vấn đề liên quan đến các thử nghiệm dễ vỡ phải được ưu tiên hàng đầu để tránh kết quả dương tính giả
Nếu thử nghiệm tự động được bắt đầu theo cách thủ công thay vì thông qua CI (Tích hợp liên tục) thì có nguy cơ chúng không chạy thường xuyên và do đó có thể gây ra lỗi thử nghiệm
Kiểm tra tự động không phải là sự thay thế cho kiểm tra thủ công mang tính thăm dò. Để đạt được chất lượng mong đợi của sản phẩm, cần có sự kết hợp giữa các loại và cấp độ thử nghiệm
Nhiều công cụ tự động hóa có sẵn trên thị trường cung cấp các tính năng đơn giản như tự động hóa việc thu thập và phát lại các trường hợp kiểm thử thủ công. Công cụ như vậy khuyến khích thử nghiệm thông qua giao diện người dùng và dẫn đến các thử nghiệm vốn dễ vỡ và khó duy trì. Ngoài ra, việc lưu trữ các trường hợp kiểm thử bên ngoài hệ thống kiểm soát phiên bản sẽ tạo ra sự phức tạp không cần thiết.
Để tiết kiệm thời gian, nhiều khi kế hoạch kiểm thử tự động hóa được lập kế hoạch kém hoặc không có kế hoạch dẫn đến việc kiểm thử thất bại.
Quy trình thiết lập và chia nhỏ thử nghiệm thường bị bỏ qua trong quá trình tự động hóa thử nghiệm, trong khi Thực hiện thử nghiệm thủ công, quy trình thiết lập và chia nhỏ thử nghiệm nghe có vẻ liền mạch
Các số liệu về năng suất chẳng hạn như số lượng trường hợp thử nghiệm được tạo hoặc thực hiện mỗi ngày có thể gây hiểu lầm nghiêm trọng và có thể dẫn đến việc đầu tư lớn vào việc chạy các thử nghiệm vô dụng
Các thành viên của nhóm tự động hóa linh hoạt phải là những nhà tư vấn hiệu quả: dễ gần, hợp tác và tháo vát, nếu không hệ thống này sẽ nhanh chóng thất bại
Tự động hóa có thể đề xuất và cung cấp các giải pháp thử nghiệm yêu cầu bảo trì liên tục quá nhiều so với giá trị được cung cấp
Kiểm thử tự động có thể thiếu chuyên môn để hình thành và đưa ra các giải pháp hiệu quả
Kiểm thử tự động có thể thành công đến mức họ không còn những vấn đề quan trọng cần giải quyết và do đó chuyển sang những vấn đề không quan trọng.
Kết luận
Phương pháp linh hoạt trong kiểm thử phần mềm liên quan đến việc kiểm thử càng sớm càng tốt trong vòng đời phát triển phần mềm . Nó đòi hỏi sự tham gia cao của khách hàng và code ngay khi có sẵn. Mã phải đủ ổn định để đưa nó vào thử nghiệm hệ thống. Kiểm thử hồi quy mở rộng có thể được thực hiện để đảm bảo rằng các lỗi đã được sửa và kiểm tra. Chủ yếu, sự giao tiếp giữa các nhóm tạo nên thành công cho việc kiểm thử mô hình Agile!!!
