Functional testing with test case writing

A correct description understandable for the tester is crucial. Test cases good quality and, consequently, functional tests’ correct execution depends on it. The person responsible for preparing the description is usually a Business Analyst or a Product Owner if the project is implemented in the Agile methodology.

What should such a description include?

• The exact application location/area in which the functionality is to operate. For me, the most helpful thing was usually the tab name and, for example, the full name of the button triggering the functionality. Of course, there may be situations where the functionality is triggered by typing a command in the application, clicking on an icon, or similar.
• A clear operational description. The description should be clear what the new functionality’s purpose is and what reaction in the application its use causes. It is also important to indicate the user for whom the functionality is implemented.

In one of the projects in which I participated, I received a screenshot of the application code. Only after talking with the project manager, the description was corrected, and I received a proper, full one. It is important to remember that the manual tester must oversee the description quality. If the tester misunderstands the functionality, then the tests are performed incorrectly – this results in low product’s quality delivered to the users.

• Requirements. As far as the requirements are concerned, projects conducted in the Agile methodology are relatively easier in this respect, as they use and write down the so-called user stories. It is recommended that user stories contain a clear requirement description, preferably written in bullet points.

In projects conducted in the Waterfall methodology, this can vary. Sometimes we receive extensive documentation describing how the application works and, on this basis, the manual tester has to create a requirements list for the given functionality. How do I handle such a situation? Most often, I create a list with a short description, without going into details, for example:

– Click the New button. A new window appears.

– Click the Save button. The window closes.

• Screenshot. A lot depends on the specific project. If there is no UX designer, then there are no project mock-ups showing the application layout and, for example, the button placement. Often, well-prepared descriptions of the previous three points are enough to fully understand the functionality. Then, the screenshot is no longer needed.

However, there are times when the lack of a sample screenshot causes confusion and a waste of time. I remember a situation from a project where the change concerned generating a new report with the order number. Unfortunately, despite providing the location, correct description, and requirements, it was not clear where the company logo, document title, footer, and amount summary fields should be placed. This blocked my work, and I had to wait until the person responsible for this functionality found time to explain the details. The screenshot would have allowed me to work without any downtime; both I and the descriptions’ author would have saved time spent on clarifying these issues.

I strongly encourage testers: do not be afraid to ask. As for me, there are no stupid questions. If a tester has doubts, something is unclear, they not only have the right to ask but should do it and ask for clarification from the person responsible for the change description. Testing is the testers’ responsibility, and without understanding how the application works, it is impossible to execute them correctly.

Well-written test case

To test the application’s functionality, a well-described test case is also essential. How to describe a test case correctly?

• ID. Each test case should have its unique identifier. If you use a test management tool in your project (such as Jira, Testlink), the numbers are generated automatically. If there is no such tool or it is unavailable due to failure, for example, you can use Excel and number the test cases sequentially, TC01, TC02, and so on.
• Name. The name should be short, without any details: Order form closing (admin user), for example. The too-long name makes your work unnecessarily difficult. I remember situations early in my testing career when I wanted to name test cases in great detail. One of the examples: “Closing the order form by clicking the cross icon by a user with administrator privileges and redirecting to the main page.” Instead of making it easier for myself, I was just wasting time because the name was hard to remember, and it often did not display completely in the test cases list because of too many characters.
• Objective. The test objective should be more specific than the name. It should be understood by a person who is not the test case author.
• Preconditions. Also called prerequisites. In other words, conditions must be met to proceed with a test case. What roles will be assigned to users, what fields should be completed, what tab should be opened, and similar?

When the Project Manager asks for information regarding the time it takes to complete a given test case, one must always take into account how long it may take to meet the prerequisites, such as filling in the fields and creating appropriate objects. Once I focused too much on steps. There were only a few of them, but I found that it took a long time to meet the prerequisites. So I gave the time too far from what I actually needed to complete the given test cases.

• Steps. Steps that should be performed so that the test result can appear in the application. The steps should be described from the end user’s point of view. The tester gets into the end user’s role as if they were using the product area.
• Expected result. The result should appear after executing the given step.
• Priority. Defines the test case importance. Allows the Project Manager and manual tester to assess which cases to execute first when time is short and a change needs to be delivered quickly.
• Version number. We have consider changes that may be introduced to the given functionality at some point. Then, test cases need to be updated. We then give the new version of the test case a higher number than the previous one.

Test case versioning is more and more often available in tools such as the popular Jira, thanks to which we can at any time review previous versions and recall what changes have been made.

Sample test case

The test case should be checked by another tester who can point out correct suggestions, catch typos, and similar.

The test case quality should be at the highest level, especially in the so-called validated projects. They are additionally checked by a validator – a person responsible for their degree of accuracy. In such projects, the form of writing test cases is usually imposed by the validator, and, from my experience, you have to adapt to the form desired in the project.

Test cases coverage

In functional testing, we should include positive as well as negative test cases.

• Positive – show that the given change works as described and intended in the application.
• Negative – are used to check what happens as a result of undesired functionality operation, after entering bad data, for example.

Let me describe this with an example.

Types of test cases

Test case vs. test scenario

You may find the terms test case and test scenario alternately used, which may be confusing. The easiest way to distinguish them is to compare the scale/scope: a test case covers a part of the application process, while a test scenario usually covers the entire process, meaning several test cases, both negative and positive.

Differences between test case and test scenario

Proper execution of functional tests consists of an adequate description of the change and correctly written test cases. If both conditions are met, a manual tester can quickly and properly test the given application area without wasting time on detailed descriptions. I hope that my tips about describing the functionality and writing good quality test cases will be useful in your work and that specification-based testing will become clearer for you.