What are the most effective ways to write test cases?

Testing is a skill and it is a type of art, and to write a testcase you need: 1- understand the user story. 2- define the inputs, output and Operation. 3- Start with the a very basic Positive Scenario and write its testcase. 4- Exploratory Testing will help you to understand how the full system is behaving. 5- Then start to Cover advanced scenarios (Boundary test, MCDC,....). 6- Then go for the interaction between different scenarios. 7- Start the automation of the test cases (self generated stimulus, self checking output, automated reporting and coverage collector). 8- Target the Negative Test Cases(for the scenarios that is not mentioned in the requirement). 9- Apply Random Testing, this will help increasing the coverage.

Writing effective test case usually involve considering the aspects like what the software needs to do, its performance, usability and most importantly the security. So It's very important to have clear understanding of the user stories and overall flow of the project that how it's actually working.

Scope and purpose is the key to write tests, and there are 3 key principles I follow: 1. Find out WHAT/WHY that triggered the code changes 2. Write down acceptance criteria that are related to your changes (ensure they are translated to automated tests then) 3. Find out scenarios where your code won’t work but it should (and when you fix that ,put test to validate it )

Setup, act, assert—I find this a useful three-step template to keep in mind for any test cases. Setup: get the system into the right state and prepare the inputs you need. Act: execute the code which you want to test. Assert: validate the outputs from the action, or the new state of the system. BDD-style tests follow the same pattern, using "given, when, then" instead. Given that the system is in this state, when I perform this action, then this should be the result. You don't have to be too strict, though. "One assertion per test" is a common rule, but it won't fit every real-life scenario. Use standards as a starting point, but prioritise clarity and readability over arbitrary rule-following.

There is a pretty standard format used by whole software community so far: 1. Setup 2. Execute 3. Assert 4. Tear down Each test case should be well documented and should also be in line with business requirements. Having additional test cases is never bad. But that only gets clarified with proper discussions among stakeholders. As a developer, people sometimes miss the business requirement which can be amended when talking about proper testing

It is important to have appropriate structure but in my experience, it is more important to have a common language while writing the test. I am not referring to a programming language, but the wording while writing sentences for preconditions, actions and results. i.e. instead of using {press, push, pick, hit, etc.} the test should use only 1 word for all the scenarios.

Long back I built a framework where you can mock HTTP based services in few seconds and just in 2 lines without any extra configuration so that QAs can focus on what they have to test. https://github.com/NaturalIntelligence/Stubmatic

A good way to vet out your test names is to ensure they answer two questions: 1. What is the action occurring 2. What is the expected result

Write test cases in simple and clear language. Avoid jargon or ambiguity. Anyone should be able to understand and execute the test cases without confusion.

While writing tests, the two major key aspects to remember are: 1. Covering Foreseeable Edge Cases: - Test extremes and invalid inputs to uncover potential issues. - Address boundary conditions, unexpected values, and edge cases. 2. Maximizing Code Path Coverage: - Test various input combinations to explore different code paths. - Ensure statements and branches are executed, and dead code is identified. By balancing these two aspects, we can create effective test cases that reveal both common and unexpected issues.

One thing I have found useful is to create a truth table that gives an understanding of how many different scenarios and combinations are to be tested specially in cases where you have multiple if else conditions

- No need to write test cases for functions you’re not developing(external imported libraries) - Start with the most obvious cases, generally as you’re writing these cases, you can think of more nuanced ones - Any feature being developed should have test cases written even before the feature is defined (TDD) - Maintain order and hierarchy when writing test cases, as you might end up writing the same one more than once

Prioriza los casos de prueba basándote en la importancia de la funcionalidad, la criticidad para el negocio, la frecuencia de uso y el riesgo asociado.

Identify Critical Test Cases: Determine which test cases are critical to the core functionality or performance of the program or feature. Assign Priority Levels: Categorize test cases into priority levels such as high, medium, or low based on their importance and impact. Consider Complexity: Assess the complexity of each test case and prioritize accordingly. High-complexity cases may need more attention. Frequency of Use: Evaluate how frequently specific features or modules are used, prioritizing test cases related to frequently accessed functionalities. Categorize by Test Type: Group test cases by type, such as unit, integration, system, acceptance, functional, non-functional, or regression tests.

Some cases are related to others and some cases if tested will create other cases and will ignore some others this lead you to prioritize and categorize you cases.

The biggest mistake people usually make while writing test cases is to just care for coverage. Test cases are code which needs to be written in easy to understand and maintain. If you end up writing a test suite that is difficult to maintain/fix, it does not serve the purpose. Test cases needs to be designed just like the code under tests. Test cases giving false positive or tests breaking for no apparent reason or difficult to fix are signs of improperly designed tests.

Regularly review and update your test cases as the software evolves. Ensure they remain accurate and relevant to the current state of the application. Collaboration with team members and stakeholders can help identify improvements.

Follow the epic or user stories to update test cases first before making changes to the feature. This helps maintain a documented workflow for the features (both development and testing).

Writing tests should be a cultural practice within a team. When this culture has not matured within the organization, it is often just a perfunctory process that lacks the necessary attention to create effective tests. Ultimately, it turns into a time-consuming task where we only go through our own tests without creating any value, especially in enterprise products. Neglecting this aspect can lead to serious consequences. So, it is crucial to remember that for writing tests, the team must work together and cultivate the culture of effective testing.

In case you have multiple versions of a software being shipped out to different customers, one may need to write different test case scenarios for different versions. Also if a higher version is backward compatible with the previous one, some tests should be created/ maintained that test this compatibility (and regularly revise the tests as well)

An additional aspect to consider occurs when large complex systems demonstrate emergent properties that are not evident when performing unit testing. Traditional testing assumes we know the properties of the system. Chaos engineering serves to inject known perturbations into the testing from a people perspective in several clever ways. Dave Rensin, Distinguished Engineer at Google has an exceptional talk you can find on YouTube that describes various techniques that can be injected to test the robustness of the triumvirate of people, processes & technology. Ultimately, this approach is used to understand the gap between how the system should behave and how it actually does behave.