How to write Test Cases?

In Manual Testing, Testers will test the Application  by executing the Test cases manually  without requiring  any automation tools.  Manual testing will take significant time to cover all the requirements. So, it is very important to write test cases effectively to cover all the requirements while keeping number of test cases at  minimum level.  Let us  see how to write test cases  for testing an application.

What is  Test Case ?

Test case is “Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.” The  purpose of Test Case  is to divide the software function into small units of function that is testable with input, and producing result that is measurable.

i-e  A test case is a feature/function description that should be executed with a range of input, given certain preconditions, and the outcome measured against expected result.

These are the  fields commonly present in the Test Cases :

  • Test case id
  • Test Case Description
  • Procedure / Test Steps
  • Test data
  • Expected result
  • Actual result
  • Status ( Pass/ Fail)
  • Comments

Test cases should be simple and easy to understand for Developers.

Test Case ID :

This ID should be Unique throughout the Testing Application and not to change at any moment.

Test Case Description:

Explain the function under test. Clearly state exactly what attribute is under test and under what condition.

Prerequisites– Every test needs to follow a sequence of actions, which lead to the function under test. It could be a certain page that a user needs to be on, or certain data that should be in the system . For example  registration step should be completed before start testing login.

Procedure/Steps:

Sequence of steps to execute the specific function.

Test data:

Specify the data used for a particular test or if it is a lot of data, mention the path of a file where this data is stored.

Expected Result:

Clearly specify the expected outcome in terms of the page/ screen that should appear after the test, changes that should happen to other pages, and if possible, changes that should happen to the database..

Actual Result :

State the actual result of the function execution. Especially in case the test case fails, the information under ‘actual result’ will be very useful to the developer to analyse the cause of the defect.

Comments:

In this section you can add your reviews, suggestions and ideas to developers for the bug how we fix that.  Especially this section made to communicate with developers.

Test case writing procedure

  • Get as much information about the application as possible through available documentation (requirement specs, use cases, user guides) , tutorials, or by exercising the software itself (when available)
  • Determine a list of features and different user roles.

 

Say for example, if you are writing Test Cases for testing  this Timesheet Application.

First you should understand the features available in this timesheet application by reading the help files and other available documents about this timesheet application.

You should know about different user roles (e.g user, admin) involved in this application.

Once you gather all the details about this application, you can start writing test cases. Find below one sample, and you can show/test your test case writing skills by adding more test cases thro’ the comments section.

  • Test case id – LG01 (LG refer as Log In)
  • Test Case Description -Check Case sensitivity in  Log In Functionality
  • Procedure
  1. Load login screen by visiting http://qualitypointtech.net/timesheetdemo/index.php
  2. Enter valid username and password in Upper case.
  3. Click “Login button”
  • Test data – Username as user || Password as USER
  • Expected result – Alert box like CAPS LOCK on to warn the user
  • Actual result – But its not visible and accessing with uppercase letters.
  • Status ( Pass/ Fail) – Fail
  • Comments –  Password is an user’s choice so we can’t restrict so we have to give the warn or alert box or format that password should be like this.
Like wise, for each and every action we have to write test cases.

At the time crunch of any project, the testers simply go with the Adhoc Testing and Exploratory testing.

 

Manual Testing

Manual testing is the process of manually testing software for the errors and bugs in it. It needs a tester to play the role of an end user. At the time of manual testing tester need only test case and with the information how to execute those test case. Manual testing is crucial for testing software applications more thoroughly.

In today’s technical world, most of the software engineering projects rely on manual testing only as it involves a demanding and accurate testing procedure.

Manual testing involves high-level test plan where we choose a methodology, and resources such as skilled people, computers, and software licenses are identified and acquired. Detailed test cases are written by the tester clearly and perfectly, with the expected Results.

The test cases were given to the testers should follow all the steps and record the results. At the end, the detailed test report is prepared to determine whether the software can be released or not. If not mean they asked to developers to fix the bug which impact the other main modules.

Advantages of Manual Testing :

  •  Easy to learn for new people who are entered into testing field.
  •  Running the test case is less cost than automation.
  •  Allows the tester to perform more Ad-hoc testing .Using this more bugs are found than automation.
  • Its very difficult to go for automation testing for Mobile applications
  •  Manual testing cost is low but in automation it is expensive

Disadvantages of Manual Testing :

  •  Regression Test cases are time consuming if it is manual testing.
  •  Requires heavy investment of human resources.
  •  For every build release you must re run the same set of tests which can be annoying.

Start with an Test Cases Writing:

What is a Test Case ?

Test Case is an Writing Statement which contains test data, outputs, expected and actual result of the application which is tested accord to the Client’s Requirements.

These are the fields present in the Test Cases :

Test case id
Test Case Description
Procedure
Test data
Priority
Expected result
Actual result
Status ( Pass/ Fail)
Comments

While writing test cases that all your test cases should be simple and easy to understand for Developers. Don’t give your explanations like essays.

Best practices in Software Testing

There are lots of materials available in internet to explain best practices in Software Testing.

Here I am writing only the very essential things for medium level projects based on my experience/view point.

  • We should start our testing activities at beginning of Software development itself.
    Understanding Scope/purpose of the project will help to judge the degree/level of testing required.
  • Testers should go thro’ the requirements in detail without missing any points given by the client before writing test cases.
  • The test cases should be updated immediately once the client gives new requirement or changes the requirements.
  • The test case document should cover all the requirements even if some requirements are non-testable. These non-testable items should be marked as non-testable. Keeping traceability matrix document will helpful to achieve this.
  • The Test case document should help to clearly identify hierarchy/arrangement of test cases. It should have clear approach to arrange test cases if many test cases exist with similar steps. It is not advisable to copy & paste the similar test cases many times, instead we can specify only the additional/different steps.
  • Description of each test case should be written clearly after understanding the context/module of description. Steps should be written only after manually executing them. Expected results should not have any ambiguity. If required, Prerequisite/preconditions should be mentioned.
  • Planning and creating test plan document is essential even for small short-term projects. The test plan document need not contain all the details, but it should contain at least very basic components such as scope, schedule, risks, environments, testers
  • Planning of development/test/staging environments should be done clearly. And it is very important to move the code and maintain version of code in each environment without any ambiguity/confusion. Testers should know which version of code/data is available in each environment
  • Test execution should be done carefully based on the test cases. It is very important to use appropriate test data. It is better to create different set of test data during test case creation itself. The test data should cover valid format, invalid format and boundary values.
    Test result (pass/fail) should be clearly updated for each test case. It is good practice to mention Actual behavior if the test case fails.The test results should be communicated to the other parties (developers, business/client) daily even if all the test cases are not executed. In this case, we should add a note to indicate that the test execution is still in progress.The test execution summary document/mail should clearly mention date of execution, environment, test name and test result.
  • In case, most of test cases are getting failed continuously, there is no meaning of continuing the execution. Execution should be resumed once after fixing the major issues.
  • It will be nice if we highlight the testing status (pass, fail, yetToStart) in appropriate color. But anyway, just highlighting the test case with appropriate color without specifying status is not a good practice. Because while taking single color printout of the test report, it is difficult to see the status from the color.
  • It is good practice to do some adhoc testing in addition to the test case execution.
  • Clear/proper communication/co-ordination within the Testing team and also with other teams (developers, client/business) is very essential.
  • The bug report should be prepared very clearly with all essential details, especially with the steps/testdata for reproducing the bug. The bug report should help the developers to reproduce the bug and to fix it.
  • Doing re-test and small regression test is essential whenever a reported bug is fixed
  • It is not good if we do all the testing manually, as manual testing will take more time/effort and it is difficult to manage, and also it not consistent or repeatable. So it is better to automate the test cases using test tools such as QTP (Quick Test professional). Even we can use simple shell scripts and vbscript to automate some part of the testing.

Tips and Tricks for doing AdHoc Testing

It is always not possible to follow proper testing such as writing Test Plan and writing Test cases.
In some cases we may need to go with adHoc Testing because of time constraint or resource constraint.

AdHoc Testing is the part of Exploratory testing.It is done without doing Planning and Documentation.
Adhoc testing will help to find the defects earlier. We know that earlier a defect is found the cheaper it is to fix it.

Here I am listing some tips for doing adhoc testing effectively.

  • In case of UI (User Interface) testing, test all navigation including Back buttonnavigation.Go thro’ all the pages of the application to find any broken links and also make sure that each and every page is having proper links to reach other pages either directly or indirectly. And, notice the page loading time also. If it takes more time then try to narrow down whether it is due to network issue or web server issue or  the page issue.  i-e If the other domain webpages are loading normally then we can say that it is not due to network issue. And, if other pages in the same domain are loading normally then we can say that it is not related to server issue.
  • Check whether all the images are having alt attribute. And anchor tags should have title attribute.
  • See the application screen or webpage by changing/setting different screen resolution in your computer monitor.
  • Test the webpage in many different web browsers such as Internet Explorer, FireFox, chrome, safari, etc.
  • Test the tab order and default focus in all the pages. Especially study the behaviour of the application when it has more than one submit button.
  • Try to enter/save test data having special characters such as single quotes, double quotes and comma .
  • You can try to enter text with HTML tags such as < and > also in the textbox
  • Try to load an authenticated webpage directly by entering url in the browser without doing login.
  • Try all the possibilities of boundary values such as entering lot of data in textbox and entering negative values in numeric fields.
  • Remember to navigate the application from two different machines/browsers simultaneously; especially concentrate on to test concurrent database saving/updating operation.
  • If possible/necessary, test the application in different OS (Operating System) such as Windows, Linux and MAC.
  • If your webpage uses flash files, try to see the behavior of your webpage when it is loaded in a machine which is not having flash player. Normally it should automatically download the flash plug-in.
  • Instead of testing everything from your local machine, just try to test some screens by hosting your site in some remote machine. It will help to identify unexpected issues which may occur due to network latency.
  • Test Session timeout, Cookie expiry and script execution timeout.  For testing these things you should know about session and cookie. Session variables are stored in server side. They will be unique for each browser session. It will expire based on server setting. Cookie will be stored in user browser. It will expire based on the expiry time set while writing the cookie. But the user can manually also delete this cookie from the browser before it actually expires. Since user login status is mostly controlled using session and cookie variables, it is very important to test behavior of the system when the session or cookie expires.
  • Try to refresh your confirmation screen many times to verify whether the multiple refresh saves/inserts the data multiple times.
  • Test with different Date and Time format if you webpage/application has date and time entry fields. And, think about Time zone also.
  • Make sure that Number/Currency/Name format is correctly displayed in all pages uniformly.
  • When testing edit/modify/update feature, modify values of all fields and make sure that everything is getting updated correctly.
  • Whenever testing Delete feature make sure that all the related data also getting deleted. For example, when deleting question and answers also will be deleted.And, make sure that necessary constraints are enforced correctly. For example, deletion of questions should not be allowed if the questions are already used in some other modules.

Writing Good Test Cases and Finding Bugs effectively

To develop bug free software application, writing good test cases is essential.Here, we will see how to write good test cases.
Before seeing this, we should understand what is Good Test Case.There won’t be any solid definition for “Good Test Case”.

I will consider a Test Case as “Good” only when a Tester feels happy to follow the steps in the Test Case which is written by another Tester.Test Cases will be useful only if they are used by the people.

If a test case is poorly written with excessive unwanted steps, then most of the Testers won’t read it fully. Just they will read few lines and will execute it based on their own understanding which will be mostly wrong.On the other hand, if it is having fewer details then it is difficult to execute it.

As of now, I am thinking below things for writing effective Test Cases.

  • Before start writing test cases, become familiar with the (AUT) Application Under Test. You will become familiar with Application by doing some adhoc/exploratory testing.
  • We should read the requirements clearly and completely. If we have any questions in the Requirements it should be clarified by appropriate person (e.g Customer or Business Team). And also, it is good practice to gather some basic domain knowledge before getting into reading requirements and writing Test Cases. And also, we can have discussion/meeting with developers/business team
  • Very Important thing is, we should use only simple language or style to write the Test cases so that any one can easily understand without any ambiguity
  • Give meaningful and easily understandable Test case ID/number.
    For example, if you are writing Test case for testing Login module you can Test Case ID as below.1a – for testing positive scenario such as entering valid username and valid password.
    1b – for testing negative scenario such as entering invalid username and invalid password.By giving Test Case number as above instead of giving sequential number, we can easily add any new case such as below one without needing to adjust/modify number of any other subsequent test cases.1c- for testing negative scenario such as entering valid username and invalid password.
  • And also, if we have any similar module we can give separate sequence number for specifying the module.For example, assume that we are having separate login modules for User and Admin with little changes.
    In this case we can give number as below,
    1.1-First case in User module.
    1.2-Second case in User module.
    2.1-First case in Admin module
    2.2-Second case in Admin module.If Test Description/Steps/Expected Results of 2.1 is mostly same as 1.1 then we should refer 1.1 in 2.1 instead writing the sample details again.By doing like this, we can avoid redundant details to have clear test case document.
  • Test Description should be short and it should uniquely represent the current test scenario without any ambiguity.
  • In any situation, don’t use “if condition” in the Test steps. Always address only one scenario in one test case. It will be helpful to have unambiguous Expected Result.
  • Give some sample test data that will be useful for executing the test cases.
  • If the Test Case requires any Preconditions/prerequisite don’t forget to mention them.
    The best way is, we should arrange/order the Test Cases such that the need for specifying precondition is minimum.For example, we need to write test case for testing user creation, user modification and user deletion.For doing user modification and user deletion we should have already created user as precondition.If we arrange the Test cases in below mentioned order, we can avoid the need for specifying any preconditions/prerequisites.
    1-Test case for creating user.
    2-Test case for verifying duplicate/existing user when adding another user with same username.
    3-Test case for modifying user.
    4-Test case for deleting user.
  • Keep Traceability Matrix to make sure that we have written test cases for covering all requirements.
  • Once after completing all positive scenarios, think about all possibilities of negative scenarios to have test cases which will effectively find most of the bugs.For doing this we can refer alternate flow section of use case document, and we can think about different data, boundary conditions, different navigations paths and multi user environment.
  • In the test case document, we can give link to screenshots explaining the steps and/or expected results with pictures. But anyway, it is not good practice to place the screenshots within the Test Case document itself unless it is very essential
  • Many tools are available to capture the screenshots with user action as video. We can make use of them to keep video explaining the steps and expected results clearly in case the test case requires any complex steps. We can give link to this video from the test case document.