Is Testing easy?

• Testing is Quality assurance. If someone starts using “testing” and “quality assurance” as interchangeable terms, it should be a serious cause for worrying. In reality testing is just one step of quality assurance. Good quality assurance should enclose the entire development process, i.e. from the very beginning of requirements gathering to product maintenance. Not only are wide range of different test techniques involved but it should also take in the standards, documentation, processes, and sign-off gates that are used throughout the whole development life-cycle.
• All the bugs can be eliminated from a system. You need to be aware of the truth. One of the great un-provable laws of computing says that all systems have bugs. You will never manage to remove all of the bugs from a system; so actual 'removing' is more a matter of tracking them down to quite a normal level.

Common Myths of Test Automation

• Testing should be automated. Automated testing can stimulate the overall testing effort, but it does not mean that manual testing is no more important. Effective testing can be best achieved through a combination of manual and automated testing. Automated tests are applied to minimize the need for some repetitive manual testing but they tend to use the same set of inputs on each case. A piece of software that is consistently subjected to solid set of automated tests may not fare so well once it passes the more random and unpredictable inputs of manual testings. The expert eye of an experienced quality assurance professional will provide a more scrupulous test than an automated script. It can also be very challenging to pick appropriate kind of reliable automated testing in the early stages of a project or for new functionality. Most development is in flux at first and it can be difficult to decide when is best to begin building in test automation. Some software platforms undergo a relative shortage of test frameworks which can further lead to reduction of automation.
• Testing is easy. The importance of quality assurance professionals is often under-estimated and under-appraised. This may happen because of the lack of understanding of their value for the project in general. Really top quality assurance professionals are great luck of any company . They provide serious knowledge of test techniques with a real passion for quality. They can be very persistent in finding even minor faults in the project. They even will manage to make your testing more efficient by making assumptions concerning defects and where they are most likely to be found. The quality assurance team brings a broader perspective to the project which comes from a deep understanding of both development and process business requirements.

Roles in the Team: Developers and Testers are like oil and water

• Only the Quality assurance team needs to be involved in testing. A team of quality assurance professionals is really valuable because they worry about product quality and have a superior understanding of what to look for while testing a system. However, everybody should be responsible for quality-assurance. It can be dangerous to entrust quality assurance to a separate team of testers as it supports the idea that only a specialist can fulfill software testing. It also implies a consistent model of development based on functional silos where business analysis write requirements, technical architects design solutions, developers write code and quality assurance test the end result. This particular model feels outdated and it can push team members to feel responsible for the overall quality of the system. More agile and modern development approaches help to resist this model by promoting a more collaborative approach. Continuous integration and iterative releases techniques can also help to stimulate a shared responsibility for system quality.
• The more testing is done the better it is. Many projects aim to achieve 100% test coverage for the system. This can possibly happen but is seldom achieved as coverage has a tendency to shorten in response to changing development schedules. Usually decisions are made about which areas to test being made on-the-fly rather than choosing a more systematic approach to circle priorities. Any decisions about priority should take into consideration risk and business imperatives so that the greatest coverage is received by those areas with the highest potential impact. This risk-based approach infers that full test coverage is unrealistic but provides a possibility to make more informed decisions concerning the most definite areas to concentrate on.
• Quality assurance can be left to the final stage. A number of projects are planned in a certain way to fulfill testing at the end of development. This may seem reasonable as it gives you a chance to test entire system through a number of quality assurance cycles and fix the whole system in its integrity. The point is that the time assigned for these quality assurance cycles tends to diminish as the project finishes. The occurrence of inevitable delays can make the later stages of development a rushed thing. If you have to choose either a round of testing or the possibility to add a new feature it’s easy to reduce expenses on the quality assurance. With such a faulty approach to testing, most if not all bugs can be left to rot in the system until the final stages of the project. It is always cheaper to fix bugs earlier on in the development cycle rather than stabilize the completed system with deep-seated bugs moreover the developer will have to refresh the code in his mind.
• Performance testing is better be done on a production environment. Performance testing is often done as a set of load tests at the very end of a development plan. This approach helps to single out the points at which a system crashes rather than ensures an acceptable level of whole system performance. At this particular stage it's not too late but rather expensive and time-consuming to fix major performance problems. That's why performance testing is better to work into the development life-cycle. Use code profiling tools to check for bottle-necks in code that may come back to haunt you. During the design phase define metrics for performance and use prototypes to evaluate architectural choices. First and foremost, constantly plan and monitor system performance throughout the development stage rather than leave it to the “big bang” of crush testing.
• Security and quality are different activities. Security testing is often assigned to a single check-up of a system just before it is released. As any last-minute testing, it only leads to extra costs as it is much cheaper to fix issues if they are spotted in the primary development process. Last-minute testing such as penetration tests can provide a important guarantees before go-live, but they should not provide the first test of security flaws. A true security assurance requires something more reliable than an audit. Theoretically, a risk-based approach of identifying and curing vulnerabilities should be used throughout the entire process of development. Architecture design and code review processes should contain build-in security audits. Moreover, a clear idea of possible risks and their perception by the system should be developed.

Is Testing expensive?

• Quality assurance is expensive. Quality assurance may be mistakenly considered as something of an extra-charge. Sometimes it can be tempting to skimp in quality assurance, especially when schedules start to slip. But this desire to save up on quality assurance proves inexperience and false economy. If you have ever experienced a project collapse because of endless bug-fixing then you would never consider cutting back on quality assurance. It's impossible to have “quick and dirty” project done – the “dirty” always remains long after the “quick” has been neglected. A project that is overloaded by quality assurance challenges is a tiresome experience. It’s like a barrel with no bottom, as you keep pouring resources into bug fixing that could have been caught earlier in the development process and thus your budget expands rapidly. This follows to undermining profitability, prejudice the reputation of your business, shatters user confidence and discourage development teams. Quality assurance really isn’t a luxury.