Đánh giá SRS là gì?

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 nhóm dữ liệu về 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 nơi hướng dẫn chi tiết được sắp xếp. Đôi khi, đối với một ứng dụng đã có, chúng tôi 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 chúng tôi thông qua tài liệu này. Chúng tôi có thể có những thông tin cần thiết để làm điều này một mình.

Đánh giá SRS là gì, nhưng đi qua các tài liệu đặc điểm kỹ thuật yêu cầu chức năng và cố gắng để hiểu những gì các ứng dụng mục tiêu là có được như thế.

Định dạng chính thức và mẫu được chia sẻ nhiều trên mạng, nhưng không nhất thiết có nghĩa là tất cả các SRS sẽ được ghi lại một cách chính xác như vậy. Hình thức luôn là thứ yếu so với nội dung. Một số đội sẽ chỉ chọn viết một danh sách có dấu gạch đầu dòng, một số đội sẽ bao gồm các trường hợp sử dụng, một số đội sẽ bao gồm các ảnh chụp màn hình mẫu (như tài liệu chúng tôi có) và một số chỉ mô tả chi tiết trong đoạn văn.

Các bước chuẩn bị trước cho yêu cầu kiểm tra phần mềm:

Bước 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 tham khảo, SRS.

Bước 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ì, nhưng chỉ có một gợi ý về dòng 'những gì cần kiểm tra' đối với một chức năng nào đó.

Bước 3: Đồng thời cũng thiết lập các hướng dẫn về cách thức phân phối này được trình bày - ý tôi là mẫu.

Bước 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 nó với nhau hay không. Rất khuyên mọi người đọc mọi thứ vì điều đó sẽ ngăn chặn sự tập trung 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 của một dự án khổng lồ, với các tài liệu SRS chạy gần 1000 trang, cách tiếp cận chia nhỏ tài liệu khôn ngoan và phân công cho từng thành viên trong nhóm là thực tế nhất.

Bước 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.

Bước 6: Là sản phẩm phụ, một danh sách các truy vấn có một số chức năng rất khó hiểu hoặc nếu cần thêm nhiều thông tin vào các yêu cầu chức năng hoặc nếu sai sót được tạo ra trong SRS chúng được xác định.

Chúng ta nên bắt đầu từ đâu?

• Phiên bản chính xác của tài liệu SRS
• Hướng dẫn rõ ràng về việc ai sẽ làm việc và họ đã có bao nhiêu thời gian.
• Mẫu để tạo các kịch bản kiểm tra
• 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?

Đội trưởng 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ộ nỗ lực này.

Nhóm dẫn khách thường hỏi - Loại đầu vào nào? Sẽ không có gì tốt hơn nếu bạn chỉ định một mô-đun nhất định cho những người quan tâm đến nó hơn là một thành viên trong nhóm không? Nó sẽ không được tốt đẹp để quyết định vào ngày mục tiêu dựa trên ý kiến ​​của đội chứ không phải đẩy một quyết định về họ? 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 sự thuận tiện và thoải mái của nhóm cụ thể.

Do đó cần lưu ý rằng, đội dẫn nhiều hơn bất cứ điều gì là thành viên trong nhóm. Đưa đội của bạn tham gia vào các quyết định hàng ngày là điều cốt yếu cho sự vận hành trôi chảy của dự án.

Tại sao một mẫu cho các kịch bản thử nghiệm - không phải là đủ nếu chúng ta chỉ tạo một danh sách?

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 "một người". Họ 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 một mô đun của phần mềm yêu cầu đặc điểm kỹ thuật mỗi. Thành viên nhóm A đã đưa ra một danh sách trên một tờ 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 từ doc. Làm thế nào để củng cố tất cả các công việc được thực hiện cho dự án vào cuối ngày?

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 và điều gì không phải là nếu chúng ta không tạo ra các quy tắc để bắt đầu?

Đó là những gì mẫu là - Một tập hợp các hướng dẫn và một định dạng đồng ý cho sự thống nhất và sự đồng thuận cho toàn bộ đội.

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

Mẫu kịch bản không cần phải phức tạp hoặc cố định.

Tất cả những gì họ cần là một cơ chế hiệu quả để tạo ra một hiện vật thử nghiệm hữu ích. Một cái gì đó đơn giản như chúng ta thấy bên dưới:

Tiêu đề của mẫu này chứa khoảng trống cần thiết để nắm bắt thông tin cơ bản về dự án, tài liệu hiện tại và tài liệu tham khảo.

Bảng dưới đây sẽ cho phép chúng tôi tạo ra các kịch bản kiểm tra. Các cột bao gồm:

Cột số 1: ID tình huống thử nghiệm Mọi thực thể trong quá trình thử nghiệm của chúng tôi phải được nhận dạng duy nhất. Vì vậy, mọi kịch bản thử nghiệm đều phải được chỉ định một ID. Các quy tắc phải tuân theo trong khi ấn định ID này phải được xác định. Trong bài này, chúng ta sẽ tuân theo quy ước đặt tên là: TS (tiền tố viết tắt của Test Scenario), tiếp theo là '', tên module MI (mô-đun Thông tin của dự án Orange HRM) tiếp theo là '' và Sau đó là phần phụ (ví dụ: MIM cho mô-đun thông tin của tôi, P để chụp ảnh ...) theo sau là số sê-ri. Một ví dụ sẽ là: "TS_MI_MIM_01".

Cột số 2: Yêu cầu Nó giúp ích khi tạo ra một kịch bản thử nghiệm, chúng ta có thể ánh xạ nó trở lại phần của tài liệu SRS nơi chúng tôi chọn nó. Nếu các yêu cầu có ID chúng ta có thể sử dụng nó. Nếu không phải là số phần hoặc thậm chí số trang của tài liệu SRS từ nơi mà chúng tôi xác định một yêu cầu kiểm chứng được sẽ làm.

Cột số 3: Mô tả kịch bản thử nghiệm Một lót xác định 'cái gì để kiểm tra'. Chúng tôi cũng sẽ đề cập đến nó như một mục tiêu kiểm tra.

Cột số 4: Tầm quan trọng Đây là một ý tưởng về chức năng nhất định quan trọng đối với AUT. Các giá trị như cao, trung bình và thấp có thể được gán cho trường này. Bạn cũng có thể chọn một hệ thống điểm, như 1-5, 5 là quan trọng nhất, 1 là ít quan trọng. Bất kể giá trị của lĩnh vực này có thể thực hiện, nó phải được quyết định trước.

Cột # 5: Số vụ kiểm tra Ước tính sơ bộ về bao nhiêu trường hợp thử nghiệm riêng lẻ mà chúng tôi có thể sẽ chỉ viết một kịch bản thử nghiệm. Ví dụ: Để kiểm tra đăng nhập-chúng tôi bao gồm các tình huống sau: Tên người dùng và mật khẩu chính xác. Tên người dùng chính xác và mật khẩu sai. Đúng mật khẩu và tên người dùng sai. Vì vậy, xác nhận tính năng đăng nhập sẽ dẫn đến 3 trường hợp thử nghiệm.

Lưu ý: Bạn có thể mở rộng mẫu này hoặc loại bỏ các trường như bạn thấy phù hợp.

Ví dụ: bạn có thể thêm "Được đánh giá bởi" trong tiêu đề hoặc xóa ngày tạo ra. Ngoài ra trong bảng, bạn có thể bao gồm trường "Đã tạo bởi" để chỉ định người kiểm tra chịu trách nhiệm về các kịch bản kiểm tra nhất định hoặc xóa "Không . Các trường hợp kiểm tra ". Sự lựa chọn là của bạn. Đi với những gì làm việc tốt nhất cho toàn bộ đội.

Bây giờ chúng ta hãy xem lại Tài liệu SRS và tạo các kịch bản kiểm tra

Mẹo: hãy kiểm tra bảng nội dung trong mẫu SRS mà chúng tôi đã cung cấp trong hướng dẫn thứ nhất để có một ý tưởng tốt về cách mọi tài liệu sẽ chảy và bao nhiêu công việc nó có thể liên quan.

Phần 1 là mục đích của tài liệu. Không có yêu cầu kiểm chứng ở đó.

Phần 2.1 - Tổng quan Dự án - Đối tượng - không có yêu cầu có thể kiểm chứng được ở đó.

Phần 2.2 - Phần cứng và lưu trữ-Phần này nói về cách trang web Quản lý Nhân sự Cam sẽ được tổ chức. Bây giờ, thông tin này quan trọng đối với người kiểm tra? Câu trả lời là Có và Không, bởi vì khi chúng ta thử nghiệm chúng ta cần có một môi trường tương tự như môi trường thời gian thực. Điều này cho chúng ta một ý tưởng về nó như thế nào cần. Không, vì nó không phải là một yêu cầu có thể kiểm chứng được - một loại điều kiện tiên quyết để thử nghiệm xảy ra.

Phần 3: Có một màn hình đăng nhập ở đây và các chi tiết của loại tài khoản chúng ta cần phải nhập vào trang web. Đây là yêu cầu khả thi. Vì vậy, nó cần phải là một phần của các kịch bản Kiểm tra của chúng tôi.

Phần 4: Yêu cầu thẩm mỹ / HTML và hướng dẫn - Phần này giải thích tốt nhất một số yêu cầu có thể không có ý nghĩa gì đối với nhóm kiểm tra tại thời điểm đánh giá SRS, nhưng nhóm nên ghi chú chúng như các yêu cầu có thể kiểm chứng được. Làm thế nào để kiểm tra chúng và nếu chúng ta cần thiết lập cụ thể / đội nào đó giúp đỡ để xác nhận nó là những chi tiết chúng ta có thể không biết tại thời điểm này. Nhưng làm cho họ một phần trong phạm vi thử nghiệm của chúng tôi là bước đầu tiên để đảm bảo rằng chúng tôi không bỏ lỡ họ.

Kịch bản thử mẫu: (nhấn vào hình để phóng to)

Một số quan sát quan trọng về đánh giá SRS:

#1. Không có thông tin để được phát hiện. #2. Thực hiện phân tích khả thi về việc liệu một yêu cầu nhất định có đúng hay không và cũng có thể kiểm tra được hay không. #3. Trừ phi có hiệu suất / an ninh riêng hoặc bất kỳ hình thức kiểm tra nào khác tồn tại - công việc của chúng tôi là đảm bảo rằng tất cả các yêu cầu phi chức năng phải được xem xét. #4. Không phải tất cả thông tin đều được nhắm mục tiêu đến người kiểm tra, vì vậy điều quan trọng là phải hiểu những gì cần lưu ý và điều gì không. #5. Tầm quan trọng và không. 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 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 tĩnh xác đị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 - trong trường hợp của bất kỳ
• Ý tưởng ban đầu về cách thức môi trường thử nghiệm được cho là 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 tôi 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à cuối cùng thực hiện.

Những điểm cần lưu ý:

#1. Các kịch bản thử nghiệm không phải là các sản phẩm phân phối bên ngoài (không được chia sẻ với các nhà phân tích doanh nghiệp hoặc đội ngũ phát triển) nhưng rất quan trọng đối với tiêu thụ nội bộ. Đây là bước đi đầu tiên của chúng tôi hướng đến mục tiêu bảo hiểm 100%. Các kịch bản kiểm tra một lần hoàn thành được đánh giá ngang hàng và một khi đã hoàn tất, tất cả đều được củng cố. Để biết thêm chi tiết về cách các tài liệu về QA được xem xét, xem bài viết: Làm thế nào để thực hiện đánh giá tài liệu thử nghiệm trong 6 bước đơn giản.

#2. Chúng tôi có thể sử dụng một công cụ quản lý kiểm tra 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à một hoạt động thủ công. Theo tôi, nó là thuận tiện hơn bằng tay. Vì đó là bước 1 nên chúng ta không cần phải đưa ra những khẩu súng lớn. Đơn giản excel là cách tốt nhất để đi về nó.