Đánh giá tài liệu đặc tả SRS và tạo ra Test Scenarios

1. Đánh giá Tài liệu đặc tả SRS là như thế nào? SRS là một tài liệu do nhóm phát triển tạo ra cùng với các nhà phân tích kinh doanh và các team môi trường / dữ liệu. Thông thường, tài liệu này khi hoàn thành, sẽ được chia sẻ với nhóm QA qua cuộc họp hướng dẫn. Nhưng đôi khi, đối với một ứng dụng đã có, chúng ta có thể không cần một cuộc họp chính thức và một người hướng dẫn thông qua tài liệu này. Chúng ta vẫn có thể có những thông tin cần thiết để tự tìm hiểu hệ thống.

Vậy đánh giá tài liệu SRS là gì nhỉ? Câu trả lời là thông qua các tài liệu đặc tả chức năng để cố gắng hiểu mục tiêu của các ứng dụng cần gì và như nào. 2. Các bước chuẩn bị trước để đánh giá tài liệu đặc tả phần mềm

#1: Tài liệu trải qua nhiều lần sửa đổi, vì vậy hãy đảm bảo chúng ta có đúng phiên bản của tài liệu đặc tả phần mềm, SRS. #2: Thiết lập hướng dẫn về những gì được mong đợi vào cuối bài đánh giá từ mỗi thành viên trong nhóm. Nói cách khác, hãy quyết định những sản phẩm nào được mong đợi từ bước này - thông thường, đầu ra của bước này là xác định các kịch bản thử nghiệm. Các kịch bản kiểm tra là gì, là sẽ test 'cái gì cho một chức năng nào đó. #3: Đồng thời cũng thiết lập các hướng dẫn về các bản mẫu sample #4: Quyết định xem mỗi thành viên của nhóm có đang làm việc trên toàn bộ tài liệu hay chia nhỏ tài liệu ra. Mọi người nên đọc mọi thứ vì điều đó sẽ ngăn được sự khác biệt về kiến thức với các thành viên trong nhóm nhất định. Nhưng trong trường hợp một dự án quá lớn, với các tài liệu SRS dài cả gần 1000 trang, cách tiếp cận để chia nhỏ các module tài liệu một cách khôn ngoan sáng suốt và phân công cho từng thành viên trong nhóm là thực tế nhất. #5: Xem lại SRS cũng giúp hiểu rõ hơn nếu có bất kỳ điều kiện tiên quyết cụ thể nào được yêu cầu để thử nghiệm phần mềm

Chúng ta cần phải bắt đầu từ đâu để review tài liệu đặc tả phần mềm SRS?

• Phiên bản chính xác của tài liệu SRS
• Làm rõ các hướng dẫn về ai sẽ làm việc và mất bao nhiêu thời gian?
• Mẫu để tạo các kịch bản thử nghiệm (test scenarios)
• Các thông tin khác về người liên lạc trong trường hợp có câu hỏi hoặc người báo cáo trong trường hợp có sự không nhất quán về tài liệu

Ai sẽ cung cấp thông tin này?

Teamlead thường có trách nhiệm cung cấp tất cả các mục được liệt kê trong phần trên. Tuy nhiên, đầu vào của thành viên nhóm luôn quan trọng cho sự thành công của toàn bộ những nỗ lực này.

Các team leads thường hỏi - Loại đầu vào nào? không phải là tốt hơn để chỉ định một mô-đun nhất định cho một người quan tâm đến nó hơn là một thành viên ít quan tâm tới module kia trong nhóm không? Sẽ không phải là tốt hơn để quyết định vào ngày mục tiêu dựa trên ý kiến của cả đội chứ không phải tự đưa ra quyết định hay sao? Ngoài ra, đối với sự thành công của dự án, các mẫu rất quan trọng. Theo nguyên tắc chung, các mẫu có tỷ lệ hiệu quả cao hơn khi chúng được điều chỉnh cho phù hợp với từng team cụ thể để cảm thấy thuận tiện và hợp lý nhất.

Do đó cần lưu ý rằng, team lead là quan trọng hơn bất cứ thành viên nào trong team. Đưa đội của bạn lên trên các quyết định hàng ngày là rất quan trọng cho sự vận hành trôi chảy của dự án. Tại sao lại cần khuôn mẫu cho kịch bản thử nghiệm - Chỉ tạo ra một danh sách là không đủ hay sao?

Chắc chắn rồi. Tuy nhiên, các dự án phần mềm không phải là chương trình của "một người". Chúng liên quan đến làm việc theo nhóm. Hãy tưởng tượng trong một nhóm 4 người nếu mỗi người trong số họ quyết định xem xét lại một mô đun của mỗi yêu cầu về phần mềm. Thành viên nhóm A đã đưa ra một danh sách trên một file giấy. Thành viên nhóm 2 đã sử dụng một bảng tính excel. Thành viên nhóm 3 đã sử dụng một notepad. Thành viên nhóm 4 đã sử dụng file doc. Làm thế nào để chúng ta review tất cả các công việc được thực hiện cho dự án vào cuối ngày? Luôn cần sự thống nhất của tất cả thành viên trong team.

Ngoài ra, làm thế nào chúng ta có thể quyết định cái nào là tiêu chuẩn và làm thế nào chúng ta có thể nói điều gì là đúng hoặc không đúng là nếu chúng ta không tạo ra các quy tắc chuẩn mực ngay từ khi bắt đầu?

Đó đó bản mẫu template là - Một tập hợp các hướng dẫn và là format cho sự thống nhất và sự đồng thuận của toàn team.

Làm thế nào để tạo một mẫu cho các kịch bản kiểm tra chất lượng?

Mẫu không phải là một file quá phức tạp hoặc không linh hoạt.

Tất cả những gì họ cần là một cơ chế hiệu quả để tạo ra một kịch bản thử nghiệm hữu ích. Đơn giản như mẫu template kịch bản thử nghiệm như ảnh dưới đây:

Các cột trong template bao gồm: Cột số 1: ID mô phỏng thử nghiệm Cột số 2: Requirement: Nêu rõ yêu cầu dựa vào mục nào trong tài liệu đặc tả SRS Cột số 3: Test scenarios decription: Mô tả vắn tắt nội dung kịch bản thử nghiệm là gì Cột số 4: Importance: Mức độ quan trọng ,ưu tiên của thử nghiệm đó Cột số 5: No of testcase: Link tới tescase nào trong bộ Tcs Dưới đây là hình ảnh về một mẫu kịch bản thử nghiệm của ứng dụng OrangeHRM

3. Một số lưu ý quan trọng về đánh giá SRS

#1. Không để thông tin quan trọng nào trong tài liệu bị bỏ qua. #2. Thực hiện phân tích tính khả thi về việc liệu một yêu cầu nào đó là chính xác hay không và cũng có thể kiểm tra được hay không. #3. Trừ khi có một hoạt động riêng biệt hoặc lí do an ninh hoặc bất kỳ hình thức kiểm tra nào khác tồn tại - chúng ta phải đảm bảo rằng tất cả các yêu cầu phi chức năng phải được để tâm tới. #4. Không phải tất cả thông tin đều được nhắm tới tester vì vậy điều quan trọng nhất là phải hiểu những gì cần lưu ý và điều gì không để tránh bỏ sót những thông tin quan trọng liên quan tới yêu cầu của phần mềm. #5. Tầm quan trọng của các trường hợp thử nghiệm cho một kịch bản kiểm tra không phải là chính xác tuyệt đối và có thể được điền vào với một giá trị gần đúng hoặc có thể để trống.

Tóm lại, kết quả rà soát SRS trong:

• Danh sách kịch bản thử nghiệm
• Đánh giá kết quả - yêu cầu về tài liệu / yêu cầu được tìm thấy bằng cách kiểm thử tĩnh/ xác minh tài liệu SRS
• Một danh sách các Câu hỏi để hiểu rõ hơn (nếu có)
• Ý tưởng ban đầu về cách môi trường thử nghiệm được thực hiện như thế nào
• Xác định phạm vi kiểm tra và ý tưởng sơ bộ về bao nhiêu trường hợp thử nghiệm mà chúng ta có thể sẽ gặp phải - vì vậy cần bao nhiêu thời gian để làm tài liệu và thực hiện nó.

Kết luận: Những điểm cần lưu ý:

#1. Các kịch bản thử nghiệm không phải là sản phẩm được public ra ngoài (không chia sẻ với đội Phân tích Kinh doanh (BA) hoặc Nhóm Phát triển (đội dev) ) nhưng lại rất quan trọng đối với nội bộ đội QA. Đây là bước đi đầu tiên của chúng ta hướng đến mục tiêu bao phủ 100% testcases, tránh sót các case quan trọng. Các kịch bản kiểm tra hoàn thành được xem xét lại và một khi đã hoàn tất, tất cả chúng ta đều hiểu sản phẩm rõ ràng tường minh hơn.

#2. Chúng ta có thể sử dụng một tool quản lý test như HP ALM hoặc qTest để tạo ra các kịch bản kiểm tra. Tuy nhiên, việc tạo kịch bản Kiểm thử trong thời gian thực lại là một hoạt động thủ công. Tài liệu tham khảo: http://www.softwaretestinghelp.com/rview-srs-document-and-create-test-scenarios-software-testing-training-course-day-2/