How To Prepare Yourself For Test Case Writing [Productivity Tips]

In this article, you will learn in detail how to prepare yourself for test case writing and improve your productivity. Let’s get started. 

When a tester decides to write high-quality test cases and wants to improve their efficiency as well as the productivity of test case writing, there are a few key points that help the testers to achieve these goals.

How To Prepare Yourself For Test Case Writing

First, they need to prepare themselves professionally and psychologically with some of the key points necessary for every successful software tester in the IT industry. This will be treated as “Inputs” for a tester before starting to write test cases.

Then, they need to understand the quality metrics involved in the project, which is used as a tool for evaluating the tester’s performance in various phases of the testing life cycle. This will be treated as “Outputs” for a tester after completing test case writing.

Finally, the tester needs to know how the bug is reported, issues are escalated and how the test reports are prepared to align to the standard procedure and can be understandable by the stakeholders of the project.

Prepare for Test Case Writing

1) Test case writing is an art and is not just a job or task. A piece or segment of software can be designed and developed, but until and unless it is completely tested for all scenarios with an efficient test approach, it will be useless and not eligible to be released and used by anyone. So, treat yourself as a critical person in the project and treat your testing activity as an important task in the project.

2) The passion with a positive attitude, which is the utmost personal quality testers should have throughout the project life cycle. Passion motivates team building capabilities and attitude brings great productivity in writing quality test cases. The test writing activity is a blend of professional and personal qualities for a common goal of achieving great results as a final output in the project.

3) Positive and negative test cases are part of writing test cases, but the testers should have a semi-positive mindset to break the application under test through finding bugs. This is not a negative mindset, rather avoiding the situation of identifying a bug by someone after release or avoiding the situation where the system will be broken by some users of the system.

4) Tester’s Efficiency should not be estimated based on the number of bugs identified in the system under testing, but on the capabilities of writing successful test cases that result is the discovery of the defects. So, the test cases should be written in such a way that the coverage and traceability should be maximum based on the system boundary and scope.

5) Understand the application Domain thoroughly. For example, testing a website is easier than testing a financial software developed for stock exchange being utilized by thousands of people at the same time. Simple website functionality can be understandable by any tester whereas the financial terms and functionalities cannot be understandable by all the testers until and unless they have the relevant educational background or training or have domain experience.

So, when a tester is being allocated on a new project, he/she should do a self-assessment, whether they are eligible and can perform their job as per the expectations or not. If the functional requirements are tough to understand, it should be escalated to the project team well in advance to avoid future misconceptions on the tester’s efficiency and performance. This will be handled by the project manager or the test manager through proper planning and training.

6) The project requirements and types of testing to be performed varies from project to project. The tester should be prepared to do any kind of testing. Don’t limit your capabilities to your skills and specialties. Be prepared to take on responsibilities and challenges in writing and executing test cases for any type of testing.

Many testers try to adapt or project themselves as only manual or automation testers. When it comes to performance testing, load testing or stress testing very few testers are taking the roles and preparing themselves by training or gathering the required knowledge. So, be a quick learner and be ready to take on responsibilities and grow in your career.  

7) Identify the types of testing to be performed and the skills required for testing the AUT. For example, some projects require only black-box testing and some require white box testing skills. The knowledge of “scripting” or experience in “SQL” or working with “mark up language” like HTML/XML etc., or even system knowledge on how to install/troubleshoot software, etc. are some project-specific requirements you must learn yourself or get training for the same.

8) Ensure that the test cases cover Performance testing, Security Testing, and Regression Testing types. For example, to login to the application using the login screen given below:

• Performance testing may be required to check whether the application is stable when 1000’s of users are logged into the system at the same time, and the test cases should be written to cover this scenario.
• Security testing may be required to check whether the application is only allowing users with proper rights and permissions to be authorized to use the system, and the test cases should be written to cover these scenarios.
• Regression testing may be required to check if the core functionality and critical features are working properly on every release.

9) Test Case Review: One of the most important and the most overlooked phases of any software development and the testing life cycle is “REVIEW”. When a project plan includes enough time allocation for a review process at each and every stage of project development, we can expect the highest quality deliverables and outputs for the same.

For instance, before starting to write test cases, testers should check if the “requirements specification” document is reviewed and all the review points are considered and updated in the document. If the organization is following a proper and mature process, all document templates should have this change information on the first page of the document itself.

Test Case Documents should be reviewed at least 3 times through:

i) Self-review
ii) Peer review
iii) Review by others for completeness, test coverage, traceability and whether the test case is testable or not.

10) Finally, understand how to estimate and plan the testing tasks. Plan to work only for the scheduled estimated time of the day. This can be achieved by starting and completing the tasks on time and leaving for the day with the plans for the next day’s tasks.

Avoid staying up late at night and spending weekends in the office. Currently, efficient project management approaches are available and projects are being executed in an Agile environment. If milestones are not achieved by the project teams, it will be treated as inefficient project management rather than inefficiency from the project teams.

Note: Keep in mind that even for automated testing, test cases should be clearly written and reviewed at least once, completely covering the functional flow of the application under test. Any automation testing tool can record and execute test cases successfully only when the manual test cases are clearly defined and written.

Quality Metrics

This is an important activity in the software testing phases. The testing team should be completely aware of the various testing metrics used to achieve the project goal. The tester’s performance is not evaluated based on only the test execution phase but from all the test metrics collected from requirement analysis, test case writing, execution, defect reporting and final test reporting phase.

Find below a few important test metrics followed by most organizations for better productivity of testers and the efficiency of testing phases.

Also, see other useful test metrics used in the testing phases

=> Important Software Test Metrics and Measurements, Live Project Bug Tracking, Test Metrics, and Test Sign off process.

1) Average Testing Efficiency

• Bugs per man – months of the testing effort.
• Calculated as Average (Total bugs during testing effort in man-months).
• To be calculated after every internal release as well as after test completion.
• Acceptance Limit: should be less than 50

2) Average Customer Defect Density

• Bugs reported by the client after delivery vs total testing efforts in man-months.
• Calculated as Average (Total bugs after delivery/testing effort in man-months).
• To be calculated after external release and project completion.
• Acceptance Limit: should be less than 1

3) Functional Test Failures

• Number of failed functional test cases / Total number of executed functional test cases.
• To be calculated monthly or fortnightly.

4) Bugs with Severity Level 1

• The total number of bugs identified with severity level 1 (blocker).
• Testing cannot be continued for the software due to blocker issues.
• To be calculated on a weekly basis.

5) Bugs with Severity Level 2

• The total number of bugs identified with severity level 2 (major bugs).
• Testing cannot be continued for the feature due to major bugs but can continue with other parts of the system.
• To be calculated on a weekly basis.

6) Bugs with Severity Level 3

• The total number of bugs identified with severity level 3 (minor bugs).
• Testing can continue as the identified bugs are minor and will not stop testing.
• To be calculated on a weekly basis.

7) Bugs with Severity Level 4

• The total number of bugs identified with severity level 4 (cosmetic issues).
• Testing can be completed without any issues as the identified bugs are cosmetic related and to be fixed for the next release.
• To be calculated on a weekly basis.

Bug Reporting

Bug Reporting mechanism should be controlled with a matured test process to maintain the application quality. There should be a proper escalation process for the right authorized persons to know the status, severity, and priority of the bug. There are a number of free and commercial bug reporting tools available like Bugzilla, Mantis, etc., which are very effective in issue tracking mechanism and can be integrated easily with any test management tool used in the project.

In each and every testing project, standard procedures need to be followed for an online status reporting mechanism on a daily basis. Any bugs/issues logged and reported in these bug tracking systems should immediately send an email to the respective authorities which will help them plan and take action accordingly.

To learn more about the bug reporting process in detail, read the following articles

=> How to write a good bug report? Tips and Tricks
=> Sample bug report
=> Why Bug Reporting an Art That Should Be Learned by Every Tester?
=> Bug life cycle
=> Sample bug reports for web and product applications

Test Reports

Apart from the bug reports raised, logged and escalated in the bug reporting system, a test report is one of the most important documents to know the status of testing and other important metrics identified and calculated during the span of test reporting time.

One such simple test report is given below.

Also, read the following useful tutorials for effective test reporting:

=> Guide to Write an Effective Test Summary Report
=> How to Report a Test Execution Smartly [Download Status Report Template]

Conclusion

The process of preparing for writing test cases is not only just an allocation of resources in the project, but there are a few key requirements like preparing ourselves as an eligible tester and understanding the quality metrics being monitored throughout the testing life cycle and even after the release.

So, following the process, standards, procedures and strictly adhering to the quality metrics with passion, can automatically bring great testing efficiency, productivity and a quality tester in you, which can become a habit in your professional life.

These quality factors can be analyzed by oneself or in a group by asking a few questions, like the ones given below which will tell whether we are on the right track of self and process improvement in the goal of achieving an efficient approach in test case writing and execution.

• Have you gone through the functional requirements/user requirements/business use case documents?
• Has the functional requirements document been reviewed and updated properly with review comments?
• Have you received the screen prototypes for all the features to be tested?
• Are you comfortable writing test cases that are testable and traceable throughout the testing life cycle?
• Do you have the required skillset and domain knowledge to test the application under test?
• Do you need any training or technical knowledge required for executing the test cases?
• Do you have a schedule for writing, reviewing and executing test cases that covers the time needed to prepare quality documents?
• Do you have peers to review your test cases and an authorized subject matter expert to check the completeness and coverage of the features and functionalities to be tested?
• Do you have enough test cases for all the functional requirements?
• Do you have enough test cases for performance, load testing, and security testing?
• Do you have enough test cases for installation and regression testing?
• Do you have the point of contact for escalating issues or reporting bugs?
• Is the bug tracking tool configured properly with all the required permissions?
• Are you comfortable following all the processes defined in the test plan?
• Are you being involved in all review meetings and getting a chance to talk to the development or management team?
• Has your productivity and efficiency improved or do you need to take any measures for the same?

Recommended reading =>> Best Online Creative Writing Courses 

There are a lot of similar questions testers may ask themselves for self-improvement analysis, depending upon the type of project or the organization they are working with. The most important thing is that all these activities should not be followed just for the sake of following the processes but should be made a daily habit which can be done through PASSION FOR TESTING only.

What do you think? Post your feedback in the comments section below. We would love to hear from you. 

PREV Tutorial | NEXT Tutorial