SOFTWARE TESTING Aarti Singh

ABSTRACT:- Software testing is an investigation  can be installed and run in its conducted to provide stakeholders with intended environments, and information about the quality of the product or  achieves the general result its stakeholders service under test Software testing can also desire. provide an objective, independent view of Software testing can be conducted as soon as thesoftware to allow the business to appreciate executable software (even if partially complete) and understand the risks of software exists. The overall approach to software implementation.In this paper we will discuss development often determines when and how testing about testing levels suct as alpha testing , beta is conducted. For example, in a phased process, most testing, unit testing , integrity testing, testing testing occurs after system requirements have been cycle and their requirement n comparison defined and then implemented in testable programs. between varius testing such as static and dynamic HISTORY: testing. The separation of debugging from testing was initially introduced by Glenford J. Myers in INTRODUCTION: 1979.[] Although his attention was on breakage Software testing involves the execution of a testing ("a successful test is one that finds a bug) it software component or system component to illustrated the desire of the software engineering evaluate one or more properties of interest. In community to separate fundamental development general, these properties indicate the extent to which activities, such as debugging, from that of the component or system under test: verification. Dave Gelperin and William C.  meets the requirements that guided its Hetzel classified in 1988 the phases and goals in design and development, software testing in the following stages:  responds correctly to all kinds of inputs,  Until 1956 – Debugging oriented  performs its functions within an acceptable  1957–1978 – Demonstration oriented time,  1979–1982 – Destruction oriented  is sufficiently usable,  1983–1987 – Evaluation oriented  1988–2000 – Prevention oriented

There are many approaches available in software testing. Reviews, walkthroughs, or inspections are TESTING METHODS: referred to asstatic testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing Static vs. dynamic testing: is often implicit, as proofreading, plus when programming tools/text editors check source code

IJIRT 142783 268

INTERNATIONAL JOURNAL OF INNOVATIVE RESEARCH IN TECHNOLOGY © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002 structure or compilers (pre-compilers) check syntax using stubs/drivers or execution from and data flow as static program analysis. Dynamic a debugger environment. testing takes place when the program itself is run. Static testing involves verification, whereas Dynamic testing may begin before the program is dynamic testing involves validation. Together they 100% complete in order to test particular sections of help improve software quality. Among the code and are applied to discrete functions or techniques for static analysis, mutation testing can modules. Typical techniques for this are either be used to ensure the test-cases will detect errors which are introduced by mutating the source code.

statements in the program to be executed at White-box testing least once) White-box testing (also known as clear box  Fault injection methods – intentionally testing, glass box testing, transparent box introducing faults to gauge the efficacy of testing and structural testing) tests internal testing strategies structures or workings of a program, as opposed to  Mutation testing methods the functionality exposed to the end-user. In white-  Static testing methods box testing an internal perspective of the system, as Code coverage tools can evaluate the completeness well as programming skills, are used to design test of a test suite that was created with any method, cases. The tester chooses inputs to exercise paths including black-box testing. This allows the through the code and determine the appropriate software team to examine parts of a system that are outputs. This is analogous to testing nodes in a rarely tested and ensures that the most circuit, e.g. in-circuit testing (ICT) important function points have been tested.[22] Code While white-box testing can be applied at coverage as a software metric can be reported as a the unit, integration and system levels of the percentage for: software testing process, it is usually done at the unit  Function coverage, which reports on level. It can test paths within a unit, paths between functions executed units during integration, and between subsystems  Statement coverage, which reports on the during a system–level test. Though this method of number of lines executed to complete the test design can uncover many errors or problems, it test might not detect unimplemented parts of the  Decision coverage, which reports on specification or missing requirements. whether both the True and the False branch Techniques used in white-box testing include: of a given test has been executed  API testing – testing of the application 100% statement coverage ensures that all code paths using public and private APIs (application or branches (in terms of control flow) are executed programming interfaces) at least once. This is helpful in ensuring correct  Code coverage – creating tests to satisfy functionality, but not sufficient since the same code some criteria of code coverage (e.g., the may process different inputs correctly or incorrectly. test designer can create tests to cause all Black-box testing

IJIRT 142783 269

INTERNATIONAL JOURNAL OF INNOVATIVE RESEARCH IN TECHNOLOGY © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002

descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non- Black box functional, though usually functional. diagram Specification-based testing may be necessary to Black-box testing treats the software as a "black assure correct functionality, but it is insufficient to box", examining functionality without any guard against complex or high-risk situations.[25] knowledge of internal implementation. The testers One advantage of the black box technique is that no are only aware of what the software is supposed to programming knowledge is required. Whatever do, not how it does it.[23] Black-box testing methods biases the programmers may have had, the tester include: equivalence partitioning, boundary value likely has a different set and may emphasize analysis, all-pairs testing, state transition different areas of functionality. On the other hand, tables, decision table testing, fuzz testing, model- black-box testing has been said to be "like a walk in based testing, use case testing, exploratory a dark labyrinth without a flashlight."[26]Because testing and specification-based testing. they do not examine the source code, there are Specification-based testing aims to test the situations when a tester writes many test cases to functionality of software according to the applicable check something that could have been tested by only requirements.[24]This level of testing usually one test case, or leaves some parts of the program requires thorough test cases to be provided to the untested. tester, who then can simply verify that for a given This method of test can be applied to all levels of input, the output value (or behavior), either "is" or software "is not" the same as the expected value specified in testing: unit, integration, system and acceptance. It the test case. Test cases are built around typically comprises most if not all testing at higher specifications and requirements, i.e., what the levels, but can also dominate unit testing as well. application is supposed to do. It uses external

recording of the entire test process – capturing everything that occurs on the test system in video Visual testing format. Output videos are supplemented by real- The aim of visual testing is to provide developers time tester input via picture-in-a-picture webcam with the ability to examine what was happening at and audio commentary from microphones. the point of software failure by presenting the data Visual testing provides a number of advantages. The in such a way that the developer can easily ﬁnd the quality of communication is increased drastically information she or he requires, and the information because testers can show the problem (and the is expressed clearly.[27][28] events leading up to it) to the developer as opposed At the core of visual testing is the idea that showing to just describing it and the need to replicate test someone a problem (or a test failure), rather than just failures will cease to exist in many cases. The describing it, greatly increases clarity and developer will have all the evidence he or she understanding. Visual testing therefore requires the

IJIRT 142783 270

INTERNATIONAL JOURNAL OF INNOVATIVE RESEARCH IN TECHNOLOGY © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002 requires of a test failure and can instead focus on the test tool to visually record everything that occurs on cause of the fault and how it should be fixed. a system becomes very important in order to Visual testing is particularly well-suited for document the steps taken to uncover the bug.[Visual environments that deploy agile methods in their testing is gathering recognition in customer development of software, since agile methods acceptance and usability testing, because the test can require greater communication between testers and be used by many individuals involved in the developers and collaboration within small teams.[ development process. For the customer, it becomes Ad hoc testing and exploratory testing are important easy to provide detailed bug reports and feedback, methodologies for checking software integrity, and for program users, visual testing can record user because they require less preparation time to actions on screen, as well as their voice and image, implement, while the important bugs can be found to provide a complete picture at the time of software quickly. In ad hoc testing, where testing takes place failure for the developers. in an improvised, impromptu way, the ability of a TESTING LEVELS:

of the software development lifecycle. Rather than There are generally four recognized levels of tests: replace traditional QA focuses, it augments it. Unit unit testing, integration testing, component interface testing aims to eliminate construction errors before testing, and system testing. code is promoted to QA; this strategy is intended to Unit testing increase the quality of the resulting software as well Unit testing, also known as component testing, as the efficiency of the overall development and QA refers to tests that verify the functionality of a process. specific section of code, usually at the function level. Depending on the organization's expectations for In an object-oriented environment, this is usually at software development, unit testing might the class level, and the minimal unit tests include the include static code analysis, data flow analysis, constructors and destructors.[32] metrics analysis, peer code reviews, code coverage These types of tests are usually written by analysis and other software verification practices. developers as they work on code (white-box style), Integration testing to ensure that the specific function is working as Integration testing is any type of software testing expected. One function might have multiple tests, to that seeks to verify the interfaces between catch corner cases or other branches in the code. components against a software design. Software Unit testing alone cannot verify the functionality of components may be integrated in an iterative way or a piece of software, but rather is used to ensure that all together ("big bang"). Normally the former is the building blocks of the software work considered a better practice since it allows interface independently from each other. issues to be located more quickly and fixed. Unit testing is a software development process that Integration testing works to expose defects in the involves synchronized application of a broad interfaces and interaction between integrated spectrum of defect prevention and detection components (modules). Progressively larger groups strategies in order to reduce software development of tested software components corresponding to risks, time, and costs. It is performed by the software elements of the architectural design are integrated developer or engineer during the construction phase and tested until the software works as a system.

IJIRT 142783 271

INTERNATIONAL JOURNAL OF INNOVATIVE RESEARCH IN TECHNOLOGY © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002

Alpha testing Alpha testing is simulated or actual operational Component interface testing testing by potential users/customers or an The practice of component interface testing can be independent test team at the developers' site. Alpha used to check the handling of data passed between testing is often employed for off-the-shelf software various units, or subsystem components, beyond full as a form of internal acceptance testing, before the integration testing between those units.[34][35] The software goes to beta testing.[39] data being passed can be considered as "message Beta testing packets" and the range or data types can be checked, Beta testing comes after alpha testing and can be for data generated from one unit, and tested for considered a form of external user acceptance validity before being passed into another unit. One testing. Versions of the software, known as beta option for interface testing is to keep a separate log versions, are released to a limited audience outside file of data items being passed, often with a of the programming team known as beta testers. The timestamp logged to allow analysis of thousands of software is released to groups of people so that cases of data passed between units for days or further testing can ensure the product has few faults weeks. Tests can include checking the handling of or bugs. Beta versions can be made available to the some extreme data values while other interface open public to increase the feedback field to a variables are passed as normal values. Unusual data maximal number of future users and to deliver value values in an interface can help explain unexpected earlier, for an extended or even infinite period of performance in the next unit. Component interface time (perpetual beta). testing is a variation of black-box testing,

Functional vs non-functional testing:

IJIRT 142783 272

Functional testing refers to activities that verify a testable and with what parameters those specific action or function of the code. These are tests work. usually found in the code requirements  Test planning: Test strategy, test documentation, although some development plan, testbed creation. Since many methodologies work from use cases or user stories. activities will be carried out during testing, Functional tests tend to answer the question of "can a plan is needed. the user do this" or "does this particular feature  Test development: Test procedures, test work." scenarios, test cases, test datasets, test Non-functional testing refers to aspects of the scripts to use in testing software. software that may not be related to a specific  Test execution: Testers execute the function or user action, such as scalability or software based on the plans and test other performance, behavior under documents then report any errors found to certain constraints, or security. Testing will the development team. determine the breaking point, the point at which  Test reporting: Once testing is completed, extremes of scalability or performance leads to testers generate metrics and make final unstable execution. Non-functional requirements reports on their test effort and whether or tend to be those that reflect the quality of the not the software tested is ready for release. product, particularly in the context of the suitability  Test result analysis: Or Defect Analysis, perspective of its users. is done by the development team usually with the focus on the data values beyond just the along with the client, in order to decide related actions of a subsystem component. what defects should be assigned, fixed, System testing rejected (i.e. found software working System testing, or end-to-end testing, tests a properly) or deferred to be dealt with later. completely integrated system to verify that it meets  Defect Retesting: Once a defect has been [36] its requirements. For example, a system test might dealt with by the development team, it is involve testing a logon interface, then creating and retested by the testing team. editing an entry, plus sending or printing results, AKA Resolution testing. followed by summary processing or deletion (or  Regression testing: It is common to have a archiving) of entries, then logoff. small test program built of a subset of tests, TESTING CYCLE: for each integration of new, modified, or Although variations exist between organizations, fixed software, in order to ensure that the there is a typical cycle for testing. The sample below latest delivery has not ruined anything, and is common among organizations employing that the software product as a whole is still the Waterfall development model. The same working correctly. practices are commonly found in other development  Test Closure: Once the test meets the exit models, but might not be as clear or explicit. criteria, the activities such as capturing the  Requirements analysis: Testing should key outputs, lessons learned, results, logs, begin in the requirements phase of documents related to the project are the software development life cycle. archived and used as a reference for future During the design phase, testers work to projects. determine what aspects of a design are

IJIRT 142783 273

REFERNCES 1. McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press. p. 2. Jump up^ Bossavit, Laurent (2013-11-20). The Leprechauns of Software Engineering--How folklore turns into fact and what to do about it. Chapter 10: leanpub. 3. Jump up^ see D. Gelperin and W.C. Hetzel 4. ^ Jump up to:a b Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. 5. Jump up^ Company, People's Computer (1987). "Dr. Dobb's journal of software tools for the professional programmer". Dr. Dobb's journal of software tools for the professional programmer (M&T Pub) 6. Software Testing by Jiantao Pan, Carnegie Mellon University 7. Jump up^ Leitner, A., Ciupa, I., Oriol, M., Meyer, B., Fiva, A., "Contract Driven Development = Test Driven Development – Writing Test Cases", Proceedings of ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007, (Dubrovnik, Croatia), September 2007

IJIRT 142783 274

INTERNATIONAL JOURNAL OF INNOVATIVE RESEARCH IN TECHNOLOGY