Testing can’t show that bugs don’t exist.
An important reason for testing is to stop defects. You can perform your tests, find and report bugs, but at no point are you able to guarantee that there are not any bugs.
It is impossible to test a program completely.
Unfortunately, this is not possible even with the simplest program because the number of inputs is very large, the number of outputs is very large, the number of paths through the software is extremely large, and therefore the specification is subjective to frequent changes.
You can’t guarantee quality.
As a software tester, you can't test everything and aren't liable for the standard of the merchandise. The main way that a tester can fail is to fail to report accurately a defect you've got observed. It is important to recollect that we seldom have little control over quality.
Target environment and intended end user.
Anticipating and testing the appliance within the environment user is predicted to use is one of the main factors that ought to be considered. Also, considering if the appliance may be a single-user system or multi-user system is vital for demonstrating the power for immediate readiness when necessary. The error case of Disney’s Lion King exemplifies this. Disney Company released its first multimedia CD-ROM game for youngsters, The Lion King Animated Storybook. It was highly promoted and therefore the sales were huge. Soon there have been reports that buyers were unable to urge the software to figure. It worked on a couple of systems- likely those that the Disney programmers wont to create the game-but, not on the foremost common systems that the overall public use.
No application is 100% bug-free.
It is more reasonable to acknowledge there are priorities, which can leave some less critical problems unsolved or unidentified.
The simple case is the Intel Pentium bug.
Enter the subsequent equation into your PC’s calculator: (4195835 / 3145727) * 3145727 – 4195835. If the solution is zero, your computer is simply fine. If you get anything, you've got an old Intel Pentium CPU with a floating-point division bug.
Be the customer.
Try to utilize the system as a lay user. To get a glimpse of this, get a person who has no idea of the application to use it for a while and you will be amazed to see the number of problems the person seems to come across. As you'll see, there's no procedure involved. Doing this might actually cause the system to encounter an array of unexpected tests – repetition, stress, load, race, etc.
Build your credibility.
Credibility is like quality that has reliability, knowledge, consistency, reputation, trust, attitude, and a spotlight to detail. It is not instant but should be built over time and provides a voice to the testers within the organization. Your keys to build credibility – identify your strengths and weaknesses, build good relations, demonstrate competency, and be willing to admit mistakes, reassess, and adjust.
Test what you observe.
It is vital that you simply test what you'll observe and have access to. Writing creative test cases can help only you've got the chance to watch the results. So, assume nothing.
Not all bugs you find will be fixed.
Deciding which bugs are going to be fixed and which won’t maybe a risk-based decision. Several reasons why your bug won't be fixed is when there's no enough time, the bug is dismissed for a replacement feature, fixing it'd be very risky or it may not be worth it because it occurs infrequently or has a workaround where the user can prevent or avoid the bug. Making the wrong decision can be disastrous.
Review competitive products.
Gaining an honest insight into various products of an equivalent kind and going to know their functionality and general behavior will assist you to design different test cases and understanding the strengths and weaknesses of your application. This will also enable you to feature value and suggest new features and enhancements to your product.
Follow standards and processes.
As a tester, you got to conform to the standards and guidelines set by the organization. These standards to be relevant to reporting hierarchy, coding, documentation, testing, reporting bugs, using automated tools, etc.
0 Comments