In our opportunity to deliver a service of providing sample test cases for crm application, we have reviewed and included the most frequently asked questions by our clients and we have also answered these questions to make it easier for professional testers to write their own test cases. This document provides answers on how to create good test cases.
In this guide, we review Sample Test Cases For Crm Application, how to write test cases for crm application, how to write test cases for loan application, and how to create test case scenario.
Sample Test Cases For Crm Application
This guide lists some of the test cases that can be used while testing a CRM system.
Test Case Title: Verify login process from home page.
This test case verifies the login process from home page.
- Login with user id – 1, password – password and click on submit button.
- Confirm that user is logged in successfully.
Steps to be followed:
Once you have clicked on the login button, enter a valid username and password in respective fields. After that, click on submit. If successful, this will take you to a dashboard that belongs to the user who just logged in.
1. Click on login button for opening login popup.
- The application should allow the user to login using a username and password.
- The application should allow the user to logout from their account.
- The application should allow the user to signup for an account on the website/application.
- The application should allow the user to reset their password if they have forgotten it or it has been changed by someone else.
2. Enter valid username & password in respective fields.
- Enter valid username & password in respective fields.
- In this test case, we want to ensure that only a user with the correct username and password can log into the system. So, we will verify if the entered credentials are valid by checking a few things:
- The user enters a valid username and password combination (e.g., alice and supersecret) in their respective fields on the login page.
- The username and password should be displayed on the login page as text input controls (e.g., for “Username”).
- The username and password fields should be visible to all users of our application from all countries, regardless of their browser or device settings (e.g., they do not get hidden by default). If any of these conditions fail, then this test case fails as well because it means that someone might be able to break into your system using brute force hacking techniques such as automated guessing software which could guess thousands or millions of passwords per second until one works).
3. Click on Login button.
- Click on Login button.
- Enter the username and password in their respective fields, and click Login button.
- If you are logged in successfully, you should be redirected to your dashboard page with a welcome message from your system administrator!
4. Verified that a dashboard is opened which belongs to the user who just logged in
It should be verified that a dashboard is opened which belongs to the user who just logged in. The dashboard should have all the functionalities and data relevant to that user. It should not have any other data or functionalities which are unrelated to that user
Expected Result:
This is the expected result of this test case:
- Open the Dashboard UI with context of logged in user (for example, open a dashboard for sales team)
A dashboard should be opened with the context of the user who just logged in.
The dashboard should be opened with the context of the user who just logged in.
The dashboard should have the context of the user who just logged in.
how to write test cases for crm application
The Customer Relationship Management software, used for analysing customers, helps in enhancing customer interaction. The primary goal of this software is to improve business relationship with customers through retention and acquisition.
Apart from its ease of use, the software delivers many benefits
CRM software testing means testing the user’s ability to use the software. In user ability testing we have to check that the software functions in all types of browsers. Mobile app testing and web app testing can be used to check the functioning of the software in mobile and web. We have to check that the font size and the color of the font used in the application is correct.
Performance of the application or the software needs to be tested to ensure its compatibility. How the software responds to an increase in the number of users should be checked. It must be ensured that there is no slowdown in the app performance and no difficulty for the users to use the application. Response time along with Peak Time, Reliability and Scalability should be checked.
Need to be performed because the customers data is confidential and security should be analysed.
Functional testing is carried out to ensure that the functions correctly match with the functionalities of the application. It is essential to check for any mis-functions in the software.
how to write test cases for loan application
There’s no one-size-fits-all for writing a good test case. There’s a lot to consider — not only between projects, but among each test within the same project. Because while they may seem like glorified to-do lists, great test cases are far more than that.
Here we’ll address common struggles related to test cases and why they happen. We’ll also provide a step-by-step guide to writing a great test case, including an example.
Common Problems with Test Cases
Simply knowing how to write a test case only gets you so far. Poorly-written test cases can waste time and, depending on the product, potentially put users in danger.
Writing great test cases means that not only are all the right tests performed, but also that you maximize your ROI. To do that, we need to look at what’s going wrong, and why.
If you struggle with any of the following, you’re likely missing something:
The Core of the Problem
In all of these instances, you’re probably missing clear answers to one or more of these three fundamental questions:
Be sure to answer all of these questions before you begin writing your test cases.
How to Write a Manual Test Case
This checklist outlines the steps you need to take to write a test case, and the guidelines that help ensure it’s written well.
Step 1. Find your requirements (or user stories.) Again, these tell you what to test. It’s critical to complete this step first. Begin each test case from a requirement.
Step 2. For each test case, create a summary. This is a clear, simple description of what the test is. If you use a test case management solution, this will appear like a title in your overview of your tests. Make it easy to distinguish one from another.
Step 3. Include a description of goals. Help the tester understand the big picture.
Step 4. Determine the starting conditions and any setup or equipment your test relies on. Picture a recipe for baking a cake. “Pre-heat the oven to 350 degrees” is a pre-condition. Two greased 9” round cake pans are required equipment. Do this for yourself by identifying necessary setup:
Use this information to be clear and thorough in your steps.
Step 5. Write clear, simple steps. If you can, attach an image of a screenshot or mockup to help clarify. Here are the criteria that will make the difference between a good test case and a poor one:
Step 6. With that same criteria, also include expected results — this is how the tester knows whether the test passed or failed. To continue the recipe analogy, for the step “Remove the cake from the oven after 45 minutes”, an expected result would be, “The top of the cake is brown, and the sides have pulled away from the pan.”
This outlines the basics of writing a test case well. You can include other parameters, as will be shown in the following example.
Test Case Example for Manual Testing
Here is a screenshot of a test case created in Helix TCM. You can see all the elements of the steps outlined above.
Additionally, it provides other information you may choose to include.
Leverage your test case tool’s ability to support custom fields, requirement traceability, and configurable workflow to help you organize and manage your testing efforts.
You can use this additional test meta-data to help:
What additional information you include with each test case will depend on your project template and test management process.
Write Even Easier Test Cases
All of this information will help you craft better test cases. But they can be even easier to create when you switch from Microsoft Office to a test case management solution.
Helix TCM lets you write, execute, and track tests with ease. Use it on its own for test management or as part of the Helix ALM suite. Even pair it with your existing tools, including Jira.
And you can try it out for free. Use the buttons below to download your 30-day trial, or watch a demo of Helix ALM to learn more about the scope of the software.
Senior Product Manager, Perforce
Paula is a Senior Product Manager for Helix ALM. With a diverse background, including roles from computational physicist to startup founder, she believes software should first and foremost make our lives easier. She specializes in application lifecycle management, with an emphasis on testing and requirements management. When out of the office, she’s always looking for a chance to play inline hockey.
how to create test case scenario
In this short primer, we’ll introduce some of the features and functions of loan applications that we pay particular attention to from the point of view of a software tester. Primarily, there are main functions of loan application software:
At XBOSoft, as many of you know, we have a credo when it comes to test automation. That is “You can’t automate what you don’t understand. We also apply this credo to our overall financial software testing practice where we absolutely demand that our staff be domain experts in the software they are testing. As for testing loan application software, we’ve worked with many subsets including mortgages, consumer, and commercial.
Below is an example for taking a personal loan.
Loan Application
The process of lending money to a customer for a loan application software begins with taking an application.
The purpose of this is to gather information about the borrower and/or spouse, and then use this information with required documents to develop a credit judgment and analysis. This includes:
1. General information
Besides the general information such as SSN, Name, Date of Birth etc, the information below are important:
2. Employment history
Gather employment information such as Employer, Position, City Employed, Date Employed etc, and other important information such as Net Salary and/or Other Income.
3. Residence and automobiles
Residence information will vary depending on whether or not the user indicated the borrower rents, is buying, owns or lives with parents. Automobiles owned and balances on existing car loans will determine borrowers capability for more debt.
4. Other real estate and assets
Gather information for other real estate and assets owned by the borrower with description and value. This determines what the borrower could use as collateral for the loan.
5. Creditor
Most loan application software requires that the user indicate their rent or mortgage debt. This sometimes can be automatically displayed by the system (pulled in from other data sources), and is associated with the applicant (A), spouse (S) or joint (J). The system should display an error message if the user fails to indicate who the debt belongs to.
The loan application system will score the loan application based on information above with business logic, and determine if the calculated score is too low to continue with the application.
As you can imagine, the business logic to determine the loan applicant’s score can be quite complex and involve many test cases. Any number of factors can cause the score to be below 600 upon which the applicant should be turned down. So testing involves ensuring that each factor impacts the score correctly, as well as making sure that the applicant’s approval or disapproval is correct.
Loan Approval
Once the loan application is complete, the next step is to evaluate the loan. Here are the main checkpoints:
As software testers, this is one of the most difficult parts in checking all the different loan evaluation scenarios. As you can imagine, it’s easy to make a mistake in evaluating a loan and approving it. So the scenarios below should also be considered when testing:
Other test scenarios include different combinations such as if an applicant’s credit grade is A which means he can borrow 10000, while the manager’s credit grade limit is B, which means he can approve max loan amount 5000. Thus, if A > B, this needs additional approval. We updated the application with new application info, and the credit score changed from A to B, which means no additional approval needed.
Loan Processing
Once information is complete and the loan has been approved, the next step is to process the loan. This involves several steps:
1. Start up the loan
1.1. Set up a payment schedule
After the loan has been approved for a given loan amount, the system should calculate additional fees and enumerate insurance options, filing fees, etc. This information should be presented to the loan applicant along with the payment schedule based on specific business rules for Interest rate, Finance Charge, Maintenance, etc. For example, the interest rate that will apply and the amount of interest that will be charged are calculated based on the approved Loan amount and the repayment period. Repayment terms, such as Lending Period: 61 Days to 72 months along with payment options such as once to twice a month, combined with maximum APR varying by jurisdiction and regulations have a significant impact on the number of permutations and therefore test cases.
1.2. Impact of APR on loan application software testing
The loan application APR (Annual Percentage Rate) is highly impacted by the constant changes in government loan regulations, often dictated on a state by state basis. For example, one state may have a maximum APR regulation of 35.99%, while another may have 23.99%. Any changes to the state APR will impact all system calculations. So if the Loan application software is used in different states with different rules, it will involve thousands of dependencies. Dependencies in such business rules impact the testing process as it requires more time, resources, and continuous monitoring.
1.3. Set up a loan account
Once the application process is complete and the terms of the loan have been agreed upon (borrower signs loan contract), the next step is to set up the account to:
2. Maintain the loan
When customers accept the terms and conditions for a loan, they enter into a commitment to repay the amount they owe, according to the specific schedule outlined in their loan documents. After this, the loan goes into maintenance whereby there can be three different types of processes.
2.1. Payoff early
When a customer chooses to payoff their loan prior to the last payment date, law requires that certain charges (such as finance charges, insurance, etc.) be refunded to the customer.
The methods used to determine cost and refund of credit insurance and/or finance charges could vary by state according to the number of days the loan is paid in advance. Some states allow additional days interest to be calculated and owed beyond when the loan is paid off. For example, for the loan with terms less than < 60 months, the refund calculation method uses the Rule of 78 in Mississippi which gives greater weight to months in the earlier part of a borrower’s loan thus increasing interest payments and is more beneficial for the lender.
On the other hand, the Accrual (actuarial) method is used in Illinois. The Accrual method is based on days whereby the unearned interest is refunded. When prepayment occurs, the lender retains 1/30 of the applicable interest for each day from the date of the loan to the date that prepayment occurs, and refunds the balance of the interest after prepayment date over the total term of payments.
As you can imagine, these rules and regulations result in more test cases as these calculations have to be verified for correctness.
2.2. Normal repayment
Accepting customer payments is an important functionality. The system must re-calculate the payment schedule to ensure the most up to date information is displayed. Re-calculation is often necessary as the data may have changed such as days to date of first payment. So depending on when the loan is started and when the first payment date is, the calculations would be different.
2.3. Payment overdue
Depending on the particular type of loan, state or regional regulations, and company policies, loans are classified into different categories according to the amount they are overdue. For example:
Depending on the number of days overdue, the software must take various actions. For example, sending an Account Past Due letter to a borrower whose account is past due to remind the user to reach out to the lenders/creditors early to discuss the situation. The amount listed on the letter should include the late charges owed at the time the letter is printed and other details according to regulations. Different letters according to the number of days overdue should be sent out accordingly.