How to

What is in a Test Case?

As we all know, a Test Case is an important instrument in Software Quality Assurance (SQA). For the benefit of those aspiring for a career in SQA, I’d like to explain why writing good test cases is imperative, and go on to describe the key elements in a good test case template. But before I go into details, let me firstly define a test case.

Test case is a document that describes an action or an event in a software app, and the expected response for that action based on the given input. It determines whether the features of the application are working to the expectations of the end users. A collection of test cases is called as a Test Case Document. A test case consists principally of many specifications such as the Test Case ID, Description, Steps, Inputs, Expected Results and Pass/Fail criteria.

So why do we need a Test Case Document?

1. To identify gaps in business requirements at an early stage of development
In SQA Practice, it is recommended to start writing test cases in the early stages of the development lifecycle, as it can help you identify problems in the requirements or design of an application. For example, if we are unable to figure out a test case (or test cases) for a given requirement, the requirement is probably too broad to be coded. It would force the product owner to go back to the drawing board and refine his or her statement of requirements.

2. To optimize testing effort
Writing test cases requires us to “think through” the entire app upfront from a functional perspective and ensure we don’t miss out on test scenarios during actual testing. Whilst ad hoc testing is a critical component of any testing exercise, deadlines and ill-thought functional boundaries by newcomers to the team at the last minute may cause us to skip checking vital functional pathways in an app. This problem is avoided when the test cases are documented. On the other hand, having test cases also helps us from repeatedly covering the same ground and wasting time; for example stepping through the login functionality many times in an app that doesn’t have CAPTCHA secured login. By spelling out exactly the necessary maximum scenarios to ensure 100% functional coverage (I use the word functional here in a broad sense, inclusive of performance, usability and other relevant testing scopes), one can save time.

3. Instill confidence in a release
When a release is tested and a set of test cases are marked as “passed”, “failed” or “not run”, everyone in the team has a clear idea of where the release stands in terms of quality. Stakeholders can make an easy judgment call about whether to push a release to Live, or to hold off for bug fixes, when under pressure due to the business urgency of the release. If one relied on ad hoc testing, one has to depend on the gut feeling of the testers, and there is no formal accountability for the quality of a given release.

4. Easy to scope-down one’s testing effort
Having test cases will help you to identify the most critical functional pathways of an app. So it offers us the advantage when under a time constraint, to intelligently scope-down the testing effort, to cover the most relevant testing areas for the release.

Types of Test Cases
We can categorize test cases based on their purpose within the SQA lifecycle. Three of the most frequently used test case types are:
1. Functional Test Case –  a test case which steps through new functionality in the app
2. Regression Test Case –  test case that is executed to identify the impact from changes to existing functionalities
3. Smoke Test Case –  a summarized test case or a check list item which is executed to identify whether the build is stable and can be accepted for further testing

How to improve Test Case Management
Due to simplicity and cost, most small software companies write test cases in Word or Excel document formats. However, there are many Test Management Software tools available in the market such as Mercury Quality Centre, QA Complete, or even open source tools like TestLink.

What is the Calcey Test Case Template?
Calcey Technologies follows industry standards for testing, and shown below are the essential elements in our Test Case Document template, that any newbie to SQA can study and master.

 

Field Name Guideline Example
Test Case ID To uniquely identify a test case, when referring to it in project communication.Give the prefix/section# given in the Functional Spec document. This will facilitate mapping the traceability and identifying any missing test cases.

Note: The test case IDs need not be just sequential numbers like 1,2,3,4 etc.

Functional Spec document:5.1 Login In
Test Case document:
5.1.0.1 for the first test case
5.1.0.2 for the second test case
Category Two categories, UI and FUN.UI: UI test cases check the screen layout and all page elements presence.

FUN: Functionality test cases cover all the user actions belonging to a particular function. This ensures that the System works as intended or accepts all the valid inputs, which is supposed to be accepted.

Feature Description This is the Test Case name. Write the Test Case Name in simple present tense.1. UI category:

Feature/Functionality name.
2. FUN category:

2.1: Feature/Functionality name-Valid-<User actions if any>
For example: Add user-Valid-Submit

2.2: For invalid test case combinations: Feature/Functionality name-Invalid- <User actions if any>
For example: Add user-Invalid-Submit

2.3: For any Cancel/Abort action: Feature/Functionality name- Cancel
For example: Add user-Invalid-Submit or Add user – Cancel.

Try to cover each user action in a separate test case.

1. Scenario: Verify labels in the Login screenUI: Login Screen-Labels
2. Scenario: Verify Valid User Login to the System
FUN: User Login-Valid
3. Scenario: Verify Invalid User Login to the System
FUN: User Login-Invalid
4. Scenario: Verify Cancel button in Login screen
FUN: User Login-Invalid-Cancel
Negative/ Positive Scenario This is a mandatory field, which has to be filled at the time of writing the test cases.This is to differentiate happy scenarios and negative scenarios.
Prerequisite Any activity that must take place prior to executing the test cases.If we are using previously executed Test

Cases as pre-conditions, always use the cell reference of the corresponding test case.

When writing pre-conditions, if a user is involved in the action, state the actor(s) name mentioned in the UC. (E.g. System Admin, Us
er)

Write the pre-requisite in past tense.

1. Adobe Reader 8 must be installed.2. User is logged in to the system.
Test Steps This is a mandatory item in test cases.These are the steps used to execute the test case. Each step in the “Test Procedure” has to be numbered and placed in a new row.

The numbering format should be as follows:
1.
2.
Write the steps in simple present tense.

1. Click on the Next button2.Enter a valid security question
3. Enter the address
4. Click on the OK button
Input Data List data to be entered into these fields in order to execute the test case.Alternately, you may point to a separate excel spreadsheet that contains the input data values used for testing.

If you do not know the input data, keep it as “<TBD>”.
If there is no input data for a particular test case, include “N/A” in the cell.

Do not leave this column blank.

Admin User Login = [email protected] Name = <TBD>
N/A
Expected Results This is a mandatory item in test cases.For each test step the predicted outcome should be documented under expected results. Without this step, the tester may not know whether the test case is a pass or fail.
It’s better to use the word ‘should’ when writing the expected results, since ‘should’ is used to indicate that something is expected.
1. Segments should be displayed when the user clicks on Organize tab.2. System should display the error “User Name cannot be left blank” 
Multiple Target Apps Today we often have mobile and web apps that are complementary and represent the same system under testing. In such cases, one must clearly mark whether the test case must be repeated for several user interfaces or devices prior to passing or failing. App1, App3
Automated Indicates whether the test has been automated or is performed manually.You can also give the name of the script for easy traceability.
Status (Passed / Failed) Initially left blank. This is a mandatory field that has to be filled at the time of execution of the test case.All tests executed should be marked as either passed or failed.

If a test case cannot be executed due to any reason, then it should be marked as “Not executable” or “Differed”, with a Comment.

Defect ID This is a mandatory field that has to be filled at the time of execution of the test case.For each test step if there is any deviation from predicted outcome then that should be documented in the defect-tracking tool (such as JIRA). Then the Defect ID generated for the defect by the tool has to be documented here.
Build Number This is a mandatory field that has to be filled at the time of execution of the test case.This is to differentiate the test cases for different builds.
Use Case Spec Reference This is not a mandatory field.Document any other Functional Spec document or Use Case references here.
Comments Any comments to elaborate a situation that cannot be represented via standard fields.
InterviewsLife at Calcey

Careers at Calcey, an engineer’s story

Rajitha Egodaarachchi is a software engineer working for Calcey Technologies; a Colombo based offshore software development facility catering to clients in the San Francisco bay area. Rajitha has been a fast track performer and was recently nominated by his managers for a promotion as a senior software engineer, in recognition of his abilities and dedication. I caught up with Rajitha during his afternoon tea break on Friday, 02-Nov, to learn more about his work experiences and interests.

Sanduni: Welcome to the interview, Rajitha, and congrats on your upcoming promotion. Tell us a bit about yourself.
Rajitha: Thanks Sanduni. Well, I’m a software developer working presently for Calcey Technologies. I’m 24 years old, and a graduate in IT. I’ve been working at Calcey for the past two years.

Which university did you study, and what subjects did you major in?
Rajitha: I got my degree from Curtin University, Australia offered offshore through SLIIT campus in Malabe, back in 2010. It was a”general degree”  in Information Technology. The subjects I studied however were focused towards software engineering.

Sanduni: Why did you pick software engineering as a career?
Rajitha: I had a passion for this subject from my school days. I got to do a lot of interesting little software projects while at the IT Club of St. Peter’s College, which ultimately paved the path for my working in the software development sector. I’s the buzzword of our time and whatever we do ends up having an information technology component in it. People literally hangout in cyberspace today, like on Facebook or Twitter, and almost every business we can think of can potentially be on the Internet. So I thought that specializing in this area would make my life interesting. The software industry is booming with new inventions every day.

Sanduni: Indeed. So why did you decide to join Calcey Technologies?
Rajitha: Well, a few companies called me for interviews. As soon as I got into the premises of Calcey I felt like it had the ideal environment for me to begin my career. I always wanted to join a “not so big” company that is well established in the trade. Calcey is a sort of boutique firm, where seniorfolks are always available for brainstorming, where there is easy access to resources, including Facebook and YouTube [laughs], and where the salary scales are good. Besides, I saw that we could play games in the evening or even shoot each other with NERF guns! I just loved the “developer-friendly” environment that I was introduced to.

Sanduni: What was the first project you worked in? Tell us what the experience was like..
Rajitha: It certainly was challenging. I landed on a C# project called Vertical Platform (later I got to know it as one of the coolest projects to work at Calcey). I was a new entrant to the industry… even though I was working at HSBC previously I had minimal development experience. So I had to work a lot harder to understand the requirements, the design concepts, and basically everything that is expected from the role of a Software Engineer. There were tons of stuff to learn, ranging from configuration management using GIT, to how to keep my cool under pressure.

Sanduni: How would you describe the work environment at Calcey?
Rajitha: Very appealing. Resources ranging from books to laptops are always available without restriction. We have an ethical, heterogeneous setup, and maintain high standards in terms of the industry practices. You can always speak to the management about issues. Plenty of stress relieving activities is available like computer games, foosball, carom or even a small in-house gym. You will find peers always giving out a helping hand as well as experienced seniors mentoring us with new concepts. Everyone’s informal and on a first name basis. The leads are also straight talking, and will point out your mistakes openly and often [laughs].

Sanduni: So Rajitha, what are your hobbies and interests? How do you make it all worth it personally?
Rajitha: I play computer games, sleep [laughs], swim, dance and work on personal R&D projects in my free time; I just hang out with friends on weekends. We do pub and club once in a while and all the latest movies are watched by us!

Sanduni: Great! Ok so do you really like your job? I mean, what improvements do you expect to see in your career in the future?
Rajitha: Yes I do like my job. The job I currently do is the profession I wanted to be, it goes without saying. Moving forward, once I grasp the engineering aspects completely, I would seek to manage projects. Thus I’m looking forward to beginning my postgraduate studies in the coming months. I think it will be helpful with my long-term career.

Sanduni: What was your learning experience like at Calcey itself?
Rajitha: Calcey practices Scrum, the most successful agile project management methodology that I know of, and I’m proud to have adjusted to an agile mindset. I also had to learn Objective-C and iOS development in double-quick time. It’s easy to switch between programming languages here, as there are experts in the domain that you can learn from. SQL, asp.net, MVC, iOS and JavaScript are a few areas of expertise that I tapped into, but I am aware that we also use other languages and frameworks like Python on AppEngine or even older technologies like ColdFusion.

Sanduni: What’s your best moment at Calcey? Is there anyone particular incident that sticks in your mind?
Rajitha: I’ve nothing in particular to single out, but the zillion birthday parties, farewell parties, trips outstation and hangouts are equally memorable for me. We are getting ready for a birthday party this evening, as you know…

Sanduni: Okay. Is there any advice you’d like to give to a newbie joining the industry?
Well, being a newbie myself just over two years back, I certainly felt the stern pressure put upon me when working towards deadlines coding complex features. Looking back after two years, the experience that one gains the hard way would be the best one could get, and would lay the foundation for a long and successful career that awaits you. Never be afraid to work hard, and play hard!

Sanduni: Thank you for your time Rajitha –  and good luck!