Be on the same page with us
Subscribe to our latest news
By clicking the button Subscribe you give a permission for the automatic sending of e-mails

Senior QA busts 4 testing myths and gives tips on test case writing

There are long-standing opinions that some ways to go about testing and quality assurance processes are flawless. And every QA specialist must stick to the magical rules of testing.

That is far from the truth. I'm a QA engineer myself, experienced in heading up teams and mentoring rookies. And I keep telling clients and colleagues: having prejudices is misleading and dangerous.

QA
By Dzmitry Seachouk, Senior Manual QA Engineer at Solvd
May 26, 2021
A software quality assurance team risks getting trapped between real needs and imaginary solutions if thinking wrong. I know many engineers who failed to draw up tasks clearly and chose a faulty testing method.

For clients, the danger of misconceptions is in potential cost increase, aggravated communication with investors, and – at its worst – reputational damage and project shut-down.

You definitely don't want that kind of consequence. Let me dispel false assumptions.
Don't believe these 4 myths
I will go from one assumption to the other, explaining to you the truth of the situation.

1. QA engineers mainly write testing scenarios and test products.


In real life, our work is much more complicated. We plan, analyze requirements, set up testing environments, develop test scenarios, launch tests, report bugs, and make retrospectives. Beyond that, we discuss suggestions on improvements and provide customer support whenever needed. Testing activities take a fraction of our workload.
2. The ultimate goal is achieving a Zen state. Testers must detect and iron out every single bug and test all the product functionality with equal efficiency.

If QA engineers work in that fashion, they will destroy a key balance between priority and important functionality. Teams and clients are often under time and budget constraints. They have to prioritize tasks, allocate time wisely, plan expenses, seeking a middle ground between costs and quality.
3. Testers must use all the possible input data and apply every testing strategy.

I teach to pick data, tools, and testing methods on a case-by-case basis. One efficient strategy and one suitable testing approach are always better than myriads.

How to make a choice? Leverage good knowledge of a product, structure QA processes adequately, and be consistent. Don't forget to determine project components that can be automated and the stages of implementing automation.
4. There is a universal recipe to make any project one hundred percent fail-free.

There is no silver bullet. The testing classification is too broad. Tool choice depends on goals, formats, and other specifics of functional and non-functional testing. When I work with unit testing or integration testing, the spectrum of activities I face is so diverse.
Let's write accurate test cases
I like well-composed test cases that help QA engineers outline the objectives and expected testing output. Discovering and fixing errors become easier in contrast to ad-hoc testing, lack of consistency.

A test case involves four mandatory sections: Title, Initial Requirements, Testing Steps, and Expected Results. But the final format and construction of a case would depend on the project specifics and regulations of a client company.

I will give you an example of creating an easy test case.

Imagine a simple login web page containing login and password boxes and buttons as Sign in, Forgot Password, and Register. The testing goal is to describe the user's ability to log in with valid user data.

Where to start a journey towards a perfect test case? In my practice, the best starting point is choosing the right style for a test case. Ask clients and colleagues follow-up questions and double-check specifications to get more valuable information.

I recommend using plain language for test cases. That would make writing clear for non-techies or those new to specific functionality. Striking a balance between the usefulness and readability of a test case is vital.

Some test case authors tend to use abbreviations nobody except them understands. That might result in a stressful misunderstanding. New team members would hardly grasp that 'conduct SUFF with VAD' stands for 'Sign in as a Facebook user with valid user data.' So don't overuse abbreviations and contractions.

Other authors may neglect to fill in each of the four test case sections. They may limit Initial Requirements to a single link to specifications, leave Steps empty, or have Expected Results duplicating information provided in Title.

They go wrong about that. All four sections require attention. But – observing the balance between usefulness and readability – it is better to keep descriptions concise.

Here is a simple rule I prefer: cut off unnecessary details irrelevant to a test case and make a case as plain as possible.

For Initial Requirements, it is enough to specify information critical to start testing, provide a link to instructions on setting up a test environment, or other similar data. Make the section look like the following: 'Connect a VPN to simulate a location (USA). Open the login page for users.'

Add Expected Results to each step so that all engineers understand things the same way. Besides, make sure this section comprehensively describes the system state. Avoid writing something like 'The user logged in.' Change that to 'Welcome, user_name; redirection to the homepage (Landing page).'

And a final tip: when filling in a case with steps, avoid dry technical language or over-described functionality and fixed test data.
Conclusion
I hope I've convinced you that sticking to misconceptions might result in pointless waste of time. Trying to achieve elusive goals, engineers would leave real challenges without adequate solutions. Clients, who share wrong ideas about QA processes and objectives, are likely to encounter additional expenses and increased product time-to-market.

At Solvd, we don't welcome myths and prejudices. Our QA testing teams care about every client case and offer the best-fit approach to arrive at the desired results.

Follow our blog and get in touch with us to start cooperation.