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 Boxes, a white box and a black box. Since then all we do is either black box or white box testing. This has limited our mind from thinking beyond the boxes. Did we ever think that going beyond these could help us in gaining a higher pace towards a solid career in software testing?

Below we will be discussing a few techniques which I follow and many of my Mentors follow as well,

Rapid Fire Test Case Creation:

This technique, as the name suggests is about rapidly creating test cases. The first thing that comes to our mind when we talk about test case creation is a Requirement Document, an Excel Sheet and some guidelines provided by the organization. For once keep aside all the things, get an idea about what you think you are about to test , Pick up a Pen and a Paper and write as many scenarios you can write within 60 seconds. Repeat the process till you are not able to think of more scenarios or ideas and finally review them.

You will definitely be surprised by the number of ideas you already have without looking into the requirement document.

Cross Testing Ideas(Analogy):

While testing an application, treat it like an entirely different application which you have used before and then start testing. Doing this you might come across issues which are not part of the requirements but is just a common/generic feature which should be present and often overlooked.

For Example: If you are testing a portal, use it like you use your E mail program or any application which you worked on before and see how the application behaves.

I remember exploring a critical defect using this technique. I was testing a secure login of a finance application and tried altering the URL and navigating to a different page (which was a defect in my last tested application). By doing this I was able to bypass the login mechanism using Secure ID and this was neither a test case nor any other team member thought that this could be one of the scenarios.

Reverse or Backward Testing Ideas:

What is the normal work flow you follow while testing?  Isn’t it the exact same steps which were used while developing the application, Requirements >> Unit Cases >> Integration Testing >> System Testing or any other approach?

The minds of the people working on the development of an application are bound to think in the direction which will cover more positive testing. The End User might not do the same every time that is the reason why Production Defects or UAT Defects exists even after extensive rounds of Unit Tests, Integration test and System Tests.

For Example: Requirement says you can upload a file which does not exceed file size of 10 MB. The most testers will follow uploading a 1MB, 2MB, 3 MB and so on till 10 MB is reached or error message is displayed. Why not start with 10MB and then try 11MB and then 9 MB. This example is nothing but a BVA but how many of us have tried using BVA in scenarios other then an input box.

Questioning:

Ideally every QA engineer should know the purpose of a requirement. Putting up questions will help a QA Engineer to refine his purpose of testing. If a QA Engineer is good at questioning he/she will be good at testing by default. You need to make sure none of the questions how so ever small or silly is ignored.

And in turn questioning will also enhance the domain knowledge of the person performing the testing.

Researching:

Researching proves to be very beneficial before starting the testing, just be aware of the issues which other people faced while doing similar assignment. Say you have to start a cross browser testing as one of your assignments. Before starting the tests researching the issues which other people encountered while using the same browser will help you find defects before starting the actual testing.

Pause: an ice breaker

Testing sometimes could be a monotonous process and the ideas may begin to saturate, you might start feeling that none of the solutions are working out or you might even run out of ideas. In such cases an effective Pause can do a lot of wonders and could help you kick start from where you left.

A Pause could be a Coffee or simply gazing out of the window.

Apart from being Creative, timing, speed of implementation of ideas and their execution are of high importance. You might get an excellent idea but what if it is too late to implement it.

Listed above are just a few ideas which will help you generate more ideas in turn.

*****

This is a guest post by Mohit Khatri. Author is specialized in testing Banking Applications, Automation Testing Frameworks and Security Testing. If you want to guest post on this blog, read the guidelines here.

If you have more creative techniques which you think have helped you at any point feel free to share below.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Thinking Out of the Box While Testing Software!

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Is it just an AD in changing the health and mind-set of people or an AD to increase the mobile connection sales?
I’m not even sure whether you would call it just another AD or maybe a hidden message for doctors or traditional seasoned managers, whom I have correlated it after seeing this AD. The context of roles is different but the consciousness prescription is the same ‘Practice what you preach’ – ‘Walk when you talk’

So, would I like to be classified under ‘walk and talk’ or ‘talk and talk’?

I certainly do not want to die yet another ‘talk and talk’ – preach and preach supervisor under at any context.

I have realized this time in Germany that I do not want to be a great tester, best supervisor, best test analyst but I do wish eagerly to be a ‘team-defender’, so that I can preach the team members what I have learnt from my mistakes for several years being a tester and on the deeper domain.

I also do not want to create and possess the best method of personal growth and make my profile very impressive in LinkedIn – yet I do want to keep my passion for testing skills’ alive in my profile. I don’t want to be treated just another resource for billable, but more to do with how valued I will be for the team.

I don’t like to create a bit of suspicious of skip level meeting amongst the team members, but I would like to be fairly judged by the team in written and having no known name or identity of the team members.

I don’t want to prove myself as an accomplished supervisor by showing sizeable numbers of direct-reports under my belt, but I’ll like to be the single point of contact for my team’s fear. I don’t want to be called as excel expert manager, who worries for numbers or percentages of work done, but I’ll like to be part of a self-management team.

I don’t want to be a clever supervisor, but I would like to be a fair and clear ‘team-defender’.

Now, please don’t think of this as a highly intellectual statement, I belong to the same class of individuals classified as tester, test lead, or test manager and know the importance and having the knowledge of the test operation, test management and as well as the painstaking, backbreaking, mind numbing effort that goes into making those pretty-looking presentations in PPT and every minute updating the spreadsheets. However, it is like one of those moments when some severity 1 and priority 1 defects falls in place from production and creates a panic at all level of management and you have to celebrate it by announcing it to the management that ‘We have verified the defect on-time’ and my boss consciousness would have said “Hooo…the team has saved my butt, lucky by chance” and hence, here I’m a step closer to the blessed state of knowingly doing what I’m suppose to do along with my team members – ‘walk when you talk’

Well said by great Sir Ji, chief architect of India (CAI):

“An ounce of practice is worth more than tons of preaching“

You must be thinking, who the heck is great Sir Ji, CAI? Yes, you’re right!

About Author:
This is a guest article by “Kajal Das“.
Kajal Das is a tester, working for LHS Ericsson, Germany as senior test expert and having practical telecoms CRM domain testing knowledge. He act as a point of contact between various telecoms service provider customers in determining all aspect of CRM testing being done in a practical and useful way.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How To Be a Good Team Mentor, Coach and a True Team-Defender in an Agile Testing World? – The Inspiration

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

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?

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Software Testing Advice for Novice Testers

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

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.

Today there isn’t such a huge difference between what testers and developers get paid and I consider this generation to be luckier than my generation without ignoring the idea that my generation might have been luckier than its previous generation.

When I started my career as a software tester, I didn’t find any training centre, which could coach me on software testing, and I lacked guidance. I didn’t know about Google and its power of search.

In the organization I worked for, there existed a senior software tester, not by designation or for the technical competence but just that he joined that organization 6 months before I did. He happened to coach me. I blindly believed all that he said about testing. I believed him and never questioned him.

By believing whatever he said I think I was becoming dumb. I looked for someone who could coach me and found two great people, one a developer and other a software architect in the organization whose ideas were much impressive than the senior software tester.

The duos were more open to questions from me as compared to the so-called senior software tester. When I questioned all things that I heard from the so-called senior software tester, I found that most of what the senior tester said was highly idiotic.

I realized that my quest in life was to see myself doing good or great testing in future. To do that, I must learn, I must learn, I must learn, I must practice, I must practice, I must practice…

What do I learn? What do I practice?

When I asked for information about software testing, some of my friends sent me material that was nothing more than, – types of testing, techniques of testing, different types of documentation, process of testing and development.

A question that I asked changed my life and you might want to know what that question is: Is there something beyond what all these people think software testing is which I can learn?

Now that leads to more questions. If it exists, where does is exist? Who has the information? How can I find it?

That lead me to discovering James Bach one of the world’s leading expert tester. His career graph is one of the most impressive career graph I have seen till date. He is a school drop out at 8th standard and yet became the youngest Test Manager of the world at the age of 20 in Apple Computers. He even helped Microsoft in Test Specification and was expert witness in court cases that involved investigations of the computer world. He has traveled to most countries where software testing is being done and has carried over consulting assignments there. He is a kind of tester that can make most testers in the world feel ashamed of their lack of skills, knowledge and maybe money. That reminds me to say, he has made lots of money.

I thought this man must have a secret with him that other software testers don’t know and I wanted to learn that. I found that James Bach is very similar to Jackie Chan as he considers skilled testing to be a mental martial art. Sorry, James doesn’t have any testing certification that you know of and he thinks certification doesn’t help, so don’t try to think of certification when you are thinking of James Bach, the great tester and guru of software testing.

I had to pass through several mental martial arts tests before I became his full time student. Let me not take you through the entire story but let you know that I reached a stage where he hired me to represent his company in India.

I don’t like comparing myself with others and run a rat race but some of my friends who were comparing with me were very disappointed as I progressed. I travel around the world speaking and coaching at international conferences. I am featured as an expert tester sometimes (which I acknowledge, I am not) in other countries. I have a fan following for my blog. I am an independent consult, working on different projects in a day and for different clients from different parts of the world. I coach, consult, speak, write, think, test, manage and learn software testing and problem solving. I was interviewed by CNBC as they considered me a problem solving expert and wrote a column for them as Expert problem solver. I was invited to manage testing for an organization products and services division with about three years of working as a software tester. I have tested over a hundred and twenty three products, so far.

Reputation means more money but if you do things just for gaining reputation you won’t get it. Reputation is a little tricky. People think it is about doing things what other people like but I think it is about other people liking what you are doing.

Don’t worry about too many “I”, I have written in this article and for the moment, think if you have so many “I” to say or probably even more, in testing that makes people to approach you for consultation, you would be making more money than you ever imagined you would make as a tester.

I want to see Indian testers make more money than what they have been making. That’s precisely why I am writing this article for you all.

To start in the journey, apply this heuristic: Question everything that – you hear, you see, you feel, you want to see, you want to hear, you want to feel, you don’t want to hear, you don’t want to feel and other things you think you missed.

How to apply this heuristic?

Let me give you an example to get you started: There is a common myth (which means something is fundamentally wrong but people blindly believe it) by which most testers to my knowledge in India live: Testing is done to improve Quality

• Who said the above statement?
• Why should I believe it?
• By having the above idea that testing improves quality, can any tester on Earth say how much quality he has improved?
• If a tester can’t say that then there is something wrong with the fundamental behind it.
• Improve what quality?
• What is quality?
• Who defines what quality is?
• Does a tester define what quality means?
• If I go to a hotel and the hotel owner says he serves quality food and I as a customer think the quality is not good, whose view is important?
• How can merely finding bugs improve quality?
• So, if a tester reports 5000 bugs and the developer quits the organization the same day, has the quality improved?
• So, if a tester finds 10000 bugs and doesn’t report them, has the quality improved?
• In the above case, testing did happen, and hence did the quality improve?
• If I as a tester report 50 bugs, and the developer in a context of fixing bugs introduces 100 more bugs, has the quality improved?
• Why do all other testers don’t understand the fundamental that it is a developer who can improve the quality?
• As a tester, isn’t my job to find information about quality than trying to think of improving the quality?
• Oh my God! I have been misguided all this while. So what’s testing then?
• Isn’t the above question, a good question?
• Didn’t I learn from this that many people around us are fooling and that is what is stopping me from becoming someone like James Bach?
• Do I want to be fooled?
• Should I allow people, bugs, documents to fool me?

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Money making, software testing career and secrets of a richest tester

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

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 just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Software testing questions and answers

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

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.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How to get your all bugs resolved without any ‘Invalid bug’ label?

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

First of all I would like to introduce three dimensional testing career mentioned by Danny R. Faught. There are three categories of skill that need to be judged before hiring any software tester. What are those three skill categories?
1) Testing skill
2) Domain knowledge
3) Technical expertise.

No doubt that any tester should have the basic testing skills like Manual testing and Automation testing. Tester having the common sense can even find most of the obvious bugs in the software. Then would you say that this much testing is sufficient? Would you release the product on the basis of this much testing done? Certainly not. You will certainly have a product look by the domain expert before the product goes into the market.

While testing any application you should think like a end-user. But every human being has the limitations and one can’t be the expert in all of the three dimensions mentioned above. (If you are the experts in all of the above skills then please let me know ) So you can’t assure that you can think 100% like how the end-user going to use your application. User who is going to use your application may be having a good understanding of the domain he is working on. You need to balance all these skill activities so that all product aspects will get addressed.

Nowadays you can see the professional being hired in different companies are more domain experts than having technical skills. Current software industry is also seeing a good trend that many professional developers and domain experts are moving into software testing.

We can observe one more reason why domain experts are most wanted! When you hire fresh engineers who are just out of college you cannot expect them to compete with the experienced professionals. Why? Because experienced professional certainly have the advantage of domain and testing experience and they have better understandings of different issues and can deliver the application better and faster.

Here are some of the examples where you can see the distinct edge of domain knowledge:
1) Mobile application testing.
2) Wireless application testing
3) VoIP applications
4) Protocol testing
5) Banking applications
6) Network testing

How will you test such applications without knowledge of specific domain? Are you going to test the BFSI applications (Banking, Financial Services and Insurance) just for UI or functionality or security or load or stress? You should know what are the user requirements in banking, working procedures, commerce background, exposure to brokerage etc and should test application accordingly, then only you can say that your testing is enough – Here comes the need of subject-matter experts.

Let’s take example of my current project: I am currently working on search engine application. Where I need to know the basic of search engine terminologies and concepts. Many times I see some other team tester’s asking me questions like what is ‘publishers’ and ‘advertisers’, what is the difference and what they do? Do you think they can test the application based on current online advertising and SEO? Certainly not. Unless and until they get well familiar with these terminologies and functionalities.

When I know the functional domain better I can better write and execute more test cases and can effectively simulate the end user actions which is distinctly a big advantage.

Here is the big list of the required testing knowledge:

• Testing skill
• Bug hunting skill
• Technical skill
• Domain knowledge
• Communication skill
• Automation skill
• Some programming skill
• Quick grasping
• Ability to Work under pressure …

That is going to be a huge list. So you will certainly say, do I need to have these many skills? Its’ depends on you. You can stick to one skill or can be expert in one skill and have good understanding of other skills or balanced approach of all the skills. This is the competitive market and you should definitely take advantage of it. Make sure to be expert in at least one domain before making any move.

What if you don’t have enough domain knowledge?
You will be posted on any project and company can assign any work to you. Then what if you don’t have enough domain knowledge of that project? You need to quickly grasp as many concepts as you can. Try to understand the product as if you are the customer and what customer will do with application. Visit the customer site if possible know how they work with the product, Read online resources about the domain you want to test the application, participate in events addressing on such domain, meet the domain experts. Or either company will provide all this in-house training before assigning any domain specific task to testers.

There is no specific stage where you need this domain knowledge. You need to apply your domain knowledge in each and every software testing life cycle.

If you are reading this article till this point then I would like to hear on which domain you are working on? So that our readers can get better idea of different domains and projects. Comment your domain below.

Update: As per the request from many readers I have updated our software testing resource page for the BFSI domain online documents and articles for downloads.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How Domain knowledge is Important for testers?

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

“The point of writing problem report(bug report) is to get bugs fixed” – By Cem Kaner. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest do not keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc etc..)

What are the qualities of a good software bug report?
Anyone can write a bug report. But not everyone can write a effective bug report. You should be able to distinguish between average bug report and a good bug report. How to distinguish a good or bad bug report? It’s simple, apply following characteristics and techniques to report a bug.

1) Having clearly specified bug number:
Always assign a unique number to each bug report. This will help to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.

2) Reproducible:
If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.

3) Be Specific:
Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.

How to Report a Bug?

Use following simple Bug report template:
This is a simple bug report format. It may vary on the bug report tool you are using. If you are writing bug report manually then some fields need to specifically mention like Bug number which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub modules of the product.

Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Operating system: Mention all operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.

Priority:
When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.

Severity:
This describes the impact of the bug.
Types of Severity:

• Blocker: No further testing work can be done.
• Critical: Application crash, Loss of data.
• Major: Major loss of function.
• Minor: minor loss of function.
• Trivial: Some UI enhancements.
• Enhancement: Request for new feature or some enhancement in existing one.

Status:
When you are logging the bug in any bug tracking system then by default the bug status is ‘New’.
Later on bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.
Click here to read more about detail bug life cycle.

Assign To:
If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.

URL:
The page url on which bug occurred.

Summary:
A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.

Description:
A detailed description of bug. Use following fields for description field:

• Reproduce steps: Clearly mention the steps to reproduce the bug.
• Expected result: How application should behave on above mentioned steps.
• Actual result: What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.

The report types are typically:
1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately:If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report:Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

3) Test the same bug occurrence on other similar module:
Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.

4) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button:
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

6) Do not use Abusive language:
It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.

Conclusion:
No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

For better productivity write a better bug report.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How to write a good bug report? Tips and Tricks

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

I will extract only points related to software testing. As a software tester keep in mind these simple points:

Share everything:
If you are a experienced tester on any project then help the new developers on your project. Some testers have habit to keep the known bugs hidden till they get implement in code and then they write a big defect report on that. Don’t try to only pump your bug count, share everything with developers.

Build trust:
Let the developers know any bug you found in design phase. Do not log the bug repeatedly with small variations just to pump the bug count. Build trust in developer and tester relation.

Don’t blame others:
As a tester you should not always blame developers for the bugs. Concentrate on bug, not always on pointing that bug in front of all people. Hit the bug and its cause not the developer!

Clean up your own mess:
When you finish doing any test scenario then reconfigure that machine to its original configuration. The same case applies for bug report. Write a clean effective bug report. Let the developer find it easy to repro and fix it.

Give credit to others for their work:
Do not take others credit. If you have referred any others work, immediately give credit to that person. Do not get frustrated if you not found any bug that later has been reported by client. Do work hard, use your skill.

Remember to flush
Like the toilets flush all the software’s at some point. While doing performance testing remember to flush the system cache.

Take a nap everyday:
We need time to think, get refresh or to regenerate our energy.
Some times its important to take one step back in order to get fresh insight and to find different working approach.

Always work in teams, team score are always better and powerful than individuals.

Now its time to take nap Happy Testing!

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Living life as a Software Tester!

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

I think finding a blocker bug like any system crash is often rewarding! No I don’t think like that. You should try to find out the bugs that are most difficult to find and those always misleads users.

Finding such a subtle bugs is most challenging work and it gives you satisfaction of your work. Also it should be rewarded by seniors. I will share my experience of one such subtle bug that was not only difficult to catch but was difficult to reproduce also.
I was testing one module from my search engine project. I do most of the activities of this project manually as it is a bit complex to automate. That module consist of traffic and revenue stats of different affiliates and advertisers. So testing such a reports is always a difficult task. When I tested this report it was showing the data accurately processed for some time but when tried to test again after some time it was showing misleading results. It was strange and confusing to see the results.

There was a cron (cron is a automated script that runs after specified time or condition) to process the log files and update the database. Such multiple crons are running on log files and DB to synchronize the total data. There were two crons running on one table with some time intervals. There was a column in table that was getting overwritten by other cron making some data inconsistency. It took us long time to figure out the problem due to the vast DB processes and different crons.

My point is try to find out the hidden bugs in the system that might occur for special conditions and causes strong impact on the system. You can find such a bugs with some tips and tricks.

So what are those tips:

1) Understand the whole application or module in depth before starting the testing.

2) Prepare good test cases before start to testing. I mean give stress on the functional test cases which includes major risk of the application.

3) Create a sufficient test data before tests, this data set include the test case conditions and also the database records if you are going to test DB related application.

4) Perform repeated tests with different test environment.

5) Try to find out the result pattern and then compare your results with those patterns.

6) When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some monkey testing.

7) Use your previous test data pattern to analyse the current set of tests.

Try some standard test cases for which you found the bugs in some different application. Like if you are testing input text box try inserting some html tags as the inputs and see the output on display page.

9) Last and the best trick is try very hard to find the bug As if you are testing only to break the application!

I will include more tips in some coming posts.

Meantime you can comment out more tips here.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
How to find a bug in application? Tips and Tricks

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.