Sunday, February 27, 2011

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.

Sunday, February 13, 2011

How to write test cases faster?

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 effective test cases quickly? 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.

Sunday, February 6, 2011

How to write a good bug report?

Bug reports are one of the most important work products in software testing. View my video, How to report bugs effectively - with sample bug report, or read on.

We know that a truly great bug report is the result of thorough isolation of the bug and its accurate documentation, among other things. But, it is very common to have a tight schedule. So, the software tester may not be able to spend too much time on perfecting the bug report. If they do, they run the risk of not being able to complete the planned tests in time.

In this common project situation, if you want to write a high quality bug report every time, just focus on getting the basics right. Use the following checklist to ensure the quality of your bug report. Note that few data items in your bug report may be static in a single test run. It is useful to create the bug report as a local document so that you can reuse as much of the existing data as you can.

1. Does the title of your bug report accurately summarize the issue?
2. Is the application name (and component name) mentioned?
3. Is the application version and build mentioned? Note: possible static data
4. Does it have the requirement (required behavior)?
5. Does it have the steps to reproduce the issue? Note: If you have a written test case that failed, you can paste that test case up to the step which failed.
6. Does it mention the observed behavior? Note: You can use screenshots or video clips here.
7. Does it mention all the data required to reproduce the issue?
8. Is the severity correct?
9. Are the name/ address (e.g. URL) and configuration (hardware and software configuration) of the server mentioned? Note: possible static data
10. Is the client configuration (e.g. O/S, browser) mentioned? Note: possible static data
11. Is it assigned to the correct team or person?
12. Is it copied to the correct people?

Out of the above data items, I consider title, steps to reproduce, observed behavior and required behavior as most important.

You can take the above checklist and customize it to your project needs. Execute the checklist to review your bug report before submitting it. This way, you would double-check that your data is correct and that no important data is missing. Ensure that you write a high quality bug report every time.