Test Strategy trong mô hình Agile

Trong mô hình Agile, phần mềm được phát triển qua từng sprint ngắn, mỗi sprint tập trung vào một vài yêu cầu hay còn được gọi là user story do đó một cách hiển nhiên là tài liệu không thực sự có vai trò quan trọng như các mô hình trước kia cả về số lượng và nội dung. Trước đây chúng ta cho rằng không cần phải có một test plan trong mỗi sprint do những hạn chế về thời gian nhưng chúng ta lại cần một high level agile test strategy như là một guideline cho agile team. Mục đích của tài liệu agile test strategy là liệt kê các phương pháp tốt nhất cũng như qui trình mà team có thể follow. Nhớ rằng agile không có nghĩa là làm việc không có qui trình.

Bài viết này ta sẽ xem xét một số khía cạnh khi phát triển tài liệu test strategy trong mô hình Agile

Trong tài liệu Agile Test Strategy document, chúng ta sẽ nhắc lại cho mọi người về khái niệm Quality Assurance

• QA là một tập các activity có hệ thống và đáng tin cậy nhằm mục đích đảm bảo rằng sản phẩm phải thỏa mãn yêu cầu khách hàng
• Trong SCRUM, QA là một công việc của tất cả mọi người trong team chứ không riêng tester. QA là tất cả các hoạt động đảm bảo chất lượng trong quá trình phát triển sản phẩm.

Hình 1: Agile testing Quadrants

WHY: Đảm bảo source code được phát triển đúng đắn

WHO: Developers / Technical Architects

WHAT: tất cả new code + re-factoring of legacy code như là Javascript unit Testing

WHEN: Ngay khi code được viết ra

WHERE: Local Dev + CI (phần được build)

HOW: Automated, Junit, TestNG, PHPUnit

WHY: Đảm bảo rằng comunication giữa các thành phần hoạt động một cách chính xác

WHO: Developers / Technical Architects

WHAT: New web services, components, controllers...

WHEN: Ngay khi API được xây dựng xong

WHERE: Local Dev + CI (phần được build)

HOW: Automated, Soap UI, Rest Client

WHY: Đảm bảo rằng sản phẩm đã đáp ứng đúng nhu cầu của khách hàng

WHO: Developer / SDET / Manual QA

WHAT: Verifying acceptance tests dựa trên the stories, verification các feature

WHEN: Khi đã thực hiện xong Unit test và các function đã được sẵn sàng

WHERE: CI / Test Environment

HOW: Automated (Cucumber)

WHY: Đảm bảo rằng các thành phần trong hệ thống được tích hợp và hoạt động đúng đắn với nhau

WHO: SDET / Manual QA / Business Analyst / Product Owner

WHAT: Scenario Testing, User flows và typical User Journeys, Performance và security testing

WHEN: Khi Acceptance Testing hoàn thành

WHERE: Staging Environment

HOW: Automated (Webdriver) Exploratory Testing

Nguyên nhân phổ biến nhất của sự thất bại trong phát triển phần mềm là do yêu cầu không rõ ràng và cách giải thích khác nhau về yêu cầu của các thành viên trong nhóm có sự khác nhau Một User story phải thỏa mãn: “I” ndependent (of all others)

“N” egotiable (not a specific contract for features)

“V” aluable (or vertical)

“E” stimable (to a good approximation)

“S” mall (so as to fit within an iteration)

“T” estable (in principle, even if there isn’t a test for it yet)

Format để viết user story:

Điều quan trọng là đừng quên phần "Benifit", vì mọi người nên biết rằng họ đang tạo ra value gì bằng cách phát triển user story.

Mỗi user story phải chứa Acceptance Criteria. Đây có thể là yếu tố quan trọng nhất để các thành viên trong nhóm có thể trao đổi với nhau.

Acceptance criteria nên được viết với cùng thời điểm user story được tạo và nên được nhúng vào trong thành phần của user story. Tất cả acceptance criteria đều phải có khả năng test được.

Acceptance criteria phải có một số lượng các Acceptance Test presented được trình bày dưới dạng kịch bản viết bởi ngôn ngữ Gherkin. Format:

Trong mỗi story workshop, mỗi người trong nhóm sẽ học về các chi tiết trong user story để dev và QA biết về phạm vi công việc. Mọi người phải có cùng một "same understand" về user story

Dev cần phải hiểu rõ về các chi tiết kĩ thuật liên quan đến user story và QA cần biết về user story sẽ test cũng như bất kì trở ngại nào có thể gặp phải trong quá trình test.

Trong cuộc họp story workshops, PO, BA, DEV, QA cùng phải tham gia.

Scenario (valid, invalid và các case khác) nên được quan tâm (QA có thể thêm vào quan điểm bằng cách suy nghĩ về use story) và viết xuống feature file

Điều quan trọng cần lưu ý là đó là các Scenario (hơn bất cứ điều gì khác) sẽ tiết lộ các defect khi kiểm thử, do đó dành nhiều effort trong bước này sẽ có kết quả tốt vào các bước cuối.

Vì đa số các defect là do yêu cầu không rõ ràng và mơ hồ, hoạt động này cũng sẽ giúp ngăn ngừa việc thực hiện hành vi không chính xác vì mọi người nên có sự hiểu biết tương tự về câu chuyện.

Tương tự như vậy, trong các cuộc họp lập kế hoạch sprint planning meeting, estimate cho story được đưa ra bao gồm testing effort chứ không chỉ effort coding. QA (cả manual và automation) cũng phải có mặt trong cuộc họp sprint planning meeting để góp phần vào việc estimate cho việc kiểm thử.

Hình 2: Test-automation-pyramid

Khi quá trình phát triển bắt đầu, các code mới hay các code sửa đổi đều cần đi qua unit test được viết bởi chính developer và peer review bởi developer khác hay skilled SDET. Bất kì commit nào cũng nên kích hoạt 1 sự thực hiện chạy các Unit test từ CI server. Nó cung cấp cơ chế phản hồi nhanh chóng tới team phát triển. Unit test đảm bảo rằng hệ thống làm việc ở cấp độ technical và không tồn tại lỗi logic

Developer cũng cần phải có hoạt động kiểm thử của riêng mình. Bạn kiểm thử như không có QA trong nhóm, dù QA có những tư duy và cách kiểm thử khác developer nhưng hãy thực hiện kiểm thử theo khả năng tốt nhất của bạn.

Nếu bạn nghĩ có thể tiết kiểm thời gian bằng cách nhanh chóng chuyển sang các user story tiếp theo nhưng thực tế khi defect được tìm ra, nó sẽ tốn rất nhiều thời gian để sửa chữa thay vì dành ra vài phút để kiểm thử đảm bảo nó hoạt động tốt ngay từ đầu.

Bất kì code hay re-factoring nên được unit test và nó cũng sẽ là một phần trong regression test. Automated Acceptance bao gồm Integration Tests and Service Tests và UI tests nhằm chứng minh phần mềm hoạt động ở cấp functional level và nó đáp ứng các yêu cầu người dùng. Automated Acceptance Tests thường được viết bằng ngôn ngữ Gherkin và được thực hiện bằng công cụ BDD như cucumber hoặc behat.

Chú ý rằng: Không phải tất cả các hoạt động test phải được automation!!!

Mục đích của Regression testing không phải là tìm lỗi mà làm đảm bảo tất cả các chức năng vẫn hoạt động đúng, không bị phá vỡ bởi các thay đổi. Thông thường regression testing có rất ít các hoạt động test manual.

Mục đích của UAT là đảm bảo rằng các tính năng đã phát triển sẽ mang lại ý nghĩa kinh doanh và hữu ích cho khách hàng. PO (Chủ sở hữu sản phẩm) nên chạy User Acceptance test hay Business Acceptance Test để xác nhận sản phẩm được xây dựng chính là cái mà khách hàng mong đợi.

Trên đây là một số hướng dẫn về những gì có thể được đưa vào Tài liệu Chiến lược Kiểm tra Agile. Các hướng dẫn trên khi đưa vào thực hiện cũng cần phải điều chỉnh cho phù hợp với dự án của bạn. Hi vọng các hướng dẫn trên sẽ giúp bạn có thể tạo được tài liệu test strategy trong dự án Agile.

Nguồn tham khảo: http://www.testingexcellence.com/agile-test-strategy-example-template/ http://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html