Hi, I’m Abrham Kassa
a Software QA Engineer Developer in Test

Enhance your software quality assurance and testing

Software quality assurance testing creates customers.

Its value lies hidden within the smooth flow of your UI, the ease with which a problem turns into a solution and the reliability and security that customers come to take for granted.

Software quality assurance is how you turn development innovation into customer experience execution. It makes sure there is nothing lurking within your application that will prevent a customer from praising your product to their friends and colleagues.

The customer is not the only one who benefits, either. An experienced QA expert knows there are several key strategies that can enhance the design and execution of software quality assurance testing to save time and resources within the SDLC—time and resources that could improve your product and your enterprise.

Enhancing QA does not require you to sacrifice breadth and depth of testing. Instead, it relies on efficient planning, modern tools and continuous integration to maximize the resources at your disposal.

Smarter testing produces quality testing faster.

It is a five-step process:

1. 1. 1. Take Full Advantage of Automation
      2. Commit Manual Testing Where Most Critical
      3. Optimize Checkpoints and Reporting
      4. Prioritize Communication and Collaboration
      5. Leverage Expertise and Experience

The process begins with the efficient use of modern QA’s most effective tool: test automation.

1. Take Full Advantage of Automation

Automation improves the depth, accuracy and coverage of your test cases, and it saves you time and valuable human resources in the process. By carefully designing test cases around your business priorities, you can ensure a stable, reliable product throughout an application’s evolution.

There are test automation tools now available to cover every phase of the QA process, including areas of GUI and UI testing that are traditionally reserved for time-consuming manual testing. Modern QA is at its best when it uses automation tools to integrate testing with development in an Agile environment. Here, developers and testers work hand-in-hand to break the SDLC down into manageable sprints bookended with automated regression tests that ensure product stability every time the evolving code changes.

Automation gives you the speed and unrelenting machine accuracy needed to balance reliability with growth. 

2. Commit Manual Testing Where Most Critical

Maximizing the benefits of automation frees your engineers to do what they do best. Released from the repetitive, boring chore of regression testing, your developers can now concentrate on your business goals and the end-user experience.

The insights of manual testers make them the best option for user interface, usability, installation, error handling and elements of security testing. Tools are available to automate these tasks, but the qualitative and subjective analysis of human testers provides valued feedback a machine is not equipped to submit.

The best possible software quality assurance testing results occur when automation is supplemented with a manual testing component. 

3. Optimize Checkpoints and Reporting

The Agile approach to development lets you access the talents of a broader range of stakeholders than traditional models of design and testing. To optimize these assets, you need to deliver regular reports that can be understood by everyone from technology whizzes to near-beginners. Many testing tools now accommodate natural language for both execution and reporting.

You should also establish clear checkpoints within the SDLC to ensure the product is proceeding efficiently and that testing adheres to core business goals. This includes the need to meet strict audit and compliance standards, such as HIPAA.

4. Prioritize Communication and Collaboration

The continuing maturity and specialization of offshore and nearshore QA solutions allows you to save important time and resources. Outsourcing to India, for example, can halve your QA spend and create a 24-hour production cycle.

Maximizing these benefits depends on prioritizing smooth communication between internal stakeholders, internal and external engineers—and between developers and scrum masters.

Regular meetings are a must, and digital communications such as video conferencing and workplace collaboration apps should be encouraged to facilitate communication across teams, management levels and locations. 

5.  Leverage Expertise and Experience

Finally, you must not feel you are alone in seeking a software quality assurance testing solution. Many enterprises, especially startups and small businesses, do not have access to the resources or test infrastructure needed to meet the highest standards of QA. There is far greater risk associated with cutting QA corners or forcing developers into double-duty as testers than you will ever encounter in outsourcing.

An expert QA partner is an extension of your team. You remain in control of the project while they provide advice on optimal test framework and tool selection, the integration of development and testing and the use of manual and automation testing.

Outsourcing allows you to scale production quickly when needed and to reduce test expenses at lower ebbs of the release cycle.

Software quality assurance testing is about your end-users. You need to maximize your QA investment to make sure the promise of your application survives to make a difference in the lives of your customers.

Types of Test Cases in Software Testing

Quality assurance in software involves many different approaches to testing. It’s nearly impossible to test everything, but you can certainly get close by narrowing in on the different types of test cases that do and ask specific things. To discover which type to use for which purpose, you need to consider all the different types of testing and filter the test cases best suited for helping you to testing that uses for its base achieve the highest quality product.

Some of these areas can overlap with others, but in general, each type of software testing and each category of test case has a specific purpose. In this post we’re going to look at some of the most common types of test cases in the world of software testing.

Different types of test cases:

Functionality Test Cases

Functionality test cases are used to discover if an application’s interface works with the rest of the system and its users. The tests identify the success or failure of functions that the software is expected to perform.

The cases are a type of black-box testing that uses for its base, the specifications or user stories of the software under test. This allows the tests to be performed without needing access to the workings or internal structures of the software being tested. The QA team are usually the writers of functionality test cases because the task falls within normal QA processes. They can be written and run as soon as development makes a first function available for testing. To help steer development, they can be written in advance of the code, if all the tester has access to are the requirements.

As specified above, they can be written and run as soon as it is viable to do so and they should be repeated whenever updates are added, right through to when customers become a possibility.

Example: Confirming a user can successfully upload a profile photo.

User Interface Test Cases

User interface test cases are used to verify that specific pieces of the Graphical User Interface (GUI) look and work as expected. These types of test cases can be used to identify cosmetic inconsistencies, grammar and spelling errors, links, and any other elements the user interacts with or sees.

These cases are usually written by the testing team but the design team may also be involved as they are most familiar with the interface. User interface test cases are the types of test cases in software testing that usually drive cross-browser testing. Browsers tend to render things differently, and user interface test cases help ensure your application behaves consistently across multiple browsers.

These test cases will be run once the development phase is complete and the UI is hooked up to the database.

Example: What happens when the website is viewed on a small screen such as a mobile phone? Does the UI break?

Performance Test Cases

Performance test cases validate response times and overall effectiveness of an application. That is, after executing an action, how long does it take for the system to respond? Performance test cases should have a very clear set of success criteria.

The testing team typically writes these test cases and they are often automated. A large application can have hundreds or thousands of performance tests. Automating these tests and running them frequently helps expose scenarios where the application is not performing at the expected level.

Performance test cases help with understanding how the application will perform in the real world. These cases can be written once the testing team has received performance requirements from the product team. However, many performance issues can be identified manually without having specified requirements.

Example: How long does it take for the system to authenticate a user, and load the next page? When multiple people login at the same time, does the application remain stable?

Integration Test Cases

Integration test cases are meant to determine how different modules interact with each other. The main purpose with integration test cases are to ensure interfaces between the different modules are working properly.

The testing team identifies which areas should undergo integration testing, while the development team will have input on how those test cases should be written. Either of these two teams may work to write the cases.

They verify that modules that are already working individually, are also able to work together.

Example: Checking the link between the home page and the “favorites” section. When you add an item as a “favorite”, from the homepage, does it appear in the “favorites” section?

Usability Test Cases

Usability test cases can often be referred to as “tasks” or “scenarios”. Rather than providing detailed step-by-step instructions to execute the test, the tester is presented with a high level scenario or task to complete.

Usability test cases help identify how a user naturally approaches and uses the application. They help guide the tester through various situations and flows. No prior knowledge of the application is necessary.

These test cases are typically prepared by the design team alongside the testing team. Usability testing should be done prior to user acceptance testing.

Example: Can the user successfully add more than one item to their shopping cart? How is that experience?

Database Test Cases

Test cases for database testing examine what’s happening behind the scenes. The user interface is clean, and everything appears to be working… but where is all that data going?

In order to write these test cases, you need to have a strong understanding of the entire application, the database tables, and the the stored procedures. The testing team will often use SQL queries to develop database test cases.

Database tests are used to verify the developer has written the code in a way that stores and handles data in a consistent, safe manner.

Example: Let’s consider the creation of a user profile. When the user submits their profile, the following should be tested in regards to the database.

1. Did the application store the inputted data in the database?
2. Was any data lost in the process?
3. Partially performed data should not have been saved.
4. Unauthorized users should not be able to view or access the user’s information.

Security Test Cases

Security test cases help ensure the application restricts actions and permissions wherever necessary. These test cases are written to protect data when and where it needs to be safeguarded.

Security test cases are used to drive penetration testing and other types of security-based tests.

Authentication and encryption are often the main focus in security test cases. The security team (if one exists) is usually responsible for writing and conducting these tests.

Example: If a user reaches X number of failed login attempts, does the account become locked? Is a user able to upload data without being logged in?

Agile test case management

A test case repository can easily grow too large and full of obsolete test cases if not regularly managed. A number of test cases will be executed by QA, reported as failed and then closed by the product owner, to then become an unnecessary waste of time and resources. We’ve all been there. A test case is written from a user story, then several sprints later, a new user story changes the workflow or the intended functionality and a new test case is written. If the previous test case is not updated or deleted, it can cause a round of confusion from QA to Dev to Product. To help avoid this situation, I’m going to provide some tips for efficiently managing these test cases in an agile environment. By being proactive with agile test case management within each sprint, the QA team will avoid accidentally executing obsolete test cases, and avoid filing invalid bugs, so creating a more efficient process for ensuring test coverage.

The Problem With Agile Test Case Management

One of the biggest mistakes a QA team can make is to dump all test cases into one bucket to be used for regression. I’ve seen this done a lot, because at the time it may appear there are more important issues to focus on. This not only adds obsolete test cases to the regression test suite, but significantly increases the demands placed on the management of test cases in the future.

Here is why: What often happens is a tester creates the test cases from a user story during a sprint. The test cases are valid and necessary for testing during that sprint, but at the end of the sprint the test cases will be moved into a bucket that includes all test cases from all previous sprints. The tests pile up and when it’s time to do a full regression, the team discover a massive amount of test cases, including duplicate test cases and invalid tests. Usually, there is a small window in which to execute the full regression and now the team must sift through all the tests to figure out which of those to execute. Executing the wrong test cases at this point is a productivity killer and will lengthen the time needed to complete the regression. The last thing QA wants is to delay a release because they were not properly prepared to complete regression testing.

The Solution to Managing Agile Test Cases

The solution is simple really, it just requires a level of proactivity, to prevent the team scrambling to update regression tests at the time of regression. Schedule time within each sprint to manage regression test cases. The changes for each user story will fall into one or more of the following four categories. Evaluate each user story and the tests created, then decide which suite or category or categories the tests for the user story falls under. It’s possible that a single user story will require tests to be added, updated and removed at the same time.

• Add Tests – If major functionality is introduced, the tests created for the sprint testing should be added to the regression set. This may include adding the test to a smoke or sanity test as well. Where the test is added will be determined by the significance of the functionality or feature. If it is a high level feature that a majority of user’s will use, then it should be added to both regression and smoke/sanity testing. Adding a test is usually done by default which will cause the issues I mentioned above. Be sure the test is one that should be added to regression to avoid duplicates. Which leads us to the next option; updating tests.
• Update Tests – In the event that a workflow is updated but, for example, no significant changes are made to functionality, it is not necessary to create new tests. Simply editing the tests to match the new workflow will be sufficient and in this case, the tests for this functionality in the regression suite should be pulled into the sprint and updated to match the new workflow or behaviour. If the test case author were to simply write a new test instead of updating the earlier one, then you have a duplicate/obsolete test case in regression. If this happens over and over you suddenly have a major headache on your hands when you start regression testing. Remember to update the existing test case before pulling it into the sprint test plan and that the original test should be updated at the source and then pulled into the sprint.
• Remove Tests – Some user stories simply require removing a feature that is no longer in use. This might be because a provider has been removed and content that was tested previously is no longer relevant. When it comes to updating test cases, it is just as important to remove unneeded details as it is to add newly relevant ones. If a new tester is hired, they will have no previous knowledge of the history of the product. When the tester is assigned a set of regression test cases that are obsolete, they will be entering invalid bugs. This wastes the time of the tester who enters them, the product team who reads and comments on them, and the senior tester who must communicate the reason for the bug being invalid. One invalid bug turns into an unnecessary waste of resources. It can all be avoided by removing the test case when it is no longer valid.
• Do Nothing – User stories that simply adjust an image, color scheme or text should have test cases created in sprint testing. These tests don’t belong in the regression suite. They are valid tests, and may need to be executed each time the software is deployed to a new environment, but after that they should be set aside. Elements that change frequently and are highly unlikely to be touched unless another user story is created, are not useful in regression testing or smoke/sanity testing. In this case, after the sprint is completed and the change is in production, leave these tests in the sprint folder for historical purposes.