Software requirements

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 ráng nào để viết kiểm tra scenarios từ bỏ tài liệu đặc tả yêu cầu.

Bạn đang xem: Software requirements

Trước hết chúng ta hãy cùng tò mò về khái niệm:

Test scenario là gì?

Test scenarion là một trong những kịch bạn dạng trong đó tất cả chứa các test case liên quan đến kịch bạn dạng đó.

Tài liệu quánh tả yêu cầu là gì? (SRS document).

Tài liệu đặc tả yêu ước là đều yêu cầu thỏa thuận về phần nhiều gì đề nghị phải tiến hành của đội trở nên tân tiến phần mềm. Tài liệu đặc tả yêu cầu nên bao gồm tất cả những định nghĩa về yêu mong của người sử dụng và sệt tả yêu mong của hệ thống. Tài liệu quánh tả yêu thương cầu chưa phải là tài liệu kiến tạo hệ thống. Nó chỉ tùy chỉnh những gì khối hệ thống phải có tác dụng chứ không hẳn việc bộc lộ rõ nó sẽ thao tác làm việc như rứa nào?

Nào, hiện giờ chúng ta hãy cùng hợp tác vào bài toán phân tích chi tiết về bí quyết hướng một tài liệu đặc tả xảy ra, chúng ta cần xác định công việc cần yêu cầu làm trong tiến độ này là gì, trước khi bắt đầu chúng ta đề xuất phải triển khai bước nào đầu tiên, những thách thức là gì khi chúng ta đối mặt...trong một vụ việc cụ thể.

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

Pha tiếp theo sau trong vòng đời phát triển của phần mềm là “Design” – đó là nơi yêu cầu tính năng được dịch đến kỹ thuật nỗ lực thể. Đội phạt triển, thiết kế, môi trường thiên nhiên hay là tài liệu đều gia nhập vào trộn này. Tác dụng của đoạn này thường là một trong những tài liệu kỹ thuật thi công (viết tắt là: TDD). Đầu vào là tài liệu biểu hiện yêu mong của hệ thống cho tất cả quá trình tạo mới TDD với đội đảm bảo an toàn chất lượng để bước đầu làm vấn đề trên các khía cạnh đảm bảo an toàn chất lượng của dự án – kia là việc xem xét những tài liệu quánh tả với xác định đối tượng người dùng kiểm tra.

Review tài liệu sệt tả là gì?

Tài liệu đặc tả là 1 trong những tài liệu được tạo do đội trở nên tân tiến cùng cùng với sự hợp tác và ký kết của team phân tích nhiệm vụ và team môi trường/dữ liệu. Thông thường, tư liệu này sau thời điểm được xong xuôi sẽ chia sẻ với đội bảo đảm chất lượng thông qua 1 cuộc họp vị trí mà định hướng cụ thể đã được sắp đến xếp. Đôi khi, so với một áp dụng đã tồn tại, bạn có thể không cần đến một cuộc họp thỏa thuận và chỉ cần phải có người lí giải cho họ thông qua tư liệu này. Từ đó bạn cũng có thể có hầu như thông tin cần thiết để làm vấn đề này bởi thiết yếu mình.

Review tài liệu đặc tả là không có gì nhưng lại hãy làm nó thông qua những tài liệu đặc tả tác dụng và cố gắng hiểu mục đích của ứng dụng đang mong muốn là gì?

Các định dạng xác định và một ví dụ đang được chia sẻ với vớ cả các bạn trong nội dung bài viết trước đó. Nó không tốt nhất thiết gồm nghĩa rằng tất cả tài liệu diễn đạt đặc tả yêu cầu sẽ được khắc ghi một cách thiết yếu xác. Hiệ tượng luôn luôn là thứ yếu đối với nội dung. Một số đội sẽ chỉ chọn lựa cách viết một list liệt kê, một số trong những đội khác sẽ bao gồm các use case, một số đội khác thì lại bao gồm các mẫu hình ảnh (như những tài liệu đang có) và một số trong những đội chỉ tế bào tả chi tiết trong đoạn văn.

Từng cách để review tài liệu quánh tả yêu mong của phần mềm.

Step #1: Tài liệu qua không ít lần sửa đổi, cho nên hãy chắc hẳn rằng rằng họ sẽ tất cả phiên bạn dạng chuẩn của tư liệu tham khảo, tài liệu quánh tả yêu cầu.

Step #2: tạo hướng dẫn về gần như gì sẽ được mong hóng ở cuối của thừa trình reviews từ mỗi thành viên trong nhóm. Nói cách khác, đưa ra quyết định về trưng bày được mong muốn đợi từ đoạn này – thông thường, áp ra output của đoạn này là khẳng định các kịch bạn dạng kiểm thử. Kịch bạn dạng kiểm thử sẽ không còn là gì dẫu vậy một bé trỏ cái “Cái gì được test” mang đến một công dụng nhất định.

Step #3: dường như những hướng dẫn về phong thái chuyển giao này là để trình bày - ý của tớ nghĩa là, các bản mẫu.

Step #4: quyết định về việc mỗi thành viên của group là thao tác làm việc trên tổng thể tài liệu hoặc phân chia nhau. Điều này khuyến khích toàn bộ mọi fan nên đọc toàn bộ mọi thứ vị nó sẽ ngăn chặn sự tập chung kỹ năng và kiến thức với các thành viên vào đội. Dẫu vậy trong trường vừa lòng của một dự án công trình khổng lồ, với tài liệu quánh tả yêu ước chạy đến 1000 trang, phương pháp tiếp cận là chia bé dại tài liệu ra thành từng module thông minh cùng phân chia cho những thành viên trong team là điều thực tế nhất.

Step #5: reviews tài liệu sệt tả yêu cầu cũng giúp ích trong câu hỏi hiểu biết tốt hơn nếu như có ngẫu nhiên điều khiếu nại tiên quyết thay thể cần thiết nào cho việc kiểm tra phần mềm.

Step #6:Là một thành phầm phụ, một danh sách các truy vấn nhưng mà một số tác dụng khó nhằm hiểu hoặc nếu có khá nhiều thông tin quan trọng cần buộc phải được chuyển vào chức năng yêu cầu hoặc nếu bao gồm lỗi tạo ra trong quy trình làm tài liệu sệt tả yêu ước đã được định nghĩa.

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

•Phiên bản tài liệu mô tả điểm lưu ý yêu cầu thiết yếu xác.

•Hướng dẫn rõ ràng về những người dân sẽ thao tác và bao nhiêu thời hạn mà họ có thể tham gia.

•Một bản mẫu để chế tạo kịch phiên bản kiểm thử.

•Thông tin khác như: rất nhiều người tương tác trong trường hợp một câu hỏi hoặc bạn để report trong trường hợp có xích míc trong tài liệu.

Ai sẽ cung ứng những tin tức này?

Test leader có nhiệm vụ hướng dẫn chung để cung cấp tất cả các yếu tố được liệt kê ở vị trí trên. Mặc dù nhiên, đầu vào của những thành viên vào team luôn luôn là yếu hèn tố đặc biệt cho sự thành công của toàn thể sự cố gắng này.

Team lead hay hỏi – rất nhiều kiểu nguyên liệu đầu vào là gì? Nó ko thể giỏi hơn nhằm gán một module nào đó với một ai suy xét nó hơn là 1 trong thành viên vào team hay không? Nó đang không giỏi để ra quyết định đưa ra ngày sau cùng dựa trên ý kiến của group nghiên cứu. Ngoài ra, đối với sự thành công xuất sắc của một dự án, những templates là quan tiền trọng. Như 1 quy lý lẽ trung, templates có xác suất cao hơn tác dụng khi chúng được thiết kế theo phong cách riêng để dễ dãi cho các nhóm rõ ràng và thoải mái.

Do đó, cần để ý rằng, team leads là bất kỳ điều gì là member trong đội. Đưa nhóm của bản thân gắn cùng với phần nhiều quyết định từ thời điểm ngày đến ngày là rất đặc trưng cho các hoạt động trơn tru của dự án.

Tại sao một template cho các kịch phiên bản kiểm demo - 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. Mặc dù nhiên, những dự án phần mềm không đề nghị là “một người”. Chúng ta tham gia thao tác làm việc theo nhóm. Hãy tưởng tượng trong một đội bốn fan nếu mọi người trong số họ quyết định để đánh giá một module của mỗi quánh tả yêu ước của phần mềm. Thành viên nhóm 3 được sử dụng một phần mềm notepad. đội team 4 được sử dụng phần mềm word. Có tác dụng thể nào để bạn có thể củng cố toàn bộ các công việc được triển khai cho dự án vào cuối ngày? ko kể ra, làm cụ nào chúng ta có thể quyết định loại nào là tiêu chuẩn chỉnh và làm nạm nào chúng ta cũng có thể khẳng định đông đảo gì là đúng và hồ hết gì là không nên nếu chúng ta không tạo thành những qui định để bắt đầu?

Đó là mọi mẫu gì – Một tập hợp những hợp các hướng dẫn và một mẫu mã thống tuyệt nhất về tính đồng hóa cho toàn đội.

Làm cụ nào để tạo nên một template cho các kịch phiên bản kiểm thử unique phần mềm?

Templates không tinh vi và nên linh hoạt.

Tất cả rất cần được làm là 1 cơ chế hiệu quả để tạo thành một quá trình kiểm thử hữu ích. Một cái gì đó dễ dàng và đơn giản giống tựa như các gì chúng tôi trình bày dưới đây:

Các tiêu đề của rất nhiều template này có chứa những không gian cần thiết để nắm bắt thông tin cơ phiên bản về dự án, tài liệu lúc này và tư liệu tham khảo.

Bảng tiếp sau đây sẽ cho chúng ta tạo ra các kịch bản thử nghiệm. Các cột bao gồm:

Column #1: kiểm tra scenario ID

Mỗi thực thể trong quy trình test phải được định danh (tức là phải bao gồm yếu tố để phân minh với các thực thể khác cơ mà không trùng nhau). Vì chưng vậy, mỗi kịch bản kiểm thử bắt buộc được định danh bởi ID. Các quy tắc nhằm tuân theo trong khi gán ID này cần được định nghĩa. Vì công dụng của bài viết này chúng ta sẽ tiến hành theo những quy ước đặt tên như sau:

Tiền tố viết tắt mang lại kịch bạn dạng kiểm demo là: TSTiếp theo vì dấu “_”Tên module: MITiếp theo bởi dấu “_”Và tiếp nối là các phần phụ (Ví dụ: MIM mang lại Module My info, p. Cho hình ảnh).Tiếp theo vì chưng dấu “_”Theo sau cuối là số serial.

Một ví dụ đã là: “TS_MI_MIM_01”.

Column #2: Requirement

Nó giúp chúng ta trong bài toán tạo một kịch phiên bản kiểm thử, bạn cũng có thể làm cho nó phù hợp trở lại phần của taid liệu SRS chỗ mà họ đã gạn lọc để base bên trên đó. Nếu như yêu cầu gồm ID bọn họ sẽ áp dụng chúng. Nếu không phần số thậm chí là số trang của tài liệu SRS từ địa điểm mà họ xác đinh được yêu cầu rất có thể được kiểm thử đang làm.

Xem thêm: Điện Thoại Iphone 6S Đài Loan Có Tốt Không Nên Và Nên Mua Điện

Column #3: thử nghiệm scenario description

Một lớp đệm quánh biết “Cái gì dùng để kiểm thử”. Công ty chúng tôi sẽ đề cập cho nó như là một mục tiêu kiểm thử.

Column #4: Importance

Điều này để cung cấp cho một ý tưởng về tầm đặc biệt quan trọng của tác dụng nhất định cho quy trình AUT. Phần đa giá trị như cao, trung bình và thấp rất có thể được gán cho nghành nghề dịch vụ này. Bạn có thể chọn một hệ thống điểm như từ 1 đến 5, trong những số đó 5 là đặc biệt nhất, 1 là ít quan trọng. Cho dù giá trị nghành nghề dịch vụ này rất có thể mất, tuy thế nó cần được ra quyết định trước.

Column #5: No. Of kiểm tra cases

Một cầu tính sơ vào bao gồm bao nhiêu chạy thử case cá nhân chúng ta có thể kết thúc bởi văn bản cho một kịch bản kiểm thử.Ví dụ: Để test tác dụng login – tôi thiết lập bao hàm các tình huống: Tên người tiêu dùng và mật khẩu bao gồm xác. Tên người tiêu dùng đúng cùng mật khẩu sai. Mật khẩu đăng nhập đúng cùng tên người tiêu dùng sai.

=> vì vậy, việc chứng thực các tính năng đăng nhập đang cho công dụng trong 3 chạy thử case.

Note: chúng ta cũng có thể mở rộng lớn template này hoặc xóa một số trường mà các bạn thấy phù hợp.

Ví dụ:

Bạn hoàn toàn có thể thêm “Reviewed by” vào title hoặc loại trừ các ngày tạo…Ngoài ra, vào bảng này có thể bao gồm 1 trường “Created by” để hướng dẫn và chỉ định tên bạn kiểm thử phụ trách cho một kịch bạn dạng kiểm thử khăng khăng hoặc đào thải cột “No. Of thử nghiệm cases”. Sự sàng lọc là của bạn. Đi đến mục tiêu là hầu hết gì cực tốt cho toàn team đảm bảo an toàn chất lượng của phần mềm.

Bây giờ chúng ta cùng reviews về một tài liệu quánh tả yêu cầu ví dụ đó là dự án: “Orange HRM” và vấn đề tạo kịch bạn dạng kiểm thử.

Mẹo: Kiểm tra các bảng ngôn từ trong template tài liệu đặc tả yêu mong mà chúng tôi đã cung ứng trong lí giải trước để có được một ý tưởng xuất sắc về cách để flow tài liệu cùng bao nhiêu các bước nó rất có thể liên quan.

Phần 1 là mục đích của tài liệu. Yêu cầu kiểm test là không tồn tại ở đây.

Phần 2.1 – Cái nhìn toàn diện về dự án công trình – Audience – yêu cầu cần yếu được kiểm thử làm việc đây.

Phần 2.2. Phần cứng và hosting.

Phần này nói về cách các trang Orange HRM sẽ được tổ chức như thế nào.Bây giờ họ hãy mày mò và hỏi đâu là số đông thông tin đặc trưng mà chúng ta cần kiểm tra?

Một câu vấn đáp là Yes hoặc No. Yes, cũng chính vì khi test chúng ta cần có môi trường xung quanh cái cơ mà như môi trường thời gian thực. Điều này cho bọn họ một ý tưởng về việc làm cầm nào nó cần phải giả lập được. Không có lý do gì, chính vì nó không hoàn toàn có thể kiểm thử về yêu mong – một dạng đk tiên quyết cho hoạt động kiểm thử vẫn xảy ra.

Phần 3: tất cả một màn hình hiển thị login tại chỗ này và có chi tiết về các loại thông tin tài khoản mà bọn họ cần phải đăng nhập cho trang này. Đây là 1 yêu cầu hoàn toàn có thể kiểm tra. Vì chưng vậy nó là 1 phần cần thiết đến kịch bạn dạng kiểm demo của bọn chúng ta.

Vui lòng xem các tài liệu kịch bản kiểm demo mà các kịch bạn dạng 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, vui lòng thêm phần sót lại của kịch phiên bản kiểm test một phương pháp tương tự. Tuy nhiên, tôi đang để vào phần 4 của tài liệu.

Phần 4: phần đa yêu mong Aesthetic/ HTML và hướng dẫn – Phần này là để giải thích tại sao một vài yêu cầu rất có thể không có chân thành và ý nghĩa với đội thử nghiệm vào giai đoạn review SRS, tuy nhiên team nghiên cứu nên thực hiện một lưu ý mà họ yêu mong để rất có thể kiểm chứng toàn bộ là như nhau. Có tác dụng thể nào để test và nếu bọn họ cần tập hợp ví dụ lên/ sự hỗ trợ của một vài team để xác nhận nó là nạm thể chúng ta cũng có thể không biết tại thời khắc này. Nhưng lại chúng một phần là phạm vi kiểm demo của chúng ta và là bước thứ nhất để bảo vệ rằng bọn chúng không thiếu.

Một số quan lại sát quan trọng đặc biệt liên quan đến đến nhận xét SRS.

Không có tin tức sai nào được phát hiện.

Thực hiện việc phân tích tính khả thi về việc có một yêu ước nào sẽ là đúng hay là không và nó rất có thể được bình chọn hay không.

Trừ khi bao gồm một năng suất riêng/ bảo mật hay bất kỳ hình thức khác sẽ tồn trên trong team test – đó là công việc của cửa hàng chúng tôi để bảo đảm an toàn rằng toàn bộ các yêu cầu phi chức năng cần phải được xem như xét.

Không phải tất cả các thông tin đều là kim chỉ nam của những người dân kiểm thử, vị vậy điều quan trọng là đề xuất hiểu hầu hết gì cần xem xét và hồ hết gì không.

Tầm đặc biệt quan trọng và “No. Of demo case” cho một kịch phiên bản kiểm thử không phải phải đúng chuẩn và rất có thể lấp đầy cùng với một giá trị gần đúng hoặc hoàn toàn có thể để trống.

Tóm lại, tác dụng review SRS như sau:

•Danh sách những kịch bạn dạng kiểm thử.

•Kết quả đánh giá – lỗi tài liệu/ yêu cầu tìm thấy /xác minh các tài liệu SRS.

•Một list các câu hỏi cho vấn đề hiểu rất tốt – trong bất kỳ trường hòa hợp nào.

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

•Xác định phạm vi kiểm thử và một ý tưởng thô trên việc có bao nhiêu test case là đầy đủ để chúng ta có thể kết thúc – như vậy bạn có thể xác định được bao gồm bao nhiêu lần họ cần mang đến tài liệu với việc tiến hành cuối cùng.

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

Chúng ta rất có thể sử dụng một chế độ kiểm tra thống trị như HP ALM hoặc qTest để tạo nên kịch bản kiểm thử. Tuy nhiên, việc tạo ra các kịch phiên bản kiểm thử trong thời gian thực là một vận động bằng tay. Theo chủ kiến của tôi, phương pháp thủ công là tiện lợi hơn. Do nó là bước thứ nhất nên bọn họ không nên phải đi kiếm các truy hỏi vấn to nào cả. Sheet excel là cách dễ dàng và có ích nhất mà họ nên làm.

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