Now, we have reached the part that

Now, we have reached the part that is the real-deal, the test cases.

As indicated in the article before this: Test cases are documented by the QA team while the Code phase of the SDLC is going on. In other words, while the Dev team builds the software system, the testing team gets ready with the test cases that would help us test the system once it is ready, i.e. at the end of the code phase.

So, in today’s article, we will work on understanding what test cases are, how to create them and write few sample test cases for our live project.

Let us get to it right away.
Basics of Writing Test Cases:

#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.

For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.

#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.

#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.

#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.

#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.

#6. The MS word template looks something like this:

Test cases MS word template

#7. The Excel template could look like the following:

qa training test cases samples xls

#8. From the above two templates it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.

So, as long as there is a field for each of the type of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.
Fields in Test Cases:

Let us take a moment, to observe the fields that are part of a test case.

Test case Id and Test case description – these are the generic ones.

The other fields can be explained as follows:

a) Precondition – state of the AUT (the state in which the AUT needs to be for us to get started)
b) Input – data entry steps. For these steps it is important to note what kind of input info is required – Test data
c) Validation point/trigger/action – what is causing the validation to happen? (Click of a button or toggle or the link access. Make sure there is at least one validation point to a test case- otherwise it is all going to be data entry with nothing to look for. Also to ensure that we have enough modularity, try not to combine too many validation points into one test case. 1 per test case is optimum.)
d) Output – expected result
e) Post condition – This is additional information that is provided for the benefit of the tester, just to make the test case more insightful and informative. This includes an explanation about what happens or what can be expected of the AUT once all the test case steps are done.

See Also => Sample test case template.
Live Project Sample Test Cases:

Now that we have enough background information to get started on the test case creation process, let us get going and create few test cases for our Live Project.

Based on the process mentioned above we have created some sample test cases for the OrangeHRM account module. These should give you exact test case format and idea on how to approach for writing test cases.

=> Download Sample Test Cases Document for our Live Project here.

------------

Note – there are few images referred in sample test cases xls document. If you are viewing this on older MS Office version, you may face compatibility issues. So we have listed those images below as per their names in the xls files:
– View Pic 1
– View Pic 2
– View Pic 3

There, all done and all good.
Test Cases Writing/Optimization Methods

Now, imagine a situation where a certain page has a few 10’s of fields on it or has a complex business logic that is implemented in there. To make sure that we optimize the test case creation process in situations like that, we testers have certain Test case optimization methods.

Below is a list and please check out the links provided for more information on these methods.

Boundary value analysis
Equivalence partitioning
Error guessing – This is a very simple method and relies on a tester’s intuition. An example is: Say there is a date field on a page. The requirements are going to specify that a valid date is to be accepted by this field. Now, a tester can try “Feb 30” as a date- because as far as the numbers are concerned, it is a valid input, but February is a month that never has 30 days in it- so an invalid input.
State transition diagrams
Decision tables

Using the above techniques and following the general test case creation process, we create a set of test cases that would effective test the application on hand.
A few important points to note:

The test cases we create are not only the point of reference for the QA phase but also to the UAT.
Internally test cases are peer reviewed within the team.
When a certain situation is not addressed by a test case – the rule of thumb is, it is not going to get tested. So, this is a good place to check whether the test suite we created achieves the 100% test coverage goal or not. To do so, a traceability matrix can be created. Check out all there is to know about traceability matrix here.
Tools – Test management tools like QC, qTest help us with the test case creation activity. For an example on how test cases can be dealt with using Quality Center, check out this Quality Center tutorial.
Automation tools can be used to create test cases- in which case, they are referred to as, Test scripts.

Tip: Please perform a spell and grammar check on each and every document we create. We are the quality representatives for IT projects – and it doesn’t reflect positively on us if our deliverables themselves are of inferior quality.

That brings us to the finish of another interesting segment.
Conclusion:

The end of test creation process/test design phase (STLC) and the end of the Code phase (SDLC) will generally mark the end of test preparation phase and the beginning of the Test execution phase.

Next tutorial in this Software Testing Course – In the coming article, we will talk about what test execution is, what it includes and what are the expectations from the QA team during this phase.

=> QA Training Day 5: Test Execution

We hope all of you are working along with this series. For the sake of simplicity, only a few test cases have been created. However, best results can be seen when you work on testing extensively, which means writing more and more test cases. So, please don’t limit your work and do as much as you can.

Please do let us know your questions and comments below. Happy testing!

Kết quả (Việt) 1:

Now, we have reached the part that is the real-deal, the test cases.As indicated in the article before this: Test cases are documented by the QA team while the Code phase of the SDLC is going on. In other words, while the Dev team builds the software system, the testing team gets ready with the test cases that would help us test the system once it is ready, i.e. at the end of the code phase.So, in today’s article, we will work on understanding what test cases are, how to create them and write few sample test cases for our live project.Let us get to it right away.Basics of Writing Test Cases:#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.#6. The MS word template looks something like this:Test cases MS word template#7. The Excel template could look like the following:qa training test cases samples xls#8. From the above two templates it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.So, as long as there is a field for each of the type of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.Fields in Test Cases:Let us take a moment, to observe the fields that are part of a test case.Test case Id and Test case description – these are the generic ones.The other fields can be explained as follows:a) Precondition – state of the AUT (the state in which the AUT needs to be for us to get started)b) Input – data entry steps. For these steps it is important to note what kind of input info is required – Test datac) Validation point/trigger/action – what is causing the validation to happen? (Click of a button or toggle or the link access. Make sure there is at least one validation point to a test case- otherwise it is all going to be data entry with nothing to look for. Also to ensure that we have enough modularity, try not to combine too many validation points into one test case. 1 per test case is optimum.)d) Output – expected resulte) Post condition – This is additional information that is provided for the benefit of the tester, just to make the test case more insightful and informative. This includes an explanation about what happens or what can be expected of the AUT once all the test case steps are done.See Also => Sample test case template.Live Project Sample Test Cases:Now that we have enough background information to get started on the test case creation process, let us get going and create few test cases for our Live Project.Based on the process mentioned above we have created some sample test cases for the OrangeHRM account module. These should give you exact test case format and idea on how to approach for writing test cases.=> Download Sample Test Cases Document for our Live Project here.------------Note – there are few images referred in sample test cases xls document. If you are viewing this on older MS Office version, you may face compatibility issues. So we have listed those images below as per their names in the xls files:– View Pic 1– View Pic 2– View Pic 3There, all done and all good.Test Cases Writing/Optimization MethodsNow, imagine a situation where a certain page has a few 10’s of fields on it or has a complex business logic that is implemented in there. To make sure that we optimize the test case creation process in situations like that, we testers have certain Test case optimization methods. Below is a list and please check out the links provided for more information on these methods. Boundary value analysis Equivalence partitioning Error guessing – This is a very simple method and relies on a tester’s intuition. An example is: Say there is a date field on a page. The requirements are going to specify that a valid date is to be accepted by this field. Now, a tester can try “Feb 30” as a date- because as far as the numbers are concerned, it is a valid input, but February is a month that never has 30 days in it- so an invalid input. State transition diagrams Decision tablesUsing the above techniques and following the general test case creation process, we create a set of test cases that would effective test the application on hand.A few important points to note: The test cases we create are not only the point of reference for the QA phase but also to the UAT. Internally test cases are peer reviewed within the team. Khi một tình huống nhất định không được giải quyết bởi một trường hợp thử nghiệm-tắc là, nó không phải nhận được thử nghiệm. Vì vậy, đây là một nơi tốt để kiểm tra cho dù bộ kiểm tra chúng tôi tạo ra đạt được mục tiêu bảo hiểm 100% thử nghiệm hay không. Để làm như vậy, một ma trận truy tìm nguồn gốc có thể được tạo ra. Kiểm tra tất cả là để biết về truy tìm nguồn gốc ma trận ở đây. Công cụ-công cụ quản lý kiểm tra như QC, qTest giúp chúng tôi với các hoạt động sáng tạo trường hợp thử nghiệm. Ví dụ về cách trường hợp kiểm tra có thể được xử lý bằng cách sử dụng trung tâm chất lượng, kiểm tra này hướng dẫn chất lượng Trung tâm. Công cụ tự động hóa có thể được sử dụng để tạo ra trường hợp thử nghiệm - trong trường hợp đó, chúng được gọi là, kiểm tra kịch bản.Mẹo: Xin vui lòng thực hiện một kiểm tra chính tả và ngữ pháp trên mỗi tài liệu chúng tôi tạo ra. Chúng tôi là đại diện chất lượng cho nó dự án- và nó không phản ánh tích cực vào chúng tôi nếu chúng tôi phân phôi mình là kém chất lượng.Điều đó mang lại cho chúng tôi để kết thúc một đoạn thú vị.Kết luận:Sự kết thúc của thử nghiệm sáng tạo quá trình, thí nghiệm thiết kế giai đoạn (STLC) và kết thúc của mã giai đoạn (SDLC) sẽ thường đánh dấu kiểm tra chuẩn bị giai đoạn kết thúc và bắt đầu giai đoạn thử nghiệm thực hiện.Tiếp theo hướng dẫn trong phần mềm thử nghiệm khóa học này-trong bài viết sắp tới, chúng tôi sẽ nói về những gì thực hiện thử nghiệm là, nó bao gồm những gì và những gì là mong đợi từ nhóm bảo đảm chất lượng trong giai đoạn này.= > Bảo đảm chất lượng đào tạo ngày 5: kiểm tra thực hiệnWe hope all of you are working along with this series. For the sake of simplicity, only a few test cases have been created. However, best results can be seen when you work on testing extensively, which means writing more and more test cases. So, please don’t limit your work and do as much as you can.Please do let us know your questions and comments below. Happy testing!

Kết quả (Việt) 2:

Bây giờ, chúng tôi đã đạt đến một phần đó là thực hợp đồng, các trường hợp thử nghiệm. Như đã trình bày trong bài viết trước đây: các trường hợp thử nghiệm được ghi nhận bởi nhóm QA trong khi giai đoạn mã của các SDLC đang xảy ra. Nói cách khác, trong khi đội Dev xây dựng hệ thống phần mềm, nhóm thử nghiệm bị sẵn sàng với các trường hợp thử nghiệm đó sẽ giúp chúng tôi kiểm tra hệ thống một khi nó đã sẵn sàng, tức là vào cuối giai đoạn mã. Vì vậy, trong bài viết hôm nay, chúng tôi . sẽ làm việc trên sự hiểu biết những gì trường hợp thử nghiệm là, làm thế nào để tạo ra chúng và viết vài trường hợp thử nghiệm mẫu cho dự án sống của chúng tôi Hãy để chúng tôi có được nó ngay lập tức. Khái niệm cơ bản của Test Viết Các trường hợp: # 1. Nếu kịch bản thử nghiệm đã được tất cả về, "Những gì chúng tôi đang đi để thử nghiệm" trên AUT - các trường hợp thử nghiệm là tất cả về "Làm thế nào chúng ta sẽ thử nghiệm một yêu cầu". Ví dụ, nếu các kịch bản thử nghiệm là "Xác nhận các chức năng đăng nhập quản trị "- Điều này sẽ mang lại trong 3 trường hợp thử nghiệm (hoặc điều kiện) - Đăng nhập (thành công), Đăng nhập-không thành công khi tên người dùng nhập sai, Đăng nhập-không thành công khi nhập sai password. Mỗi trường hợp thử nghiệm sẽ lần lượt có các bước để giải quyết như thế nào chúng ta có thể kiểm tra một điều kiện kiểm tra cụ thể là hài lòng hay không. # 2. Các đầu vào để tạo ra một tài liệu test là FRD, các kịch bản thử nghiệm tạo ra trong bước trước đó và bất kỳ tài liệu tham khảo khác nếu có. # 3. Các tài liệu hướng dẫn trường hợp thử nghiệm là một chuyển giao quan trọng của đội ngũ QA và được chia sẻ với BA, PM và các đội khác, khi làm cho họ phản hồi. # 4. Công việc được phân chia giữa các thành viên trong nhóm và từng thành viên sẽ chịu trách nhiệm cho việc tạo ra các trường hợp thử nghiệm cho một module nào đó hay một phần của một module nào đó. # 5. Cũng giống như với các kịch bản thử nghiệm, trước khi chúng ta bắt đầu tài liệu Trường hợp thử nghiệm, một mẫu chung phải được sự đồng ý. Thực tế bất cứ điều gì có thể được sử dụng để tạo ra các trường hợp thử nghiệm. 2 sự lựa chọn thường xuyên nhất được sử dụng là MS Excel và MS Word. # 6. MS từ mẫu trông giống như sau: Kiểm tra các trường hợp MS từ mẫu # 7. Các mẫu Excel có thể trông giống như sau: trường hợp thử nghiệm đào tạo qa mẫu xls 8 #. Từ hai mẫu trên, có thể quan sát thấy rằng các lĩnh vực (hoặc các thành phần) mà làm cho một trường hợp thử nghiệm là như nhau, chỉ khác nhau về cách thức mà chúng được tổ chức. Vì vậy, miễn là có một lĩnh vực cho mỗi loại thông tin được bao gồm trong một thử nghiệm, các dạng của các mẫu không quan trọng. Tuy nhiên, yêu thích cá nhân của tôi xảy ra là các sheet excel, bởi vì nó rất dễ dàng để mở rộng, sụp đổ, sắp xếp, vv Nhưng một lần nữa, chọn bất kỳ định dạng nào phù hợp nhất cho bạn. Fields trong trường hợp thử nghiệm: Chúng ta hãy lấy một chút thời gian, để quan sát . các lĩnh vực là một phần của một trường hợp thử nghiệm. Trường hợp thử nghiệm Id và trường hợp thử nghiệm mô tả - đó là những cái chung chung Các lĩnh vực khác có thể được giải thích như sau: a) Điều kiện tiên quyết - nhà nước của AUT (nhà nước, trong đó AUT cần được cho chúng tôi để bắt đầu) b) Input - bước nhập dữ liệu. Đối với những bước quan trọng là phải lưu ý những loại thông tin đầu vào là cần thiết - Kiểm tra dữ liệu c) Điểm Validation / kích hoạt / hành động - những gì đang gây ra sự xác nhận để xảy ra? (Click vào một nút hoặc chuyển đổi hoặc truy cập liên kết. Hãy chắc chắn rằng có ít nhất một điểm xác nhận để một đựng pin- kiểm tra nếu không nó là tất cả sẽ được nhập dữ liệu với không có gì để tìm. Ngoài ra để đảm bảo rằng chúng tôi có đủ mô đun, cố gắng không để kết hợp quá nhiều điểm xác nhận vào một trường hợp thử nghiệm 1 cho mỗi trường hợp thử nghiệm là tối ưu).. d) Kết quả - kết quả mong đợi e) Điều kiện Post - Đây là thông tin bổ sung được cung cấp cho các lợi ích của các máy đo, chỉ để làm cho trường hợp thử nghiệm sâu sắc hơn và thông tin. Điều này bao gồm một lời giải thích về những gì sẽ xảy ra hoặc những gì có thể được dự kiến của AUT một khi tất cả các bước kiểm tra trường hợp đang thực hiện. Xem thêm => Sample trường hợp thử nghiệm mẫu. Sống Dự án Trường Mẫu thử: Bây giờ chúng ta có đủ thông tin cơ bản để bắt đầu quá trình tạo trường hợp thử nghiệm, để chúng tôi có được đi và tạo ra một vài trường hợp thử nghiệm cho dự án sống của chúng tôi. Dựa trên quá trình nêu trên, chúng tôi đã tạo ra một số trường hợp thử nghiệm mẫu cho các module tài khoản OrangeHRM. Những nên cung cấp cho bạn chính xác định dạng trường hợp thử nghiệm và ý tưởng về cách tiếp cận đối với trường hợp văn bản thử nghiệm. => Tải mẫu trường hợp thử nghiệm tài liệu cho dự án của chúng tôi sống ở đây. ------------ Lưu ý - có vài hình ảnh gọi trong trường hợp thử nghiệm mẫu tài liệu xls. Nếu bạn đang xem trên phiên bản cũ hơn MS Office, bạn có thể phải đối mặt với vấn đề tương thích. Vì vậy, chúng tôi đã liệt kê những hình ảnh dưới đây theo tên của họ trong các tập tin xls: - Xem Pic 1 - Xem Pic 2 - Xem Pic 3. Ở đó, tất cả được thực hiện và tất cả tốt trường hợp thử nghiệm Viết / Phương pháp Tối ưu hóa Bây giờ, hãy tưởng tượng một tình huống mà một số trang có một vài 10 của các trường trên đó hoặc có một logic kinh doanh phức tạp đó được thực hiện trong đó. Để chắc chắn rằng chúng tôi tối ưu hóa các trường hợp thử nghiệm quá trình tạo trong những tình huống như thế, chúng tôi xét nghiệm có phương pháp Kiểm tra trường hợp tối ưu hóa nhất định. Dưới đây là danh sách và xin vui lòng kiểm tra các liên kết được cung cấp để biết thêm thông tin về các phương pháp này. Phân tích giá trị ranh giới tương đương phân vùng Lỗi đoán - Đây là một phương pháp rất đơn giản và dựa vào trực giác của một tester. Một ví dụ là: nói có một lĩnh vực ngày trên một trang. Các yêu cầu sẽ xác định rằng một ngày hợp lệ là được chấp nhận bởi lĩnh vực này. Bây giờ, một thử nghiệm có thể thử "ngày 30 tháng 2" như một date- vì theo như các con số được quan tâm, nó là một đầu vào hợp lệ, nhưng tháng Hai là một tháng mà không bao giờ có 30 ngày trong nó- vì vậy một đầu vào không hợp lệ. Biểu đồ chuyển nhà nước Quyết định bảng Sử dụng các kỹ thuật nói trên và sau quá trình tạo trường hợp kiểm tra tổng quát, chúng ta tạo ra một tập hợp các trường hợp kiểm tra sẽ kiểm tra hiệu quả các ứng dụng trên tay. Một vài điểm quan trọng cần lưu ý: Các trường hợp thử nghiệm, chúng tôi tạo ra không chỉ là điểm tham chiếu . cho giai đoạn QA mà còn để các UAT nội trường hợp thử nghiệm được phản biện chuyên gia trong đội. Khi một tình huống nhất định không được giải quyết bằng một vụ thử nghiệm - các quy tắc của ngón tay cái, nó sẽ không được xét nghiệm. Vì vậy, đây là một nơi tốt để kiểm tra xem các bộ kiểm tra, chúng tôi tạo ra đạt được mục tiêu bảo hiểm thử nghiệm 100% hay không. Để làm như vậy, một ma trận truy xuất nguồn gốc có thể được tạo ra. Kiểm tra tất cả những gì cần biết về truy xuất nguồn gốc ma trận ở đây. Tools - các công cụ quản lý thử nghiệm như QC, qTest giúp chúng tôi với các hoạt động tạo ra trường hợp thử nghiệm. Đối với một ví dụ về cách test có thể được xử lý bằng cách sử dụng Trung tâm Chất lượng, kiểm tra hướng dẫn Trung tâm Chất lượng này. Các công cụ tự động hóa có thể được sử dụng để tạo ra các bài kiểm tra cases- trong trường hợp đó, chúng được gọi là, các kịch bản thử nghiệm. Mẹo: Hãy thực hiện một chính tả và ngữ pháp kiểm tra trên mỗi và mọi tài liệu chúng tôi tạo ra. Chúng tôi là đại diện chất lượng các dự án CNTT - và nó không phản ánh tích cực về chúng tôi nếu chúng tôi phân phôi chính họ là kém chất lượng. Điều đó mang lại cho chúng tôi để kết thúc của một đoạn thú vị. Kết luận: Sự kết thúc của quá trình tạo thử nghiệm / thử nghiệm giai đoạn thiết kế (STLC) và kết thúc của giai đoạn Code (SDLC) nói chung sẽ đánh dấu sự kết thúc của thử nghiệm giai đoạn chuẩn bị và sự khởi đầu của giai đoạn thực hiện thử nghiệm. hướng dẫn tiếp theo trong này Software Testing Course - Trong phần tới, chúng tôi sẽ nói về những gì thử nghiệm thực là, những gì nó bao gồm những gì và những kỳ vọng từ các đội QA là trong giai đoạn này. => QA Training Day 5: Test Execution Chúng tôi hy vọng tất cả các bạn đang làm việc cùng với loạt bài này. Vì lợi ích của sự đơn giản, chỉ có một vài trường hợp thử nghiệm đã được tạo ra. Tuy nhiên, kết quả tốt nhất có thể được nhìn thấy khi bạn làm việc trên thử nghiệm rộng rãi, có nghĩa là viết nhiều hơn và các trường hợp thử nghiệm nhiều hơn. Vì vậy, xin vui lòng không hạn chế công việc của bạn và làm nhiều như bạn có thể. Xin vui lòng cho chúng tôi biết câu hỏi và ý kiến của bạn dưới đây. Chúc mừng thử nghiệm!