Tạo tài liệu Test Strategy

1. Test Strategy là gì?

Test Strategy (chiến lược/mục tiêu test) là 1 kế hoạch để xác định các cách tiếp cận kiểm thử, và nó trả lời cho câu hỏi như bạn muốn thực hiện gì và làm thế nào bạn sẽ thực hiện nó. Đây là tài liệu quan trọng nhất cho bất kỳ team QA nào về kiểm thử phần mềm và viết tài liệu này một cách hiệu quả là một kỹ năng mà mọi người thử nghiệm phát triển với kinh nghiệm. Các hoạt động lập kế hoạch kiểm tra hướng dẫn nhóm xác định phạm vi kiểm tra và phạm vi thử nghiệm. Nó cũng giúp các quản lý để có được hình ảnh rõ ràng của dự án tại bất kỳ trường hợp nào. Khả năng thiếu bất kỳ hoạt động kiểm tra nào là rất thấp khi có một chiến lược kiểm tra phù hợp tại chỗ. Toàn bộ team phải được tiếp cận với chiến lược kiểm thử để team sẽ nhất quán về cách tiếp cận và trách nhiệm.

2. Test Plan Vs Test Strategy

Có một sự nhầm lẫn lớn về Test Plan Vs Test Strategy. Các tổ chức khác nhau sẽ có quy trình và tiêu chuẩn độc đáo của họ để quản lý các tài liệu này. Ví dụ, một số tổ chức bao gồm các sự kiện chiến lược kiểm tra trong kế hoạch kiểm tra bản thân trong khi một số tổ chức bao gồm chiến lược như một phần nhỏ trong kế hoạch kiểm thử.

3. Chuẩn bị 1 chiến lược test như thế nào?

Mỗi tổ chức đều có ưu tiên riêng và một bộ quy tắc thiết kế phần mềm, vì vậy đừng sao chép bất kỳ một tổ chức nào một cách mù quáng. Luôn đảm bảo rằng tài liệu của họ tương thích và tăng giá trị cho sự phát triển phần mềm của bạn trước khi làm theo mẫu.

Bước #1: Xác định phạm vi

Nó định nghĩa các tham số như:

• Ai sẽ xem lại tài liệu?
• Ai sẽ phê duyệt tài liệu này?
• Các hoạt động kiểm tra được thực hiện với thời hạn?

Bước #2: Phương pháp thử

Nó định nghĩa:

• Quá trình thử nghiệm
• Mức độ kiểm tra
• Vai trò và trách nhiệm của từng thành viên
• Các loại kiểm tra (tải, bảo mật, thử nghiệm Performace ...)
• Cách tiếp cận thử nghiệm và công cụ tự động hóa nếu có
• Thêm các lỗi mới, kiểm tra lại, kiểm tra lỗi, kiểm tra hồi quy và kiểm tra đăng xuất

Bước #3: Kiểm tra Môi trường

• Xác định số yêu cầu và thiết lập cần thiết cho mỗi môi trường
• Xác định sao lưu dữ liệu thử nghiệm và khôi phục chiến lược

Bước #4: Testing Tools

• Các công cụ quản lý tự động và kiểm tra cần thiết để thực hiện kiểm tra
• Xác định số lượng các công cụ mã nguồn mở cũng như thương mại cần thiết và xác định có bao nhiêu người dùng được hỗ trợ trên đó và lên kế hoạch cho phù hợp

Bước #5: Kiểm soát Phát hành

• Phát hành kế hoạch quản lý với lịch sử phiên bản phù hợp sẽ đảm bảo tiến hành thử nghiệm cho tất cả các sửa đổi trong bản phát hành đó.

Bước #6: Phân tích rủi ro

• Liệt kê tất cả các rủi ro mà bạn có thể ước tính
• Cung cấp một kế hoạch rõ ràng để giảm thiểu rủi ro cũng là một kế hoạch dự phòng

Bước #7: Xem xét và Chấp thuận

• Tất cả các hoạt động này được xem xét và ký kết bởi đội ngũ kinh doanh, quản lý dự án, nhóm phát triển, v.v.
• Tóm tắt những thay đổi về đánh giá nên được bắt nguồn từ đầu tài liệu cùng với ngày, tên và nhận xét đã được phê duyệt

Bước #8: Lập kế hoạch

• Kế hoạch kiểm tra nên lập dự toán về thời gian để hoàn thành giai đoạn thử nghiệm. Có rất nhiều yêu cầu để hoàn thành các giai đoạn thử nghiệm. Thứ nhất, người kiểm tra phải thực hiện tất cả các trường hợp thử nghiệm ít nhất một lần. Hơn nữa, nếu phát hiện lỗi, các nhà phát triển sẽ cần phải khắc phục sự cố. Người kiểm tra sau đó nên kiểm tra lại trường hợp thử nghiệm không thành công cho đến khi nó hoạt động đúng. Cuối cùng nhưng không kém phần quan trọng nhất, người thử cần tiến hành kiểm tra hồi quy vào cuối chu kỳ để đảm bảo rằng các nhà phát triển đã không làm hỏng các phần của phần mềm trong khi sửa một phần khác. Điều này có thể xảy ra trong các trường hợp thử nghiệm đã hoạt động đúng cách trước đó.
• Lịch kiểm tra cũng nên ghi số người kiểm tra có sẵn để thử nghiệm. Nếu có thể, chỉ định các trường hợp thử nghiệm cho mỗi người kiểm tra.
• Thường rất khó để ước tính chính xác lịch trình thử nghiệm vì giai đoạn thử nghiệm liên quan đến nhiều sự không chắc chắn. Các nhà hoạch định cần phải tính đến thời gian cần thiết để có thể giải quyết các vấn đề tiềm ẩn. Một cách để làm cho xấp xỉ này là để xem xét thời gian cần thiết cho các bản phát hành trước của phần mềm. Nếu phần mềm là mới, nhân hai lần so với kế hoạch thử nghiệm ban đầu của hai là một cách hay để bắt đầu.

Bước #9: Kiểm tra hồi quy

• Khi một vấn đề cụ thể được xác định, các chương trình sẽ được gỡ lỗi và sửa chữa sẽ được thực hiện cho chương trình. Để đảm bảo rằng bản sửa lỗi hoạt động, chương trình sẽ được kiểm tra lại cho tiêu chí đó. Kiểm tra hồi quy sẽ đảm bảo rằng một sửa chữa không tạo ra một số vấn đề khác trong chương trình đó hoặc trong bất kỳ giao diện nào khác. Vì vậy, một tập hợp các trường hợp thử nghiệm liên quan có thể phải được lặp lại một lần nữa, để đảm bảo rằng không có gì khác bị ảnh hưởng bởi một sửa chữa cụ thể. Làm thế nào điều này sẽ được thực hiện phải được xây dựng trong phần này. Trong một số công ty, bất cứ khi nào có một bản sửa chữa trong một đơn vị, tất cả các đơn vị kiểm tra đơn vị cho đơn vị đó sẽ được lặp lại, để đạt được chất lượng cao hơn.

Bước #9: Nhóm các kiểm thử

• Từ danh sách các yêu cầu, chúng ta có thể xác định các khu vực có liên quan, có chức năng tương tự. Các khu vực này là các nhóm thử nghiệm. Ví dụ: trong hệ thống đặt chỗ đường sắt, mọi thứ liên quan đến đặt vé là một nhóm chức năng; Bất cứ điều gì liên quan đến việc tạo báo cáo là một nhóm chức năng. Tương tự như vậy, chúng ta phải xác định các nhóm thử nghiệm dựa trên khía cạnh chức năng.

Bước #10: Thiết lập sự ưu tiên

• Trong số các trường hợp thử nghiệm, chúng ta cần phải thiết lập các ưu tiên. Trong khi thử nghiệm các dự án phần mềm, một số trường hợp thử nghiệm nhất định sẽ được coi là những sản phẩm quan trọng nhất và nếu không, sản phẩm không thể được phát hành. Một số trường hợp thử nghiệm khác có thể được điều trị như mỹ phẩm và nếu không, chúng tôi có thể phát hành sản phẩm mà không có sự thỏa hiệp nhiều về tính năng. Mức độ ưu tiên này phải được nêu rõ. Chúng cũng có thể được ánh xạ tới các nhóm thử nghiệm.

Bước #11: Thu thập status và báo cáo

• Khi các trường hợp thử nghiệm được thực hiện, người lãnh đạo kiểm tra và người quản lý dự án phải biết, chính xác là dự án đang đứng về các hoạt động thử nghiệm. Để biết được nơi mà dự án đứng, đầu vào từ các xét nghiệm cá nhân phải đến với người lãnh đạo kiểm tra. Điều này sẽ bao gồm, những trường hợp thử nghiệm được thực hiện, mất bao lâu, bao nhiêu trường hợp thử nghiệm thông qua, bao nhiêu thất bại, và bao nhiêu là không thực thi được. Ngoài ra, tần suất dự án thu thập được tình trạng cũng phải được nêu rõ. Một số dự án sẽ có một thực tiễn thu thập tình trạng trên cơ sở hàng ngày hoặc hàng tuần.

4. Tổng kết

Việc có 1 chiến lược test rõ ràng minh bạch ngay từ đầu sẽ giúp team QA định hướng và xác định được 1 kế hoạch test hiệu quả. Tuy nhiên, trong quá trình phát triển phần mềm 1 số vấn đề có thể phát sinh cho nên chiến lược cần được điều chỉnh cho phù hợp với quá trình phát triển của dự án.