Business Analyst QA Training Tech Landmark Inc 71

Business Analyst / QA Training Tech Landmark Inc. 71 Pond Street 23 A, Quincy, MA 02169 info@Tech. Landmark. com Private & Confidential 1

Project & Operations According to the PMBOK: “A project is a temporary endeavor undertaken to create a unique product or service. ◦ Temporary means that the project has an end date. ◦ Unique means that the project's end result is different than the results of other functions of the organization. ” Operations is defined as “the recurring activities of an organization directed toward producing a product or rendering a service. such activities may include, but are not limited to, marketing, sales, production, purchasing, human resources, finance and accounting. ” Private & Confidential 2

Project Management Project management is concerned with the overall planning & co-ordination of a project from inception to completion aimed at meeting the client's requirements & ensuring completion on time, within cost and required quality standards. Project management is the application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of the particular project. Project management knowledge and practices are best described in terms of their 5 component processes. ◦ Initiating, ◦ Planning, ◦ Executing, ◦ Controlling and ◦ Closing. Private & Confidential 3

Important Terms Sign-off - The process of agreeing in writing, to the scope of a project or the acceptability of a deliverable. Stakeholders - Specific people or groups who have a stake in the outcome of the project. Normally they are from within the company, & include internal clients, management, employees, administrators, etc. Methodology - A methodology represents a package of practical ideas and proven practices for a given area of activity, such as the planning, design development or management of IT-based systems. Project Plan - A description of the project that divides it into sub-projects, including start and completion times, responsible parties, interdependence of work steps, and resources needed. Private & Confidential 4

Role of a Business Analyst (BA) Business Analysts are responsible for identifying the business needs of their clients and stakeholders to help determine solutions to business problems. Translate what the user is asking for into a technical form that the programmer or web developer can understand. Business Analyst elicits, analyzes, validates and documents business, organizational and/or operational requirements. The Business Analyst is a key facilitator within an organization, acting as a bridge between the client, stakeholders and the solution team. Private & Confidential 5

Role of a Tester / QA Analyst QA analyst is required to create and execute test scripts / cases and validate expected results and log defects. Such individuals develop and use stringent testing methods. Creates test plans and executes test cases; by reviewing technical documentation that includes business requirements, functional specs, design, and release content documents. Software QA involves the entire software development PROCESS: ◦ Monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, ◦ and ensuring that problems are found and dealt with. It is oriented to 'prevention‘. Private & Confidential 6

Methodologies & Requirements Private & Confidential 7

Software Development Life Cycle The Software Development Life Cycle is a conceptual model used in project management that describes the stages involved in an IS development project, from an initial feasibility study through maintenance of the completed application. Software development is the process of developing software through successive phases in an orderly way. It is a complicated process as it requires careful planning and execution to meet the goals. Different phases in this development process include the actual writing of code, preparation of requirements and objectives, the design of what is to be coded, and confirmation that what is developed has met objectives. Prior to SDLC methods, the development of new systems or software was often carried out by using the experience and intuition of management and technical personnel. Private & Confidential 8

Steps Involved in SDLC The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel. The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement. The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage. Private & Confidential 9

Steps Involved in SDLC The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once. Once the new system is up & running, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures. Private & Confidential 10

Different Methodologies Used Various SDLC methodologies have been developed to guide the processes involved, including but not limited to: ◦ Rational Unified Process, ◦ SUMMIT, ◦ Brainstorming, ◦ The Waterfall Model, ◦ Rapid Application Development (RAD), ◦ Joint Application Development (JAD) ◦ The Fountain Model and, ◦ The Spiral Model. Private & Confidential 11

Rational Unified Process (RUP) The Rational Unified Process is an iterative software design method that describes how to deploy software effectively using commercially proven techniques. It is not a rigid process but a process framework that encompasses a large number of different activities, and is designed to be tailored/customized according to requirements. The RUP consists of 4 major stages: ◦ Inception ◦ Elaboration ◦ Construction & ◦ Transition. Private & Confidential 12

Rational Unified Process (RUP) The Inception Phase: ◦ In this phase a business case which includes: business context, success factors such as (expected revenue, market recognition, etc), and financial forecast are established. ◦ Besides a business case, a basic use case model, project plan, initial risk assessment and a document that generally describes the project (the core project requirements, constraints and key features) are realized. The Elaboration Phase: ◦ The Elaboration phase is where big things happen, in this phase the problem domain analysis is made and also the architecture of the project gets its basic form. ◦ There is big step from this to next because this step means transition from lowrisk operation to high-risk operation. Private & Confidential 13

Rational Unified Process (RUP) The Construction Phase ◦ In this phase the main focus goes to the development of components and other features of the system that is being developed. This is the phase when coding takes place. ◦ At the end of this phase the first release of the software product is expected and this is a major criterion of its milestone. The Transition Phase ◦ In the transition phase the product moves from the development organization to the end user. In software world the first release of a product doesn't mean that the whole system under development will work. ◦ A subset of the system or the whole system is completed against an acceptable quality level and after that new releases will be made to the system until completion and the expected quality level is reached. Private & Confidential 14

SUMMIT Methodology The SUMMIT (a. k. a. SUMMIT Ascendant) Tool is an IBM product that contains a wealth of information, standards and proven processes for to help deliver technology projects. SUMMIT Ascendant is a process solution that delivers a comprehensive library of methods for planning and managing enterprise IT project and programs. The process framework is supported by tools for planning, estimating, and monitoring a project or portfolio of projects. Private & Confidential 15

SUMMIT Methodology - Phases Requirements Analysis Phase: ◦ The purpose of this phase is to document the scope, business objectives, and requirements of the system. ◦ Based upon this input, the project team can then examine the alternative approaches that can be used to solve the business problem and recommend an approach. ◦ If business processes have been redesigned in a business process reengineering or strategy project, then the requirements should be based on the new processes. Private & Confidential 16

SUMMIT Methodology – Phase Deliverables System Prospectus: ◦ Provide the project stakeholders & team with scope, business objectives, and requirements of the system as well as alternative approaches that can be used to solve the business problem. Requirements Specification: ◦ Provides the project stakeholders & team with the complete baselined set of requirements to solve business problem/opportunity identified in the Project Charter. Attached as appendix document in the System Prospectus. Test Strategy: ◦ Sets the framework for the testing effort, which is expanded in the Test Plan. Attached as appendix in the System Prospectus. Private & Confidential 17

SUMMIT Methodology - Phases Solution Definition Phase: ◦ The objective of this phase is a functional or external description for user approval. This is sometimes called external design. ◦ The System Delivery Specification is the documentary key deliverable developed during the Solution Definition phase. ◦ It includes information on functions, user interfaces, manual processes, automated processes, data structures, security, control, back-up and contingency requirements, as well as relevant error handling procedures. Private & Confidential 18

SUMMIT Methodology – Phase Deliverables System Delivery Specification: ◦ Expands upon the user requirements and outline design documented in the System Prospectus to produce a detailed specification of the system to be delivered. ◦ The focus is still on user requirements; however, the emphasis is on WHAT the system is to do rather than HOW it is to be implemented. Test Plan: ◦ Expands upon the high-level planning documented in the Test Strategy document. ◦ The combination of the Test Plan and the Test Strategy describe in detail the scope, approach, resources and schedule of the testing activities. Private & Confidential 19

SUMMIT Methodology - Phases Design Phase: ◦ The Design phase of the project consists of the tasks necessary to describe how the proposed system is to be built or work is to be done. This is sometimes called technical design. ◦ During the Design phase, internal system design will be completed. Upon completion of the Design phase, the Technical System Design Document will be produced. Private & Confidential 20

SUMMIT Methodology – Phase Deliverables Technical System Design ◦ Describes how the proposed system is to be built, continuing from the System Delivery Specification document. Test Case Log ◦ Provide a place to track all test cases for all testing stages for the project and to use as a "Status" of the testing effort. Defect Reporting Form ◦ Provides a structured format for documenting defects that are identified during testing. Test Report Form ◦ Summarizes the outcome of the completed test stage and a recommendation on whether or not the project should proceed to the next Test stage. Private & Confidential 21

SUMMIT Methodology - Phases Build & Test Phase: ◦ The objective of the Build and Test phase is to construct and test the final system solution. ◦ During the Build and Test phase the actual programming of the system, the design and development of user procedures, and the system and user testing of the entire system will be completed. Private & Confidential 22

SUMMIT Methodology – Phase Deliverables ◦ Consolidated User Procedures The User Procedures Development tasks produce the following three documentary deliverables: User Procedures Manual User Staff and Resources Requirements Training Program. ◦ Accepted System The Accepted System is the new system that is accepted by the user before it moves to production. The Accepted System documentation includes the following: Private & Confidential 23

SUMMIT Methodology – Phase Deliverables ◦ Acceptance Approvals These are formal documents received from the User accepting the new system. ◦ Unresolved Issues This is a list of all issues that were documented from the user acceptance tests. Identify each issue along with the action plan and responsible person to resolve it. ◦ Acceptance Tested Software The Acceptance Tested Software is the new system supported by the assurance that it has been successfully tested from the user perspective and has satisfactorily met the user expectations. Private & Confidential 24

SUMMIT Methodology - Phases Transition Phase: ◦ The objective of the final phase of most projects is to transition to live operation. It should also set the stage for a Post-Implementation Review on larger projects. Private & Confidential 25

SUMMIT Methodology – Phase Deliverables The key or major client deliverables of the Transition phase activities include the Converted Data and the Production System supported by the Production System Review Report. The user accepted production system from the Testing phase is converted into a production system. Following the User Transition Sign. Off directive, the new system is the only production system that is officially supported by the IT staff and user management. The Production System Review Report is completed in a few weeks following the official cut over date. It is used by IT and user management as a base for action to resolve any pending problems and reassurance that the project is completed and the user is getting the expected benefits. Private & Confidential 26

The Waterfall Model is a software development model describing the naive approach to software development in which development is seen as flowing steadily through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. Often considered the classic approach to the SDLC, the Waterfall Model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. Private & Confidential 27

Brainstorming It is a method used to generate ideas on causes and possible solutions to process problems. A brainstorming session usually involves a group of people getting together and listing ideas. Analysis and commentary on ideas is held off until after the brainstorming session has concluded. A group process used to generate a large number of ideas about specific issues in a non-judgmental environment. Brainstorming is typically used as a synonym for ”talking in a group”. It is a highly structured process to help generate ideas that is based on the principle that you cannot generate & evaluate ideas at the same time. You must first gain agreement from the group to try brainstorming for a fixed interval. Private & Confidential 28

RUP vs SUMMIT vs Waterfall Rational Unified Process SUMMIT Methodology Waterfall Method Inception Requirements Analysis Elaboration Solution Definition Design Construction Design Implementation Transition Build and Testing Transition Integration Maintenance Private & Confidential 29

What are Requirements? In software engineering, a requirement is a description of what a system should do. Systems may have from dozens to hundreds of requirements. A requirement describes a condition to which a system must conform; either derived directly or indirectly from user needs. A requirement for a computer system specifies what you want or desire from a system. Requirements should be: ◦ unique in scope, ◦ precise in wording, ◦ bounded by concrete expectations and ◦ irrefutably testable. Private & Confidential 30

Characteristics of Requirements? Is it Unique? ◦ Is this the only requirement that defines this particular objective? Is it Precise? ◦ Are there any vague words that are difficult to interpret? Is it Bounded? ◦ Are there concrete boundaries in the objectives? Is it Testable? ◦ Can you build one or more test cases that will completely verify all aspects of this requirement? Private & Confidential 31

Sample Requirement Example: ◦ “The system response time shall always be reasonable for all critical transactions. ” Revised Answer: “The system response time for “end-to-end transactions” for “Download” shall always be “less than 5 seconds. ”” Private & Confidential 32

Requirements vs Specifications There is a distinct difference between requirements and specifications. ◦ A requirement is a condition needed by a user to solve a problem or achieve an objective. ◦ A specification is a document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system, and often, the procedures for determining whether these provisions have been satisfied. For example, a requirement for a car could be that the maximum speed to be at least 120 mph. The specification for this requirement would include technical information about specific design aspects. Private & Confidential 33

Software Requirements Specification (SRS) An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system (i. e. , a software application, an e. Commerce Web site, and so on) must provide, as well as states any required constraints by which the system must abide. Private & Confidential 34

Software Requirements Specification (SRS) The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the “parent” document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. Private & Confidential 35

Components of SRS is typically developed during the first stages of “Requirements Development” which is the initial product development phase in which information is gathered about what requirements are needed or not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a (ROI) analysis or needs analysis of the customer or client's current business environment. A well-designed, well-written SRS accomplishes four major goals: ◦ It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language versus a formal language in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. Private & Confidential 36

Components of SRS ◦ It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. ◦ It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. ◦ It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification. Private & Confidential 37

User Requirement Specification (URS) The User Requirements Specification is a document produced by, or on behalf of your organization, which documents the purposes for which a system is required - its functional requirements - usually in order of priority / gradation. While the URS will not usually probe the technical specification, it will however outline the expectations and, where essential may provide further detail e. g. the UI, say Microsoft Windows, & the expected hardware platform etc. The URS is an essential document which outlines precisely what the user is expecting from this system. The term User Requirement Specification can also incorporate the functional requirements of the system or may be in a separate document labeled the Functional Requirements Specification - the FRS. Private & Confidential 38

Functional Requirements These are the requirements that express what a software solution should do to solve some customer problem. Traditionally, functional requirements describe what tangible outputs are produced by a software solution for a given suite of inputs. Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. Functional requirements also include behavior rules, standards, policies, and other factors from the customer problem space that affect what the software needs to do to the inputs in order to provide the specified outputs. These are the type of behavior you want the system to perform. Private & Confidential 39

Functional Requirements If you were buying vehicles for a business your functional requirement might be: ◦ The vehicle should be able to take a load from a warehouse to a shop. Similarly for a computer system you define what the system is to do. For example: ◦ The system should store all details of a customer’s order. The important point to note is that WHAT is wanted is specified, and not HOW it will be delivered. Private & Confidential 40

What is a Use Case? A Use Case is a top level category of system functionality (i. e. : Log on, Shut down, etc. ). A Use Case has graphical representation and/or a text description. The diagram or description identifies all the actors (outside of the system) involved in the function, as well as an indication of how the Use Case is initiated. The collection of Use Case diagrams provides a ‘context’ diagram of system interfaces. Each Use Case constitutes a complete list of events initiated by an Actor and it specifies the interaction that takes place between an Actor and the System. In a Use Case the system is viewed as opaque, where only the inputs, outputs, and functionality matter. Private & Confidential 41

Use Cases – Contd. A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system. ◦ A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance. A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. The Use Case also includes possible variants of this sequence, e. g. , alternative sequences that may also satisfy the goal, sequences that may lead to failure to complete the service due to exceptional behavior, error handling, etc. Private & Confidential 42

Use Cases – Contd. The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system. Private & Confidential 43

Components of a Use Case? The Use Case diagram just provides a quick overview of the relationship of actors to Use Cases. The meat of the Use Case is the text description. This text will contain the following: ◦ Name ◦ Brief Description ◦ SRS Requirements Supported ◦ Pre & Post Conditions ◦ Event Flow The requirements in the SRS are each uniquely numbered so that they may be accounted for in the verification testing. These requirements should be mapped to the Use Case that satisfies them for accountability. Private & Confidential 44

Components of a Use Case? The Pre-Condition specifies the required state of the system prior the start of the Use Case. This can be used for a similar purpose in the Test Case. The Post-Condition is the state of the system after the actor interaction. This may be used for test pass/fail criteria. The event flow is a description (usually a list) of the steps of the actor’s interaction with the system and the system’s required response. Recall that system is viewed as a black box. The event flow contains exceptions, which may cause alternate paths through the event flow. Private & Confidential 45

Sample Use Case / Test Case Monitor and control the normal entry and exit of building occupants through the use of personal security cards. This includes entry and exit of the building proper, and entry and exit from particular security zones within the building. The system controls the locks on the doors, and will not unlock a door unless the appropriate security card is swiped through the card reader by the door. Private & Confidential 46

Sample Use Case / Test Case Enter Building Event Flow ◦ Use case starts when user slides card through card-reader ◦ Card-reader scans employee ID from card [E 1] ◦ System validates employee access [E 2] ◦ System unlocks door for configured time period [E 3] ◦ Employee opens door [E 4] ◦ Employee enters and door shuts [E 5] ◦ System locks door [E 6], ◦ Use Case ends Private & Confidential 47

Sample Use Case / Test Case The following events and the associated exceptions can then be generated for the Enter Building use case. ◦ Use case starts when the user slides a card through the card-reader ◦ Card-reader scans employee ID from card Exception 1: ◦ Card can’t be read ◦ Log event ◦ Use case ends ◦ System validates employee access Exception 2: ◦ Employee ID is invalid ◦ Log event ◦ Use case ends ◦ System unlocks door for configured time period Private & Confidential 48

Sample Use Case / Test Case Exception 3: ◦ System unable to unlock door ◦ Log event ◦ Use case ends ◦ Employee opens door Exception 4: ◦ Door is not opened ◦ System waits for timeout ◦ System locks door ◦ Use case ends ◦ Employee enters and door shuts Private & Confidential 49

Sample Use Case / Test Case Exception 5: ◦ ◦ ◦ ◦ Door is not shut System waits for timeout System attempts to lock door Log event Set alarm condition Use case ends System locks door, Use case ends Exception 6: ◦ ◦ ◦ Door fails to lock System waits for timeout System attempts to lock door Log event Set alarm condition Use case ends Private & Confidential 50

Sample Use Case / Test Case For this Use Case, based on the above events and exceptions, we have derived the following Test Case. Test Condition 1: ◦ Happy days scenario – valid employee card is used ◦ Swipe card ◦ Verify door is unlocked ◦ Enter building ◦ Verify door is locked Test Condition 2: ◦ Card can’t be read ◦ Swipe a card that is not valid ◦ Verify event is logged Private & Confidential 51

Sample Use Case / Test Case Test Condition 3: ◦ ◦ Swipe card with invalid employee ID Verify door is not unlocked Verify event is logged Test Condition 4: ◦ ◦ Invalid employee ID System unable to unlock door Swipe card “Injected” failure of unlocking mechanism Verify event is logged Test Condition 5: ◦ ◦ ◦ Door is not opened Swipe card Verify door is unlocked Don’t open the door and wait until timeout is exceeded Verify door is locked Private & Confidential 52

Sample Use Case / Test Case Test Condition 6: ◦ Door is not shut after entry ◦ Swipe card ◦ Enter building ◦ Hold door open until timeout is exceeded ◦ Verify alarm is sounded ◦ Verify event is logged Test Condition 7: ◦ Door fails to lock ◦ Swipe card ◦ Enter building ◦ “Injected” failure of locking mechanism ◦ Verify alarm is sounded ◦ Verify event is logged Private & Confidential 53

Traceability Matrix The requirements traceability matrix is a table used to trace project life cycle activities and work products to the project requirements. The matrix establishes a thread that traces requirements from identification through implementation. In a software development process, the traceability matrix is a table that correlates the high-level requirements (sometimes known as Marketing Requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed Design, test plan (a. k. a. Test Outline), and test case. It can also be used between any two documents that require a many to many relationship to determine completeness. Private & Confidential 54

Gap & Impact Analysis In information technology, gap analysis is the study of the differences between two different information systems or applications, often for the purpose of determining how to get from one state to a new state. A gap is sometimes spoken of as “the space between where we are and where we want to be. ” Gap analysis is undertaken as a means of bridging that space. The process of determining, documenting, and approving the variance between business requirements and system capabilities in terms of packaged application features and technical architecture. The process of determining and evaluating the variance or distance between two items’ properties being compared. It is an analysis of the gap between requirements that are met and not met; a deficiency assessment. Private & Confidential 55

Gap & Impact Analysis The identification of critical business processes, and the potential damage or loss that may be caused to the organization resulting from a disruption to those processes. Business impact analysis (BIA) is an essential component of an organization's business continuance plan; it includes components to reveal any vulnerabilities, and a planning component to develop strategies for minimizing risk. The result of analysis is a BIA report, which describes the potential risks specific to the organization studied. One of the basic assumptions behind BIA is that every component of the organization is reliant upon the continued functioning of every other component, but that some are more crucial than others and require a greater allocation of funds in the wake of a disaster. For example, a business may be able to continue more or less normally if the Private & Confidential cafeteria has to close, but would come to a complete halt if the information system 56

Unified Modeling Language (UML) The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other nonsoftware systems. UML includes a standardized graphical notation that may be used to create an abstract model of a system: the UML model. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. Private & Confidential 57

Types of UML Diagrams UML diagrams commonly created in visual modeling tools include: ◦ Use Case Diagram displays the relationship among actors and use cases. ◦ Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. ◦ Interaction Diagrams Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects). Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages. Private & Confidential 58

Types of UML Diagrams ◦ State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. ◦ Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing. ◦ Physical Diagrams Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time. Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. Private & Confidential 59

Use Case Diagram A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors. Use Case Actor An actor represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task. Private & Confidential 60

Activity Diagram Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel. The main reason to use activity diagrams is to model the workflow behind the system being designed. Activity Diagrams are also useful for analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes. Private & Confidential 61

Activity Diagram Private & Confidential 62

Statechart Diagram Objects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state. As shown in example, the notation set of the statechart diagram has five basic elements: the initial starting point, which is drawn using a solid circle; a transition between states, which is drawn using a line with an open arrowhead; a state, which is drawn using a rectangle with rounded corners; a decision point, which is drawn as an open circle; and one or more termination points, which are drawn using a circle with a solid circle inside it. To draw a statechart diagram, begin with a starting point and a transition line pointing to the initial state of the class. Private & Confidential 63

State Chart Diagram Private & Confidential 64

Entity – Relationship Diagrams Identifies the data required by the business. An entity corresponds to a person, place thing, event, or concept about which we are interested in recording data. Entities must be clearly defined so that all understand exactly what is being represented. 2 entities whose information is somehow dependent on one another or connected with each other are said to have a relationship between them. Relationships are evaluated in both directions to determine what type of relationship exists (e. g. “ 1 friend may have many telephones”, and “ 1 telephone belongs to a single friend”). Private & Confidential 65

Components of an ERD Entities are drawn in boxes. Entities should be expressed in the plural. The existence of a relationship between two entities is drawn as a line connecting the entities. Arrows at the ends of the lines indicate different types of relationships (one-toone, one-to-many, many-to-many). Verbs may be placed on the relationship lines that describe what the relationships mean (e. g. “addresses locate businesses”, where “addresses” and “businesses” are related entities, and “locate” is the verb describing the relationship). Lists of attributes are developed as you go. (An attribute is a single piece of information that is descriptive of an entity, e. g. friend name, friend e-mail). A single attribute for each entity is selected (or an arbitrary one is assigned) as being the unique identifier for each occurrence of the entity (e. g. business id number to uniquely identify a business). Private & Confidential 66

SQL Commands SELECT Statement - The SELECT statement is used to select data from a table. ◦ SELECT column_name(s) FROM table_name INSERT INTO Statement - The INSERT INTO statement is used to insert new rows into a table. ◦ INSERT INTO table_name (column 1, column 2, . . . ) VALUES (value 1, value 2, . . ) UPDATE Statement - The UPDATE statement is used to modify the data in a table. ◦ UPDATE table_name SET column_name = new_value WHERE column_name = some_value Private & Confidential 67

SQL Commands UPDATE Statement - The UPDATE statement is used to modify the data in a table. ◦ UPDATE table_name SET column_name = new_value WHERE column_name = some_value DELETE Statement - The DELETE statement is used to delete rows in a table. ◦ DELETE FROM table_name WHERE column_name = some_value ORDER BY - The ORDER BY keyword is used to sort the result. ◦ SELECT column_name 1, column_name 2 FROM table_name ORDER BY cloumn_name 1 Private & Confidential 68

Introduction to QA / Testing Private & Confidential 69

Facts Programmers are experts at building software. Testers are experts at breaking software. Programmers & Testers have a common objective. Destructive attitude while testing. Constructive attitude for dealing with the developer. Private & Confidential 70

What is Quality Assurance? The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented. Quality assurance is the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures. ◦ Processes include all of the activities involved in designing, developing, enhancing, and maintaining software. ◦ Products include the software, associated data, its documentation, and all supporting and reporting paperwork. Private & Confidential 71

What is Testing? The process of exercising software to verify that it satisfies specified requirements and to detect errors. Testing involves operation of a system or application under controlled conditions to evaluate results. The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented towards “detection”. Private & Confidential 72

Why do we need testing? Programmers are too close to their product. Misinterpretation of the specifications. Programmers usually do not test from product point of view. Developers are building more complex systems in shorter time. Need to ensure system works before its is turned over to the business. Track defects in the newly developed software/system. Private & Confidential 73

Why does software have bugs? Miscommunication or lack of communication. Software Complexity / Software Development Tools. Programming Errors. Changing Requirements. Time Pressures. Poorly Documented Code. Private & Confidential 74

Test Cases A test case is a document that describes an input, action, or event and an expected response. A QA engineer or other tester performs the test case scenario to determine if a specific feature of an application is working correctly. The process of developing test cases can help find problems in the requirements or design of an application since test case development requires thinking through the complete operation of the application. For this reason, it is useful to prepare test cases early in the development cycle. A test case contains: ◦ Detailed test set-up instructions. ◦ Detailed test procedure, including all steps or actions. ◦ Expected results and pass/fail criteria. Private & Confidential 75

How to Write Good Test Cases Requirement writers and developers often do not know the full scope of how the system will be used. Test the system in a way that it is not intended to be used. Deviations may occur due to the variety of reasons: ◦ User Errors. ◦ Program Errors. ◦ Data Errors. System should handle deviations gracefully. Private & Confidential 76

How to Write Good Test Cases Use your imagination and ask “How can I break the system? ” ◦ Invalid data (type, size, structure, special symbols, etc) ◦ Invalid syntax (keywords, delimiters, separators, terminators, operators, constructions, combinations, etc) ◦ Invalid objects/resources (non-existent, invalid type, inaccessible, protected, etc. ) ◦ Invalid sequence (operations, tasks, keystrokes, mouse clicks, etc. ) ◦ Invalid limits (data, items, characteristics, number of data items, table size, query size, I/O streams, file size). ◦ Invalid configuration parameters (home directory, log file location, database connection names, maximum number of resources, etc. ) Therefore we should have positive scenarios and negative scenarios. Private & Confidential 77

What is a Test Script? Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool. Test script refers to a short program usually written in scripting language which can test some set of features of the system under test (SUT). Test scripts are used to automate software testing. Automatically executed test scripts are used for regression testing. This is a document, developed alongside the functional specification, which provides a checklist for testing your system after release from the programmers. It outlines the tasks that the system should be able to perform and the people who can perform those tasks. Private & Confidential 78

When Should Testing Occur? Requirements Phase ◦ Determine the test strategy. ◦ Determine adequacy of requirements. Design Phase ◦ Determine consistency of design with requirements. ◦ Determine adequacy of design. ◦ Generate structural and functional test conditions. Program (Build) Phase ◦ Determine consistency with design. ◦ Determine adequacy of implementation. ◦ Generate structural and functional test conditions for programs/units. Private & Confidential 79

When Should Testing Occur – Contd. Test Phase ◦ Determine adequacy of the test plan. ◦ Test application system. Installation Phase ◦ Place tested system into production. Maintenance Phase ◦ Modify and retest. Private & Confidential 80

Positive / Negative Testing What is Positive Testing? ◦ Positive testing is that testing which attempts to show that a given module of an application does not do what it is supposed to do. What is Negative Testing? ◦ Negative testing is that testing which attempts to show that the module does something that it is not supposed to do. Private & Confidential 81

Verification & Validation Verification: ◦ Involves reviews and meetings to evaluate documents, plans, code, requirements and specifications. Verification checks whether we are building the right system. Validation: ◦ Involves actual testing and takes place after verification. Validation checks whether we are building the system right. Private & Confidential 82

Verification Strategies Verification Strategy Explanation Deliverable Requirements Review The study and discussions of the computer system requirements to ensure they meet stated user needs and are feasible. Reviewed statement of requirements. Design Review The study and discussion of the computer system design to ensure it will support the system requirements. System Design Document, Hardware Design Document. Code Walkthrough Informal analysis of the program source code to find defects and verify coding techniques. Software ready for initial testing by the developer. Code Inspection Formal analysis of the program source code to find defects as defined by meeting system design specification. Software ready for testing by the testing team. Private & Confidential 83

Validation Strategies Validation Strategy Explanation Deliverable Unit Testing of single program, modules, or unit of code. Software unit ready for testing with other system component. Integration Testing of related programs, modules, or units of code. Portions of the system ready for testing with other portions of the system. System Testing of entire computer system. This kind of testing can include functional and structural testing. Performance Testing Tested computer system, based on what was specified to be developed. Testing of the application for the Stable application performance at stipulated times and performance. stipulated number of users. Private & Confidential 84

Validation Strategies – Contd. Validation Strategy Explanation Deliverable Alpha Testing of the entire computer system before rolling out to the UAT. Stable application. User Acceptance Testing (UAT) Testing of computer system to make sure it will work in the system regardless of what the system requirements indicate. Tested and accepted system based on the user needs. Installation Testing of the Computer System during the Installation at the user place. Successfully installed application. Beta Testing of the application after the installation at the client place. Successfully installed and running application. Private & Confidential 85

Types Of Testing Acceptance Testing ◦ Testing the system with the intent of confirming readiness of the product and customer acceptance. Ad Hoc Testing ◦ Testing without a formal test plan or outside of a test plan. With some projects this type of testing is carried out as an adjunct to formal testing. If carried out by a skilled tester, it can often find problems that are not caught in regular testing. Sometimes, if testing occurs very late in the development cycle, this will be the only kind of testing that can be performed. Sometimes ad hoc testing is referred to as exploratory testing. Alpha Testing ◦ Testing after code is mostly complete or contains most of the functionality and prior to users being involved. Sometimes a select group of users are involved. More often this testing will be performed in-house or by an outside testing firm in close cooperation with the software engineering department. Private & Confidential 86

Types Of Testing Automated Testing ◦ Software testing that utilizes a variety of tools to automate the testing process and when the importance of having a person manually testing is diminished. Automated testing still requires a skilled quality assurance professional with knowledge of the automation tool and the software being tested to set up the tests. Beta Testing ◦ Testing after the product is code complete. Betas are often widely distributed or even distributed to the public at large in hopes that they will buy the final product when it is released. Compatibility Testing ◦ Testing used to determine whether other system software components such as browsers, utilities, and competing software will conflict with the software being tested. Private & Confidential 87

Types Of Testing Configuration Testing ◦ Testing to determine how well the product works with a broad range of hardware/peripheral equipment configurations as well as on different operating systems and software. Functional Testing ◦ Testing two or more modules together with the intent of finding defects, demonstrating that defects are not present, verifying that the module performs its intended functions as stated in the specification and establishing confidence that a program does what it is supposed to do. Independent Verification and Validation (IV&V) ◦ The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The individual or group doing this work is not part of the group or organization that developed the software. A term often applied to government work or where the government regulates the products, as in medical devices. Private & Confidential 88

Types Of Testing Installation Testing ◦ Testing with the intent of determining if the product will install on a variety of platforms and how easily it installs. Integration Testing ◦ Testing two or more modules or functions together with the intent of finding interface defects between the modules or functions. Testing completed at as a part of unit or functional testing, and sometimes, becomes its own standalone test phase. On a larger level, integration testing can involve a putting together of groups of modules and functions with the goal of completing and verifying that the system meets the system requirements. (see system testing) Load Testing ◦ Testing with the intent of determining how well the product handles competition for system resources. The competition may come in the form of network traffic, CPU utilization or memory allocation. Private & Confidential 89

Types Of Testing Performance Testing ◦ Testing with the intent of determining how quickly a product handles a variety of events. Automated test tools geared specifically to test and fine-tune performance are used most often for this type of testing. Pilot Testing ◦ Testing that involves the users just before actual release to ensure that users become familiar with the release contents and ultimately accept it. Often is considered a Move-to-Production activity for ERP releases or a beta test for commercial products. Typically involves many users, is conducted over a short period of time and is tightly controlled. (see beta testing) Regression Testing ◦ Testing with the intent of determining if bug fixes have been successful and have not created any new problems. Also, this type of testing is done to ensure that no degradation of baseline functionality has occurred. Private & Confidential 90

Types Of Testing Security Testing ◦ Testing of database and network software in order to keep company data and resources secure from mistaken/accidental users, hackers, and other malevolent attackers. Software Testing ◦ The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The organization and management of individuals or groups doing this work is not relevant. This term is often applied to commercial products such as internet applications. (contrast with independent verification and validation) Stress Testing ◦ Testing with the intent of determining how well a product performs when a load is placed on the system resources that nears and then exceeds capacity. Private & Confidential 91

Types Of Testing System Integration Testing ◦ Testing a specific hardware/software installation. This is typically performed on a COTS (commercial off the shelf) system or any other system comprised of disparent parts where custom configurations and/or unique installations are the norm. User Acceptance Testing ◦ Same As Acceptance Testing. Private & Confidential 92

Test Phases Requirements Review Design Review Code Inspection Code Walkthrough Unit Testing Integration Testing Performance Testing System Testing Alpha Testing User Acceptance Testing Beta Testing Installation Testing Private & Confidential 93

Black Box Testing A software testing technique whereby the internal workings of the item being tested are not known by the tester. For example, in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications. Black-box test design treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional requirements. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box. Private & Confidential 94

Black Box Testing Advantages: ◦ The test is unbiased because the designer and tester are independent of each other. ◦ The tester does not need knowledge of any programming languages. ◦ The test is done from the point of view of the user, not the designer. ◦ Test cases can be designed as soon as the specifications are complete. Disadvantages: ◦ The test can be redundant if the software designer has already run a test case. ◦ The test cases are difficult to design. ◦ Testing every possible input stream is unrealistic because it would take a inordinate amount of time; therefore, many program paths will go untested. Private & Confidential 95

White Box Testing A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. White-box test design allows one to peek inside the "box" & focuses specifically on using internal knowledge of the software to guide the selection of test data. Synonyms for white-box include: structural, glass-box and clear-box. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. Private & Confidential 96

Web-Based Testing Navigation: ◦ Web-based applications allow the users to move around in a way that is much more unpredictable that in more traditional applications. ◦ Hyperlinks allow jumping between screens, data, applications, and servers in more arbitrary sequence. ◦ Testing user workflow for such applications is not straightforward as for more traditional applications. ◦ However, it should still be possible to construct reasonable workflow scenarios that many users may want to pursue. Private & Confidential 97

Web-Based Testing – Contd. Creative: ◦ Deviations to the workflow should be tested, such as jumping in and out of a specific workflow and repeatedly revisiting certain areas. ◦ Testers should now verify that all hyperlinks are complete and resources that are not reachable from anywhere else in the application. ◦ In Web world resources are reachable in more than one way; for example a section of a document can be reached either by scrolling or by a direct jump through a hyperlink. Private & Confidential 98

Web-Based Testing – Contd. ◦ Tester should explore what occurs if a hyperlink does a non-existent, inappropriate, or damaged object. ◦ The environment in which web-based applications run is more unpredictable and chaotic. ◦ Performance testing or stress testing of this environment will be determined if the product will be used on the internet or intranet. ◦ Different types of http browsers with their own distinct behavior. Private & Confidential 99

Test Environment Test Environment consists of hardware, software, test data, test scripts and test automation tools. Test Environment should be on different machines, network and have an independent set of libraries from development environment. The Test Environment should documented in the Test Strategy document. The Test Environment must be ready before testing starts. It is critical that developers should not be updating the software. Private & Confidential 10 0

What is a Defect? Nonconformance to requirements or functional / program specification. A discrepancy between a test case and the product requirements, design, or implementation. Defects can also occur in the test case itself. Popularly known as a bug. A programming error that causes the program to fail, i. e. not accomplish its nominal task. is a failure to conform to requirements. Private & Confidential 10 1

Defect Tracking Life Cycle The Tester finds the Bug while testing. Tester reports the Defect in the Defect Tracking Tool w/ Status “Open” The concerned developer is informed about the Defect. The Developer fixes the Defect. The Developer changes the Status to “Resolved”. If the Defect re-occurs, the status changes to “Re-Open” The Tester Re-Tests and changes Status to “Closed”. Private & Confidential 10 2

Defect Classification This section defines a defect Severity Scale framework for determining defect criticality and the associated defect Priority Levels to be assigned to errors found in the software/application being tested. The defects can be classified as follows: ◦ Critical: There is s functionality block. The application is not able to proceed any further. ◦ Major: The application is not working as desired. There are variations in the functionality. ◦ Minor: There is no failure reported due to the defect, but certainly needs to be rectified. ◦ Cosmetic: Defects in the User Interface or Navigation. ◦ Suggestion: Feature which can be added for betterment. Private & Confidential 10 3

Defect Priority The priority level describes the time for resolution of the defect. The priority level would be classified as follows: Immediate: Resolve the defect with immediate effect. At the Earliest: Resolve the defect at the earliest, on priority at the second level. Normal: Resolve the defect whenever possible. Later: Could be resolved at the later stages. Private & Confidential 10 4

Test Plan A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project: Private & Confidential 10 5

Components of Test Plan Title of the Project Identification of document including version numbers Revision history of document including authors, dates, approvals Table of Contents Purpose of document, intended audience Objective of testing effort Software product overview Relevant related document list, such as requirements, design documents, other test plans, etc. Relevant standards or legal requirements Traceability requirements Relevant naming conventions and identifier conventions Test organization and personnel/contact-info/responsibilities Assumptions and dependencies Private & Confidential 10 6

Components of Test Plan Project risk analysis Testing priorities and focus Scope and limitations of testing Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable Outline of data input equivalence classes, boundary value analysis, error classes Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems Test environment setup and configuration issues Test data setup requirements Database setup requirements Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs Test automation - justification and overview Private & Confidential 10 7

Components of Test Plan Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs Test tools to be used, including versions, patches, etc. Test script/test code maintenance processes and version control Problem tracking and resolution - tools and processes Project test metrics to be used Reporting requirements and testing deliverables Software entrance and exit criteria Initial sanity testing period and criteria Test suspension and restart criteria Personnel pre-training needs Test site/location Relevant proprietary, classified, security, and licensing issues. Appendix - glossary, acronyms, etc. Private & Confidential 10 8

Test Metrics Collection of Test Metrics must be done every week during product test. The Test metrics required by QMO are: ◦ Total Tests. ◦ Tests Run. ◦ Tests Passed. ◦ Tests Failed. ◦ Tests Deferred. ◦ Tests passed the first time. The QMO quality records generated during System testing are ◦ The final pass/fail status of each test case. ◦ List of MRs. Private & Confidential 10 9

When to test more & when to stop Functional areas should be vigorously tested as long as error detection % exhibits upward trend. If the trend is downward, then testing effort might be shifted to other areas. The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section. Therefore high error areas should be thoroughly checked. Testing should continue until error detection is within an acceptable level of quality. All areas of product should be tested because errors are not uniformly distributed, due to different developers. Regression testing is very important. Rerun all the tests during regression, because any code change can potentially cause new problems in area not associated with the area where code is changed. Private & Confidential 11 0

What to Test For? System testing encompasses a wide variety of areas that should be tested. Features ◦ Functional - The product should be tested against the requirements. Limits - System limits should be tested at and around their boundaries, both for input and output. This should be done not only for data value ranges, But also for size of input and output, whether it be total bytes, number of rows, etc. Storage - Storage specifications should be tested whether the storage system can successfully accommodate required amount of data. Private & Confidential 11 1

What to Test For? – Contd. ◦ Industrial Strength: Performance - Timings for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done in stand-alone, and in multi-user environment. Volume - Large volume of data should be fed to the system to make sure it can correctly process such amount. Systems can often respond unpredictably when large volume causes files to overflow Stress - Loads that results from a large number of simultaneous users, transactions, and/or devices are needed to test the system to determine whether it can handle peak usage periods. Throughput and system stability should be monitored. Recovery - A system should be tested to see how it responds to errors and abnormal conditions, such as System crash, loss of device, communication, or power. Private & Confidential 11 2

What to Test For? – Contd. Reliability/Availability - It is concerned with the issues such as mean-time-to failure, and usually requires extensive testing over long periods of time. Security - The system should be secure from the unauthorized use and unauthorized data access. ◦ Environment: Installation - The tester should install the system (with a variety of options) to determine whether the installation is viable. The installation document must be followed in order to determine its accuracy. Private & Confidential 11 3

What to Test For? – Contd. Configuration - The system should be tested to determine whether it works correctly with appropriate hardware and software configurations. Compatibility - The system should be tested to determine whether it is compatible with other systems that it needs to interface with. ◦ Usability Error - The system should exit gracefully upon an error and leave its environment in a predictable state. Appropriate error message should be generated. Documentation - The documentation for a system should be correct, complete, and easy to understand. Private & Confidential 11 4

Requirements for Test Tools Testing tools automates the process of testing and can save a large amount of time: Regression testing tools captures your tests and play them back whenever required. A successful regression testing tool must have following features: ◦ Easy to install and maintain ◦ Keep track of test cases and selectively run the test cases ◦ Must be able to reuse the captured scripts on different browsers on multiple platforms. ◦ Capture the mouse clicks and hyperlink jumps between web pages as objects and not as absolute locations on the window. ◦ Edit the script to include new data values for regression tests. ◦ Play back the scripts and adjust the speed of playback ◦ Compare the regression run with the expected results and produce the differences in concise reports. These reports should be able to filter errors. Support various HTML releases. Check for valid URLs Private & Confidential 11 5

Testing Process Life Cycle The following are some of the steps to consider: ◦ Obtain requirements, functional design, & internal design specifications ◦ Obtain schedule requirements ◦ Determine project-related personnel and their responsibilities, reporting requirements. ◦ Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests. ◦ Determine test approaches and methods - unit, integration, functional, system, load, usability tests. ◦ Determine test environment requirements (hardware, software, communications, etc. ) ◦ Determine tool requirements (record/playback tools, coverage analyzers, defect tracking, etc. ) ◦ Determine test input data requirements ◦ Identify tasks, those responsible for tasks. Private & Confidential 11 6

Testing Process Life Cycle Determine input equivalence classes, boundary value analyses, error classes Prepare test plan document and have needed reviews/approvals Write test cases Have needed reviews/inspections/approvals of test cases Prepare test environment and tools, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data Obtain and install software releases Perform tests Evaluate and report results Track problems/bugs and fixes Retest as needed Maintain & update test plans, test cases, test environment, and tools through life cycle Private & Confidential 11 7

QA Activities & Deliverables Each of the five phases of Project Delivery Lifecycle will incorporate QA activities & deliverables that off-set the risks of common project problems. This summary of Project Delivery Lifecycle is a high-level list of QA activities & deliverables related to each phase. Assessment Phase ◦ Assessment process consists of market research and a series of structured workshops that the and client teams participate in to discuss and analyze the project objectives and develop a strategic plan for the effort. The products of these meetings, combined with market research, form the basis for the final output of the assessment: a tactical plan for realizing specific business and project objectives. ◦ QA Deliverables QA Editor submits revised and approved deliverable documents. Private & Confidential 11 8

QA Activities & Deliverables Planning Phase ◦ In the Planning phase, the team defines specific system requirements and develops strategies around the information architecture (static content and information flows) and the business functions that will be addressed. QA Activities ◦ ◦ Establishing Standards and Procedures: QA records the set requirements. Planning (Test Matrix): QA develops a test matrix. QA confirms that all set requirements are testable and coincide with the project objectives. ◦ Auditing Against Standards and Procedures: QA editor edits the documents and confirms that they meet the objectives and the quality standards for documents. ◦ Establishing Completion Criteria: QA records the completion criteria for the current phase. QA Deliverables ◦ ◦ QA submits an initial test matrix. QA Editor submits revised and approved deliverable documents. Private & Confidential 11 9

QA Activities & Deliverables Design Phase ◦ During the Design phase, the team identifies all of the necessary system components based on the requirements identified during the Assessment and Planning phases. The team then creates detailed design specifications for each component and for the associated physical data requirements. ◦ QA Activities Auditing Standards and Procedures: QA confirms that all designs meet the set requirements and notes any discrepancies. Additionally, QA identifies any conflicts or discrepancies between the final design of the system and the initial proposal for the system and confirms that an acceptable resolution has been reached between the project team and the client. ◦ Planning (QA Plan, QA Test Plan): ◦ QA begins developing the QA Plan. QA revised the test matrix to reflect any changes and/or additions to the system. QA Deliverables QA presents the initial QA test plan. QA submits a revision of the test matrix. Private & Confidential 12 0

QA Activities & Deliverables Development Phase ◦ During the Development phase, the team constructs the components specified during the Design Phase. ◦ QA Activities Planning (Test Cases): Using the test matrix, QA develops a set of test cases for all deliverable functionality for the current phase. ◦ Prepare for Quality Assurance Testing: QA confirms that all test cases have been written according to the guidelines set in the QA test plan. Quality Assurance works closely with the Configuration Management group to prepare a test environment. ◦ QA Deliverables QA submits a set of Test Cases. QA Environment is set up. Private & Confidential 12 1

QA Activities & Deliverables Implementation Phase ◦ In the Implementation phase, the team focuses on testing and review of all aspects of the system. The team will also develop system documentation and a training or market test plan in preparation for system launch. ◦ QA Activities QA Testing: QA executes all test cases in the QA testing cycle. ◦ QA Deliverables Test Results Defect Reports Private & Confidential 12 2

Testing Tradeoffs Shortage of time and resources How does a tester best deal with this Coverage of test cases by breadth and depth testing. Breadth of coverage addresses the number of areas, features, and options. Depth of coverage addresses the extent to which different tests are run for an area feature or option. Breadth of testing should be covered well. Otherwise there is a danger of having basic features that simply do not work. How to make decision what to test in depth: ◦ perform depth testing in the problematic areas shown in the breadth or depth testing proven problematic in the previous versions of software. ◦ Critical areas require depth testing simply because of their importance. Private & Confidential 12 3

Testing Tradeoffs Should tests in the same functional area be grouped together, or should they be mixed? Grouping tests in the same or related areas makes it easier for tester track and understand an area, mixing increases the odds that you will identify problematic area early in the testing and pursue depth testing where it is needed. Should tests to break the system be grouped by type or should they be mixed. Should individual tests and workflow scenarios be tested separately. All the tests cannot be written before the actual testing starts. You may overlook needed tests. The results of the tests will provide clues as to what other tests should be performed. System crash, error or warning messages, incorrect results may alert you to include some additional tests. Private & Confidential 12 4

Environmental Impact Environment plays a role in the results of the tests. Particularly in the areas of performance testing. Some of the areas you cannot control. ◦ Other traffic on the network ◦ Other processes running on the server ◦ Other process running on the DBMS The areas you can control in the test environment: ◦ Connection to the DBMS - opening a connection involves overhead; it is efficient to keep a session open. ◦ File opens - opening a file involves overhead. It is more efficient to keep a file open. ◦ DBMS space management - file fragmentation, data and index page splits occurs due to the large number of inserts or updates. This impacts performance. Deletes may results unused spaces. ◦ Space utilization should be monitored. Database utilities should be run regularly to control this. Private & Confidential 12 5

Environmental Impact Buffer pools may hold previously retrieved data or indexes and can give different performance results compared to data that must be retrieved from permanent storage. It might be desirable to flush the buffers between database requests. Logging can slow the response time. Transaction logging is necessary for recovery. However, event logging for other types information capture may be undesirable while performance testing is in progress. Private & Confidential 12 6

Performance Testing Tools Performance testing tools determine the load a web server. A successful performance testing tool must have the following features: ◦ Easy to install and maintain ◦ Keep track of test cases and selectively run the test cases. ◦ Capture the mouse clicks and hyperlink jumps between web pages as objects and not as absolute locations on the window. Simulate many users from one machine by running the captured script. Mix several scripts and run them several times to simulate many users doing different tasks. Collect performance data and have reporting tools to analyze the data. Able to measure the network load under different number of simulated users. Able to measure the CPU load by the server. Able to measure throughput by the number of pages served by server Private & Confidential 12 7

Deliverables The Deliverables from the Test team would include the following: ◦ Test Plan. ◦ Test Case Documents. ◦ Defect Reports. ◦ Status Reports (Daily/weekly/Monthly). ◦ Test Scripts (if any). ◦ Metric Reports. ◦ Product Sign off Document. Private & Confidential 12 8

Capability Maturity Model (CMM) Software CMM is a common sense application of process management and quality improvement concepts to software development and maintenance. A scale for assessing the degree of built-in documentation and discipline in a process, in which the scale goes from Level 1, with no formal process, to Level 5, with a continuous, rigorous and self-improving process. The Capability Maturity Model for Software developed by the Software Engineering Institute of Carnegie Melon has had a major influence on software process and quality improvement around the world. The SW-CMM defines a five level framework for how an organization matures its software process. These levels are the result of evolution from ad hoc processes to more matured and disciplined software process. This model is now being extended to a broader range of applications in management. Private & Confidential 12 9

Testing Tools Mercury Test. Director: ◦ Mercury Test. Director™ allows you to deploy high-quality applications quickly and effectively by providing a consistent, repeatable process for gathering requirements, planning and scheduling tests, analyzing results, and managing defects and issues. Test. Director is a single, Web-based application for all essential aspects of test management — Requirements Management, Test Plan, Test Lab, and Defects Management. You can leverage these core modules either as a standalone solution or integrated within a global Quality Center of Excellence environment. ◦ Test. Director supports high levels of communication and collaboration among IT teams. Whether you are coordinating the work of many disparate QA teams, or working with a large, distributed Center of Excellence, this test management tool helps facilitate information access across geographical and organization boundaries. Private & Confidential 13 0