How to write test cases and organize them into test suites?

Question

I read a few ISTQB manuals like the ISTQB Foundation Level, Agile Testing, Acceptance Testing, etc. The only manual where I found some kind of useful references was the Certified Tester Advanced Level Test Analyst (CTAL-TA) but it's not nearly enough.

I am looking for references and some critical knowledge on how to write and organize test cases.

I know that test cases should be modular, organized based on features, reusable, etc.

I am in need of sustaining an argument against bad practices but I am having a hard time backing up my arguments.

To me it is kind of common sense but how to point out that the test cases shouldn't be organized by sprints/releases, that even if duplicating and tweaking test cases is easy, in the long run, it's not sustainable (even if that has been happening for quite some time).

I know how to write code and have clean and organized code because best practices are established but when it comes to documentation (test cases/suites), where can I refer to? Is there any official reference besides ISTQB? Something like the Project Management Institute which has very good and detailed material for its topics.

I will be working on plugging a new automation framework to our test repository and I don't want to spend my time cleaning test cases. I still don't have much visibility on how to do it but I want to plug testrail to jenkins and I think a way to do it is to have sections named the same way as methods.

Answer 1

As a software testing solutions organization, test case writing and mapping is very important for Functional/Automated tests. Test cases should be written and organized w.r.t. Smoke, Sanity, Regression and Feature or Sprints. As you said in your question that you prefer test rail for integration and organize with your automation suite, than in that case you can refer to TestRail official documentation. Organizing test cases: https://www.gurock.com/testrail/docs/lite/organizing-cases/

Answer 2

Before starting with how to write testcases we need to be clear with the idea behind writing a testcase i.e. what we are trying to achieve and the answer is to achieve a complete coverage of our entire application under test. This means that we cover each and every part of the application may it be a minute detail or a large functionality in the application

As we are now clear with the idea behind creating the testcases now the main question comes how to write them. For covering all the application we need to take care of all the below mentioned aspects while writing a testcase and those are: Functional Negative Our testcases should cover all the major fields that are required to identify and mark the testcase as pass or fail depending upon the clarity of the steps and their expected results. Below are the fields that should be included while creating a testcase:

1.Test case id for each testcase to uniquely identify the testcase 2.Section under test: What needs to be verified? 3.Test data: Any Variables and their values such as login credentials 4.Detailed steps that are to be executed 5.Expected Results for each steps 6.Pass/Fail as per the execution

Now only testcases creation is not enough managing them into test suites to fill any gaps is equally important. The top software companies always create and organize their test suites on timely basis as they are very useful during the below mentioned cases:

-For verification of build tests: They are used to perform a primary set of validation of most of the functional areas in the product. The testcases are executed whenever a product is build and before the build is released on production to be accessed by larger set of audience. -Smoke tests: To ensure that the basic functionality of the product is working correctly. Generally, these tests are the initial level of testing that is performed after changes are made to the system under test. -Functional verification tests: These test cases primarily focus on a specific product function. Executing these type of tests with a test suite guarantees that several aspects of a specific features are tested.

For managing the test cases in test suites we need to start with the following: Planning our test suites: As if we are automating the testcases without planning then this increases the chances that our testing will be inefficient and of no use. An essential part of any test plan is the definition of a strategy for test automation.

Setting up a common location for all the test cases: In order to help with ease the maintenance of the automated test suites, we need to locate our test assets in a repository that are easily accessible to the development team. There are many test automation environments providing test management tools making it easier to organize the test assets in a common repository.

Answer 3

That's a tough one, really hard to find some sort of codified commandment for something that seems so common sense. How can a project which is big enough to assign resources to writing test cases even live without some baseline regression set and more in-depth test sets for particular modules/components/features? Maybe you can just wait for a big-time outage and demonstrate how easily that could've been prevented by a well-organised testing process. Not a great option, huh.

Looking at the problem from a different angle, maybe you don't have to make a revolution but can normalise existing process without confronting the team? I wouldn't say that organising test cases by sprint/release is an inherently bad practice. Out of the top of my head, it could be viable as a part of a process like this:

• Initial tests are based on new requirements(+ existing tests for the component). Early code is deployed to dev/test environment and the test cases are executed, combined with exploratory techniques and updated. After some iterations the process converges and you get a final release-specific test set at about the same time the code can be deemed release candidate
• Release candidate is then deployed to pre-prod/staging/ UAT environment and the finalised test should be run against it as sort of acceptance testing step. If UAT with actual end users is part of your process, they might be following these test cases.
• After the acceptance is successful and the code is released to prod, it can be easy and convenient to select a subset of your release-specific test set to do post-deployment checks
• After the conclusion of go-live you review the release-specific tests and choose which should be added to your regression set and other baseline suites, while the remaining ones won't likely be used ever again and can just be kept attached to the release as history.