Need for Testing: Testing is a major component of software development, and is a major science in itself.

What is the need for testing ? Software development involves developing software against a set of requirements (whether they be a specific client's requirements for a project, or generic requirements for a shrink-wrapped product). Software testing is needed to verify and validate that the software that has been built has been built to meet these specifications. Testing ensures that what you get in the end is what you wanted to build. Testing enhances the integrity of a system by detecting deviations in design and errors in the system. Testing aims at detecting error-prone areas. This helps in the prevention of errors in a system. Testing also adds value to the product by conforming to the user requirements. Another way to say this is: The desired result of testing is a level of confidence in the software so that the organization is confident that the software has an acceptable defect rate. What constitutes an acceptable defect rate depends on the nature of the software. Another way of saying this in an even more business like manner is: Testing is a process of technical investigation, performed on behalf of stakeholders, that is intended to reveal quality-related information about the product with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding errors. And what are some the common things that necessitate the need for a testing plan: 1. Communication gaps between the requirement specifier and the developer 2. Over committment by the developer 3. Not proper understanding of all the complexities of the system 4. Inadequate requirements gathering 1. To check the reliability of the software. 2. To be ensure that the software does not contain any bug which can become a reason for failure. 3. The software made according to its specification, 2. Despite the array of techniques for preventing bugs and for facilitating bug detection, software development is still error-prone. Even with all the quality techniques practised today, the lions share of bugs is found by testing. Testing is the most important way of assuring (or controlling) the quality of software. Good practices throughout the development process contribute to the quality of the final product, but only testing can demonstrate that quality has been achieved and identify the problems and the risks that remain. This is not really the best state of affairs, as testing is by far the costliest method of finding bugs. The cost of a bug found using inspections, walkthroughs, reviews, modelling and proofs is much less than a bug found in testing. These techniques can be performed early, at intermediate stages of development, meaning that fixing a bug entails less rework, less rechecking, and less likelihood of introducing a new fault. Testing, on the other hand, entails manufacturing test data and transactions, and running the software on something approaching the live hardware and network infrastructure. It

also requires a (nearly) working piece of software, which is usually only available towards the end of a development stage (or development iteration in iterative processes). All this is expensive and time-consuming. To fix a bug found during a test implies rework, which might go far back into the development cycle - possibly all the way back to the initial requirements. All that rework needs to be re-tested. The cost of fixing bugs increases exponentially at each stage of development. Rework and re-testing are time-consuming and expensive, and fixes are errorprone - studies have shown that each fix has a 50% chance of creating a new defect. Despite the drawbacks and the available alternatives, software development still relies heavily on testing. Testing was probably the first activity used by programmers to flush out bugs in software before it is made live. It is the most intuitive step to take - write a program, then run it. The persuasive appeal of testing is that it has, at least within the abstract realm of software, relatively tangible results. At the end of a test, you have evidence of the softwares behaviour. Even if you employ the best in software development practices, tools and engineers, and you deploy the full range of quality assurance/quality control methods throughout the whole lifecycle, you will still need to test. You may find that you have reduced the cost and timescales of testing by employing best practice bug-prevention and early bug-detection disciplines during development, but you will still need testing to measure and prove just how effective all that was. None of the other quality techniques provides the same level of observable confirmation that software behaves as expected, and running it does not result in failures. You will need to test to be confident that software performs technically and functionally as designed, to demonstrate to users that it solves the problem they intended it to, and to measure what risks you may be taking if, as is nearly always the case, the software is not perfect. Business management is increasingly aware that software testing is an essential process that can deliver significant business benefits. With its abilities to demonstrate that business requirements are met and to expose the risks that remain in deploying a newly developed piece of software, testing has business interests at its centre. It is a powerful tool in ensuring that software development results are aligned with business objectives.

The Psychology of Testing

A software tester is any human being who tests the software. So, what do you answer if anybody asks you 'Does software testing need a specialized skill'? It looks very simple to answer this question, isn't it? But ofcourse not. Software Testing is not as easy as you might

think of. Needless to say, It's one of the most important and difficult tasks in the entire gamut of software development life cycle process. Human beings reaction in this complex world of happenings varies widely with respect to situations, surroundings, emotions, need, requirements, time frame, money, visualization, belief, education, knowledge, expertise, intuition and so on. Such complex is the nature of human being and certainly there's no exception at work place too. Therefore it's cynical to say that the job being done (software testing) by a software tester is simple & complete. Nevertheless, the quality of the job done by the software tester is directly proportional to his or her psychological maturity and profoundness acquired, adopted and developed with age and experience. "The psychology of the persons carrying out the testing will have an impact on the testing process [Meyer 1979]." Let's examine the psychology of the person under discussion (tester) by describing the definition of software testing under three circumstances. 1. "Software testing is the process to prove that the software works correctly" The above definition sounds good. If the person under discussion (software tester) is the one who has developed the software he/she will try to use the above definition. This person's intentions would mostly revolve around the point to prove the software works. He/She will only give those inputs for which correct results are obtained. This above explanation is the typical psychology of testing by a software developer. 2. "Testing is the process to prove that the software doesn't work" This definition sounds very good especially if the aim of the tester is to prove that the software doesn't work for what it's supposed to do. This type of psychology would bring out the most of the defects in the software. A software tester should therefore have such a psychology to push the software beyond its boundaries. Nevertheless, this definition involves a practical difficulty If you question "how many days does the software should be tested to conclude that the software works perfectly?", perhaps the answer would again recur to be a question in itself. It's never a right conclusion to infer that there are no bugs in the software if one says that "the software has no bugs even after testing for more than a week or a month or an year" nor it is wise to say that the software is completely reliable. Testing does not guarantee defect less or zero bug software at all times but can only reduce or minimize known defects because the very nature of a bug can be volatile. If the above definition is to be strictly implemented, then perhaps the most Operating Systems & other Commercial Software packages which we use today would not have been in the market yet. If so, then the above definition would seem to be unrealistic.

3. "Testing is the process to detect the defects and minimize the risks associated with the residual defects" This definition appears to sound realistic. Practically, if at any point, the software product development starts, the testing process should start and keep in track the number of bugs being detected while correcting them. At some stage of a planned testing, there would be a stage where no bugs are identified after many days or weeks or sometimes months of testing which statistically allows you to conclude that the software is "good enough" to be released into the market. i.e there may still exist some bugs undetected, but the risk associated with the residual defects is not very high or are tolerable. The decision to release a software may thus vary based on many other factors like business value, time constraint, client requirements & satisfaction, company's quality policies etc. From the above three definitions, we can understand that the psychology of a software tester plays a vital role through out the software development cycle & the quality processes of software testing. "The objective of testing is to uncover as many bugs as possible. The testing has to be done without any emotional attachment to the software. If someone points out the bugs, it is only to improve the quality of the software rather than to find fault with you." Role & Characteristics of a Software Tester Software Development & Software Testing go hand in hand. Both aim at meeting the predefined requirements and purpose. Both are highly creative jobs in nature but the general outlook towards these two individuals is psychological rather than distinctive classification. If success is perceived as achieving something constructive or creative, like the job of developing a software to work, software testing in contrast is perceived as destructive job or negative job by majority of the masses. Nevertheless, software testing itself has to be perceived as an equally creative job on par with the development job, but this perception can only be practically possible with a different outlook and mindset. Software Testers require technical skills similar to their development counterparts, but software testers need to acquire other skills, as well.

Keen Observation Detective Skills Destructive Creativity Understanding Product as integration of its parts Customer Oriented Perspective Cynical but Affable Attitude Organized, Flexible & Patience at job Objective & Neutral attitude

Keen Observation The software tester must possess the qualities of an 'eye for detail'. A keen observation is the prime quality any software tester must possess. Not all bugs are

visible clearly to the naked eye in a software. With keen observation, the tester can easily identify or detect many critical bugs. Observing the software for established parameters like 'look & feel' of GUI, incorrect data representation, user friendliness etc needs this type of characteristics. Detective Skills Ideally the software under development would be documented before, after and throughout the development process. Unfortunately, there is every chance of not updating the documentation (specification, defect reports etc) due to time and resource constraints. The software under testing would be completely described in a well defined set library of functions and design specifications in documents called specs or SRS etc. which needs constant update. The tester should therefore apply his knowledge of rationalization in knowing about the product from formal system like system specifications, design & functional specifications. From this information, the tester should look for researching more analytical information through other sources called non-formal sources of information like developers, support personnel, bugs and related product documents, reviews of related and (seemingly) unrelated documents. A tester should therefore possess the quality of a 'detective' to explore the product under test, more rationally. Destructive Creativity The Tester need to develop destructive skills means skills to perturb and crash the software workflow and its functionality. In other words, the tester should 'not hesitate to break the software' fearing to buy it or being empathetic to the creation of developers. In software testing, boundaries are meant to be crossed not obeyed. A creative oriented but destructive approach is necessary while testing a software by the tester to make the software evolve more robustly and reliably. "The Software under test should be tested like a Mercedes-Benz car. " Understanding the Product as an integration of its parts The software(read as product) is a culmination of lines of code interacting with data through user interface and database. It is an integration of separate group of code interacting with other groups assembled together to function as a whole product. The developers might be working on a respective piece of code module focusing more on those modules under work, at a time. It is no wonder if the developer sometimes may not even know the complete workflow of the product and not necessary too. Where as, in the case of a tester, being the rider of the software under test, should understand and know about the complete specifications (operational and workflow requirements) of the product. The tester may not be the best expert on any one module of the software but definitely he/she should gain expertise on the overall operation of the product. In fact, the tester should possess a 'Systems' view of the product because they are the only people to see and test the complete functionality of interdependent modules and compatibility between the software and hardware specifications laid down by the client before it is sent to the customer.

Customer Oriented Perspective Testers need to possess a customer oriented perspective. Customers (read as users) need not be as wise as software engineers or testers. As the number of computer users are growing every day (need not be as wise as engineers or testers), the end-users may neither be comfortable nor tolerate any bugs, explanations, or frequent upgrades to fix the bugs. As any customer would simply be interested in consuming the product (software) by deriving its value the software tester must adopt a customer oriented perspective while testing the software product. Hence the tester must develop his abilities to suffice himself/herself in the place of the customer, testing the product as a mere end-user. Cynical but Affable Attitude Irrespective of the nature of the project, the tester need to be tenacious in questioning even the smallest ambiguity until it is proved. In other words ,the tester must chant the words "In God we Trust- Everything Else gets Tested" throughout the testing cycle. There may arise some situations during the course of testing large number of bugs might be encountered unusually which might compel to further delay in shipping of the product. This may lead to heat up the relation between the testers and other development teams. The tester should balance this relationship not at the cost of the bugs but by convincing and upholding their intentions to "assault the software but not the software developers". Organized, Flexible and Patience at Job: Software testers must remember the fact that as the world is shrinking since the advent of internet and web, so, change is very dynamic and no exception for modern software. Not all the tests planned are performed completely and some tests dependent on other tests has to be blocked for later testing. This needs an organized approach by the tester in attempting to phase out the bugs. Sometimes, significant tests has to be rerun which would change the fundamental functionality of the software. The tester should therefore have patience to retest the planned bugs and any new bugs that may arise. It is even more important to the testers to be patient and keep prepared in the event of a dynamic development and test model. Development keeps changing continuously as requirements and technology keeps changing rapidly and so should testing. The testers must take these changes into account and plan to perform tests while maintaining the control of test environment to ensure valid test results. Objective and Neutral Attitude Nobody would like to hear and believe bad news, right? Well, testers are sometimes viewed as messengers of bad news in a software project team. No wonder, how good the tester is (meaning very negative) and brilliant in doing his job (identifying bugs-no one likes to do it but most human beings are taken for granted to be naturally very good at it, at least from childhood), he/she might always be a messenger of communicating the bad part of the software, which, the creators (developers) doesn't like it. "Nobody who builds the houses likes to have them burned." The tester must be able to deal with the situation where he/she is blamed for doing his/her job (detecting bugs) too good. The tester's jobs must be appreciated and the bugs should be welcomed by the development team because every potential bug found by the tester would

mean a reduction of one bug that would potentially might have been encountered by the customer. Irrespective of the negative aspects of doing such a highly skillful job, the role of a tester is to report honestly every known bug encountered in the product with always an objective and a neutral attitude.