How much time should a tester spend testing every day?

Not so long ago, I went to attend a walk-in interview. While we were all waiting to be called, I struck a conversation with a test engineer who had also come to be interviewed. One of the things we talked about was the daily routine of this person. Here is a rough daily schedule:

9:00 a.m. Arrive at office and settle down

9:15 a.m. to 9:45 a.m. Check emails

10:00 a.m. to 11:00 a.m. Team meeting

11:00 a.m. to 1:00 p.m. Test the application (2 hours)

1:00 p.m. to 2:00 p.m. Lunch break

2:00 pm. to 3:30 p.m. Test the application (1.5 hours)

3:30 p.m. to 4:00 p.m. Log bug reports (0.5 hours)

4:00 p.m. to 5:00 p.m. Enter test results in the test management system and enter timesheet

5:00 p.m. to 5:30 p.m. Reply to questions on prior bug reports

5:30 p.m. to 6:00 p.m. Write status report for the day

6:00 p.m. Leave office for home

It shocked me. This person was spending 50% or less of his daily time on testing. This does not even take any ad-hoc meetings, training, test environment down-time or usual interruptions into account. If what this person said is true and it is a good representation of the daily schedules kept by testers in companies, I don't think it is okay. Why?

1. Testing software is the core function of a software test engineer. Most of the time should be spent on this important task.

2. Non-testing tasks e.g. team meetings, email exchanges and compiling test statuses are important but not at the cost of testing time.

3. Time should not be spent on redundant activities. A 10-minute stand-up summarizing what everyone did yesterday is fine but listening to the details of what each of the 10 team members did yesterday is not the best use of time.

4. There is duplicity of effort. If data is accurately entered in the test management/ project management system, it should be sufficient to produce any desired test status report.

However, a test engineer may not be able to guard his time because many of these non-testing tasks are driven by their managers. If a manager insists on long meetings and detailed status reports everyday, which task do you think would suffer? Yes, it is testing that would be impacted. It may not be as deep, wide or inspired as it could have been.

If you are a test manager, you may want to think about how to minimize the burden of non-testing tasks of your testers. Keep them accountable to find problems with the software while allowing them to focus on their core function. Most of the time.

How to be more successful in software testing interviews?

Hope that you liked my previous post, How to write a resume that is selected? If you are really interested in a position and they have short-listed your resume, the next step is to get selected in the interview :). Here is how to increase your chances of success in interviews.

 

A couple of thumb rules first:

1. For each interview you attend,

• Make the effort to understand (I mean internalize, not just read) the job description.
• Gather more information about the job, the project and the organization.
• Anticipate questions and prepare excellent answers ahead of the interview.

2. Interview more :)

 

Pre-interview

You should reach the interview venue well in time, go over your notes (see the 1st thumb rule) and relax before the interview starts.

Interview

Now is the time to use your preparation, thinking skills and communication skills. Every question you are asked is an opportunity for you to demonstrate your suitability for the position. When you answer a question, do not blurt out the first thing that comes to your mind. Understand the question and frame a very good reply in your mind before speaking. But don't take too long to respond; a pause of few seconds is okay. Provide specific details from your own experience. Aim to surprise the interviewer positively. Here are some examples:

Question. What tests can you design for a common object, say an office chair?

 An excellent response would highlight the test design approach as well as really good test ideas. For example, one could say that I would analyze the documented requirements, designs, contemporary objects, standards and use my own ingenuity to design the tests. Some test ideas would be:

1. Does the chair accommodate the weight of a large person for extended hours and continuous movement? Does the chair allow 360 degree movement, height/ back/ neck/ armrest adjustments? Is the chair comfortable? Ergonomic?

2. Is the chair good to see and feel? Does the color match the office decor? Does it require maintenance/ cleaning infrequently?

3. On being used daily, how long can it stay in perfect condition? What are the steps to install and adjust the chair? and so on.

 

 

Question. Can you describe a bug that you discovered?

 A good response would indicate the process used to find the bug and some details of the bug itself. The chosen bug should be a high severity bug (e.g. one impacting financial calculations, one affecting system availability to a large number of users), not caught by the pre-existing test suite and potentially disastrous if released to the customers.

 

Post-interview

This is the time when you have to judge the success your interview.

If you do not receive outright acceptance, it is possible that there is an objection. You need tact to get this from your interviewer. Possible ways to know the objection are:

1. Ask for the next steps and timelines - If there is an objection, you may get a vague response e.g. "We will get back to you".

2. Summarize each part of the job description and highlight how suitable you are with respect to each part. Note the reaction of the interviewer to each part keenly.

3. If required, be direct and ask for the objection.

 It may not be possible to remove the objection due to say salary/ position fitment, regulatory requirement (e.g. security clearance), customer requirement or specific instructions from top management. However if you truly feel that the objection can be removed, talk about it professionally. Hollow promises will not move a professional interviewer. Give examples from your experience when you faced a similar challenge and how you solved it. State your plan how you would remove the objection quickly.

 

If there is no objection and you are accepted, good luck with the new offer and congratulations.

In one of my prior projects, I was writing test cases (see my video, What is test case) with the deadline only a couple of days away. It made me anxious at the time and I put in longer hours to finish the task. But, I decided to later search ways to complete writing my test cases faster. Here are my thoughts for your benefit. Especially useful if you work on projects with very tight deadlines. See the video, How to write TEST CASES in manual testing with Example or read on...

How to write test cases faster?

1. "A picture is worth a thousand words."

Tables are a great way to consolidate test cases. Especially, when you have to test a number of combinations. Compare the ordinary version (TC1, TC2, TC3 and so on) with the tabular version (only TC1) for the login test case example.

When you use the table, your focus will shift from writing the sentences to designing the test combinations.

2. Refer other documents in your test cases.

If another document (e.g. a user manual) already lists the clear steps to perform an operation the application, you can refer the appropriate section within your test case. No need of pasting the section within your test case. This not only reduces your effort. It also makes your test case more maintainable. If the source document changes, there is no need to update your test case since it just contain a reference. However, the source document should be readily available.

You can also use this approach across test cases.

3. De-clutter your test cases.

Write only what is essential. Not one word more. Separate test data from test steps and expected results. This will allow you focus better on one item at one time. It will also make your test cases cleaner.

Nice side-effects of using the above approaches include:

a. Your test cases will be shorter and hence easier to read, understand and execute.

b. Your test cases will have less duplicity making them more maintainable.

c. It will be easier for you to review them to eliminate mistakes.

In short, not only will you take lesser time to write your test cases now, but your test cases will end up with higher quality too.

See also:

How to write effective test cases quickly? video
How to write a good bug report?

How to do better reviews? 

Tester role in agile software testing

How to impress your boss and team

How to compete against other software testing teams and win?