You are on page 1of 15

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 program‟s 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

  

    

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

If the customer doesn't then I fell the test organization should based on risk or other. Every organization / software has some target of fixing the bugs. quality is a subjective term. Answer3: Priority/Severity P1 P2 P3 S1 S2 S3 Generally the defects are classified in aboveshown grid. Thus the organization should decide its target and act accordingly. the customer should assign priorities to their requirements. it is critical one so it has to be fixed ASAP. and is maintainable. However. They tend to resist this. similar considerations.Answe2: As a tester we don't fix the defects but we surely can prioritize them once detected. Basically bugfree software is not possible. 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. multi-year project I just completed. On a large. 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. meets requirements and/or expectations. In our org we assign severity level to the defects depending upon their influence on other parts of products. P3S3 -> 5% of the bugs reported may be fixed. Example P1S1 -> 90% of the bugs reported should be fixed. delivered on time and within budget. Answer4: Ideally. If a defect doesnt allow you to go ahead and test test the product. It will depend on who the „customer‟ is and their overall . Rest are taken in letter service packs or versions. What is Software “Quality”? Quality software is reasonably bug-free.

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

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

the supplier submit his software for retesting?. 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. or the number of attempts? A well drawn contract will grant the customer options in the event of failure of . when entire project is tested & client have some doubts about the quality of testing. with only retesting of the bug fix.(one given by your definition). you don't test the optimization. If you don't see the special case.are done at the system level primarily because we don't trust that they were done at the unit level. including (1) will test program which are doomed to failure be allowed to finish early. They are wasteful and tedious at the system level. 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. 2. I'd rather see them properly done and properly automated in a suite of programmer tests. So QA does a re-test to make sure the bug still exists and again assigns it back to them. Also. and more effective because the programmer is likely to fix what she finds. Re-Testing can be called. and (3) how many times can the supplier fail tests and submit software for retesting ñ is this based on time spent. It can also be testing the same application again for better Quality. Re-testing is the testing for a specific bug after it has been fixed. faster because there is no delay from tester-reporter to programmer. Answer2: 1.most boundary tests -. 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. Many tests -. The supplier may want to submit the software for re-testing. A product should never be released after any change has been applied to the code. the rapid feedback gives the programmer information about the weaknesses in her programming that can help her write better code. The contract should deal with the parameters for retests. because there is no communication overhead. and she is likely to know the cause of the problems she sees. or must. 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). This is cheaper. Answer3: Regression Testing is. Programmers find and fix the vast majority of their own bugs. or must they be completed in their entirety? (2) when can. and without a regression test.optimizations in programs that treat special cases. Most programmers anticipate more errors than most testers. a substantial portion of most programs is error handling.

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

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

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

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

writes the test strategy and reviews the plan with the project team.once unit test result is ok. 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. including test tools. each module is okay. It's used in functional and system testing. pass/fail criteria and risk assessment. The test plan may include test cases. the code paths. 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. A test strategy is developed for all levels of testing. means that modules work correctly (according to the requirement documemts)" Not quite. they should be the QA team -. Functional testing is needed to test how the individual components work together. How do you create a test strategy? The test strategy is a formal description of how a software product will be tested. The test team analyzes the requirements. unit testing is done by programmers.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. meaning by using the software the way an end user would. good programmers will run some basic black-box tests before handing the application to QA for testing. It means that on a stand-alone basis.we check each module's function in the unit testing" Who is "we"? Are you programmers or quality assurance testers? Usually. 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. conditions. and white-box testing would be how they'd do it. if we doing testing again in black box will we lose time and money?" No. This isn't a substitute for having QA do the tests. But again. ". then retesting. as required. Now that I've said that. who is "we"? The black box testers should not be the people who did the programming. the test environment. without reference to the code (which is what black-box testing is). then fixing and releasing a new build. a list of related tasks. Inputs for this process: * A description of the required hardware and software components. White box testing only tests the internal structure of the program. and this is best done from an external perspective. "We do everything in white box testing: .also some end users for the usability testing. It's far more expensive to fix errors after release than to test for them and fix them early on. This . Part of this is that error handling must work correctly.

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

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

Verification takes place before validation. Assinged 3. Validation. severe implies adherence to rigorous standards . Fixed 4. evaluates the product itself. is the actual testing of an actual product. reviews and meetings. Severity is the state or quality of being severe.. a precedence established by urgency or order of or importance. and the word "severity" is associated with standards. The inputs of verification are checklists. specifications. plans. plans. The input of validation. What stage of bug fixing is the most cost effective? Bug prevention techniques (i.different stages after a defect is identified. issues lists. The output of validation.. peer design reviews. Tested What's the difference between priority and severity? The word "priority" is associated with scheduling. and requirements document. is a nearly perfect. requirements. A general Interview answer can be given as: 1. and specifications. New or Opened 2. The output of verification is a nearly perfect set of documents.e.. actual product. on the other hand. Verification evaluates documents.? Answer1: Defect life cycle is. "Priority" means something is afforded or deserves prior attention. and not vice versa. code. 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. on the other hand. on the other hand. and walk-throughs) are more cost effective than bug detection What is Defect Life Cycle. inspections. walkthroughs and inspection meetings.

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