PHASES OF SOFTWARE PROJECT A software project is made up of a serious of phases.

Most software projects compress the following phases:

Requirements gathering and analysis Planning Designing Development or coding Testing Deployment and maintenance

REQUIREMENTS GATHERING AND ANALYSIS During requirements gathering the specific requirements of the software to be built are gathered and documented.

PLANNING The purpose of the planning phases is to come up with a schedule. The scope and resource requirement for release. DESIGNING The purpose of the design phase is to figure out how to satisfy the requirements enumerated in the system requirement specification document. DEVELOPMENT OR CODING It compresses coding the programs in the chosen programming language. TESTING The testing is the process of exercising the software product in predefined way to check if the behavior is the same as expected behavior.

DEPLOYMENT AND MAINTENANCE The product now enter the maintenance phase where the product is maintained or changed to satisfy the changes that arises from customer expectation environment changes tec.., Maintenance is made up of corrective maintenance, adaptive maintenance and preventive maintenance. Quality: Quality is meeting the requirements expected of the software consistently and predictable. A software product is designed to satisfy certain requirements of a given customer. The expected behavior is characterized by a set of a test case. Each test case is further characterized by The environment under which the test case is to be executed. Inputs that should be provided for the test case. How these inputs should get preceded. What changes should be produced in the internal state or environment. What output should be produced.

QUALITY ASSURANE Concentrate on the process of producing the products. Defect preventing oriented. Usually done through out the life cycle. This is usually a staff function. Example : Reviews and Audits.

QUALITY CONTROL Concentrates on specific products. Defect detection and correction oriented. Usually done after the product is built.

This is usually a line function. Examples software testing at various levels.

VERIFICATION Verification is the process of evaluating a system or component to determine whether the product of a given phase satisfies the conditions imposed at the start of that phase. Quality assurance = Verification VALIDATION Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfy the specified requirements. Quality Control = Validation = Testing PROCESS MODEL TO REPRESENT DIFFERENT PHASES Process model is a way to represent any given phases of the software development that effectively built in the concepts of validation and verification to prevent and minimize the delay between defect injection and defect detection. This model known as the Entry Task Verification Exit or ETVX Model offer several advantages for effective verification and validation. Clear entry criteria make sure that a give phase does not start prematurely. The verification for each phase helps prevent defects or at least minimize the time delay between defect injection and defect detection. Documentation of the detailed task that compress each phase reduced the ambiguity interpretation of the instructions and thus minimizes the variations that can come from repeated executions of these task by different individuals. Clear exit criteria provide a means of validation after the phase is done but before handing over to the next phase. LIFE CYCLE MODEL A life cycle model describes how the phase combine together to form a complete project or life cycle. Such a model is characterized by the following attributes:

Activities performed Deliverable from each activity Methods of validation of the deliverable Sequence of activities

ACTIVITY PERFORMED: Any given software project apart form the most common activities or phases requirement gathering, design, development, testing and maintenance there could be other activities as well. DELIVERABLE FROM EACH ACTIVITY Each activity produces a set of deliverables which are the end products of that activity

METHODS OF VALIDATION OF THE DELIVERABLE The outputs produced by a given activity represent the goal to be satisfied by that activity. SEQUENCE OF ACTIVITIES The different activities work together in unison in a certain sequence of a steps to achieve overall project goals.

WHITE BOX TESTING What is white box testing? It is the way of testing the external functionality of the code by examine and testing the program code that realize external functionality. This is also known as clear box or glass box or open box testing. White box testing takes into account the program code, code structure and internal design code. White box testing is classified into static and structural Static Testing:

It is the type of testing which requires only the source code of the product not the binaries or executables. It does not involves executing the programs in computers, but involves select people going through the code to find out whether The code works according to the functional requirement The code has been written in accordance with the design developed earlier in the project life cycle. The code for any functionality has been missed out The code handles error properly It can be done by human or with the help of specialized tools STATIC TESTING BY HUMANS: These methods relay on the principle of humans reading the program code to detect errors rather then computer executing the code to find error. There are multiple methods to achieve static testing by humans. They are as follows: Desk checking of the code Code walk through Code review Code instruction STRUCTURAL TESTING It takes into account the code structure internal design and how they are coded. The fundamental difference between structural and static testing is that in structural testing tests are actually run by the computer on the built product where as in static testing the products is tested by humans using just the source code not the executable or binaries. Structural testing can be classified into Unique/code functional testing Code coverage Complexity testing

CHALLENGES IN WHITE BOX TESTING White box testing requires a sound knowledge of the program code and the programming language. This means that the developers should get intimately involved in white box testing. Human tendency of the developer being unable to find the defects in his or her code. Fully tested code may not correspond to realistic scenario.

UNIT : II BLACK BOX TESTING What is black box testing? It is done without the knowledge of the internals of the system under test. It is done from the customers view point. It looks at the specifications and does not require examine the code of a program. It is convenient to administrator because they use the complete finished product and do not require any knowledge of this construction. Why Black box testing? Overall functionality verification It is done based on requirements It addresses the stated requirements as well as implied requirements It encompasses the end user perspectives It handles valid and invalid inputs When to do black box testing? Black box testing activities require involvement of the testing team from the beginning of the software project life cycle, regardless of the software development life cycle model choosen from the project. Testers can get involved right from the requirements gathering and analysis phase for the system under test. Once the code is ready and delivered for testing, test execution can be done. How to do black box testing? It exploits specification to generate test cases in a methodical way to avoid redundancy and to proved better coverage. Various techniques to be used to generate test scenarios for effective black box testing. Various techniques are Requirements based testing Positive and negative testing Boundary value analysis

Decision table Equivalence partitioning State based testing User documentation testing Domain testing

INTEGRATION TESTING What is integration testing ? The set of interactions among components Testing the interaction between the modules and interaction with other system externally. It is both a type of testing and a phase of testing. INTEGRATION AS A TYPE OF TESTING: Integration testing means testing of interfaces. Two types of interfaces Internal interface and exported/external interfaces . Internal interfaces are provide communication across two modules with in a project or product, internal to the product and not exposed to the customer or external developers. Exported interfaces are those that are visible outside the product to third party developers and solution provider. Integration testing is done with test case which goes through the internal and exported interface, and tests the functionality of the software. The exported interface where provided through APIs and Software Development Kit. Integration testing type focuses on testing interfaces that are implicit and explicit and internal and external. There are several methodologies available, to in decide the order for integration testing. Top down integration Bottom up integration

Bi directional integration System integration TOP DOWN INTEGRATION Integration testing involves testing the top most components interface with other components in same order as you navigate from top to bottom till you all the components. BOTTOM UP INTEGRATION It is just the opposite of top down integration, where components for a new product development become available in reverse order starting from the bottom. Arrow pointing down depict, logic flow, arrow pointing out indicate integration path. BI DIRECTIONAL INTEGRATION It is the combination of the top down and bottom up integration approaches used together to derive integration steps. INTEGRATION TESTING AS A PHSAE OF TESTING: It starts form the point where two components can be tested together, to the point where all the components work together as a complete system, delivering system or product functionality. Integration testing phase focuses on finding defect which predominantly arise because of combining various component for testing, and should not be focused on for component and few components. Integration testing as a phase involves different activities and different types of testing have to be done in that phase. This is a testing phase that should ensure completeness and coverage of testing for functionality. The integration testing phases involves developing and executing test cases that cover multiple components and functionality.

SCENARIO TESTING It is defined as a set of realistic user activities that are used for evaluating the product. It is also defined as the testing involving customer scenarios. There are two methods: System Scenarios Use Case Scenarios / role based scenarios

SYSTEM SCENARIO It is a method where by a set of methods used for scenario testing covers several components in the system. The following approaches can be used to develop system scenarios: Story line Life cycle or state transition Deployment or implementation stories from customer Business verticals Battle ground

USE CASE SCENARIO It is the step wise procedure on how a user intends to use a system with different user roles and associated parameters. It terms as the user with different role as a actors. What the product should do for a particular activity is termed as a system behavior. User with the specific role to interact between the actor and the system are called agents. DEFECT BASH It is an adhoc testing a people performing different roles in an organization test the product together at the same time. The activities in the defect bash are planned activities expected for what to be tested. It involves several steps: Choosing the frequency and duration of defect bash Selecting the right product built Communicating the objective of defect bash Setting up and monitoring the lab for defect bash Taking actions and fixing issues Optimizing the effort involved in defect bash