Software Quality Assurance (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that

an item or product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which products are developed or manufactured.

What's difference between client/server and Web Application ? Client/server based is any application architecture where one server application and one or many client applications are involved like your mail server and MS outlook Express, it can be a web application as well, where the Web Application is a kind of client server application that is hosted on the web server and accessed over the internet or interanet. There are lots of things that differs between testing of the two type above and cann't be posted in one post but you can look into the data flow, communication and servside variable like session and security etc

Software Quality Assurance Activities

Application of Technical Methods (Employing proper methods and tools for developing software) Conduct of Formal Technical Review (FTR) Testing of Software Enforcement of Standards (Customer imposed standards or management imposed standards) Control of Change (Assess the need for change, document the change) Measurement (Software Metrics to measure the quality, quantifiable) Records Keeping and Recording (Documentation, reviewed, change control etc. i.e. benefits of docs). What's the difference between STATIC TESTING and DYNAMIC TESTING? Answer1: Dynamic testing: Required program to be executed static testing: Does not involve program execution The program is run on some test cases & results of the programs performance are examined to check whether the program operated as expected E.g. Compiler task such as Syntax & type checking, symbolic execution, program proving, data flow analysis, control flow analysis

Answer2: Static Testing: Verification performed with out executing the system code Dynamic Testing: Verification and validation performed by executing the system code

What is software testing What black box testing types can you tell me about? Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality. Functional testing is also a blackbox type of testing geared to functional requirements of an application. System testing is also a black box type of testing. Acceptance testing is also a black box type of testing. Functional testing is also a black box type of testing. Closed box testing is also a black box type of testing. Integration testing is also a black box type of testing. What is software testing methodology? One software testing methodology is the use a three step process of... 1. Creating a test strategy; 2. Creating a test plan/design; and 3. Executing tests. This methodology can be used and molded to your organization's needs. Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his clients' applications. Whats the difference between QA and testing? TESTING means Quality Control; and QUALITY CONTROL measures the quality of a product; while QUALITY ASSURANCE measures the quality of processes used to create a quality product. Why Testing CANNOT Ensure Quality Testing in itself cannot ensure the quality of software. All testing can do is give you a certain level of assurance (confidence) in the software. On its own, the only thing that testing proves is that under specific controlled conditions, the software functioned as expected by the test cases executed. s regression testing performed manually? The answer to this question depends on the initial testing approach. If the initial testing approach was manual testing, then the regression testing is usually performed manually. Conversely, if the initial testing approach was automated testing, then the regression testing is usually performed by automated testing.

How to choose which defect to remove in 1000000 defects? (because It will take too much resources in order to remove them all.)

Answe2: As a tester we don't fix the defects but we surely can prioritize them once detected. In our org we assign severity level to the defects depending upon their influence on other parts of products. If a defect doesnt allow you to go ahead and test test the product, it is critical one so it has to be fixed ASAP. We have 5 levels as 1-critical 2-High 3-Medium 4-Low 5-Cosmetic Dev can group all the critical ones and take them to fix before any other defect. Answer3: Priority/Severity P1 P2 P3 S1 S2 S3 Generally the defects are classified in aboveshown grid. Every organization / software has some target of fixing the bugs. Example P1S1 -> 90% of the bugs reported should be fixed. P3S3 -> 5% of the bugs reported may be fixed. Rest are taken in letter service packs or versions. Thus the organization should decide its target and act accordingly. Basically bugfree software is not possible. Answer4: Ideally, the customer should assign priorities to their requirements. They tend to resist this. On a large, multi-year project I just completed, I would often (in the lack of customer guidelines) rely on my knowledge of the application and the potential downstream impacts in the modeled business process to prioritize defects. If the customer doesn't then I fell the test organization should based on risk or other, similar considerations.
What is Software Quality? Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is a subjective term. It will depend on who the customer is and their overall

influence in the scheme of things. A wide-angle view of the customers of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organisations management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine reviewers, etc. Each type of customer will have their own view on quality - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free. What are the five dimensions of the Risks? Schedule: Unrealistic schedules, exclusion of certain activities when chalking out a schedule etc. could be deterrents to project delivery on time. Unstable communication link can be considered as a probable risk if testing is carried out from a remote location. Client: Ambiguous requirements definition, clarifications on issues not being readily available, frequent changes to the requirements etc. could cause chaos during project execution. Human Resources: Non-availability of sufficient resources with the skill level expected in the project are not available; Attrition of resources - Appropriate training schedules must be planned for resources to balance the knowledge level to be at par with resources quitting. Underestimating the training effort may have an impact in the project delivery. System Resources: Non-availability of /delay in procuring all critical computer resources either hardware and software tools or licenses for software will have an adverse impact. Quality: Compound factors like lack of resources along with a tight delivery schedule and frequent changes to requirements will have an impact on the quality of the product tested. What is good code? A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards. How do you perform integration testing? To perform integration testing, first, all unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable, or acceptable, based on client input. Why back-end testing is required, if we are going to check the front-end ....? Why we need to do unit testing, if all the features are being tested in System testing. What extra things are tested in unit testing, which can not be tested in System testing.

Answer1: Assume that you're thinking client-server or web. If you test the application on the front end only you can see if the data was stored and retrievd correctly. You can't see if the servers are in an error state or not. many server processes are monitored by another process. If they crash, they are restarted. You can't see that without looking at it. The data may not be stored correctly either but the front end may have cached data lying around and it will use that instead. The least you should be doing is verifying the data as stored in the database. It is easier to test data being transferred on the boundaries and see the results of those transactions when you can set the data in a driver. Answer2: Back-End testing : Basically the requirement of this testing depends on ur project. like Say if ur project is .Ticket booking system,Front end u will provided with an Interface , where u can book the ticket by giving the appropriate details ( Like Place to go, and Time when u wanna go etc..). It will have a Data storage system (Database or XL sheet etc) which is a Back end for storing details entered by the user. After submitting the details ,U might have provided with a correct acknowledgement.But in back end , the details might not updated correctly in Database becoz of wrong logic development. Then that will cause a major problem. and regarding Unit level testing and System testing Unit level testing is for testing the basic checks whether the application is working fyn with the basic requirements.This will be done by developers before delivering to the QA.In System testing , In addition to the unit checks ,u will be performing all the checks ( all possible integrated checks which required) .Basically this will be carried out by tester Answer3: Ever heard about divide and conquer tactic ? It is a same method applied in backend and frontend testing. A good back end test will help minimize the burden of frontend test. Another point is you can test the backend while develope the frontend. A true pararelism could be achived. Backend testing has another problem which must addressed before front end could use it. The problem is concurency. Building a scenario to test concurency is formidable task. A complex thing is hard to test. To create such scenarios will make you unsure which test you already done and which you haven't. What we need is an effective methods to test our application. The simplest method i know is using divide and conquer. Answer4: A wide range of errors are hard to see if you don't see the code. For example, there are many

optimizations in programs that treat special cases. If you don't see the special case, you don't test the optimization. Also, a substantial portion of most programs is error handling. Most programmers anticipate more errors than most testers. Programmers find and fix the vast majority of their own bugs. This is cheaper, because there is no communication overhead, faster because there is no delay from tester-reporter to programmer, and more effective because the programmer is likely to fix what she finds, and she is likely to know the cause of the problems she sees. Also, the rapid feedback gives the programmer information about the weaknesses in her programming that can help her write better code. Many tests -- most boundary tests -- are done at the system level primarily because we don't trust that they were done at the unit level. They are wasteful and tedious at the system level. I'd rather see them properly done and properly automated in a suite of programmer tests. What is retesting? Answer1: Retesting is usually equated with regression testing (see above) but it is different in that is follows a specific fix--such as a bug fix--and is very narrow in focus (as opposed to testing entire application again in a regression test). A product should never be released after any change has been applied to the code, with only retesting of the bug fix, and without a regression test. Answer2: 1. Re-testing is the testing for a specific bug after it has been fixed.(one given by your definition). 2. Re-testing can be one which is done for a bug which was raised by QA but could not be found or confirmed by Development and has been rejected. So QA does a re-test to make sure the bug still exists and again assigns it back to them. when entire project is tested & client have some doubts about the quality of testing, Re-Testing can be called. It can also be testing the same application again for better Quality. Answer3: Regression Testing is, the selective retesting of a system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the reparations and that newly added features have not created problems with previous versions of the software. Also referred to as verification testing It is important to determine whether in a given set of circumstances a particular series of tests has been failed. The supplier may want to submit the software for re-testing. The contract should deal with the parameters for retests, including (1) will test program which are doomed to failure be allowed to finish early, or must they be completed in their entirety? (2) when can, or must, the supplier submit his software for retesting?, and (3) how many times can the supplier fail tests and submit software for retesting is this based on time spent, or the number of attempts? A well drawn contract will grant the customer options in the event of failure of

acceptance tests, and these options may vary depending on how many attempts the supplier has made to achieve acceptance. So the conclusion is retesting is more or less regression testing. More appropriately retesting is a part of regression testing. Answer4: Re-testing is simply executing the test plan another time. The client may request a re-test for any reason - most likely is that the testers did not properly execute the scripts, poor documentation of test results, or the client may not be comfortable with the results. I've performed re-tests when the developer inserted unauthorized code changes, or did not document changes. Regression testing is the execution of test cases "not impacted" by the specific project. I am currently working on testing of a system with poor system documentation (and no user documentation) so our regression testing must be extensive. Answer5: * QA gets a bug fix, and has to verify that the bug is fixed. You might want to check a few things that are a gut feel if you want to and get away by calling it retesting, but not the entire function / module / product. * Development Refuses a bug on the basis of it being Non Reproducible, then retesting, preferably in the presence of the Developer, is needed. How to establish QA Process in an organization? 1.CURRENT SITUATION The first thing you should do is to put what you currently do in a piece of paper in some sort of a flowchart diagram. This will allow you to analyze what is being currently done. 2.DEVELOPMENT PROCESS STAGE Once you have the "big picture", you have to be aware of the current status of your development project or projects. The processes you select will vary depending if you are in early stages of developing a new application (i.e.: developing a version 1.0), or maintaining an existing application (i.e.: working on release 6.7.1). 3. PRIORITIES The next thing you need to do is identify the priorities of your project, for example: - Compliance with industry standards - Validation of new functionality (new GUIs, etc) - Security - Capacity Planning ( You should see "Effective Methods for Software Testing" for more info). Make a list of the priorities, and then assign them values of (H)igh, (M)edium and (L)ow. 4. TESTING TYPES Once you are aware of the priorities, focus on the High first, then Medium, and finally evaluate whether the Low ones need immediate attention. Based on this, you need to select those Testing Types that will provide coverage for your priorities. Example of testing types:

- Functional Testing - Integration Testing - System Testing - System-to-System Testing (for testing interfaces) - Regression Testing - Load Testing - Performance Testing - Stress Testing Etc. 5. WRITE A TEST PLAN Once you have determined your needs, the simplest way to document and implement your process is to elaborate a "Test Plan" for every effort that you are engaged into (i.e.: for every release). For this you can use generic Test Plan templates available in the web that will help you brainstorm and define the scope of your testing: - Scope of Testing (defects, functionality, and what will be and will not be tested). - Testing Types (Functional, Regression, etc). - Responsible people - Requirements traceability matrix (match test cases with requirements to ensure coverage) - Defect tracking - Test Cases DURING AND POST-TESTING ACTIVITIES Make sure you keep track of the completion of your testing activities, the defects found, and that you comply with an exit criteria prior to moving to the next stage in testing (i.e. User Acceptance Testing, then Production Release). Make sure you have a mechanism for: - Reporting - Test tracking What is the testing lifecycle? There is no standard, but it consists of: Test Planning (Test Strategy, Test Plan(s), Test Bed Creation) Test Development (Test Procedures, Test Scenarios, Test Cases) Test Execution Result Analysis (compare Expected to Actual results) Defect Tracking Reporting What is quality?

Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free What is Benchmark? How it is linked with SDLC (Software Development Life Cycle)? or SDLC and Benchmark are two unrelated things.? What are the compoments of Benchmark? In Software Testing where Benchmark fits in? A Benchmark is a standard to measure against. If you benchmark an application, all future application changes will be tested and compared against the benchmarked application. What is the general testing process? The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests. Test data are inputs that have been devised to test the system Test Cases are inputs and outputs specification plus a statement of the function under the test. Test data can be generated automatically (simulated) or real (live). The stages in the testing process are as follows: 1. Unit testing: (Code Oriented) Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. 2. Module testing: A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures and functions. A module encapsulates related components so it can be tested without other system modules. 3. Sub-system testing: (Integration Testing) (Design Oriented) This phase involves testing collections of modules, which have been integrated into subsystems. Sub-systems may be independently designed and implemented. The most common problems, which arise in large software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by

rigorously exercising these interfaces. 4. System testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems and system components. It is also concerned with validating that the system meets its functional and nonfunctional requirements. 5. Acceptance testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data. Acceptance testing may reveal errors and omissions in the systems requirements definition( user - oriented) because real data exercises the system in different ways from the test data. Acceptance testing may also reveal requirement problems where the system facilities do not really meet the users needs (functional) or the system performance (non-functional) is unacceptable. Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for a single client. The alpha testing process continues until the system developer and the client agrees that the delivered system is an acceptable implementation of the system requirements. When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the system builders. After this feedback, the system is modified and either released fur further beta testing or for general sale. What is boundary value analysis? Boundary value analysis is a technique for test data selection. A test engineer chooses values that lie along data extremes. Boundary values include maximum, minimum, just inside boundaries, just outside boundaries, typical values, and error values. The expectation is that, if a systems works correctly for these extreme or special values, then it will work correctly for all values in between. An effective way to test code is to exercise it at its natural boundaries. Boundary Value Analysis is a method of testing that complements equivalence partitioning. In this case, data input as well as data output are tested. The rationale behind BVA is that the errors typically occur at the boundaries of the data. The boundaries refer to the upper limit and the lower limit of a range of values or more commonly known as the "edges" of the boundary. What is the purpose of black box testing?

Answer1: The main purpose of BB Testing is to validate that the application works as the user will be operating it and in the environments of their systems. How do you do system testing and integration testing? You may lose time and money but you may also lose Quality and eventually Customers! Answer2: "What is the purpose of black box testing?" Black-box testing checks that the user interface and user inputs and outputs all work correctly. Part of this is that error handling must work correctly. It's used in functional and system testing. "We do everything in white box testing: - we check each module's function in the unit testing" Who is "we"? Are you programmers or quality assurance testers? Usually, unit testing is done by programmers, and white-box testing would be how they'd do it. "- once unit test result is ok, means that modules work correctly (according to the requirement documemts)" Not quite. It means that on a stand-alone basis, each module is okay. White box testing only tests the internal structure of the program, the code paths. Functional testing is needed to test how the individual components work together, and this is best done from an external perspective, meaning by using the software the way an end user would, without reference to the code (which is what black-box testing is). if we doing testing again in black box will we lose time and money?" No, the opposite: You'll lose money from having to repair errors you didn't catch with the whitebox testing if you don't do some black-box testing. It's far more expensive to fix errors after release than to test for them and fix them early on. But again, who is "we"? The black box testers should not be the people who did the programming; they should be the QA team -- also some end users for the usability testing. Now that I've said that, good programmers will run some basic black-box tests before handing the application to QA for testing. This isn't a substitute for having QA do the tests, but it's a lot quicker for the programmer to find and fix an error right away than to have to go through the whole process of reporting a bug, then fixing and releasing a new build, then retesting. How do you create a test strategy? The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment. Inputs for this process: * A description of the required hardware and software components, including test tools. This

information comes from the test environment, including test tool data. * A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules. * Testing methodology. This is based on known standards. * Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents. * Requirements that the system can not provide, e.g. system limitations. Outputs for this process: * An approved and signed off test strategy document, test plan, including test cases. * Testing issues requiring resolution. Usually this requires additional negotiation at the project management level. What is the purpose of test strategy? Reason number 1: The number one reason of writing a test strategy document is to "have" a signed, sealed, and delivered, FDA (or FAA) approved document, where the document includes a written testing methodology, test plan, and test cases. Reason number 2: Having a test strategy does satisfy one important step in the software testing process. Reason number 3: The test strategy document tells us how the software product will be tested. Reason number 4: The creation of a test strategy document presents an opportunity to review the test plan with the project team. Reason number 5: The test strategy document describes the roles, responsibilities, and the resources required for the test and schedule constraints. Reason number 6: When we create a test strategy document, we have to put into writing any testing issues requiring resolution (and usually this means additional negotiation at the project management level). Reason number 7: The test strategy is decided first, before lower level decisions are made on the test plan, test design, and other testing issues Why Q/A should not report to development? Based on research from the Quality Assurance Institute, the percent of quality groups in each location is noted, 50% - reports to Senior IT Manager - This is the best positioning because it gives the Quality Manager immediate access to the IT Manager to discuss and promote Quality issues, when the quality manager reports elsewhere, quality issues may not be raised to the appropriate level or receive the necessary action. 25% - reports to Manager of systems/programming 15 % reports to Manger oprerations. 10 % outside IT function.

What is a requirements test matrix? The requirements test matrix is a project management tool for tracking and managing testing efforts, based on requirements, throughout the project's life cycle. The requirements test matrix is a table, where requirement descriptions are put in the rows of the table, and the descriptions of testing efforts are put in the column headers of the same table. The requirements test matrix is similar to the requirements traceability matrix, which is a representation of user requirements aligned against system functionality. The requirements traceability matrix ensures that all user requirements are addressed by the system integration team and implemented in the system integration effort. The requirements test matrix is a representation of user requirements aligned against system testing. Similarly to the requirements traceability matrix, the requirements test matrix ensures that all user requirements are addressed by the system test team and implemented in the system testing effort. Can you give me a requirements test matrix template? For a requirements test matrix template, you want to visualize a simple, basic table that you create for cross-referencing purposes. Step 1: Find out how many requirements you have. Step 2: Find out how many test cases you have. Step 3: Based on these numbers, create a basic table. If you have a list of 90 requirements and 360 test cases, you want to create a table of 91 rows and 361 columns. Step 4: Focus on the the first column of your table. One by one, copy all your 90 requirement numbers, and paste them into rows 2 through 91 of the table. Step 5: Now switch your attention to the the first row of the table. One by one, copy all your 360 test case numbers, and paste them into columns 2 through 361 of the table. Step 6: Examine each of your 360 test cases, and, one by one, determine which of the 90 requirements they satisfy. If, for the sake of this example, test case number 64 satisfies requirement number 12, then put a large "X" into cell 13-65 of your table... and then you have it; you have just created a requirements test matrix template that you can use for cross-referencing purposes What metrics are used for bug tracking? Metrics that can be used for bug tracking include the followings: the total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and the number of fixes per week. Metrics for bug tracking can be used to determine when to stop testing, for example, when bug rate falls below a certain level. You CAN learn to use defect tracking software. What is the difference between verification and validation?

Verification takes place before validation, and not vice versa. Verification evaluates documents, plans, code, requirements, and specifications. Validation, on the other hand, evaluates the product itself. The inputs of verification are checklists, issues lists, walkthroughs and inspection meetings, reviews and meetings. The input of validation, on the other hand, is the actual testing of an actual product. The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect, actual product. What stage of bug fixing is the most cost effective? Bug prevention techniques (i.e. inspections, peer design reviews, and walk-throughs) are more cost effective than bug detection What is Defect Life Cycle.? Answer1: Defect life cycle is....different stages after a defect is identified. New (When defect is identified) Accepted (when Development team and QA team accepts it's a Bug) In Progress (when a person is working to resolve the issue-defect) Resolved (once the defect resolved) Completed (Some one who can take up the responsibly Team lead) Closed/reopened (Retested by TE and he will update the Status of the bug) Answer2: Defect Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported. A general Interview answer can be given as: 1. New or Opened 2. Assinged 3. Fixed 4. Tested What's the difference between priority and severity? The word "priority" is associated with scheduling, and the word "severity" is associated with standards. "Priority" means something is afforded or deserves prior attention; a precedence established by urgency or order of or importance. Severity is the state or quality of being severe; severe implies adherence to rigorous standards

or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles. For example, a severe code of behavior. How do you write test cases? When I write test cases, I concentrate on one requirement at a time. Then, based on that one requirement, I come up with several real life scenarios that are likely to occur in the use of the application by an end user. When I write test cases, I describe the inputs, action, or event, and their expected results, in order to determine if a feature of an application is working correctly. To make the test case complete, I also add particulars e.g. test case identifiers, test case names, objectives, test conditions (or setups), input data requirements (or steps), and expected results. Additionally, if I have a choice, I like writing test cases as early as possible in the development life cycle. Why? Because, as a side benefit of writing test cases, many times I am able to find problems in the requirements or design of an application. And, because the process of developing test cases makes me completely think through the operation of the application.