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

How To Prepare Yourself For Test Case Writing And Improve Your Productivity:

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

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

Next, 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 in 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 a segment of software can be designed and developed, but until and unless it is completely tested for all the scenarios with an efficient test approach, it will be useless and not eligible to released and use by anyone. So, treat yourself as an important 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 the team building capabilities and attitude brings great productivity in writing quality test cases. Means, 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 having 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. It will be handled by the project manager or the test manager through proper plans and training.

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

Many testers try to adapt themselves or project themselves as only manual or automation testers. When coming to performance testing, load testing or stress testing very few testers are taking the roles and prepare themselves by training or gathering required knowledge. So, be a quick learner and be ready to take 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 a system knowledge on how to install/troubleshoot installation of the software, etc. are some project-specific requirements you must learn yourself or get training for the same.

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

• Performance testing may be required to check whether the application is stable when 1000’s of users are login to 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 having 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 phase of any software development and the testing life cycle is “REVIEW”. When a project plan includes enough time allocation for a review process on each and every stage of project development, the most quality deliverables and outputs we can expect 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 matured process, all the 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 in a 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 late nights and spending weekends in the office. Nowadays, 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, 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 for achieving 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 cases writing, execution, defect reporting and finally test reporting phase.

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

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

=> Important Software Test Metrics and Measurements and 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

• A 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 the 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 the major bugs but can be continued 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 be continued as the identified bug are minor and does not stop the 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 to the right authorized persons to know the status, severity, and priority of the bug. There are many 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. Every bug/issue logged and reported in these bug tracking systems should immediately send an email to the respective authorities which will help them plan and take actions accordingly.

To learn 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 is 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.

Below is one such a simple test report:

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

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

Conclusion

The process of preparing for writing test cases is not only just allocation of resources in the project, but there are few key requirements like preparing ourselves as an eligible tester and understand 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 will become a habit in your professional life.

These quality factors can be self-analyzed or group analyzed by asking few questions 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 in writing test cases which 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 the schedule for writing, reviewing and executing test cases, which covers the time for preparing quality documents?
• Do you have the peers to review your test cases and an authorized subject matter expert for checking 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 the issues or reporting bugs?
• Is the bug tracking tool configured properly with the required permission to all?
• Are you comfortable in 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?
• Are 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 as your daily habits which can be done through PASSION FOR TESTING only.

PREV Tutorial | NEXT Tutorial