My 3 Mistakes In Early Career

I had started my testing career approximately 20 years back.

I did not attend any training course.

And there was no YouTube back then.

As my experience grew, I learnt. On the job. I learnt from watching others performing the testing. More importantly, I leant from mistakes.

My mistakes and others’ mistakes.

Most of the mistakes were small. Did not have much impact on the product.

But some mistakes where bigger. That led to defect escapes to production.

There are advantages on the flip side of it.

I learnt a lot.

They are life lessons, that is, I will remember them forever.

Today, I will give you my 3 mistakes in testing.

I will also explain what was the impact of that mistake. And then I will briefly explain, how I corrected it later.

I hope this helps you to avoid these mistakes.

Let’s dive in.

Assuming User Behavior

I was assuming somethings.

One of them was assuming user behavior. How user uses the application.

Long back, I was part of team, testing an Asset management product. It was used by the nuclear power generation companies.

One of the modules was creating a Purchase Order (PO) and then Works order.

PO was created by one department. And Works Order (WO) by another department. Sometimes they were not related and in some scenarios they were inter-related. That is WO was created on PO.

WO could be created by entering data in a form.

Other option was by scanning a bar code. When PO was scanned for bar code, the details of that PO would appear in the corresponding fields of WO.

In a scenario I had tested that.

But I assumed that, WO would be created only by data entry. That is, entering all the data in the WO creation window.

So I kept on performing same steps to create WO. Which was a pre-requisite to testing WO and its usage later. Every time I did same.

However when product went live, there were many issues reported by customers.

My Team lead told me that, most of them are related to WO.

I was shocked. Because I have tested them multiple times.

But, when I analysed the steps performed by users, I came to about my mistakes. Most of the times users were scanning the PO. That is physical (hard) copy of PO using hand held scanner.

All the fields were not populated, as expected.

Reasons were many- scanner could not scan properly, PO had incomplete data, scanner could not identify special characters, etc.

If I would have tested this scanning process more, then I would have avoided these production bugs.

Impact of this mistake was bigger. I had to analyze the issues, identify the root cause, explain the root cause to manager and development team.

Development team had to fix that quickly and make a patch release.

Again testers had to perform regression testing.

So, a mistake costed a patch release.

Then onwards, I stopped assuming the user behavior, how he/she uses the product.

I started noting the flows of each feature. Covered them in testing.

Lesson to you : Do not assume anything in testing. If in doubt, ask.

Also read: 7 Thinks I Hate As A Tester

Relying Only On Test Cases

I started my testing career with test cases.

There were some 500+ test cases already written by someone. The team lead asked me to go though the test cases once. Then asked me to run those test cases.

This was my KT (Knowledge Transfer) on the product !

So, I kept on running those test cases.

Whenever new feature is added to the product I wrote the new test cases in excel file.

I was given the test case template. So added test cases in that template and uploaded in the HP-QC (Quality Control) tool later called as ALM (Application Lifecycle Management).

Test case execution for new feature.

And test case execution for regression testing. This was my routine.

I thought this as ‘the testing’ activity.

One version of the product releases. After few days, many bugs were reported by users. I was wondering why?

I started analysing the those production bugs.

Tried to map them to our test cases. Much to the surprise, none of them were misses from test case point of view. But those scenarios were not covered in test cases !

Then I realised that test case execution is not enough.

I need to do more to uncover bugs.

So I started to think more negative scenarios, different flows. Also I started doing exploratory testing. Which yielded good results.

I could uncover more bugs.

Lesson to you: Do more exploratory testing. Know the product first.

Also read : Difference Between Test Case and Test Scenario

Improper Bug Reporting

While testing, I logged defects.

If I remember correctly, we were using the tool called ‘Lotus Notes’ for defect management. So, in that tool, I was used to report the defects.

I used to write the summary of the bug.

Then step where issue was reproducible and attached screenshots. That is it.

Then we used to have defect triage meeting once in two days. In that, developers started asking many questions- How did you test, which version of build has issue, which OS, etc.

And these questions were repeating.

Worse than that, many bugs were rejected.

Also read : Why Software Has Bugs?

Then I started worrying about my bug reporting. That led to all the additional communication, bug rejection, re-work, etc.

Figured out that I have to right a clear bug report.

Started adding following to bug report:

1. Clear summary
2. Detailed description
3. Steps to reproduce
4. Any additional observations
5. OS, Browser etc details
6. Screenshots
7. Video recording of the steps
8. Log files, wherever applicable
9. Linking bug to requirement
10. Linking bug and test cases
11. Build number of the product
12. Assigned to concerned Developer
13. Environment found (QA/Staging/Prod)

And then there were not much questions from developers.

Bugs were fixed quickly and new builds were smooth.

Lesson to you: Write detailed bug report. Do not miss any information.

Conclusion

As you can see, I have learnt on the job, from the mistakes. Some mistakes can be very costly. Some can be tricky. The mistake causes re-work, additional communication and some time bug escapes.

Learn from my mistakes and learn.

Be a great tester. Deliver quality products !

That’s all for now !

If you have any questions, ask me !

Want to discuss about your career? Call me 1-on-1