Làm thế nào để review tài liệu đặc tả yêu cầu (SRS) và tạo kịch bản kiểm thử (Test Scenario).    

• Báo cáo

Bài đăng này đã không được update trong 5 nămBài viết được tìm hiểu thêm từ nguồn :http://www.softwaretestinghelp.com/rview-srs-document-and-create-test-scenarios-software-testing-training-course-day-2/

Hôm nay chúng ta cùng nhau đi tìm hiểu về vấn đề làm thế nào để viết test scenarios từ tài liệu đặc tả yêu cầu.

Trước hết tất cả chúng ta hãy cùng tìm hiểu và khám phá về khái niệm :Test scenario là gì ?Test scenarion là một ngữ cảnh trong đó có chứa những test case tương quan đến ngữ cảnh đó .Tài liệu đặc tả yêu cầu là gì ? ( SRS document ) .Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực thi của đội tăng trưởng phần mềm. Tài liệu đặc tả yêu cầu nên gồm có toàn bộ những định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu của mạng lưới hệ thống. Tài liệu đặc tả yêu cầu không phải là tài liệu phong cách thiết kế mạng lưới hệ thống. Nó chỉ thiết lập những gì mạng lưới hệ thống phải làm chứ không phải việc miêu tả rõ nó sẽ thao tác như thế nào ?Nào, giờ đây tất cả chúng ta hãy cùng bắt tay vào việc nghiên cứu và phân tích cụ thể về cách hướng một tài liệu đặc tả xảy ra, tất cả chúng ta cần xác lập những bước cần phải làm trong quy trình tiến độ này là gì, trước khi khởi đầu tất cả chúng ta cần phải thực thi bước nào tiên phong, những thử thách là gì khi tất cả chúng ta đương đầu … trong một yếu tố đơn cử .

Pha Design trong vòng đời phát triển của phần mềm (SDLC-Software left cycle)

Pha tiếp theo trong vòng đời tăng trưởng của phần mềm là Design đây là nơi yêu cầu công dụng được dịch đến kỹ thuật đơn cử. Đội tăng trưởng, phong cách thiết kế, thiên nhiên và môi trường hay là tài liệu đều tham gia vào pha này. Kết quả của bước này thường là một tài liệu kỹ thuật phong cách thiết kế ( viết tắt là : TDD ). Đầu vào là tài liệu diễn đạt yêu cầu của mạng lưới hệ thống cho cả quy trình tạo mới TDD và đội bảo vệ chất lượng để mở màn thao tác trên những góc nhìn bảo vệ chất lượng của dự án Bất Động Sản đó là việc xem xét những tài liệu đặc tả và xác lập đối tượng người tiêu dùng kiểm tra .

Review tài liệu đặc tả là gì?

Tài liệu đặc tả là một tài liệu được tạo bởi đội tăng trưởng cùng với sự hợp tác của đội nghiên cứu và phân tích nhiệm vụ và đội thiên nhiên và môi trường / tài liệu. Thông thường, tài liệu này sau khi được hoàn thành xong sẽ san sẻ với đội bảo vệ chất lượng trải qua một cuộc họp nơi mà khuynh hướng cụ thể đã được sắp xếp. Đôi khi, so với một ứng dụng đã sống sót, tất cả chúng ta hoàn toàn có thể không cần đến một cuộc họp chính thức và chỉ cần có người hướng dẫn cho tất cả chúng ta trải qua tài liệu này. Từ đó tất cả chúng ta hoàn toàn có thể có những thông tin thiết yếu để làm điều này bởi chính mình .Review tài liệu đặc tả là không có gì nhưng hãy làm nó trải qua những tài liệu đặc tả công dụng và cố gắng nỗ lực hiểu mục tiêu của ứng dụng đang mong ước là gì ?Các định dạng chính thức và một ví dụ đã được san sẻ với toàn bộ những bạn trong bài viết trước đó. Nó không nhất thiết có nghĩa rằng tổng thể tài liệu diễn đạt đặc tả yêu cầu sẽ được ghi lại một cách đúng chuẩn. Hình thức luôn luôn là thứ yếu so với nội dung. Một số đội sẽ chỉ chọn cách viết một list liệt kê, một số ít đội khác sẽ gồm có những use case, 1 số ít đội khác thì lại gồm có những mẫu ảnh ( như những tài liệu đã có ) và 1 số ít đội chỉ miêu tả cụ thể trong đoạn văn .

Từng bước để review tài liệu đặc tả yêu cầu của phần mềm.

Step # 1 : Tài liệu qua nhiều lần sửa đổi, do đó hãy chắc như đinh rằng tất cả chúng ta sẽ có phiên bản chuẩn của tài liệu tìm hiểu thêm, tài liệu đặc tả yêu cầu .Step # 2 : Xây dựng hướng dẫn về những gì sẽ được mong đợi ở cuối của quy trình review từ mỗi thành viên trong nhóm. Nói cách khác, quyết định hành động về phân phối được mong đợi từ bước này thường thì, đầu ra của bước này là xác lập những ngữ cảnh kiểm thử. Kịch bản kiểm thử sẽ không là gì nhưng một con trỏ dòng Cái gì được test cho một công dụng nhất định .Step # 3 : Ngoài ra những hướng dẫn về cách chuyển giao này là để trình diễn – ý của tôi nghĩa là, những bản mẫu .Step # 4 : Quyết định về việc mỗi thành viên của nhóm là thao tác trên hàng loạt tài liệu hoặc chia nhau. Điều này khuyến khích tổng thể mọi người nên đọc tổng thể mọi thứ vì nó sẽ ngăn ngừa sự tập chung kiến thức và kỹ năng với những thành viên trong đội. Nhưng trong trường hợp của một dự án Bất Động Sản khổng lồ, với tài liệu đặc tả yêu cầu chạy đến 1000 trang, cách tiếp cận là chia nhỏ tài liệu ra thành từng module mưu trí và phân loại cho những thành viên trong nhóm là điều thực tiễn nhất .Step # 5 : Review tài liệu đặc tả yêu cầu cũng giúp ích trong việc hiểu biết tốt hơn nếu có bất kể điều kiện kèm theo tiên quyết đơn cử thiết yếu nào cho việc kiểm tra phần mềm .Step # 6 : Là một mẫu sản phẩm phụ, một list những truy vấn mà 1 số ít công dụng khó để hiểu hoặc nếu có nhiều thông tin thiết yếu cần phải được đưa vào tính năng yêu cầu hoặc nếu có lỗi phát sinh trong quy trình làm tài liệu đặc tả yêu cầu đã được định nghĩa .

Chúng ta cần những gì để bắt đầu?

Phiên bản tài liệu miêu tả đặc thù yêu cầu đúng chuẩn .Hướng dẫn rõ ràng về những người sẽ thao tác và bao nhiêu thời hạn mà họ hoàn toàn có thể tham gia .Một bản mẫu để tạo ngữ cảnh kiểm thử .tin tức khác như : Những người liên hệ trong trường hợp một câu hỏi hoặc người để báo cáo giải trình trong trường hợp có xích míc trong tài liệu .

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

Test leader có nghĩa vụ và trách nhiệm hướng dẫn chung để cung ứng toàn bộ những yếu tố được liệt kê ở phần trên. Tuy nhiên, nguồn vào của những thành viên trong team luôn luôn là yếu tố quan trọng cho sự thành công xuất sắc của hàng loạt sự nỗ lực này .Team lead thường hỏi Những kiểu nguyên vật liệu nguồn vào là gì ? Nó không hề tốt hơn để gán một module nào đó với một ai chăm sóc đến nó hơn là một thành viên trong team hay không ? Nó sẽ không tốt để quyết định hành động đưa ra ngày sau cuối dựa trên quan điểm của nhóm điều tra và nghiên cứu. Ngoài ra, so với sự thành công xuất sắc của một dự án Bất Động Sản, những templates là quan trọng. Như một quy luật trung, templates có tỷ suất cao hơn hiệu suất cao khi chúng được phong cách thiết kế riêng để thuận tiện cho những nhóm đơn cử và tự do .Do đó, cần chú ý quan tâm rằng, team leads là bất kể điều gì là thành viên trong đội. Đưa nhóm của mình gắn cùng với những quyết định hành động từ ngày đến ngày là rất quan trọng cho những hoạt động giải trí trơn tru của dự án Bất Động Sản .

Tại sao một template cho các kịch bản kiểm thử – nó là không đủ nếu chúng ta chỉ cần thực hiện một danh sách?

Chắc chắn rồi. Tuy nhiên, những dự án Bất Động Sản phần mềm không phải là một người. Họ tham gia thao tác theo nhóm. Hãy tưởng tượng trong một nhóm bốn người nếu mỗi người trong số họ quyết định hành động để review một module của mỗi đặc tả yêu cầu của phần mềm. Thành viên nhóm 3 được sử dụng một phần mềm notepad. Nhóm team 4 được sử dụng phần mềm word. Làm thể nào để tất cả chúng ta hoàn toàn có thể củng cố toàn bộ những việc làm được triển khai cho dự án Bất Động Sản vào cuối ngày ? Ngoài ra, làm thế nào tất cả chúng ta hoàn toàn có thể quyết định hành động cái nào là tiêu chuẩn và làm thế nào tất cả chúng ta hoàn toàn có thể khẳng định chắc chắn những gì là đúng và những gì là không đúng nếu tất cả chúng ta không tạo ra những nguyên tắc để khởi đầu ?Đó là những mẫu gì Một tập hợp những hợp những hướng dẫn và một mẫu thống nhất về tính như nhau cho toàn đội .

Làm thế nào để tạo một template cho các kịch bản kiểm thử chất lượng phần mềm?

Templates không phức tạp và phải linh hoạt.

Tất cả cần phải làm là một chính sách hiệu suất cao để tạo ra một quy trình kiểm thử hữu dụng. Một cái gì đó đơn thuần giống như những gì chúng tôi trình diễn dưới đây :Các tiêu đề của những template này có chứa những khoảng trống thiết yếu để chớp lấy thông tin cơ bản về dự án Bất Động Sản, tài liệu hiện tại và tài liệu tìm hiểu thêm .Bảng dưới đây sẽ cho tất cả chúng ta tạo ra những ngữ cảnh thử nghiệm. Các cột gồm có :Column # 1 : Test scenario IDMỗi thực thể trong quy trình test phải được định danh ( tức là phải có yếu tố để phân biệt với những thực thể khác mà không trùng nhau ). Vì vậy, mỗi ngữ cảnh kiểm thử phải được định danh bằng ID. Các quy tắc để tuân theo trong khi gán ID này phải được định nghĩa. Vì quyền lợi của bài viết này tất cả chúng ta sẽ triển khai theo những quy ước đặt tên như sau :

• Tiền tố viết tắt cho kịch bản kiểm thử là: TS
• Tiếp theo bởi dấu _
• Tên module: MI
• Tiếp theo bởi dấu _
• Và sau đó là các phần phụ (Ví dụ: MIM cho Module My info, P cho hình ảnh).
• Tiếp theo bởi dấu _
• Theo sau cùng là số serial.

Một ví dụ sẽ là : TS_MI_MIM_01 .Column # 2 : RequirementNó giúp tất cả chúng ta trong việc tạo một ngữ cảnh kiểm thử, tất cả chúng ta hoàn toàn có thể làm cho nó tương thích trở lại phần của taid liệu SRS nơi mà tất cả chúng ta đã lựa chọn để base trên đó. Nếu yêu cầu có ID tất cả chúng ta sẽ sử dụng chúng. Nếu không phần số thậm chí còn số trang của tài liệu SRS từ nơi mà tất cả chúng ta xác đinh được yêu cầu hoàn toàn có thể được kiểm thử sẽ làm .Column # 3 : Test scenario descriptionMột lớp đệm đặc biết Cái gì dùng để kiểm thử. Chúng tôi sẽ đề cập đến nó như thể một tiềm năng kiểm thử .Column # 4 : ImportanceĐiều này để phân phối cho một ý tưởng sáng tạo về tầm quan trọng của tính năng nhất định cho tiến trình AUT. Những giá trị như cao, trung bình và thấp hoàn toàn có thể được gán cho nghành này. Bạn cũng hoàn toàn có thể chọn một mạng lưới hệ thống điểm như từ 1 đến 5, trong đó 5 là quan trọng nhất, 1 là ít quan trọng. Dù giá trị nghành này hoàn toàn có thể mất, nhưng nó phải được quyết định hành động trước .Column # 5 : No. of Test casesMột ước tính sơ vào có bao nhiêu test case cá nhân chúng ta hoàn toàn có thể kết thúc bằng văn bản cho một ngữ cảnh kiểm thử. Ví dụ : Để test tính năng login tôi thiết lập gồm có những trường hợp : Tên người dùng và mật khẩu đúng mực. Tên người dùng đúng và mật khẩu sai. Mật khẩu đúng và tên người dùng sai .=> Vì vậy, việc xác nhận những tính năng đăng nhập sẽ cho hiệu quả trong 3 test case .Note : Bạn hoàn toàn có thể lan rộng ra template này hoặc xóa một số ít trường mà bạn thấy tương thích .Ví dụ :Bạn hoàn toàn có thể thêm Reviewed by vào tiêu đề hoặc vô hiệu những ngày tạoNgoài ra, trong bảng này hoàn toàn có thể gồm có một trường Created by để chỉ định tên người kiểm thử chịu nghĩa vụ và trách nhiệm cho một ngữ cảnh kiểm thử nhất định hoặc vô hiệu cột No. of Test cases. Sự lựa chọn là của bạn. Đi đến tiềm năng là những gì tốt nhất cho toàn team bảo vệ chất lượng của phần mềm .Bây giờ tất cả chúng ta cùng review về một tài liệu đặc tả yêu cầu đơn cử đó là dự án Bất Động Sản : Orange HRM và việc tạo ngữ cảnh kiểm thử .Mẹo : Kiểm tra những bảng nội dung trong template tài liệu đặc tả yêu cầu mà chúng tôi đã phân phối trong hướng dẫn trước để có được một ý tưởng sáng tạo tốt về cách để flow tài liệu và bao nhiêu việc làm nó hoàn toàn có thể tương quan .Phần 1 là mục tiêu của tài liệu. Yêu cầu kiểm thử là không có ở đây .Phần 2.1 Cái nhìn chung về dự án Bất Động Sản Audience yêu cầu không hề được kiểm thử ở đây .Phần 2.2. Phần cứng và hosting .Phần này nói về cách những trang Orange HRM sẽ được tổ chức triển khai như thế nào. Bây giờ tất cả chúng ta hãy khám phá và hỏi đâu là những thông tin quan trọng mà tất cả chúng ta cần kiểm tra ?Một câu vấn đáp là Yes hoặc No. Yes, do tại khi test tất cả chúng ta cần có thiên nhiên và môi trường cái mà như môi trường tự nhiên thời hạn thực. Điều này cho tất cả chúng ta một sáng tạo độc đáo về việc làm thế nào nó cần phải giả lập được. Không có nguyên do gì, chính bới nó không hoàn toàn có thể kiểm thử về yêu cầu một dạng điều kiện kèm theo tiên quyết cho hoạt động giải trí kiểm thử sẽ xảy ra .Phần 3 : Có một màn hình hiển thị login ở đây và có cụ thể về những loại thông tin tài khoản mà tất cả chúng ta cần phải đăng nhập đến trang này. Đây là một yêu cầu hoàn toàn có thể kiểm tra. Vì vậy nó là một phần thiết yếu cho ngữ cảnh kiểm thử của tất cả chúng ta .Vui lòng xem những tài liệu ngữ cảnh kiểm thử mà những ngữ cảnh kiểm thử cho một vài phần của SRS được thêm vào. Đối với thực hành thực tế, vui vẻ thêm phần còn lại của ngữ cảnh kiểm thử một cách tương tự như. Tuy nhiên, tôi sẽ để vào phần 4 của tài liệu .Phần 4 : Những yêu cầu Aesthetic / HTML và hướng dẫn Phần này là để lý giải tại sao một vài yêu cầu hoàn toàn có thể không có ý nghĩa với nhóm thử nghiệm trong quy trình tiến độ review SRS, nhưng team điều tra và nghiên cứu nên thực thi một chú ý quan tâm mà họ yêu cầu để hoàn toàn có thể kiểm chứng tổng thể là như nhau. Làm thể nào để test và nếu tất cả chúng ta cần tập hợp đơn cử lên / sự giúp sức của một vài team để xác nhận nó là đơn cử tất cả chúng ta hoàn toàn có thể không biết tại thời gian này. Nhưng chúng một phần là khoanh vùng phạm vi kiểm thử của tất cả chúng ta và là bước tiên phong để bảo vệ rằng chúng không thiếu .Một số quan sát quan trọng tương quan đến đến review SRS .

Tóm lại, kết quả review SRS như sau:

Danh sách những ngữ cảnh kiểm thử .Kết quả review lỗi tài liệu / yêu cầu tìm thấy / xác định những tài liệu SRS .Một list những câu hỏi cho việc hiểu tốt nhất trong bất kể trường hợp nào .

Ý tưởng sơ bộ về môi trường test được cho là giống nhau.

Xác định khoanh vùng phạm vi kiểm thử và một ý tưởng sáng tạo thô trên việc có bao nhiêu test case là đủ để tất cả chúng ta hoàn toàn có thể kết thúc như vậy tất cả chúng ta hoàn toàn có thể xác lập được có bao nhiêu lần tất cả chúng ta cần cho tài liệu và việc thực thi ở đầu cuối .

Những điểm chú ý quan trọng:

Phần tiếp theo tôi sẽ trình bày một ví dụ cụ thể và chi tiết để tạo một kịch bản kiểm thử từ tài liệu đặc yêu cầu. Mời các bạn tiếp tục theo dõi ở bài sau nhé!