Entries Tagged 'How to be a good tester' ↓

This is a phrase that you come across dozens of times a day, ‘Creative Thinking’ or ‘Out of the Box Thinking’.

Do we know what it actually means when we say ‘Thinking out of the Box’?

As per Wikipedia:

“Thinking outside the box is to think differently, unconventionally or from a new perspective. This phrase often refers to novel or creative thinking”

But the above definition could be extended when we relate it to our field, Software Testing.

When we step into the field of software testing the first thing we are taught or we learn are the Two Continue reading →

You must be impressed with the ‘Idea’ AD and this time it is back with the ‘Walk when you talk’ idea. Abhishek Bacchan, who appears as a doctor in ‘Walk when you talk’ AD, this is a definitely out of an ordinary AD, but then, I wouldn’t expect anything else from the “Idea” AD; I love to see the AD and it’s one of my favorite AD since it’s place in line with my emotion and I hope with some of yours emotion as well.

Is it just an AD in changing the health and mind-set of people or an AD to increase the mobile connection sales?
Continue reading →

Novice testers have many questions about software testing and the actual work that they are going to perform.  As novice testers, you should be aware of certain facts in the software testing profession.  The tips below will certainly help to advance you in your software-testing career.  These ‘testing truths’ are applicable to and helpful for experienced testing professionals as well.  Apply each and every testing truth mentioned below in your career and you will never regret what you do.

Know Your Application
Don’t start testing without understanding the requirements.  If you test without knowledge of the requirements, you will not be able to determine if a program is functioning as designed and you will not be able to tell if required functionality is missing.  Clear knowledge of requirements, before starting testing, is a must for any tester.

Know Your Domain
As I have said many times, you should acquire a thorough knowledge of the domain on which you are working.  Knowing the domain will help you suggest good bug solutions.  Your test manager will appreciate your suggestions, if you have valid points to make.  Don’t stop by only logging the bug.  Provide solutions as well.  Good domain knowledge will also help you to design better test cases with maximum test coverage.  For more guidance on acquiring domain knowledge, read this post.

No Assumptions In Testing
Don’t start testing with the assumption that there will be no errors.  As a tester, you should always be looking for errors.

Learn New Technologies
No doubt, old testing techniques still play a vital role in day-to-day testing, but try to introduce new testing procedures that work for you.  Don’t rely on book knowledge.  Be practical. Your new testing ideas may work amazingly for you.

You Can’t Guarantee a Bug Free Application
No matter how much testing you perform, you can’t guarantee a 100% bug free application.  There are some constraints that may force your team to advance a product to the next level, knowing some common or low priority issues remain. Try to explore as many bugs as you can, but prioritize your efforts on basic and crucial functions.  Put your best efforts doing good work.

Think Like An End User
This is my top piece of advice.  Don’t think only like a technical guy.  Think like customers or end users.  Also, always think beyond your end users.  Test your application as an end user.  Think how an end user will be using your application.  Technical plus end user thinking will assure that your application is user friendly and will pass acceptance tests easily.  This was the first advice to me from my test manager when I was a novice tester.

100% Test Coverage Is Not Possible
Don’t obsess about 100% test coverage.  There are millions of inputs and test combinations that are simply impossible to cover.  Use techniques like boundary value analysis and equivalence partitioning testing to limit your test cases to manageable sizes.

Build Good Relations With Developers
As a tester, you communicate with many other team members, especially developers. There are many situations where tester and developer may not agree on certain points.  It will take your skill to handle such situations without harming a good relationship with the developer.  If you are wrong, admit it.  If you are right, be diplomatic.  Don’t take it personally.  After all, it is a profession, and you both want a good product.

Learn From Mistakes
As a novice, you will make mistakes.  If you don’t make mistakes, you are not testing hard enough!  You will learn things as you get experience.  Use these mistakes as your learning experience.  Try not to repeat the same mistakes.  It hurts when the client files any bug in an application tested by you.  It is definitely an embracing situation for you and cannot be avoided.  However, don’t beat yourself up.  Find the root cause of the failure. Try to find out why you didn’t find that bug, and avoid the same mistake in the future.  If required, change some testing procedures you are following.

Don’t Underestimate Yourself if Some of Your bugs Are Not Fixed
Some testers have assumptions that all bugs logged by them should get fixed.  It is a good point to a certain level but you must be flexible according to the situation.  All bugs may or may not be fixed.  Management can defer bugs to fix later as some bugs have low priority, low severity or no time to fix.  Over time you will also learn which bugs can be deferred until the next release.  Read article on ‘How to get all your bugs resolved‘.

Over To You:
If you are an experienced tester, what advice do you like to give to novice testers?

This is a guest article from Pradeep Soundararajan. He is a Consulting Tester, Satisfice Inc & Software Testing Magician. Reach him at his blog Tester tested

These days a lot of people who pass out of engineering and science colleges are interested about software testing as a career. When I passed out at a time when the IT had started to boom back in India, most of the fresh graduates with whom I interacted didn’t even know there existed jobs or careers like software testing.

I was offered a job as a tester in a start up for 7440 rupees a month compared to fresh developers (who were picked from better institutes from where I graduated) being paid 34,500 rupees a month.

Continue reading →

This article is the part software testing question and answer series. Here I will answer some reader’s questions asked to me in comments or using contact form. If you have queries on software testing, quality assurance or career in testing then you can ask me these questions in comment section below.

It’s not possible to address each and every question in detail as I observed the questions are on vast topics, for which detail answers will itself require a new article. I will answer such questions in brief here and will also write detail articles separately if required.

So let’s get some questions answered:

Naresh A. asks:

“My past experience was related to “Test Engineer”. Recently I am appointed as Test Lead in a product based company. Currently there is no Pre-established testing process. As a TL am meant to define a standard process for the entire testing flow and I will maintain certain documents for each product.
Can you help me out in establishing a process for testing, and make me know the entire responsibilities of TL and what documents I am supposed to prepare and maintain?”

As a team leader you are responsible for project planning, scheduling, communicating your project status to your manager and most important task of assigning and monitoring the project work. Your main responsibility is to build a team to achieve your project goals. You need to focus on handling the challenges in your project so that your team and project will grow and perform well.

As far as the standard testing process is considered, it’s depends on you – what procedure you want to establish. Yes some people might blame me for this point but I prefer to establish my own processes that work for me. I don’t stick to those old process definitions that are written and managed in some 90′s and most of which might not applicable nowadays.

Test lead is responsible for ensuring project plan changes are incorporated in test plan. You might write a test plan and test strategy (In some cases it might be written by senior test team member or even by project test manager) Ensure the work is going according to this test plan. Identify the risks and try to mitigate them. At the end of project testing life cycle ensure that all test objectives are accomplished and acceptance criteria is met.

More TL responsibilities includes: Test Case Review, Requirements Validation, Monitoring the execution of manual and automated test cases, Prepare test summary report and Communicate test status to seniors and prepare corresponding documents.

To know more on SQA processes read this article “SQA Processes- How to Test complete application“. Hope from this answer you will get good idea of testing processes and TL responsibilities.

Pavan Ankus asks:

“I am appearing for the QA positions in US. I would kindly request you to mail me the suitable challenging situations in manual testing and also since I don’t have domain knowledge in Insurance, finance and other financial domain experience I am finding hard to explain to the interviewer as an experienced person. In this regard I need your suitable answer as to how to face the interviewer?”

In every testing interview you will get this question: “Tell me any challenging situation you faced in your previous projects or Tell me any bug that you feel proud to find it?”

I think answers to these questions depend on your testing career. I know every one of you might have faced many challenging situations where exceptional thinking is required to solve such problems.

I will suggest to pick any such situation from you career and explain it in better way. At least it should sound challenging This will help you to face further questions from interviewer depending on your answer.

The broad challenges in manual testing are: How to ensure complete test coverage? Testing without an automation tool is itself a big challenge. You can also explain non-technical challenges in manual testing like managing the testing work in critical time (Llink to testing under time limit) i.e. completing testing before deadline and even worst case if the deadline itself is not feasible.

Explaining a challenging bug you found in your career can be also a good answer for this question. For example the bug that was difficult to find or reprove or having big impact on customer revenue etc.

Pavan you mentioned that you don’t have knowledge in banking and finance domain then how you expect from yourself to give answer on that? If you don’t have experience in banking and finance domain then do not put this as a skill in your resume just for the sake of matching your profile with employer requirements. If you really want to get into testing of BFSI (Banking, Financial services and Insurance) domain then first study this domain. Know the basic concepts in BFSI domain. See the resources I have listed on BFSI domain on our resource page. Keep in mind you can answer in detail about any question if you have worked on that.

Mitch asks:

“What is the best way to go about getting a pay rise? Is reporting and graphing bugs found compared to other team member a good idea?

Comparing the bug count with other team or team member is very bad idea to ask for pay rise. If you are working for the organization for long time then your employer know your value and importance in organization. There is no need to show how your bug count graph is higher than your counterparts.

So what is the best way to ask for good salary rise?
At the time of your performance appraisal you should be able to convince to your reviewer that how you worked hard for your organization, How you succeeded in managing difficult tasks and how you enhanced your skills to better match your current work profile. If you succeed in this negotiation then you will definitely get good pay rise.

Other factors considered while giving you pay rise:
Your relevant skills, Complexity of application you are working on, problem solving skill, total and relevant experience, education and certifications.
Ask your questions in below comment section.

Read the previous article on testing questions and answer part1.
If you want to get your questions answered then Subscribe via email.

I hate “Invalid bug” label from developers for the bugs reported by me, do you? I think every tester should try to get his/her 100% bugs resolved. This requires bug reporting skill. See my previous post on “How to write a good bug report? Tips and Tricks” to report bugs professionally and without any ambiguity.

The main reason for bug being marked as invalid is “Insufficient troubleshooting” by tester before reporting the bug. In this post I will focus only on troubleshooting to find main cause of the bug. Troubleshooting will help you to decide whether the ambiguity you found in your application under test is really a bug or any test setup mistake.

Yes, 50% bugs get marked as “Invalid bugs” only due to testers incomplete testing setup. Let’s say you found an ambiguity in application under test. You are now preparing the steps to report this ambiguity as a bug. But wait! Have you done enough troubleshooting before reporting this bug? Or have you confirmed if it is really a bug?

What troubleshooting you need to perform before reporting any bug?

Troubleshooting of:

• What’s not working?
• Why it’s not working?
• How can you make it work?
• What are the possible reasons for the failure?

Answer for the first question “what’s not working?” is sufficient for you to report the bug steps in bug tracking system. Then why to answer remaining three questions? Think beyond your responsibilities. Act smarter, don’t be a dumb person who only follow his routine steps and don’t even think outside of that. You should be able to suggest all possible solutions to resolve the bug and efficiency as well as drawbacks of each solution. This will increase your respect in your team and will also reduce the possibility of getting your bugs rejected, not due to this respect but due to your troubleshooting skill.

Before reporting any bug, make sure it isn’t your mistake while testing, you have missed any important flag to set or you might have not configured your test setup properly.

Troubleshoot the reasons for the failure in application. On proper troubleshooting report the bug. I have complied a troubleshooting list. Check it out – what can be different reasons for failure.

Reasons of failure:
1) If you are using any configuration file for testing your application then make sure this file is upto date as per the application requirements: Many times some global configuration file is used to pick or set some application flags. Failure to maintain this file as per your software requirements will lead to malfunctioning of your application under test. You can’t report it as bug.

2) Check if your database is proper: Missing table is main reason that your application will not work properly.
I have a classic example for this: One of my projects was querying many monthly user database tables for showing the user reports. First table existence was checked in master table (This table was maintaining only monthly table names) and then data was queried from different individual monthly tables. Many testers were selecting big date range to see the user reports. But many times it was crashing the application as those tables were not present in database of test machine server, giving SQL query error and they were reporting it as bug which subsequently was getting marked as invalid by developers.

3) If you are working on automation testing project then debug your script twice before coming to conclusion that the application failure is a bug.

4) Check if you are not using invalid access credentials for authentication.

5) Check if software versions are compatible.

6) Check if there is any other hardware issue that is not related to your application.

7) Make sure your application hardware and software prerequisites are correct.

8 ) Check if all software components are installed properly on your test machine. Check whether registry entries are valid.

9) For any failure look into ‘system event viewer’ for details. You can trace out many failure reasons from system event log file.

10) Before starting to test make sure you have uploaded all latest version files to your test environment.

These are all small and common mistakes but can mostly impact on your relations and credibility in your team. When you will find that your bug is marked as invalid and the invalid bug reason is from above mentioned list – it will be a silly mistake and it will definitely hurt you. (At least to me!)

Share mistakes done by you while reporting any bug. This will help other readers to learn from your experience!

If you like this post then join our email newsletter. Click Here to get new article notifications via email.