Read are Extra information Test first development Its also call Test-driven development is a software development process

requires developer to create automated unit test case define code requirement before writing the code itself. For example we have requirement namely we want to write message to a file, this message must be appended to the file if it exist. Public Function file_exists(file_name) Dim objF,path Set objF=CreateObject(scripting.FilesystemObject) Path=objF,GetAbsolutePathName(file_name) If objF.FileExists(path) then Echo Your file exist you can append the message Else Echo File doesnt exits in the path End if End Function Call file_exits(c:\message.txt) This will fail because the required file does not exit or created Now write the code to pass the test below Public function file_exists1(file_name) Dim objF,path,crfile,getname Set objF=createObject(scripting.FilesystemObject) crfile=objF.CreateTextFile(file_name) Path=objF.GetAbsolutePathName(crfile) Crfile.writeLine(Your message appended)
If objF.FileExists(path) Then Response.Write ("Your file has been created.") End If

End Function Call file_exists1 (c:\simple.txt) Finally refractors the new code to acceptable standards Refactoring enables you to evolve your code slowly over time, to take an iterative and incremental approach of programming. Test driven development is related to test first programming concepts of extreme programming. Test driven development requires developers to create automated unit test that define code requirements (immediately) before writing the code itself. The test contains assertions that are true or false .Passing the tests confirms. Correct behavior as developer evolves and refractor the code. Developers often use testing frame works, such as xUnit to develop the test cases. A programming technique called refactoring, a disciplined way to restructure code. The basic idea is that you make small changes to your code to improve your design, making it easier to understand and to modify. Refactoring enables you to evolve your code slowly over time, to take an iterative and incremental approach to programming

A critical aspect of a refactoring is that it retains the behavioral semantics of your code, at least from a black box point of view. For example there is a very simple refactoring called Rename Method, perhaps from getPersons() to getPeople(). Although this change looks easy on the surface you need to do more than just make this single change, you must also change every single invocation of this operation throughout all of your application code to invoke the new name. Once youve made these changes then you can say youve truly refactored your code because it still works again as before. Keyword-Driven and Data-Driven Test Ans: keyword-driven testing also known as table-driven testing or action-word testing is a software testing methodology or frame work for automated testing. The keyword-driven framework is an application independent framework that performs all possible actions and verifications on an object. Example of keyword: A simple keyword one action on one object such as: entering user name in a text field. Here action is entering data on text field (object) Object Action Data Textfield (username) Enter text <username> More complex example a combination of keywords in a meaning full event such as logging in Object Action Data Textfield (domain) Enter text <domain> Textfield (username) Enter text <username> Textfield (password) Enter text <password> Button (login) Click One left click Keyword driven QTP sample code: Browser(title:=*,index:=0).page(title:=*.).webEdit(attached text:=Agent Name:=username).set abcd This script sets the username value in webEdit object .OTP object repository holds the objects. Keyword driven methodology separates the test creation into distinct stages: a. Planning stage: Plan your tests to ensure that your tests cover your testing requirements. Keywords are defined in this stage such as webEdit, Dialog etc. b. Implementation stage. Is a part of automation tools such as QTP and GUIdancer. For keyword-driven methodology we need to develop these steps: Stage 1: Analyze the application under test (AUT) to determine the testing needs a. Determine the development environment of AUT such as web, java, applet, .Net, SAP, Visual Basic etc so that we can load the required add-ins. b. Analyze the various business processes that users perform while using the application to determine the actions we need to create. For example: An e-commerce application enables users to purchase

items on line might contain various business processes. Including registering on the site and purchasing items. Each process may require one or more tasks. Each task represents an action. For example registering on the site may be a simple process requiring only one action. Whereas purchasing items may be more complex, requiring several actions. Such as Login action, a browse action an AddToCart action, a purchaseItems action, and a logout action. We can reuse the repeating actions include calls to the same actions from multiple tests. For example, you may want to include a Login action in many of your tests. Stage 2: Preparing the Testing Infrastructure: Infrastructure is part of test planning system, we will build set of resources to be used by the AUT such creating keyword object repositories in local and shared scope, function libraries, setting up global testing preferences, run session preferences, any test-specific preferences, and recovery scenarios. Automation scripts that automatically set the required configurations such as load the required add-ins. Creation of one or more tests that serve as action repositories in which we can store the actions to be used in the tests Stage 3: We are adding steps to the actions in test action repository. Before adding the steps, make sure that you associate your function libraries and recovery scenarios with relevant tests, so that you can insert steps using keywords. You can create steps using the keyword-driven functionality available in the table-like, grphical keyword view or using the expert view, we can program steps directly using vbscript. Step 4. Enhancing your test: You can enhance the testing process by modifying your test with special testing options and/or with programming statements such as: a. Inserting checkpoints and output values into your test. b. Broaden the scope of your test by replacing fixed values with parameters, parameter data can come from data table, define environment variables and values c. Add user defined functions by creating function libraries and calling there functions from the test. Step 5. Running and debugging your test a. Run your test to debug it b. Run your test to check your application c. Run your test to update it Step 6. Analyzing Test Results and Reporting Defects: After run the test you can view the result and analyze the result to find defects, you can report defects detected during a run session and can report the defects in project database by QC Implementation of keyword driven methodology: If we are preparing a test suit for shopping cart, we might perform for each of these steps:

Define the testing environment for shopping cart application: Shopping cart is a web application that contains html and php.Therefore; we need to ensure that Quickest Web Add-ins are installed and loaded. To activate the application, we need to run a URL in a Web browser. The URL is http://localhost/sites/shoppingcart/index.html Analyze the Shopping Cart Application: The business process that should be tested for Shopping Cart application includes: a. Registering on the site b. Displaying and selecting products c. Adding the Item to the Cart d. Displaying the Basket summary e. Deleting items f. Checking it out g. Paying h. Administrator Pages i. Managing completed orders j. Viewing a specific order A logical break down of the above business process could be: Registering on the site: Open the application Go to the registration page Enter the required information in the form Submit the form Verify that the form information is valid If a mandatory field did not have a value, an error message is displayed. If the password and confirm password values are not the same, an error message is displayed. If the username entered in the form already exists in the database, an error message is displayed Otherwise, the successful registration page is displayed. Displaying and selecting products: Open the application Sign on Navigate to the product category page Choose a product Click the buy link User selects the quantity of items User can click the X symbols to delete any item from the cart And so on Now we can create action repository for the set of business processes could include a.register b.sign on c.product Details

d.Adding items to cart e. Delete items from cart f. verification and confirmation Here are the steps 1- Enter name in username field 2- Enter password in password field 3- Click on ok button in the above manual script, Following are the keywords used for manual test case writing enter 1- Enter 2-Username field 3- Enter 4-Password field 5- OK Button Pros Maintenance is low in a long run Test cases are concise Test Cases are readable for the stake holders Test Cases easy to modify New test cases can reuse existing keywords more easily Keyword re-use across multiple test cases Not dependent on Tool / Language Division of Labor Test Case construction needs stronger domain expertise - lesser tool / programming skills Keyword implementation requires stronger tool/programming skill - with relatively lower domain skill Abstraction of Layers. Cons Longer Time to Market (as compared to manual testing or record and replay technique) Moderately high learning curve initially Creating Test using keyword-driven methodology (framework) Data driven testing: When an automation test that consist of the same operations but differ in input and expected values, we can use data driven testing to separate test logic from test data by replacing hard coded values with variables. We can create re-usable automated tests that can run repeatedly with different data sets supplied by an external data source. The inputs are read from data sheet or data base table and the verifiable out put is saved in the datasheets or data tables. Example of data driven test script: DataTable.Import c:/datasheet.xls Num_rows=DataTable.GetRowCount For i=1 to Num_rows DataTable.setCurrentRow(i) If Dialog(text:=Login).exist then

With Dialog(text:=login) .WinEdit(attachedtext:=Agent Name:).set Datatable(userid,dtGlobalSheet) .winEdit(attachedtext:=Password:).set DataTable(pwd:,dtGlobalSheet) .winButton(text:=OK).click DataTable.SetNextRow Next End with Recovery Scenario: The ultimate goal of a test automation running the test unattended this create some concern how to handle if something happen and stop the test. This is reality of life this may happen, we can fight this equipped our script to handle the unknown incident by implementing recovery scenario functionality. For example when we are surfing a website a window pop with the message title information bar and system hangs until you press the ok button. This problem we can easily handle by a recovery function, the function automatically click the ok button and the script will run with out any problem Public function Recover_MessageDialog (object) return a handle to a run time objects window Win_handle=object.GetRoProperty(hwnd) Assigning an object reference to a variable Set pop_win=Window(hnwd:=&win_handle) printing the objects title Msgbox pop_win.GetROProperty(title) clicking ok button on that object Pop_win.winButton(text:=OK).click End function Dim obj Obj=Browser(title:=.*,index:=0).Page(title:=.*) Call Recover_MessageDialog(obj) What is Framework and automation Framework? Explain keyword driven and data driven test framework? There are many tools assist the software tester to perform the testing task some of them are: 1. Problem Management tools-defect tracking tools such as Excel sheet, Quality center. The purpose of a problem management tools is to provide a central repository for describing defects uncovered. 2. Source code control tools: Source Code Control System (SCCS), and Visual SourceSafe. Its major function is to provide strict controls on a software entity, providing proper serialization of software parts that are created and modified by multiple developers simultaneously. The terms check out and check in are used to describe whether a part is in the process of being modified or integrated into the software product. 3. Test Management tools: Also called a test tracking tool, this tool gives a test team an easy way to deliver a status update, it tells you whether you are ahead of or behind schedule, by this tool we can create test plan, test case, defect repository such kind tools are HP Quality Center, Zypher.

4. Code Coverage tools: It reports on the source code statements that have been executed after tests have been run, as well as those have not been executed. 5. Static code Analysis Tools: These tools scan the source code and identify common coding mistakes such as uninitialized variables, memory leaks and out of bounds array access. Its normally the development team responsibility. 6. Test execution Aids: There are many, many tools in this category such as enduser simulators and frameworks. This class of tools assists in the actual execution of tests and can also ease the burden of creating test cases. End user Simulators: These tools provide a way to automate entering work into systems in ways similar to those of the softwares real users. By simulating or creating hundreds to thousands virtual users such as HP Load Runner Framework: A basic structure underlying (basis of something) a system, a software framework is a collection of software libraries providing a defined API. Test automation Framework: A framework used for test automation. Provides some core functionality (e.g. Logging and reporting) and allows its testing capabilities to be extended by adding new test libraries. There are two kind of automation framework implementation the keyword driven and data driven framework. An automation framework must be able to execute tests, verify results, and recover form expected errors and report results. The framework MUST be easy to use without programming skills and must be easily maintainable. Automatic Test Execution: The framework must be able to execute tests unattended. It can be scheduled by windows schedule utilities and corn in UNIX The end date arrives and testing isnt finished: The end date has come the test team hasnt received its exit criteria, Major bugs remain unresolved, significant chunks of testing are not complete, as a tester and the softwares first user we cant sign off releasing it as is. Its decision time as a tester is not sole authority to decide whether code will go to production. Its a business decision to be made by senior managers who will take into account many factors, only one of which is test status. However, its likely the test team will have an opinion on what the decision should be. What solutions might you recommend? How can you convey your opinion in a way thats convincing? There are several possibilities: Delay Shipment: If problems in software are serious and pervasive (Spreading widely throughout an area) and testing is per behind in major functional areas, there may be little choice but to extend the end date. If the test team feels strongly that a delay is required, we must present our rationale to the decision makers in a precise and powerful way. We can provide problem tracking and test measurement chart should provide solid base, present the standard S curve, a bar chart, with each bar representing a major functional area of the software and showing its planned versus actual accumulations of testing points. Withdraw or Fence a Function: If trouble is focused in one or two distinct areas of the software, in this case to keep the end date intact we can pull those specific functions from the package. If the function is intertwined with the rest of the

packages, it may not be realistic. In that case we can disable the function that is called fencing. Overlap the code freeze or software shipped to customer time window: Most of the commercial software has a time window code freeze normally 72 hours before the software installation in the production or finished product shipment (COS) time to customer. This time is often used to finish the documentation CD creation we can exploit this time wind to finish the remaining testing. What is conflict how you can resolve team conflict? Conflict is a state of disagreement between incompatible (Unable to live together) persons, ideas or interests. Conflict in work terms is not necessarily destructive, a positive conflict can lead to new ideas and approaches to organizational processes. When negative conflict arise we can handle the negative conflict by: Direct approach, Bargaining, Enforcement, and Retreat Direct approach: Identify the exact nature of the conflict if particular member or group of people are involved with conflict. If conflict involves only by two persons, then meet separately with those individuals to try to reach a resolution. If criticism is necessary then constructive criticism must be used. Bargaining: If group of people involved in conflict then obtain each members opinion about conflict try to find a common ground. Some times we can take help from third party as a mediator such as team manager. Compromise involves give and take on both sides. Enforcement of Team Rules: This technique is only used when it obvious that a member does not want to be a team player and refuse to work with the rest. If enforcement has to be used on an individual, it may be best for that person to find another team. Retreat: Use this method when the problem isnt real to begin with. By simply avoiding it or working around it, give enough time the conflicting individual to cool off. What is J2EE? Describe it: J2EE is the short for Java 2 platform Enterprise Edition.J2EE is a platformindependent(J2EE application servers that run on a variety of operating systems), java centric environment from Sun Micro system/Oracle for developing, building and deploying enterprise Web applications online. (There are two major standard evolve for enterprise web applications development Microsoft .Net Frame work ASP.Net and J2EE) J2EE architecture consists of four major elements: (A Servlet is a Java class in Java EE that conforms to the Java Servlet API, a protocol by which a Java class may respond to requests. They are not tied to a specific client-server protocol, but are most often used with the HTTP protocol. Therefore, the word "Servlet" is often used in the meaning of "HTTP Servlet. Servlet 2.2 is the part of J2EE
It's important for you to realize that J2EE is a standard, not a product.

Java: The foundation for J2EE

The J2EE architecture is based on the Java programming language. What's exciting about Java is that it enables organizations to write their code once, and deploy that code onto any platform. The process is as follows: 1. Developers write source code in Java. 2. The Java code is compiled into bytecode, which is a cross-platform intermediary, halfway between source code and machine language. 3. When the code is ready to run, the Java Runtime Environment (JRE) interprets this bytecode and executes it at run-time. J2EE is an application of Java. Your J2EE components are transformed into bytecode and executed by a JRE at runtime. Even the containers are typically written in Java. Note the important difference: .NET is a product strategy, whereas J2EE is a standard to which products are written.

The .NET Framework Microsoft.NET offers language-independence and language-interoperability. This is one of the most intriguing and fundamental aspects of the .NET platform. A single .NET component can be written, for example, partially in VB.NET, the .NET version of Visual Basic, and C#, Microsofts new object oriented programming language. How does this work? First, source code is translated into Microsoft Intermediate Language, sometimes abbreviated MSIL, sometimes and IL. This IL code is language-neutral, and is analogous to Java bytecode.The IL code then needs to be interpreted and translated into a native executable. The .NET Framework includes the Common Language Runtime (CLR), analogous to the Java Runtime Environment (JRE), which achieves this goal. The CLR is Microsofts intermediary between .NET developers source code and the underlying hardware, and all .NET code ultimately runs within the CLR. This CLR provides many exciting features not available in earlier versions of Windows DNA, such as automatic garbage collection, exception handling, cross-language inheritance, debugging, and side-by-side execution of different versions of the same .NET component. J2EE promotes Java-centric computing, and as such all components deployed into a J2EE deployment (such as EJB components and servlets) must be written in the Java language. To use J2EE, you must commit to coding at least some of your e-Business systems using the Java programming language. Other languages can be bridged into a J2EE solution through web services, CORBA, JNI, or the JCA, as previously mentioned. However, these languages cannot be intermixed with Java code. In theory, JVM bytecode is language-neutral, however in practice; this bytecode is only used with Java. By way of comparison, .NET supports development in any language that Microsoft's tools support due to the new CLR. With the exception of Java, all major languages will be supported. Microsoft has also recently introduced its new C# language which is equivalent (with the exception of portability) to Java and is also available as a programming language within the Visual Studio.NET environment. All languages supported by the CLR are interoperable in that all such languages, once translated to IL, are now effectively a common language. A single .NET component can therefore be written in several languages. As far as hardware, J2EE supports UNIX and Mainframe systems, while both J2EE and .NET support the Win32 platform, which is generally the less expensive alternative.)

1. The J2EE Application Programming Model is the standard programming model used to facilitate the development of multi tire, thin client application. 2. It includes set of services, protocols and APIs such as Java servlets, Java Message services(JMS), Java server Pages(JSP) equivalent of Microsofts Active server Pages(ASP) 3. The J2EE compatibility Test suit ensures the J2EE products are compatible with the platform standards. 4. Java Database Connectivity (JDBC), the Java equivalent to Open Database Connectivity (ODBC), is included as the standard interface for Java databases.

IBM or Microsoft Enterprise Content Management (ECM): Enterprise Content Management (ECM) is the strategies, methods and tolls used to capture, manage, store, preserve, and deliver content and documents related to organizational processes. ECM tools and strategies allow the management of an organizations unstructured information, where those information exists.ECM solutions have been transformed with the advent SharePoint, a Microsoft platform based ECM technology. Effective content management systems support an organizations business processes for acquiring, fitering, organizing, and controlling access to information. Numerous factors determine the degree of difficulty an organization will face in deploying or improving their content management systems. An organizations size and geographic dispersion can give a first-order estimate. Another factor to consider is the diversity in forms of electronic data held within the organization. Besides plain text documents, critical data can also exist in

alternate forms such as graphics, audio/video, and engineering diagrams that can prove much more difficult to manage Enterprise Content Management helps an organization for Search quickly and easily across multiple content types and repositories. Satisfy e-discovery demands and compliance requirements. Allow users to publish, manage, and retrieve content without leaving a single familiar interface. Scale it throughout the agency or within multiple departments. Control access and protect information from unauthorized use. Ensure that documents are properly disposed of at scheduled times. ECM solution treats structured and unstructured data types in the same way whether theyre documents, spreadsheets, e-mail messages, instant message conversations, or even audio, video, or image files we can apply uniform rules for labelling, archiving, retrieving, and deleting records. Consistent treatment helps make sophisticated, enterprise-wide management convenient and effective. By ECM we gain the centralized control over electronically stored content. Enhanced rights management and routing make it easy to manage document permissions and respond to e-discovery requests. 'Structured data' has structure/rules attached to it e.g. a product. A product will always have a code, manufacturer, category etc. and thus defines the structure of data. Unstructured data consists of two basic categories: Bitmap Objects: Inherently non-language based, such as image, video or audio files. Textual Objects: Based on a written or printed language, such as Microsoft Word documents, e-mails or Microsoft Excel spreadsheets. Geographic Information system (GIS): Integrates hardware, software, and data for capturing, managing, analyzing, and displaying all forms of geographically referenced information such as Map locations, Map Quantities, Map Densities and Map specific Areas, Map change What is software development life cycle (SDLC)? The software/systems development life cycle (in systems engineering, information systems and software engineering,) is the process of creating or altering computer application systems, and the models and methodologies that people use to develop information management systems. The ultimate goal of SDLC builds a product that meets or exceeds the customers expections,the developed product is build on time and budget, product should works effectively and efficiently in the current or planned information technology infrastructure, and is inexpensive to maintain and cost effective to enhance. SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on lightweight (In computer operating systems, a light-weight process (LWP) is a means of achieving multitasking) process which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process, focus on limited project scope and expanding or improving products by multiple

iterations. Sequential or big-design-up-front (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. The Rational Unified Process (RUP): is an iterative (repeat again and again) and incremental software development process. It starts with an initial planning and ends with deployment with the cyclic interactions in between.

An iterative development model Iterative and incremental development is essential parts of the Rational Unified Process software development frameworks. The basic idea is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. The key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. There are nine disciplines in iteration: Six software engineering disciplines Business Modeling Requirements Analysis and Design Implementation Test Deployment

Phases: The unified process divided into 4 phases: Inception (starting), elaboration (Details), construction, and transition Inception (I1): identifies project scope, risks, and requirements at high-level work estimation. Elaboration (E1-E2): Delivers a working architecture that mitigates the top risks and fulfills the non-functional requirements. Construction (c1-c4) incrementally fills in the architecture with production-ready code produced from analysis, design, implementation, and testing of the functional requirements Transition (T1-T2): delivers the system into the production operating environment. Each of the phases may be divided into 1 or more iterations. which are usually time-boxed, Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full. Three supporting disciplines: Configuration and Change management Project Management Environment.

The Waterfall model Progress flows from top to bottom like a water fall. There are 5 disciplines in this model: requirements, design, implementation, verification, and maintenance. Each discipline project wide work products are the input of the next discipline. Business value is delivered all at once, and only at the very end of the project. Waterfall method is sequential process. Why an agile method would be more appropriate than a Waterfall method for the next C++ project? The project development methodology depends of projects. If we consider the problems in traditional waterfall model, its clearly defined deliverable for every phase; the work product of early phase is the input of the next phase, so going back is difficult and costly in-terms of time and money. If we consider the iterative and incremental model such as RUP (Rational Unified process), the main objective of this model is to build the system incrementally, starting from basic partial system features and gradually adding more feature until the entire system is completed. This model allows flexibility in accommodating new requirements or changes and it also provide room for improvement in succeeding iterations based on lessons learned from previous iterations. Iteration 0 Iteration 1 Repeat as needed Iteration n Project setup plan Plan, develop, Plan, develop, Develop & Test Test & feedback Test & feedback Release Product If we consider the agile, the basic idea of agile to develop software application that could accommodate the fast-paced evolution of the Internet, agile is a variant of iterative model .The main difference is that agile cuts the delivery time from months to weeks. Due to modular nature of object oriented design and programming, such as C++, is much suited for iterative and incremental model such as agile. In C++ we create object and code this object module and tested then integrated the modules, early test help to reduce bug leak from one stage to other stage of the software. Agile model is adaptable with requirement change easily. When equipment change probability is high and frequent we must use agile. How to build a successful QA?

A successful team is a high performing team achieve superior levels of participation, co-operation, and collaboration because their members trust one another, share a strong sense of group identity, and have confidence in their effectiveness as a team. In other words, such team process high level of group emotional intelligence (EI).Implementing these steps build the groups EI off to solid start. 1. Make time for team members to appreciate each others skills Interpersonal understanding is critical to trust, the group must be aware of each members skills and personality. Members can get acquainted with one another as they start hammering out team goals and creating a shared vision of success. Before start the day work group members should meet for five minutes meeting to share the work progress, problems, and personal reflections helps fortify the groups understanding of each individual and how together they all contribute to common goal. 2 Use knowledge of seasoned player in the team: The person who has spent considerable amount of time in same project or similar kind of work, for team success we can utilize that knowledge 3. Each team members has unique qualities and working style we can motivate the individual in positive way to get the best from the individual for team success 4. Celebrate success: Recognizing individual and group achievements help individual and other members of the team will encourage acting on similar grounds and ultimately team benefit from their collective response. Such bonus, team lunch Enterprise Resource Planning (ERP): integrates internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc.ERP systems automate this activity with an integrated software application. Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Such as: SAP Why did you choose to be a software tester? There are three reason led me to choose the software quality assurance and testing as my career. Job growth and job security, quality control is a challenging job, lots of creativity is there. To day we cant imagine any small business, big corporations, government can survive with out computer technology. Every works of life is so dependent on computer, this dependency create problems software failure due to inadequate test and quality management. Lots of big software crash and company loose millions and there creditability for example European space agencys arian5 rocket failure on of the example. These fears create software testing, which helps to create tremendous job growth and job security which attract me on this career. Software testing is challenging job, if we compare in the testers and developers goal developer looks for one solution that fit the specifications, on the other hand testers goal to find all bugs introduce by the development activity, challenge is more interesting just as the challenge for the hunter is greater than for the harvester. I love challenge thats why I m in testing.

Testing need lots of creativity to find the potential anomalies in the software code nothing knowing it, the greatest creativity of all be able to design the best test set to find largest number of most damaging bugs in the system under test. What did you include in a test strategy? Test strategy or test approach is a set of guide lines describe how testing is going to perform in terms of technology and peoples. There are two level of test strategy company/or organization level, and project level. Testing strategy includes the following components: Overview, Back ground, scope, constraints, key inputs, task overview, key deliverables, acceptance criteria, problem management, critical success factors, risk and contingency plans, metrics Test strategy or Test approach is a set of guide lines that describes test design. Test strategy says-How testing is going to be performed? What will be the test architecture? Test strategy can be at two levels- Company/Organization level and project level. If company is product based, then there can be a general test strategy for testing their products. Same strategy can be implemented with or without some modification at project level whenever a new project comes. Testing Strategy includes the following components: Testing Strategy Overview, Background, Scope, Constraints, key Inputs, Task Overview, Key Deliverables, Acceptance Criteria, Problem management, Critical Success factors, Risk and Contingency plans, Metrics Overview: Testing strategy determines the projects approach to testing. The test strategy looks at the characteristics of the system to be built, the project time line and budget, and plans the breadth and depth of the testing effort. The testing strategy will influence tasks related to test planning, test types, test script development and test execution. Scope: To define the testing scope of<Application Name>, the following areas were examined: testing tasks, test type by task, converted data sources, system interfaces, testing environtments, testing tools. Testing tasks: This project includes the following testing tasks: module test, module integration test, system test, systems integration test, acceptance test. Constraints: The project must operate within the following limits: Time, required system resources, business, and technical. Key Inputs: Key inputs to <Application Name> testing are as follows: System Process Model, Function Model, system data model, system interfaces etc Task overview: The key testing tasks for <Application Name> are as follows: Develop testing strategy, Develop system process Test Model, Develop module and module integration test plan, develop system test plan ,prepare system test environment, perform system test, Develop systems integration test plan ,perform system integration test, Prepare acceptance test environment, support acceptance test. Key Deliverables: Testing strategy, system process test model, module and module integration test plan, module and module integration test results, system

test plan, system test environment, system test results, system integration test plan, systems integration test results, acceptance test environment, acceptance test results Acceptance criteria: completion and sign-off all the key deliverables, deliverables for the test scripts and test results will be subject to quality reviews. Problem Management: The assessment and prioritization of defects found during testing will be strictly controlled using the problem management process. Critical success factors: The following critical success factors are specific to testing process: Testing considerations must be beginning in the early phases of the project; test script development must be based on key project deliverables. Testing must be objective and must perform by an independent test team; the scope of the regression test should be well defined. Risk and contingency plan: If code is late then over time required to finish the testing Metrics: Key metrics as follows: number of test iterations planned for each test task, complexity of the application system under test, number of functional areas involved in the module and module integration test, number of system process, number of scenarios per system process, number of test steps per scenario etc. Revision log: Date, version, change reference, author, reviewed by Appendices: Entire content here. Approval: prepared by, signature, date; accepted by: acceptor name, designation, organization, signature, date; approved by: approver name, title, organization, signature, date. Test Plan: Practically both of test plan and test strategy are same! Theoretically they differ in some aspects; a project may run with out test strategy but not with test plan. Test Strategy is the subset of test plan. Test logistics is the set of ideas how to organize and manage activities that provide testing. Test plan is the combination of test strategy and test logistics that guide a test project. The level of test plan depend on project types, the type of project depends on size number of person involved in the project, project completion time, and project complexity. Test plan contains the following items: 1. Test plan Identifier: Identify the test plan, it include application name, document template name with unique company generated number, revision history and project name such as: ANSB WPID C6.5 V1.0 PD485.doc 2. Introduction: state the purpose of the plan; this is essentially the executive summary part of the plan, such as: This project PD485.doc addresses customer migration for SBC customers. ports and pvcs 3. Featured to be tested: This is a listing of what is to be tested from the users view point 4. Feature not to be tested: This is a listing of what is NOT to be tested from both the Users viewpoint 5. Approach (Strategy): Overall test strategy for this test plan, we need to find the answer of the following questions: Are any special tools to be used and what are they? Will the tool require special training? What metrics will be collected? How configuration Management to be handled?

Hard ware software used? What levels of regression testing will be done and how much at each test level? 6. Item Pass/Fail criteria: what are the completion criteria for this plan? This is a critical aspect of any test plan and should be appropriate to the level of the plan: All level of test such as unit, system, regression, and UAT all test cases completed and the expected and actual test out put is same items pass if the two results are not same then the items fail. If number of major defect is 0 and some minor defect can exist for passing criteria 7. Suspension criteria and Resumption Requirements: Need to know when to pause in a series of tests such as manual testing is suspended at the end of a working day and resumed the following office hours. If there is high servility sev1 critical defect that crash the system and further testing is not possible then suspend the testing until the bug is fixed. 8. Entrance and exit criteria: Before start testing we have to check this constraint : Test region is set, test input entered in the test database, code is thoroughly unit tested, unit test result received and reviewed, developer sign-off the code and new code/binary is installed /copied in the test region. Exit criteria: All test cases executed successfully, there is no critical or sev 1and sev2 bug is remains open .then test is finish 9. Test Deliverables: what is to be delivered as part of this plan? Test plan document, Test cases, Test design specifications, test progress report, test error logs and execution logs, problem reports and corrective actions. 10. Test tasks: These tasks need to be finish: Prepare and inspection of test plan, test cases, setup test environment, enter test data, execute test case, and verify the test data. 11. Environmental needs: Are there any special requirements for this test plan such as: special hardware such as simulators, static generators etc, restricted use of the system during testing, operating system 12. Schedule: Should be based on realistic and validated estimate when to start and when to finish 13. Responsibilities: Who is in charge? Setting risks, setting overall strategy for this level of plan, who provides the required training? Who is owner of the application, who makes the critical go/no go decisions for items not covered in the test plan? 14. Risk and contingencies: What are the overall risks to the project with an emphasis on the process? Lack of personnel resources when testing is to begin, lack of availability of required hardware, software, data or tools, late delivery of the code, hardware or tools, Changes to the original requirements or designs. What will be done for above risks, for example: if the requirement definition will be complete by September01,2011,if requirement change after that date the following actions will be taken: The test schedule and development schedule will move out an appropriate number of days, the number of test performed will be reduced, the number of acceptable defects will be increased, resources will be added to the test team ,the test team will work over time 15. Staffing and training needs: Training on the applications/system. training

for any test tools to used. 16. Approvals: 17 Glossary (terms, definitions and acronyms, team members, acknowledgements references, List of figures, List of tables How do you ensure that no functionalities are left out during the testing? By a good accurate requirements traceability Matrix: A traceability matrix is a table that traces a requirement to the test that are needed to verify that the requirement is fulfilled. A good traceability matrix will provide backward and forward traceability, ie.a requirement can be traced to a test and a test to a requirements.The matrix links higher level requirements, design specifications, test requirements, and code files It acts as a map, providing the links necessary for determining where information is located. Below is a simple traceability matrix structure. There can be more things included in a traceability matrix than shown. In traceability, the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.

The examples show forward and backward tracing between user and system requirements. User requirement identifiers begin with "U" and system requirements with "S." Tracing S12 to its source makes it clear this requirement is erroneous: it must be eliminated, rewritten, or the traceability corrected.

B001 Cancel transaction when client press the cancel button Cancel_transictons.c Cancel_transictions.h U12 TC1 Forward Traceability Sources of the Requirement-> Requirements->Work Products that Implement the Requirements Backward Traceability Work Products that Implement the Requirements-> Requirements-> Sources of the Requirement How do you report work in progress? To report test progress we used a template called System verification Test progress Report (WP08.2) it has the following components Test Report Identifier-A unique identifier that can be used to identify the report. The identifier also contain the reporting period (i.e. R2010 -040110) Number of test cases Passed, failed and pending Number of Defects Detected vs. Number of projected Defects Number of test cases successfully Executed vs. Total number of test cases. Identify the percentage of test cases completed. Major concern-Identify any major concern such as the progress of testing, quality of the code, the ability to meet the testing completed Evaluation of test effort- Identify the need to make changes in the original test plan. There may be a need to add or remove test cases or the focus of the test effort may need to shift due to complexity of a function System Verification Test Results Summary Report (WP08.1) To report test results summary report we use the above template WP08.1 It contains the following components Summary Summarize the results of the test items including actual vs. planned Identify the functions/feature tested

Indicate the environment in which testing activities took place Variances Document any variances of the test items from the design specifications Indicate any variances from the test plan, design documentation or test procedures Comprehensive Assessment Evaluate the comprehensiveness of the testing process against the criteria specified in the test plan Identify features or feature combinations which were not sufficiently tested and explain the reasons. Evaluation This evaluation must be based upon the test results and the item level pass/fail criteria Provide over all risk assessment Anomalies Describe unexpected events that happened either during or after a test. Approvals Specify the names and titles of all persons who must approve this report What is a role of a leader? Liaison to Administration, attends management meeting weekly Runs weekly Team meeting Oversees team operations Provides supervision/support to team staff Oversees the budget Delegate jobs Discuss issues at meetings. Team progress Report; List the task already performed by the group List the things to do Any problems the group needs to be deal What types of testing have you performed? I have performed functional, system, regression, intersystem (IST), user Acceptance (UAT), web; data ware house, performance, volume, unit and back end testing. Functional testing: Is a black box testing dealt with only the functionality of the application for example we have requirement to calculate monthly bill for a client Functionality test verify the monthly bill is calculated according to requirement. System testing: Is a black box testing combination of functional and non functional testing such as usability or performance testing. For example, according to customer he wants bill calculation complete in 5 sec the calculation time checking is non functional performance. Regression testing: Is a backward check testing to ensure that new functionality added to the system did not break the old checked functionality of the system. Unit testing: Is a white box testing tester has the access to the code each single unit is tested to find the anomalies developer responsibility. Integration testing: Is also white box testing like Unit testing, in this testing is the integration of different modules it comes after unit testing before the functional testing. Inter system: Testing between the different upstream and down stream application like

ANSB and AISE. User Acceptance Testing: If you had limited documentation, how would you plan your testing? In this situation we should get information from development team, user or visit some references resemble the projects to prepare use cases and requirements or AD-hoc testing for required job. In some case we may need to go with ad-hoc testing because of time constraint or resource constraint. It is done without planning and documentation some tips of ad-hoc testing In case of user interface testing, test all navigation items such as button, links Check the application screen or web pages by setting different screen resolution Try to enter/save test data having special character or combination alpha numeric Try to run the application in different OS and browser environment When testing edit/modify/update feature, modify values of all fields and make sure that every thing is getting update correctly. Try to break the software by randomly trying functionality of software. Explain front and backend testing Front end testing: Testing the application from the user perspective, it consists of functionality, usability, GUI and verification and validation. Web page testing is an ideal example we provide data in front and out put also getting in front Back end testing: Involves databases or any backend storage. Its basically testing data while traveling from front to back end or back end to back end. In my previous jobs we feed test data to the system through the oracle from then data is stored in database when we run the testing process then the out put is stored all so data base and we have to write the SQL script to get the data for verification with expected result. Data base and data warehouse is the back end testing. How do you ensure test coverage? How much program is exercised by a test suite expressed in percentage (Test suite: A collection of test scenarios and/or test cases that are related with each other). Test coverage is one of the most important indicators of software test progress. There are many ways to track test coverage: such as Bug count: This helps that a product is ready or not for release higher count is preferred Requirement coverage: requirement traceability helps that product is ready or not higher count 100% is mandatory Component coverage: tracking test against individual components of a product Code coverage: the lines of code covered measure are use full for showing how much of the application is exercise in testing Explain system use cases (give examples) A use case describes a way in which a real world user interacts with the system. There are two type of use case informal & formal. Informal: Type of use case developed for initial requirements modeling for example we are considering student enrollment for a seminar we can define the use case in this informal way: Name: Enroll in seminar

Identifier: UC 1 Basic course of Action: 1. Student enter his/her name and student number 2. System verifies the student is eligible to enrollment 3. System displays a list of available seminars 4. Student chooses a seminar or decided not to enroll 5. System validates the seminar fits into the students schedule 6. System calculates and displays fees 7. Student verifies the cost may or may not enroll 8. System enrolls the student in the seminar and bills them for it 9. The system prints enrollment receipt A formalized system use case refers to specific user interface components-such as screens, HTML pages. Formal use case example: Name: Enroll in seminar Identifier: UC 17 Description: Enroll an existing student in a seminar for which he/she is eligible Preconditions: The student is registered at the university Post conditions: The student will be enrolled in the course she wants if she is eligible and room is available. Basic course of Action: The use case begins when a student wants to enrol in a seminar The student inputs name and id number in to the system via U/23 Login touch screen The system verifies the student eligible to enrol in seminars at the university according to business rule (BR299) The system displays the list of available seminars in the touch screen U/23 The student indicates the seminar in which she wants to enrol or not to enrol The system validate the seminar fits into the existing schedule of the student according to business rule BR233 The system calculate the fees for the seminar according to business rule BR 133 The system displays the fees and schedule via terminal U/23 The system asks the student he/she wants to enrol? The student indicates to enrol or not If student indicates to enrol the system enrol the students System bills the student and asks he/she want a printed statements If student intend for printed receipt. The system print the receipt The use case ends when the student takes the printed statement. Explain how you would test 3 weeks effort into in 2 weeks. There are number of options that be considered First of all: Re-priorities the tests and run the most important tests first Assuming that we are not running all test cases in this time frame. Must be done risk analysis to left some test cases. If risk is too high then we should consider work over time if it seems the work over time is not sufficient then ask for more staff to help. Explain unit & end-to-end testing, whats the different? Testing methodologies can be categorized into two techniques. White box testing, such as unit testing, it relies on detailed knowledge of the code, and

checks different conditions of components, and classes and their methods, The second is black box testing such functional testing. End to end testing referees to user level testing of component based systems. It verifies that the integrated components works correctly as part of overall system and the existing components of the system works as before. End to-End testing approaches the system from both the functional side and the architecture side, thus combining black-box and white box techniques. Explain what is an exit criterion? Is a part test plan establishing certain criteria when we can call off testing? The criteria are: All the test trouble report (ttr) must be close All test must passed Test manager must sign off the release. When do you know when its time to stop testing? Testing is potentially endless. We can not test till we uncover all bugs and corrected. At some point we have to stop. The question is when as we know testing is a trade off between budget, time and quality. Any of the allocated resource such as time, money and test cased exhausted then we have to stop testing the optimistic stopping rule is to stop testing when reliability meets the requirement, or benefit from continuing testing can not justify the testing cost. A critical defect is found 3 days before delivery. Dev. can fix it in 15 minutes, what would you do? Its a management issue according to release management a complete list of software that is to be Implemented on a schedule release date will be released and published to all business users three days prior to implementation. On the other hand it depend on code freeze schedule describe in release management. For the sake of project deadline consulting with management may be Ill allow retesting. What is Analysis: The purpose of analysis to understand what will be built why we are built it at what cost and in what order it should be built. The purpose is to determine what users want to have built. The main goal to under stand the user needs and potential usage of the system. It represents middle ground between requirements and design. Testing Data Warehouse Applications-the ETL Perspective Data Warehouse is the main repository of any organizations historical data. It contains the material and information for managements decision support system. Data warehouse testing phases Business Understanding High level Test Approach Test Estimation Review business specifications Attend Business specifications and Technical Specification walkthrough Test plan creation, review and walkthrough Source-target mapping document (ETL initiative Test case creation, review and walkthrough Test Bed & environment set up Test data creation and prediction of test result ie expected result Test case execution and regression testing test error report log creation

Deployment: Validating the business rule in the production environment The DW Testing Life Cycle: As with any other piece of software a DW implementation undergoes the natural cycle of Unit, System, Integration testing and Accepting testing. However, unlike others there are no off the shelf testing System testing: Generally the QA team owns this responsibility. Design document is like bible to them all set of test cases are directly based upon it. System test is basically functional testing of the application is a black box. The major challenge here is preparation of test data. An intelligently designed input dataset can bring out the flaws in the application more quickly. When ever possible use production like data. You may also use the data generation tools or customized tools. We must test for all possible combinations of input and specially check out the errors and exceptions. The QA team must test for: Data completeness-match source to target counts. Data aggregations match aggregated data against staging tables. Data aggregation is a process in which information is gathered and expressed in a summary form. A common aggregation purpose to get more information for particular groups based on specific variable such as age, profession, or income. For example, a site that sells music CDs might advertise certain CDs based on the age of the user. A staging involves putting something in a specific location to be accessed at later time. For databases, the most common staging location would be data base table. There is a physical data movement from source database to data warehouse database. Staging area is primarily designed to serve as intermediate resting place for data before it is processed and integrated into the target data warehouse. Granularity of data is as per specifications. The granularity of data refers of data refers the fineness with which data fields are sub-divided. For example, a postal address can be recorded, with low granularity , as a single field: address =13 thorncliffe Apt:115,Toronto,ON M4H 1L5 Canda or with high granularity, as multiple fields. Error logs and audit tables are generated and populated properly Notification to IT and/or business is generated in proper format. Constraints testing: The objective is to validate unique constraints, primary keys, foreign keys, indexes, and relationships (part of Unit testing) Source to target records counts the objective of the record count test is to match the record counts in the source and the target. Source record count=Record rejected + data loaded in warehouse Source to target field-to field validation. The most labour and through analysis intensive process such as Threshold testing- checking any truncation that may be occurring during the transformation or loading data For example: Source: table1.field1 (VARCHAR 40) Stage: table2.filed5 (VARCHAR 25) Target: table3.field2 (VARCHAR 40) In this example the source field has a threshold of 40,the stage field has a threshold 25 and the target mapping has a threshold of 40.The last 15 characters will be truncated during the ETL process of the stage table. Field- to field testing- is a constant value being populated during the ETL process? The

values in the source fields match the values in respective target fields? Regression testing Integration testing Accepting testing: Performance testing What is the tester goal? All software has bugs; its a fact of life. So the goal of finding and removing all bugs in a software product is a losing proposition, due to four key reasons: The number of possible inputs and possible output is very large The number of paths trough the software is very large The software specification is subjective. You might say that a bug in the eye of the beholder. Consider the example the Microsoft windows Calculator you are assigned to test

You decide to start with addition. You try 1+0=.You get an answer 1.Thats correct. Then you try 1+1=. You get 2.How far do you go? The calculator accept a 32-digit number, so you must try all possibilities up to 1+99999999999999999999999999999999(32 9s)= Once you complete the 1 series, you can move on to 2+0=, 2+1, and so on. Eventually you will get to 99999999999999999999999999999999+9999999999999999999999999999999 9= Next you should try all the decimal values: 1.0+0.1, 1.0+0.2, and so on. Once you verify the regular numbers sum properly, you need to attempt illegal inputs 1+a,z+1,1a1+2b2, they are literally billions upon billions of these. Edited inputs must also be tested; you need to test all button, menu items, and calculator windows If you or your heirs manage to complete all these cases, you can then move on to adding three numbers, then four numbers

There are so many possible entries that you could never complete them, and thats only for addition. You still have subtraction, multiplication, division, square root, percentage, and inverse to cover The point of this example is to demonstrate that its impossible to completely test a program, even software as simple as a calculator. If you decide to eliminate any of the test conditions because you feel theyre redundant or unnecessary, or just to save time, youve decided not to test the program completely. So in the world of general purpose, large-scale, business-critical software, the test team goal is to found all are those defects that will disrupt real production environments; in other words, to find the defects that matter. What are the properties of a good requirement? These are the properties of a good requirement: 1. Requirement should be understand able to all involve in software development projects such as developer, tester, and end users. such as requirement terminology must be understandable to all, the system shall not employ non deterministic method 2. Correct: The behaviour specified must be proper behaviour, correct implies completely correct. For instance, the requirement must indicate the fullest possible conditions. While a requirement to support at least 3 terminals can be considered correct, if the user expects to eventually expand to 300, the requirement should reflect it! Will support 3 terminals initially, but may expand to 300 over time. 3. Complete: The requirement should be considered complete only if not missing any requirements that would separate an acceptable system from one that isnt acceptable! 4. Concise: Requirements should consist of only the necessary information 5. Precise: The bounds of the requirement should be evident and unambiguous, In the case of numerical bounds, it ought to be evident whether the end-points are included or not. Such as system shall accept valid integer number between 1 and 9999 inclusive with out leading zeros as the employee id. 6. Clear: Requirement should be free from high level abstraction such as The items in tab-separated columns and underscore-separated rows of the output may refer to each other, but no item in (row, column) position (i, j) may refer to another in position (p, q) unless p < i, or if i = p, q < j. It should be like this The out put consist of rows and columns, Items across each row are separated by tabs. There is an underscore between rows 7. Unambiguous: The unspecified referent is a great problem: when using words like the,it,that,readers can become confused about which it the writer is referring to 8. Consistent: Requirement should agree with each other: one requirement should not stipulate something that is not conflict with other requirements. 9. Traceable: Each requirement should have a unique identifier; requirement should be traceable in the code. We ought to be able to answer the question why is this code here?

10. Modifiable: Its a reality that requirements can change, so requirements should be modifiable. 11. Testable (Verifiable): Requirements ought to be something that can be verified, they ought to provide outputs that are measureable based on a given set of inputs. This is called design for testability. 12. Feasible: Feasible means that the requirement has a sound basis for design. Requirement should not like this When the start button is pressed, the system shall convert a kg of lead into a kg of gold. This is clear, unambiguous, testable, modifiable and even correct requirement, but it is not feasible. Example of a requirement : if the student id is a negative number then an error message will print at the console: student id is out of range What types of documents would you need for QA, and software testing? What types of documents would you need for QA and QC? Software Development Framework (SDF) There are three kind of software development framework 1. Waterfall software development 2.Iterative and Incremental development 3. Automation framework Waterfall development consists of these steps: 1. Project management 2.Time and cost estimation 3.change management 4.software quality assurance 5.inspection 6.software quality gate 7.P00 Access Business concept 8. P02-Idetify business requirements 9.P03-Specify system requirement 10.P04Specify Architectural Solutions 11.P05-Specify system design 12.P06-Construct Software Components 13.P07-Verify Component Integration and system Features 14.P08-Verify system solution 15.P09-Install system solution 16.Continious Process Improvement 17.Process Audit Points 18.External Reference Test team involvement: from P02-09 Software Quality Assurance (SQA): Establish the quality direction and commitment of the organization Provide the means to ensure that the quality activities are implemented The SQA function is created for assessment, control and improvement throughout the software development process Project SQA activities: Communicate goals, recommend tools and training Select SQ-Gate, criteria, and work product for inspection Develop SQA plan WP01.2 and change Management Plan WP01.3 Inspect the SQA plan, communicate SQA plan with stakeholders Implement the SQA plan Monitor and evaluate the processes Software Quality Assurance (SQA) Inputs to SQA Activities: Quality goals, Project Retrospective of similar prior projects

Project Plan-WP01.1 Initial function point count Inspection reports Quality tracking information Outputs as a result of SQA Activities Project specific list of SQ-Gates, SQ-Gate criteria with associated checklist, and templates SQA Plan WP01.2, Change Management Plan WP01.3 SQ-Gate Criteria Check Reports SQ-Gate Certification Reports SQA Plan status reports Process evaluation and audit results Inspection Reports Training, reviews, assessments, recommendations Software Quality Gates (SQ-Gates) Ensure that required deliverables are completed with expected quality outcomes & are available for downstream process Artefacts are reviewed, inspected & base lined prior to SQ-Gate Criteria: Each software quality gate contains a list of criteria Project Manager & SQA Manager determine which criteria will be included for the project, criteria that must be included on every project BRD, SRD Passing SQ-Gates: criteria check, verify that all required artifacts, work products & other elements specified in the SQA plan have been inspected or reviewed prior to SQ-Gate Certification SQ-Gates Certification: Verify that all outputs from a given process have been completed Complete required SQ-Gate Certification Report including signatures Software Quality Gates (SQ-Gates) SDF-SQ-Gates certification reports: SQ-GATE: SQ9-Project Initiated SQ-GATE: SQ8-Business Requirements Completed SQ-Gate: SQ7-System Requirements completed SQ-GATE: SQ6- Architecture Completed SQ-GATE: SQ5- Design Completed SQ-GATE: SQ4- Code & Unit Test completed SQ-GATE: SQ3-Inegration /Feature Test Completed SQ-GATE: SQ2-System Verification Test Completed SQ-GATE: SQ1-User Acceptance Test Completed SQ-GATE: SQ0- Production Ready P07-verify component Integration and System Features: Inputs: Tested Source code (Unit &String) System Design & System Interface Agreements Integration/Feature Test Plan & Cases Unit Test Results, Logs & summary Report Software Build Plan Process Steps: Verify Initial Test Assumptions

Schedule Test Execution Prepare Test Environment Execute Tests Review Test Results Identify & Escalate Issues Create Integration/Feature Results, Log & Summary Report Software Build Package SQ-Gate 3 Certification Criteria SQ3-1 Integration/Feature Test plan executed SQ3-2 Severity1 & 2 MRs resolved SQ3-4 System Test (end-user-like) Environment created SQ3-5 System Test Plan base lined SQ3-6 1st Software Build for system Test Environment created WP07.1 Integration/Feature Test Results Summary Report created WP07.2 Integration/Feature Test Progress Report WP07.3 Integration/Feature Test Log Describe any bug you remember: During my software testing career I unearthed lots of software defects called bugs, some are very important and dangerous. Software defects can be classified in 3 categories sev1, sev2 and sev3 bug. Sev 1 bug causes system crash or data loss such as BEM core dump system must be corrected and put into place with in 24 hours.Sev2 A major Testing item is fails. System performance is below normal load (e.g. response time, batch run time).Functional or performance problems prevent users from performing their jobs.System must be corrected in 48 hours. Such test case failed with fatal error: Sev3-Minor function of the system is unavailable, unusable or over all system performance is below the minimum load requirements. Functional or performance problem causes inconvenience to users. Defect should be corrected during the current release. Memorable bug, I can remember when I was working on AT&Ts ANSB (Accuspan Network Service Biller) ANSB Platform Upgrade project. We were upgrading all hard ware, third party and in house software. The third party software includes database application from oracle 8i to 10g, UNIX operating system salaries 8 to Solaris 10, all Microsoft tools and applicatioin, cobra etc. After upgrade we were running regression testing, in regression testing we are testing all test cases since 1996.We got an unusual fall out in very old test case. The test failed with sev1 level severity. After analyzing the fault this failure due to an uninitialized expiry date indicator. In old oracle 7/8i indicator initialization was not strictly impose such as new oracle 10g.The new database failed due to data corruption of uninitialized indicator. It surprises me and whole team the bug is living with the application long time when it get proper environment it strikes. Same saying remind me no software is bug free. It is impossible to test software in its all possible inputs. Software testing is a risky proposition. What is the purpose of the software testing?

The purpose of software testing to deliver its end user a quality, error free, complete, secure, ready to use product. What is the difference between QA and software testing? QA: a set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meets its objectives. It makes sure we are doing the right things, the right way. QC: a set of activities designed to evaluate a developed work product. It makes sure finished product full fills its requirements it made for. Testing: The process of executing a system with the intent of finding defects How do you scope, organize, and execute a test project? First of all we need to know the scope in the context of test project, scope represents at high level what the system is expected to do, the capabilities of the system, what is the weakness, opportunities, need of the system, future operating vision, system boundary, impacted areas, risks, issues, principles, constrains and assumptions. To get all information we need for scope, I would analyze the business requirements document (BRD), system requirement document (SRD), technical, architectural design of the application, business process, use case of the system, software quality assurance(SQA) plan, the process of software quality gate certification and software quality gate documents. Any other document that relevant to test project and help to meet the quality of the developed product. To organize the project, Define clear roles and responsibilities of test team members Set communication protocol Set testing process-Requirement, change, Defect,release, and Project Management Execute I would 1. Create test strategy, test plan. 2. Create the test suit/test cases that include folders for each functional area to be tested. 3. Prioritize the test cases according to critical functionality Review /inspect integration/Feature Test cases Create new release update check list for test bed creation Before start changing the database for the release check the these lists 1. Review the conversion plan, the conversion plan describes any change in database such add/remove data table, data table fields 2. Reset test region before the DBA apply changes for the release running the reset script (resetdb.sh) 3. Notify the DBA to have the DBA overlay the testing regions. This include installing all new release packages, triggers and views 4. Get the development region info and the new release version info. 5. Create subdirectories to archive the old release code mention the old releases number. Such as $TEST_HOME/OLD release# 6. copy all old file to newly created archive folders 7. Delete the old files from the respective folder

8. Copy the new binaries in the respective folders running the load shell script After building the test region enter the test data in to the database. Check the entered data are correct before running them. Execute the test according running procedure after successful run check the result. Writing sql queries, analyze the result if any discrepancy found check the test data, test cases, compare with requirement 100% make sure its a real bug. Then create the bug report, refer to appropriate design or development group, escalate the issue. After fixing the reset the database Copy the new binaries and rerun the test. If bug is fixed close the TTR. Role and Responsibilities of software quality assurance in a software development project: The SQA Plan provides the SQA and the project Manager with tools for defining and managing the quality associated with delivering the function and features of the software development project. The SQA plan covers all the development activity of the software processes including SDF from process P01,project initiate to P10,Evaluate project Results. SDF have standardized quality processes with associated criteria for all software construction. To be in compliance with these standards, required criteria must be passed at each software quality gate (SQ-Gate).Ten gates are defined, beginning with SQ-9 to SQ-0. Goals: All deliverables inspected according to SQA plan Purpose: Minimize defects detected at later stages of the project Measurement: No of inspection completed/No of planned inspection Goals: Reduce Software Construction defects Purpose: Increase success in defect prevention Measurement: Number of defect found in construction phase increase the defect removal efficiency. Roles: The SQA and Project Manager are responsible for ensuring all work products delivered with in the level of quality defined in the SQA Plan. All project team members are responsible for ensuring the quality of project artefacts. Artifices are defined as any project documentation to be archived for future reference. This includes time and costs, base lined work products, plans, logs, quality reports, etc. Task and Responsibility: The Major tasks associated with software quality assurance for the project as follows: Tasks Responsible Person(s) Ensure the execution of SQA policies, processes and SQA procedures Develop and execute the SQA plan SQA Assist in project planning ,ensure SQA activities are SQA and Project incorporated into the Project Plan, sufficient time and Manager resources are allocated Ensure execution of the project QA activities for the Project Manager

organization Metrics: Metrics support monitoring, controlling and analyzing effectiveness. A metric is computed from one or more measures. A measure is a single piece of raw data. Basic software metrics includes Cycle Time, Errors/Defects, Function potstonetime delivery, and Effort and Project size. Inspections and Quality Gates: A) Deliverable Inspections An inspection is a process that formally examines a work product, idetifies defects and provides a basis for baseline and benchmark measurements. A work product is base lined when it is formally reviewed or inspected and agreed upon. Once work product has been base lined it servers as the basis for further development and can be changed only through formal change control procedures. The SQ-Gate process consists of inspections and SQ-Gate criteria checks and certifications SQ-Gate Certification: is a high level project quality assessment to decide whether the appropriate criterion for the SQ-Gate has been met. B) Change Management Change must be managed in each software development project to ensure effective process utilization and the integrity of resulting products. Change management address changes throughout the project lifecycle, including: Change Requests (CRs) for new and continuing development Maintenance Requests (MRs) arising from testing Software configuration Management C) Non compliance: project team stakeholder are responsible for maintaining the quality of all work products and complying the SDF In order to be in compliance with the processes, SQ-Gate criteria, development policies, and/or processes must be satisfied. Noncompliance issue will be reported to the project SQA and the Project Manager(s) and the affected team members. Defects identified during a review or an inspection must be corrected prior to the base lining of the documents. What sort of a manager would you like to work? I like to work for a manager who can create a productive environment where software tester/developer can thrive and like to work, who will listen to my ideas and give me the authority and responsibility to do the job. Define quality for me as you understand it? There are lots of definitions about quality, in my opinion the best definitions is Fit the purpose because the person/company that is using the product or services will find how suitable the product is. Quality is affect every body in some way for example if eat bad food I might sick and probably out of work for several day, it will affect me, my family, company, and the country. Due to lack of quality it can be global problem. It is necessary for safety first then to reduce waste, cost and creates good will of the product and services attract

customers from the competitors. Quality is an achievable by education, training and following the quality guide line strictly. In respect software quality we can say that quality software may contain these attribute: Meets the customer/end user all kind of requirements such as: functional, nonfunctional, its reasonably bug free and full fill the end user budget requirement and deliver the product on time. Describe to me what you see as a process A process is an activity which take place over time and which has a precise aim regarding the result to be achieved. A process may consist of a partially ordered set of sub processes. A process can be represented by a box with a single input coming into it and single out put from it. Describe to me when you would consider employing a failure mode and effect analysis Failure Mode and Effects Analysis (FMEA) is a proactive tool, technique and quality method that enables the identification and prevention of process or product error before they occur. Tell me about any quality efforts you have overseen or implemented. Describe some of the challenges you faced and how you overcame them. The responsibility of a software quality assurance analyst and testers to oversee the quality of the software development process and the finished product. Software development process quality can oversee by inspection, review and walkthrough. And software finished product quality can be measure by testing. Software quality assurance oversee responsibility on SQA personals like SQA representative and SQA manager. There responsibly includes monitoring the SQA related activities in every development stage of software from requirement gathering to maintenance of the software, SQ-Gate certification process. The software tester responsibility to oversee quality of the finished product, product fit to use, it full fill the end users requirement that includes budget, performance, on time. During the software life cycle they try to verify that software can accomplish certain task. To implement the quality attribute there lot of challenge we can face the most important on is maintaining the project dead line, this challenge is increased proportionally if you work an environment where outage or delay leads million dollar range fines. One week point in the water fall software development model is test team get the whole system at once for test. If there is a delay in development the delay affect the whole testing process it reduced the test time so to accommodate this difficulty we have two kind of solution ask for more resources or over time. At the end of project development finding additional extra resource is quite impossible. To overcome this problem we prefer work longer time and weekend. In this regard I can remember one project this is an AT&T project no PE966.This project adds regulated normalization logic for ATM product. When coding half done the lead developer need to go to England because his mother passed way. Then another lead from BEM he took the responsibility and he delivered us the raw code with out unit testing properly we faced lots problem we get defect every other line of code, so we face lot testing and retesting it was very bad experience, at the end we were successful to deliver the quality product to AT&T which satisfies AT&Ts requirement.

How do you deal with environments that are hostile to quality Change efforts? In this context hostile means unfavourable to quality change efforts, at the beginning most of the people are simply unfavourable to any kind of change, whether it relates to quality or not. The reasons of hostility due to fear of risk change can do harm rather then good, previous bad experience with quality related changes, seen as threat for insecure members of a group. There are no fixed ways to dealing with hostility toward quality change. People welcome changes for two reasons; changing idea is good for affected group or the pain of changing become very minimal. We can convey the above to ideas in this way: 1. Define and explain the comprehensive change management plan for entire project or part of the quality related phase. Communicating this plan to concern stakeholders and get there approval 2. Thoroughly analyze the risk and impacts of the change effort explain details how to mitigate the risk, this will convince the group of people how are opposing the change effort if they under stand that change will do less harm in compare to good. In general, how do you see automation fitting into the overall process of testing? If automating-what is your process for determining what to automate and in what order? OR Can you automate all the test scripts? Explain? OR How do you plan test automation? OR What criteria do you use when determining when to automate a test or leave it manual? Here the term fitting used means appropriate to the situation. In Test automation all phases to testing such as release management, requirement gathering, test planning, test cases creation, test execution, result analysis, bug retorting and tracking can be accomplish by a automation tools like HP Quality Center,zypher. In these situations automation makes sense: 1. Regression during regression we are rerunning huge number of old test case if we use manual test it will take long time for this case using automation tools to perform the regression it best fit. 2. Load, volume, random test need large amounts or long sequence of data ,transactions, or other inputs at a system are easily and profitable automated 3. With the rise of web-based application and rise of complexity of GUI application automation is more likely to alternate of option of manual testing. How do you promote the concept of phase containment and defect prevention? The idea is that defects may be introduced at any stage of SDLC i.e., planning, requirements definition, design, construction, even in testing. If we apply the SQGate certification technique through inspection, review and walk through we can detect error at each stage and prevent them from leaking to downstream phases. The defect and their effects are contained with in the phase that created them.

If you come onboard, give me a general idea of what your first overall tasks will be as far as starting a quality effort. The first tasks would be to get familiar with the existing quality assurance/testing processes defined. Talk to experience member and team lead what kind of project and steps are established in the organization, know the organizations quality goal and goal achievement, procedures. What the best work have you performed? Have you ever worked with QA in developing test tools? Explain the participation Development should have with QA in leveraging such test tools for QA use. No body is perfect as there is always a room for improvement. I always try to do my best everywhere, I did fantastic job in my last company I was involved to develop and test in house automation tool, the tool was created using vb6 in the back end we are using Access Database. That tool is SIF verification tool. The project was 100% successful by using that tool AT&T saving 5% of total software development project cost and for that we were given awards and bonus. What metrics do you think determine a testers progress in an organisation? Non existent Describe the ideal software testing Environment. Testers strive to find as many defects as they can, and customer/end-user want to avoid defects at all cost. These opposite objectives create challenging issues for testers. To fulfill these objectives testers have to more closely emulate the end user/customers, understanding the daily struggles of customer software support personnel and building empathy for them. Customer empathy will provide tester for understanding the importance of taking end-to-end view. Tester will see how the software theyre testing has to fit into much bigger environment and able to withstand all types of external stimuli. The ideal test environment should be as much as possible a replica of end-user/customer production environment, it allows for good requirements, suitable schedules, and adequate trained staff. We need separate test server, separate database server. Suppose software has three inputs, each having a defined valid range, how many test cases will you need to test all the boundary values? Boundary value analysis and Equivalence partitioning both are test case design strategies in black box testing. Equivalence Partitioning: The input domain data is divided into different equivalence data classes. In this process we are taking all possible test cases and placing them into classes. One test value is picked from each class while testing. Example: According to the specification, a program accepts 4 to 10 inputs, which are five-digit integers greater than 10,000.Identify equivalence partitions and possible test cases. Ans: If input conditions specify a number of values n, test with (n-1),n and (n+1) input values, requirement states: Accepts 4 to 10 inputs and each input is 5-digit integer > 10,000 Partition system inputs and outputs into equivalence sets

Number of Input values: 4< (4-10)>10.Here 3 set of number of input value less than 4, in between (4-1) and greater than 10 Input values: 10000< (10001-99999)>99999.Here 3 set of input values less than 10,000 in between (10001-99999) and greater than 99999. There will be total 6 test cases 00000 invalid special value that may be checked 10000 invalid left boundary values 10001 valid left boundary value 50000 valid mid value 99999 valid right boundary value 100000 invalid right boundary value Boundary value analysis: testing technique is used to identify errors at boundaries rather than finding those exist in center based on belief that input values at the extreme ends of input domain causes more errors in system. Test case for input box accepting numbers between 1 and 1000 1 valid left boundary value 1000 valid right boundary value 0 invalid left boundary values 999 invalid right boundary value 2 &1001 invalid values just above the extreme edges Boundary value analysis is often called as a part of stress and negative testing How do you perform regression testing of software? After finishing the Integration/feature testing we need perform the regression testing to check the new functionality introduces in the existing system doesnt introduce new error. Ultimate goal is to uncover new bugs. For regression testing we can use automation tool. When I was working in AT&Ts project in IBM, we were using an IBM in-house tool called Test Verification Systems (TVS).This was developed using Java. The following steps need to finish the regression. 1. Reset the database reset.sh 2. Load all previously ran test case into tvs by running the shell script all_aisefile.sh. Before running this shell we need to update the file list in this shell 3. Load all oracle CTL and sql file in tvs 4 run this shell with aisexx.dat file as the parameter Run_regress.sh aise01.dat 4. Run the java tester from windows command front 5. java Tester r Run_number run_regin >output.log 6. After success full run check the ouput.log file for any fallout. What knowledge do you think are important to be successful in software testing? Testers knowledge and experience is indispensable for any testing method or technique. Experience a kind of intuition that tells them what to test and how. Tester should competent in all ten knowledge categories to be effective 1. The general risk associated with software development and change 2. Knowledge and understanding of the system under test

3. Thoroughly understand the technology the system being deployed. 4. understanding the development methodology 5. Knowledge how to manage test project 6. Understanding how to identify defect, and defect reporting 7. knowledge and understanding of service concept and systems design 8. Knowledge about test artefact and documentation 9. Knowledge and understanding of test result analysis 10. Knowledge about user acceptance testing. How do you analyze your test results? What metrics do you try to provide? The main goal to test software is to find problems. Therefore, it is critical that testers take care to detect when a problem has actually occurred. Most bugs leave behind a trail of evidence. Lets review several possibilities Test Case Failures: The most straightforward evidence that a defect has surfaced is when a test case fails. Abnormal Termination (abend): For certain types of failures, the test case will not finish normally but instead will abnormally terminate or crash. Such crashes occur for different reasons, and each typically return a code or issue an error message. Such as system error abnormal termination signal (signal 6), Core dump, and Fatal error Wait States (Hang): This occurs with catastrophic errors when the operating system has determined it can not safely continue and create a wait state code. A wait state code will identify what the failure was. Such as: 022 a page fault occurred, 027 a power interruption occurred Error logs: In some cases, its possible an error occurs, this variety of failure is usually written to an error log. Tester must review these logs often to see if any silent failures are occurring. Messages: System messages often reveal a lurking defect to the alert tester. Carefully examine all error messages. Do they lead you to the correct understanding of the problem? Do they supply enough information? If not, you have found a valid usability or serviceable bug.

Obtained some incorrect output?

After successful run of test case we need to check the test result to find the discrepancy between actual result and expected result. If discrepancy exists its a potential bug. Problem Diagnosis: After a problem has been detected it needs to be diagnosed. Problem diagnosis is broken into two phases: Level One and Level Two. Level-one Problem Determination Tester will examine the documentation collected fro the problem to get a basic grasp of what happened. He will then do some research to determine if it is a duplicate problem, level one examination includes the following:

a. If an error message was issued from the system, look it up in the system message manual. Try to discover more detailed information about what it means and determine the module that detected the problem. b. In the event of a crash, look up the termination code in the system codes manual to learn what it signifies. From the resulting, memory/core dump, try to determine in which module the failure occurred and location of the failure within that module. c. When there is a return code from a function that signalled an error, look it up to find out what it denotes. After collecting this information ,use it to search defect tracking database if match found then need to determine if there is a fix available if not. This sort of duplicate occurrence is handy for prioritizing bugs, if the duplicate occurrences is blocking the progress of further testing, you may need to inform development that they should place higher priority on resolving it Level-two Problem Determination In level-one if you dont find any match then it may be a new problem. This level of problem determination typically requires additional skills. Among them are: a. Insight into the architecture and instruction set of the computer the software is running on b. Detailed knowledge of the internal structure of the software under test c. Experience with the programming language that the software is written in d. A through understanding of the debugging tools available for the system. Analysis can provide the following measure (matrices) Defect Density: total no of defects reported Test effectiveness: Is the ratio of total bugs detecting in system testing and total bug found during UAT Defect removal efficiency (DRE): total number of defect removed/total number of defect found)*100 Realising you won't be able to test everything - how do you decide what to test first? In this situation we need to analysis the risk where testing should be focused. Risk analysis requires judgement skills, common sense and experience. Consideration may include: a. Functionalities are most important and visible to the software enduser/customers. b. Functionalities has the most safety and financial impact c. Consult with developer find the most critical and complex parts of the code. d. Most important aspect of the system to the user e. Kinds of problems causes most customer service complaints f. Highest risk aspect of the application g. System area never tested before and area that have high usages h. Negative data input testing Where do you get your expected results?

The source of expected result in the input of a test case, Test case is the mapping the requirement .if requirement is not clears enough we can check the pervious similar test case inputs. Some time we can talk to senior tester or programmer. Most of the time experience, commonsense and intuition can dictate the expected results. Mapping out a test plan for a common situation, such as an ATM (Bank) transaction, what Items might include in the Test Plan. Any kind of test plan the following items might include a. Test plan Identifier: This test plan is used for testing ATM terminal used for processing bank transaction of the project PATM01. b. Introduction: This test plan is to document testing strategies and testing areas of ATM, It covers all the ATM areas that need to be tested. The Login interface and withdraw Interface c. Areas to be Tested: Application Login flow, withdraw flow d. Areas not to be tested: None of the processes other than listed above e. Approach: The following test process is to be used system test plan completed and inspected, system test cases completed and reviewed, test data entered, receive new code, which has already been inspected, unit tested and string tested, test case execution, test result verification, regression test and Go/No Go. f. Item Pass/Fail Criteria: The system test team must successfully verify all test cases before the code freeze. If there are still outstanding test cases that cannot be verified prior to installation. Go/No go decision, a meeting will be held with all affected parties(project management, affected interfaces, developers/analysts/managers) to assess the impacts/risk of allowing the release to be implemented into production. g. Entrance and Exit Criteria: Entrance Criteria Code inspections, unit and string testing must be completed prior to entering system test, Access to ATM applications in the environment and associated PINs secured. Exit criteria- all test trouble report resolved ,system test agreement for go/no go negotiated h. Suspension and Resumption Criteria: Suspension Criteria- ATM card is not valid, wrong PIN, altered or damaged card. Resumption-Valid Card and PIN i. Test Deliverables: Integration/system Test plan ,Integration/system Test cases, integration/system Test progress & summary report j. Testing Tasks: Prepare and inspect Test plan and test cases, enter test case data, set up test environment copy the new code into test region after code is being certified by development team, execute the test case and verify test cases. k. Environment requirements: Hard ware and software, database, test region for testing l. Responsibilities: Roles-Tester, Team lead, test case data and execution m. Staff and Training Needs n. Schedule

o. Risk and Contingencies: Delayed delivery code or delayed delivery of test items will require working over time to meet the delivery date. For ATM Forged card, wrong PIN, damaged card how to deal with risks such dont allow any kind of transaction. p. Test case Identifier: The individual test case for the ATM sees the test cases. q. Appendix: Terms, definitions, acronyms, test members, acknowledgements, references(Total 20 items in a test plan) Since there is no requirements document for ATM test we will follow the use cases to create test cases: Use case Initial System Input Function Expected State being tested output Session System is on Insert a System reads Card is and not readable ATM a customers accepted servicing a bank card ATM card system asks customer for entry of PIN System is on Insert a System reads Card is and not unreadable a customers rejected servicing a ATM bank ATM card system customer card displays an error screen, system is ready to start a new session System is Enter a PIN System System asking for accepts displays a entry of PIN customers menu of PIN transaction types System is Perform a System allows System asks displaying transaction customer to whether menu of perform a customer wants transaction transaction another types transaction System is Answer yes System allows System displays asking whether multiple a menu of customer wants transactions in transaction another one session types transaction System is Answer no Session ends System ejects asking whether when customer card and is customer wants chooses not to ready to start a another do another new session transaction transaction Transaction A readable Enter an System System asks

card has been entered

incorrect PIN and then attempt a transaction Choose withdrawal transaction Choose checking account

handles an invalid PIN properly

Withdrawal

Menu of transaction type is being displayed Menu of account type is begin displayed System is displaying the menu of withdrawal

System ask customer to choose an account to withdraw from System asks customer to choose a dollar amount to withdraw System performs a legitimate withdrawal transaction properly

for correct PIN 3 times. Unsuccessful operation due to Wrong PIN number System displays a menu of account types System displays a menu of possible withdrawal amounts System dispenses this amount of cash; and asking for receipt if yes then print a correct receipt showing withdrawal amount and correct updated balance; System records transaction correctly in the log (showing both message to the bank and approval back) System displays an appropriate message and asks customer to choose a different amount

Choose an amount that the system currently has and which is not greater than the account balance

System has been started up with less than the maximum withdrawal amount in cash on hand; System is

Choose an amount greater than what the system currently has

System verifies that it has not sufficient cash on hand to fulfill the request

Deposit

requesting a withdrawal amount Menu of transaction types is being displayed

Choose Deposit transaction

Menu of Choose account types is checking being displayed account System is displaying a request for the customer to type a dollar amount System is requesting that customer insert an envelope Enter a legitimate dollar amount

System asks customer to choose an account to deposit to System asks customer to enter a dollar amount to deposit System asks customer to insert an envelope System performs a legitimate deposit transaction properly

System displays a menu of account types System displays a request for the customer to type a dollar amount System requests that customer insert an envelope System accepts envelope; System prints a correct receipt showing amount and correct updated balance; System records transaction correctly in the log (showing message to the bank, approval back, and acceptance of the envelope) System displays a menu of account types specifying transfer from System displays a menu of account types specifying transfer to

Insert an envelope

Transfer

Menu of transaction types is being displayed

Choose Transfer transaction

Menu of Choose account types checking to transfer from account is being displayed

System asks customer to choose an account to transfer from System asks customer to choose an account to transfer to

Menu of account types to transfer to is being displayed System is displaying a request for the customer to type a dollar amount

Choose savings account

Enter a legitimate dollar amount

System asks customer to enter a dollar amount to transfer System performs a legitimate transfer transaction properly

System displays a request for the customer to type a dollar amount System prints a correct receipt showing amount and correct updated balance; System records transaction correctly in the log (showing both message to the bank and approval back)

If you're given a program that will average student grades, what kinds of inputs would you use? Before answer the question we need to know what is GPA? Is a measure of how well the student doing in there academic studies. The academic grading scale goes from A+ to F, with corresponding grade point ranging from the highest 4.33 to Lowest 0.00 for each letter grade the grade point in fixed following tables shows the Letter grade and their corresponding grade points.
Letter Grade A+ A AB+ B BC+ C CD F DNC Numerical Grade 90 - 100 85 - 89 80 - 84 77 - 79 73 - 76 70 - 72 65 - 69 60 - 64 55 - 59 50 - 54 0 - 49 -Grade Points 4.33 4.00 3.67 3.33 3.00 2.67 2.33 2.00 1.67 1.00 0.00 0.00

Grade point average (GPA) is a ratio of total grade points and total hours of credit attended.
Example Student Transcript Course Biology Credit Hours 3 Grade A+ Grade Points 12

Biology Lab English 101 Mathematics

1 3 3

B C

3 6

0 21 Total Grade Points

10 Total Credit Hours Attempted

GPA= Total Grade Points/ Total Credit Hours Attempted To calculate the gpa we need two kind of input Letter Grade as character or string like (A+) and Credit hours Positive small integer (1-5). The input path will be 12 test cases on valid data 12 invalid data on left boundary, 12 invalid right boundaries is the minimum. What are your most valuable lessons learned from the last Software Testing project that you were involved? The valuable lesson learned from any testing that bugs you will never find them all. (Then memorable bug) What is configuration management? Tools used? Is a field of management that focuses on establishing and maintaining consistency of a system or products performance and its functional and physical attributes with its requirements, design, and operational information? Tools include Rational Clear case, PVCS How do you apply configuration management (CM) process in software testing? The main objective of software configuration management is maintaining the consistency of test artefacts such requiments, design. This includes baselining, version control, release management, build management, controlling changes, tracking status, auditing storage control of the artefacts. How you handle a difficult situation with a co-worker First make list what is upsetting me such as: a. habitually ask to do his/her works while he/she visits chat room b. person makes the off-color jokes("off-color" are acts concerned with sex, a particular ethnic group, or gender) c. person undermining my work or gossiping about me To solve difficult situation with co-workers I can follow these steps Meet the person directly or discuss the situation with the manager. Start the conversation by telling what is upsetting you one by one from the above list after finishing let the person respond, may be its misunderstanding each other it will help you to over come the misunderstanding and personal relation may be improve If persons response is not satisfactory then we can meet with person with manager, manager can work as a referee to help both parties to diffuse the tension among the parties to resolve the communication gap and other miss understanding What are your strong and week points?

The successful Quality Assurance Tester must have educational, technical and soft skills; I have all skills those are my strong point includes: I have formal IT training through computer science degree, certification in software testing, many years of hand on experiences I am self-motivativative, highly organized have an affinity for details and have excellent trouble shooting skills I am able to communicate and work effectively with other team members. I love challenges; I never miss the project dead line, I m a good listener and learner, and a good mentor. Technical skills and experience include: Experience in system, Intersystem, regression, user acceptance, web application testing in various environment and methodology such black box, gray box, waterfall, Rup, agile and different test and operating system environment such windows, UNIX, Linux, IE, Netscape Week points: No body knows every thing, I have lacks of skill such as ERP but I try to learn new technology and skills. I become aware of my weakness in the way I perform my duties. I do my best to full fill that gap through formal training, reading or directly learn from my colleagues. Tell me about how you had to meet a very tight dead line The reputation of test team is generally based on two things: the quality of work and how well deadlines were meat. 1. Care about deadlines, Im vey serious about meeting the deadline and make them number one priority 2. Keep a list of projects & deadlines Write down the deadlines, and have one place that I can check often and sure that I know whats due and when. 3. Communicate a clear deadline among the test team, so every body is aware about deadline 4. Work in a cushion .Its wise to build in a cushion for deadline, by breaking the project time frame in a smaller pieces and estimates the time for each peace and fixed a milestone in these piece time frame. This estimate should be less than original project completion time, This will allow for delays 5. If the above steps failed we will request for additional resource interims of people or overtime. How to motivate a software tester? First of all we need to know what motivation is. Motivation is a process that initiate, guides and maintains goal-oriented behaviours. The term motivation is frequently uses to describe why a person does something. There are three major components to motivation: activatioin, persistence and intensity. Activation involves the decision to initiate behaviour, such as working in software testing. Persistence is the continued effort toward a goal even though obstacles may exist such as taking more time to reach the quality goal. Intensity can be seen in the concentration and vigour that goes into pursuing a goal. To motivate a software tester they should be appreciate from higher management for there hard works, There should be some reward program to finding good critical bugs

my be a small gift or just few kind word or team launch from team manager. This will keep sprit live in testers to keep them motivate. Is an "A fast database retrieval rate" a testable requirement? No. But this can be a testable if the requirement is clear and specifies the acceptable range of retrieval rate i.e. less than 1 second etc. Discuss what test metrics you feel are important to publish an organization? Test metrics are essential data which provide the status of either testing itself or the product under test. These are important matrices need to publish Total Number of test cases executed Number of test case passed and failed, Total number of defects found and number of defect fixed, number of defect unresolved, Defect severity. Explain some techniques for developing software components with respect to testability. Software testability is the degree to which a software artefact such as software system, module, requirement, design document supports testing in a given context. Testability of software components is determined by factors such as: Controllability: It is possible to the control the state of the component under test Observ ability: It is possible to observe test results. Isolate ability: component under test can tested in isolation Understand ability: The component under test is documented Automat ability: The component under test can be automated. Requirements need to fulfill the following criteria in order to be testable: Consistent, complete, unambiguous, quantitative, verifiable Describe a past experience with implementing a test harness in the development of software. When we are writing test cases, whether they are unit, regression, any other kind there are some functions doing same job each time these includes function lunching the application, login the system and report results. We could write these functions each time we start testing a new feature or we could write them once and use them every time as needed. A test harness, at its most simple, is just that systems to handle the elements we will repeat each time you write a test. I was involve to write this kind of function when we are using hp QTP automation tools to check the GUI and web application testing, In GUI there is function login and logout we used every feature of GUI or WebPages. We wrote this function in function library module of QTP and called from other vbscript function. We can write this functionality in Action level to and call this login and logout action script called from other actions. Give me some examples of how you have participated in Integration testing: First I want to explain what integration is, some times its called string test, after unit test developer combined the individual software modules and tested as a group this white box testing limited scope for tester,Occuasanaliy I ran such test Describe your solution to one of the most difficult testing problems you have faced:

Answer is up problem on ICTCSO project when pual went for vacation How do you know your code has met specifications when there are no specifications? Since there is no requirement/specification we will go for ad-hoc testing using the use case if system is unbreakable then we can say it met the useable functionality How do you feel about cyclomatic complexity? When a program contains a decisional module it creates independent path, Cylomatic complexity is a measure of complexity of code related to the number of ways there are to traverse a piece of code. This determine the number the minimum number of inputs you need to test all ways to execute the program. How do you survive chaos? There are several reasons for chaos: Important and seasoned member leave the team, schedule is not managed properly, and code is not test for unit and string testing. One way to survive chaos is to just do what you have been doing at the same pace you have been doing from the start, follow the testing order and schedule if you need more resource ask for interims of human or overtime. How would you ensure 100% coverage during software testing? Requirement metrics A completed trace matrix is only as valuable as the contents. If the requirements are not complete or clear than the test cases designed and executed might fulfill the requirements but the testing won't have provided what was needed. Conversely if the requirements are clear but the test cases are insufficient then a completed trace matrix still doesn't indicate the testing coverage and confidence that How do you deal with criticism? There are two kind of criticism negative and constructive. Negative criticism saying something only with the purpose of showing that it is simply wrong, false, mistaken, objectionable, disreputable or evil. Negative criticism is also often interpreted as an attack against a person. Constructive Criticism aims to show that the same thing can be achieved better way by an alternative approach. How to deal with criticism First of all try to understand the motive of the critics, if its false accusations and any one try to tarnish my image with false things, solve conflicts at personal level and get to point of mutual understanding, some times critics might be right that case its wise to accept them with a learning attitude, there might be something really important in the comment and might be fruitful for me. Analysis the reason why client gave a negative comment, I might carefully address the reason and ratify it. Can talk about IBM criticism and point after migration. What is UML and how to use it for software testing? Unified Modeling Language (UML) is a visual modeling language that can be used to specify, visualize, construct, and document the artefacts of software system. UML can be divided into three logical sub packages such as Foundation, Behavioural Elements, and model management. Behavioural

elements model the dynamic behaviour of the system and includes use case diagram, activity diagram and sequence diagrams. Software testing process use behavioural element package, because most of the activities in software testing seek to discover defects that arise during the execution of a software system and these defects are generally dynamic(behavioural) in nature. UML use cases are often used to express software requirements, they help express computer application work flow. How to monitor test progress? Checking the status report or dashboard in automation testing Describe a few reasons that a bug might not be fixed. The reasons for not fixing a bug are Deadline is very near there is not enough time to left in schedule to fix the bug test and retest. Its not a bug at all tester developer are not aware that requirement change, its a part of software Its to risky to fix software is very complex functionality is intertwined like spaghetti, its possibilities that fix create more bug in other functionalities Fixes are not worth in terms of time and money, this bug is so rare may appear in little used features. Please describe test design techniques like: state-transition diagrams, decision tables, and activity diagrams. State-transition diagrams: are used to give an abstract description of the behaviour of a system. This behaviour is analyzed and represented in series of events that could occur in one or more possible states. The system is described is composed of a finite number of states. State transition testing: models each state a system can exist in models each state transition define for each state transition start state-> input->output-<finish state consider an example switch on off start state:off input : switch on output: light on finish state: on Decision table: When we need to validate the input field data of a user interface the equivalence partitioning and boundary value analysis are very use full technique. But lots of testing that we do as test analyst involves testing the business logic that sits underneath the user interface we can use the above said technique on business logic too, but these three techniques are more suitable. Techniques are: decision tables, use case and state-based testing. Decision tables, like flowcharts, if-then-else and switch-case statements associate conditions with actions to perform. This model connects combinations of conditions with actions or actions that should occur when each particular combination of conditions arises. Any given decision table can be converted into

cause-effect graph, and any given cause effect graph can be converted into a decision table. To create test cases from a decision table or cause-effect graph, we design test inputs that fulfill the conditions given. The test outputs correspond to the action or actions given for that combination of conditions. During test execution, we check that the actual actions taken correspond to the expected actions. Consider an e-commerce application where we need to validate payment information, specifically credit card type, card number, card security code, expiration month, expiration year and card holder name. We can use boundary value analysis and equivalence portioning to test the ability of the application to verify the payment information as much as possible, before sending it to the server. So, once the information goes to the credit car processing company for validation, there are actually a whole set of conditions that determine this processing: Does the named person hold the credit card entered, and is the other information correct? Is it still active or has it been cancelled? Is the person within or over the limit? Is the transaction coming from a normal or suspicious location? The decision table in table 1 shows how these four conditions interact to determine which of the following three actions will occur: Should we approve the transaction? Should we call the cardholder? Should we call the vendor? The decision table shown below: Condition Alternatives Conditions 1 2 3 5 6 7 9 Real Y Y Y Y Y Y N account? Account Y Y Y N N N active? With in Y Y N Y Y N Limit? Location Y N - Y N Y okay? Actions Action Entries Approve? Y N N N N N N Call card N Y Y N Y Y N holder Call vendor N N N Y Y Y Y From the above table if we consider the 1st column of condition alternatives all condition is true is a real active account purchasing in credit limit from genuine location action should be approve the card transactions. In the 2nd column location is suspicious action is disapprove transactions we can go through until

16 columns to check the conditions and their corresponding actions. Each column of condition alternative and action entries produces a test case. The conditions represent the each test inputs. Well replace the Y/N conditions with actual input values for credit card number, security code, expiration date, and card holder name during test design time. Well verify the actions which are the tests expected results. Remove those condition are not feasible for example card is fake how it can be active this condition is ambiguous. A Simple Example Scenario: A marketing company wishes to construct a decision table to decide how to treat clients according to three characteristics: Gender, City, and age group: A (under 30), B (between 30 and 60), C (over 60).The company has four products (W, X, Y and Z) to test market. Product W will appeal to female city dwellers. Product X will appeal to young females. Product Y will appeal to Male middle aged shoppers who do not live in cities. Product Z will appeal to all but older females. 1. Identify Conditions & Values Three data attributes tested by the conditions in this problem are gender, with values M/F, city dweller, with values Y/N and age group, with values A, B, and C as stated in the problem 2. Compute Maximum Number or Rules The maximum number of rule is 2X2X3=12 3. Identify Possible Actions The four actions are: market product W, X, Y and Z Conditions 1 2 3 4 5 6 7 8 9 10 11 12 Gender F M F M F M F M F M F M City dweller Y Y N N Y Y N N Y Y N N Age group A A A A B B B B C C C C 30<age=A 30<age>60= B Age>60 =C Actions W Y Y Y X Y Y Y Y Y Z Y Y Y Y Y Y Y Y Y Y Simplify the decision table Conditions 1 2 Gender F M City dweller Y Y Age group A 30<age=A 30<age>60= B Age>60 =C 3 F N A 4 M N A 5 F Y B 6 M Y B 7 F N B 8 M N B 9 F Y C 10 M N C

Actions W X Y Z

Y Y Y Y

Y Y Y Y Y Y Y Y Y

Y Y Y

Converting the above decision table to test case table: Since there are 10 rules, we get following 10 test cases Conditions Actions Test Case Gender City Age group: Expected result F/M Dweller A,B,C Y/N 1 F Y 23 Women will buy W product 2 M Y All age All age proper buy group product Z 3 4 5 6 7 8 9 10 Activity diagrams: describe the workflow behaviour of a system. Activity diagram is 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.Activitty diagrams can show activities that are conditional or parallel. Activity diagrams should be used in conjunction with other modeling technique such as state diagrams. Activity diagram is used to mode the workflow behind the system being designed. It is also useful for analyzing a use case by describing what actions need to take place and when they should occur. How to Draw: Activity Diagrams Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities are occurring at the same time. The diagram below shows a fork after activity1. This indicates that both activity2 and activity3 are occurring at the same time. After activity2 there is a branch. The branch describes what activities will take place based on a set of conditions. All branches at some point are followed by a merge to indicate the end of the conditional behaviour started by that branch. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state.

Below is a possible activity diagram for processing an order. The diagram shows the flow of actions in the system's workflow. Once the order is received the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing. On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed. Finally the parallel activities combine to close the order.

Test Scenario: No 1 2 3 4

Test Scenarios Send invoice-Fill Oder-Overnight Delivery-Receive Payment-close order Send invoice-Fill Order-Regular Delivery-Receive Payment close order Send Invoice-Receive Payment-Fill order overnight Delivery-Close order Send invoice-Receive Payment-Fill order-Regular Deliveryclose Order.

Describe business process testing and what test design technique would you use for it? A business process or business method is a collection of related, structured activities or task that produce a specific service or product for a particular

customer or customers. It often can be visualized with a flowchart as a sequence of activities. There are three types of business process: 1. Management processes the process that governs the operation of a system such as corporate governance and strategic management. 2. Operational processes that constitute the core business and create the primary value stream. Typical operational processes are purchasing. 3. Supporting processes which support the core processes such accounting The testing of the full business process, from the start of a transaction through to the completion, testing the full business process ensures that the system is really going to work. ((((((((((Extra Information))))))))))))) KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK There are three kind of automation test framework First generation, Second generation and Third generation: In third generation scripts are well-designed, modular, robust, documented, test data take out of the scripts make the framework more flexible same driver script can be used for similar test cases only changing the data, second benefit is that test design and framework implementation are separate tasks-former can be given someone with the domain knowledge and letter to someone with programming skills. This concept is called data-driven testing. Keyword driven testing takes the concept even further by adding keywords driving the test executing into the test data. Designing and implementing a large scale test automation framework for functional testing in component and system level. The framework must be able to execute tests, verify results, recover from expected errors and report results. It must also be both easy to use and maintain. The automation process needs to consider these issues: 1. When to automate-Tool selection process. 2. What to automate-Taking tools and frameworks into use. 3. what to automate first-Test planning and design 4. What can be automated Effect to development and testing processes. 5. How much to automate Other Organizational issues. 6. Build or buy Costs and savings 7. Build in-house or use consultants- Metrics Why an agile method would be more appropriate than a Waterfall method for the next C++ project? There are reasons to support both waterfall and agile methods. However, after looking more closely at these it will be clear why an agile method is the more appropriate choice in this case. First, and most important: as mentioned earlier, once one stage of the waterfall method has been completed, going backwards is practically impossible. This of course makes most software designed and implemented under the waterfall method harder to change with the times and user needs. The common fix to this problem is to go back and design an entirely new system, which is both costly

and inefficient. It must be noted here, however, that there is a view that says the waterfall method was in fact designed to be iterative (Person on CMM) although this is a minority viewpoint. The agile methods, on the other hand do, as the word agile suggests, adapt to change. Their approach to software design and implementation is one which means that at the end of each stage you have a logical program, designed from the outset to cope and adapt with new ideas and to change easily. This may involve a modular approach to the programming, so that if changes are necessary the whole program does not need to be rewritten, thus reducing the overheads. This is also useful when looking at upgrading programs. Another major advantage of agile methods is that not only do you have a launch able product after each stage, but the program is also tested at the end of each stage. This means that bugs are caught sooner in the development cycle, and as such can be eliminated and new tests brought in to double-check for them. This is very different to the waterfall method whereby the product is tested only at the end, and due to the nature of the waterfall method it is difficult to change the program when bugs are found in this test, as the program has been written by this stage. Due to its modular nature, therefore, object-orientated design and programming, such as C++, is much more suited to agile methodology. For example, you would be able to design a C++ project in terms of objects, and code these as separate modules, thus allowing you to test them before integration to reduce the number of bugs you have to deal with when testing the final project. As already discussed, when using agile methodology you will always have a working model that you can release, whereas with the waterfall method there will only be one main release. Therefore, if this main release has a problem delays will occur, which does not help customer satisfaction. When using agile methods, however, a working program can be released on time although it may not always fulfil the entire specification. This would therefore be useful for a C++ project as the manager would be able to be continually updated with progress. The agile method can always be changed to the end-user's liking. If the specification of the project is changed, therefore, this is allowed for in the adaptability of agile methodology, which means that customers are easily accommodated. This is not possible in the waterfall method, as already mentioned, where a change in the requirements would mean that the project would have to start all over again. Both methodologies allow for some sort of departmentalization. In the case of waterfall, this can be done at each stage, while in the case of agile each module of coding can be delegated to separate groups. This means that both methods are fairly quick as several parts can be done at once, although it is used more effectively in agile methodologies than in waterfall methodologies which still

require you to go through each stage in turn. On the plus side, waterfall has defined stages and elements of said stages and allows for thorough planning especially for deployment, so when you do get a product finished deploying can often be a matter of executing the agreed plan. To conclude, the adaptability of the agile methodology makes it the sound choice for the next C++ software development project to be carried out. Although the waterfall method does lend itself to a logical design, implementation and deployment, its lack of future proofing is also a major drawback. As a result, I would choose to use an agile methodology such as extreme programming. Both the Waterfall method and the Agile method of software development have their uses. Although Agile arose as a reaction to the limitations imposed by the Waterfall method, Waterfall still retains its relevance as a better method when the environment is stable with no room for changes, when frequent interactions with ends users and other stakeholders are not possible, or when there is a risk of key developers quitting the project midway. Agile is a lightweight method. As software developers focus on smaller work areas, overhead becomes less, and the project costs considerably less than when using the Waterfall method. When customer requirements are hazy, or the business environment is uncertain, Agile methods that allow making frequent changes, and testing during the construction stage remains the best choice. Successful execution of Agile projects nevertheless requires highly skilled and competent developers, and stakeholders who know what they want. With the scope to accommodate changes, an Agile project can easily lose its way. Here are some of the more popular life cycles:

Waterfall
This traditional life cycle method has been around for decades and has proven its ability to deliver. In fact, the US Department of Defence was actively promoting the use of this method in all its projects when it published Standard 2167A in 1998. Waterfall is defined as a sequential development model with clearly defined deliverables for every phase. Many industry practitioners are strict in performing audit reviews to ensure that the project has satisfied the input criteria before continuing to the next phase. The standard phases of waterfall are shown in the diagram below:

Iterative, Incremental
The main objective of iterative development is to build the system incrementally, starting from basic partial system features and gradually adding more features until the entire system is completed. Compared to waterfall, iterative development allows flexibility in accommodating new requirements or changes thereof. It also provides room for improvement in succeeding iterations based on lessons learned from previous iterations. The diagram below, courtesy of Microsoft's MSF, clearly shows how iterations are scheduled and delivered:

Agile
Agile methodologies arose from the need to develop software applications that could accommodate the fast-paced evolution of the Internet. Agile is, in some way, a variant of iterative life cycle where deliverables are submitted in stages. The main difference is that agile cuts delivery time from months to weeks. Companies practicing agile are delivering software products and enhancements in weeks rather than in months. Moreover, the agile manifesto covered development concepts aside from the delivery life cycle, such as collaboration, documentation, and others. The diagram from Microsoft MSF shows the various components of an agile life cycle:

How to build a successful QA team? There is a famous quote A team with a star player is a good team, but a team without one is a great team Success of team in long run doesnt depend on individual who is considered STAR but does depends on all who form clusters of stars that makes great team. Characteristics of Great Software Testing Team New member should know the reason why he/she has been selected for the team? Clearly define the roles and responsibilities of new members help the individuals to understand the project in bigger context. That includes the relevance of newcomers job, skills of individuals that could be contributed towards the projects, share the common team goal. This does bring great commitment towards the work and hence contributes towards its quality.

Ownership: When project complexity increases in terms of tasks and team size, it would not be possible to keep track of the individuals tasks by single leader. Hence the solution to this would be assigning ownership to individuals. The ownership helps the team member to understand at hand, situation at much broader perspective and bringing common level of understanding among their team members. Support their team member at the time of difficulty of handling task, word of encouragement, correcting their mistakes by not acting as lead but as a peer, acting up on ideas or taking advice for appropriate situation from experienced members would certainly benefit towards shared goal. Collaboration and a solid sense of interdependency in a team will defuse blaming behaviour and stimulate opportunities for learning and improvement. Knowledge of seasoned players in the team: The team-seasoned players indicate the person who has spent considerable amount of time in same project or similar kind of work .They is resources who have vast knowledge about project. By channelling their knowledge in proper way, the entire team could be benefited Motivation Each of team members has unique qualities and unique working style as team lead should motivate the individual in positive way leader should instils the confidence among team members to believe in their abilities and at the same time working at the background. Recognition: Everyone likes to be recognized for his/her work, when an individual is awarded for his/her work, the responsibility of team lead should bring the reason for individual recognition in front of others. As a other member of the team will be encouraged to act on similar grounds and ultimately team benefits from their collective response. There are plenty of things to be considered while building successful team. The key words Unity, Trust, Respect for others opinion and acting without fear are ingredients for great test team, in general successful tem. How to build a successful QA team? There is a famous quote A team with a star player is a good team, but a team without one is a great team Success of team in long run doesnt depend on individual who is considered STAR but does depends on all who form clusters of stars that makes great team. Characteristics of Great Software Testing Team New member should know the reason why he/she has been selected for the team? Clearly define the roles and responsibilities of new members help the individuals to understand the project in bigger context. That includes the relevance of newcomers job, skills of individuals that could be contributed towards the projects, share the common team goal. This does bring great commitment towards the work and hence contributes towards its quality.

Ownership: When project complexity increases in terms of tasks and team size, it would not be possible to keep track of the individuals tasks by single leader. Hence the solution to this would be assigning ownership to individuals. The ownership helps the team member to understand at hand, situation at much broader perspective and bringing common level of understanding among their team members. Support their team member at the time of difficulty of handling task, word of encouragement, correcting their mistakes by not acting as lead but as a peer, acting up on ideas or taking advice for appropriate situation from experienced members would certainly benefit towards shared goal. Collaboration and a solid sense of interdependency in a team will defuse blaming behaviour and stimulate opportunities for learning and improvement. Knowledge of seasoned players in the team: The team-seasoned players indicate the person who has spent considerable amount of time in same project or similar kind of work .They is resources who have vast knowledge about project. By channelling their knowledge in proper way, the entire team could be benefited Motivation Each of team members has unique qualities and unique working style as team lead should motivate the individual in positive way leader should instils the confidence among team members to believe in their abilities and at the same time working at the background. Recognition: Everyone likes to be recognized for his/her work, when an individual is awarded for his/her work, the responsibility of team lead should bring the reason for individual recognition in front of others. As a other member of the team will be encouraged to act on similar grounds and ultimately team benefits from their collective response. There are plenty of things to be considered while building successful team. The key words Unity, Trust, Respect for others opinion and acting without fear are ingredients for great test team, in general successful tem. Why is requirements traceability important? Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward and backward direction; from its origins, through its realization in the design and functional specifications, to its eventual development and deployment and use, through subsequent rounds of modification and refinement. If a requirement is changed or modified, using a requirements traceability matrix the analyst can identify those areas within the functional specifications that are impacted by the requirement and make the appropriate modifications. In addition, the analyst can determine if the portion of the specification being modified traces back to any other requirements. This is important to ensure that the new modification doesnt break any existing requirements within the system.

Similarly, sections of the specification can be traced to areas of the physical code to ensure that all required changes are made during the development process. Test cases can also be traced back to functional specifications. When functional specifications are changed test cases nearly always need to be updated to ensure complete and accurate testing can take place. Project identifier: Project Name such as: PD450 Testing Strategy Overview: what we want to do Testing Stage: Identify the type of testing to be undertaken such UAT Schedule: When start and when will finish 2011.05.11 to 2011.07.11 Location: Test will be carried out in the IBM steal/Victoria Park office Participants: Identify who will involved in testing, what will be the skill set of the participants such as Testing manager, Testers who will do what? Testing Environment: Environment can be subdivided such as Operating System, database, manual testing environment, autotest environment, UAT environment. Equipment environment: Identify the equipment required for testing for example PCs or main frame Data environment: Identify the data to be used for testing such as data come from data base or flat file Backup: Identify how open data backups should be undertaken and who will responsible for back up. Restore: Identify how and when a restore should take place. Release Management: Prior to any testing being undertaken, a complete and documented release management facility must be in place. Such when the software will implemented into the production environment, when a code will be freezes. Software/Tools: Identify any third party soft ware need to test the application may test management or automated test soft ware, how to procure that licenses.