advertisement

Lesson 7...Question Part 1

50 %
50 %
advertisement
Information about Lesson 7...Question Part 1

Published on December 6, 2008

Author: bhushan4qtp

Source: slideshare.net

Description

For Queries mail to : bhushan4qtp@gmail.com or
bhushan4qtp@yahoo.com
advertisement

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 Answer2: Static Testing: Verification performed with out executing the system code Dynamic Testing: Verification and validation performed by executing the system code Software Testing Software testing is a critical component of the software engineering process. It is an element of software quality assurance and can be described as a process of running a program in such a manner as to uncover any errors. This process, while seen by some as tedious, tiresome and unnecessary, plays a vital role in software development. Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should

happen'). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization's size and business structure. What's difference between QA/testing The quality assurance process is a process for providing adequate assurance that the software products and processes in the product life cycle conform to their specific requirements and adhere to their established plans.quot; The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built 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 black-box 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. What’s 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.

How to find all the Bugs during first round of Testing? Answer1: I understand the problems you are facing. I was involved with a web-based HR system that was encountering the same problems. What I ended up doing was going back over a few release cycles and analyzing the types of defects found and when (in the release cycle including the various testing cycles) they were found. I started to notice a distinct trend in certain areas. For each defect type, I started looking into the possibility if it could have been caught in the prior phase (lots of things were being found in the Systems test phase that should have been caught earlier). If so, why wasn't it caught? Could it have been caught even earlier (say via a peer review)? If so, why not? This led me to start examining the various processes and found a definite problem with peer reviews (not very thorough IF they were even being done) and with the testing process (not rigorous enough). We worked with the customer and folks doing the testing to start educating them and improving the processes. The result was the number of defects found in the latter test stages (System test for example) were cut by over half! It was getting harder to find problems with the product as they were discovering them earlier in the process -- saving time & money! Answer2: There could be several reasons for not catching a showstopper in the first or second build/rev. A found defect could either functionally or physiologically mask a second or third defect. Functionally the thread or path to the second defect could have been boken or rerouted to another path or physiologically the tester who found the first defect knows the app must go back and be rewritten so he/she procedes halfheartedly on and misses the second one. I've seen both cases. It is difficult to keep testing on a known defective app. The testers seem to lose interest knowing that what effort they put in to test it, will have to be redone on the next iteration. This will test your metal as a lead to get them to follow through and maintain a professional attitude. Answer3: The best way is to prevent bugs in the first place. Also testing doesn't fix or prevent bugs. It just provides information. Applying this information to your situation is the important part. The other thing that you may be encountering is that testing tends to be exploratory in nature. You have stated that these are existing bugs, but not stated whether tests already existed for these bugs. Bugs in early cycles inhibit exploration. Additionally, a tester's understanding of the application and its relationships and interactions will improve with time and thus more 'interesting' bugs tend to be found in later iterations as testers expand their exploration (ie. think of new tests). No matter how much time you have to read through the documents and inspect artefacts, seeing the actual application is going to trigger new thoughts, and thus introduce previously unthought of tests. Exposure to the application will trigger new thoughts as well, thus the longer your testing goes, the more new tests (and potential bugs) are going to be found. Iterative development is a good way to counter this, as testers get to see something physical earlier, but this issue will always exist to some degree as the passing of time, and exploration of the application allow new tests to be thought of at inconvenient moments. Is 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.) Answe1: Are you the programmer who has to fix them, the project manager who has to supervise the programmers,

the change control team that decides which areas are too high risk to impact, the stakeholder-user whose organization pays for the damage caused by the defects or the tester? The tester does not choose which defects to fix. The tester helps ensure that the people who do choose, make a well-informed choice. Testers should provide data to indicate the *severity* of bugs, but the project manager or the development team do the prioritization. When I say quot;indicate the severityquot;, I don't just mean writing S3 on a piece of paper. Test groups often do follow-up tests to assess how serious a failure is and how broad the range of failure-triggering conditions. Priority depends on a wide range of factors, including code-change risk, difficulty/time to complete the change, which stakeholders are affected by the bug, the other commitments being handled by the person most knowledgeable about fixing a certain bug, etc. Many of these factors are not within the knowledge of most test groups. 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? The quality of the software varies widely from system to system. Some common quality attributes are stability, usability, reliability, portability, and maintainability.

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. What errros/bugs we are missing out by not doing back-end testing. 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 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 organisation’s 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 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 quot;not impactedquot; 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 quot;big picturequot;, 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 quot;Effective Methods for Software Testingquot; 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 quot;Test Planquot; 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 software testing? 1) Software testing is a process that identifies the correctness, completenes, and quality of software. Actually, testing cannot establish the correctness of software. It can find defects, but cannot prove there are no defects. 2) It is a systematic analysis of the software to see whether it has performed to specified requirements. What software testing does is to uncover errors however it does not tell us that errors are still not present. Any recommendation for estimation how many bugs the customer will find till gold release? Answer1: If you take the total number of bugs in the application and subtract the number of bugs you found, the difference will be the maximum number of bugs the customer can find. Seriously, I doubt you will find any sort of calculations or formula that can answer your question with much accuracy. If you could refernce a previous application release, it might give you a rough idea. The best thing to do is insure your test coverage is as good as you can make it then hope you've found the ones the customer might find. Remember Software testing is Risk Management! Answer2: For doing estimation : 1.)Find out the Coverage during testing of ur software and then estimate keeping in mind 80-20 principle. 2.)You can also look at the deepening of your test cases e.g. how much unit level testing and how much life

cycle teting have you performed (Believe that most of the bugs from customer comes due to real use of lifecycle in the software) 3.)You can also refer the defect density from earlier releases of the same product line. by doing these evaluation you can find out the probability of bugs at an approximately optimum estimation. Answer3: You can look at the customer issues mapping from previous release (If you have the same product line) to the current release ,This is the best way of finding estimation for gold release of migration of any product.Secondly, till gold release most of the issues comes from various combination of installation testing like cross-platform,i18 issues,Customization,upgradation and migration. So ,these can be taken as a parameter and then can estimation be completed. When the build comes to the QA team, what are the parameters to be taken for consideration to reject the build upfront without committing for testing ? Answer1: Agree with R&D a set of tests that if one fails you can reject the build. I usually have some build verification tests that just make sure the build is stable and the major functionality is working. Then if one test fails you can reject the build. Answer2: The only way to legitimately reject a build is if the entrance criteria have not been met. That means that the entrance criteria to the test phase have been defined and agreed upon up front. This should be standard for all builds for all products. Entrance criteria could include: - Turn-over documentation is complete - All unit testing has been successfully completed and U/T cases are documented in turn-over - All expected software components have been turned-over (staged) - All walkthroughs and inspections are complete - Change requests have been updated to correct status - Configuration Management and build information is provided, and correct, in turn-over The only way we could really reject a build without any testing, would be a failure of the turn-over procedure. There may, but shouldn't be, politics involved. The only way the test phase can proceed is for the test team to have all components required to perform successful testing. You will have to define entrance (and exit) criteria for each phase of the SDLC. This is an effort to be taken together by the whole development team. Developments entrance criteria would include signed requirements, HLD doc, etc. Having this criteria pre-established sets everyone up for success Answer3: The primary reason to reject a build is that it is untestable, or if the testing would be considered invalid. For example, suppose someone gave you a quot;bad buildquot; in which several of the wrong files had been loaded. Once you know it contains the wrong versions, most groups think there is no point continuing testing of that build. Every reason for rejecting a build beyond this is reached by agreement. For example, if you set a build verification test and the program fails it, the agreement in your company might be to reject the program from testing. Some BVTs are designed to include relatively few tests, and those of core functionality. Failure of any of these tests might reflect fundamental instability. However, several test groups include a lot of additional tests, and failure of these might not be grounds for rejecting a build. In some companies, there are firm entry criteria to testing. Many companies pay lipservice to entry criteria but start testing the code whether the entry criteria are met or not. Neither of these is right or wrong--it's the culture of the company. Be sure of your corporate culture before rejecting a build. Answer4: Generally a company would have set some sort of minimum goals/criteria that a build needs to satisfy - if it satisfies this - it can be accepted else it has to be rejected For eg.

Nil - high priority bugs 2 - Medium Priority bugs Sanity test or Minimum acceptance and Basic acceptance should pass The reasons for the new build - say a change to a specific case - this should pass Not able to proceed - non - testability or even some more which is in relation to the new build or the product If the above criterias don't pass then the build could be rejected. What is software testing? Software testing is more than just error detection; Testing software is operating the software under controlled conditions, to (1) verify that it behaves “as specified”; (2) to detect errors, and (3) to validate that what has been specified is what the user actually wanted. Verification is the checking or testing of items, including software, for conformance and consistency by evaluating the results against pre-specified requirements. [Verification: Are we building the system right?] Error Detection: Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. Validation looks at the system correctness – i.e. is the process of checking that what has been specified is what the user actually wanted. [Validation: Are we building the right system?] In other words, validation checks to see if we are building what the customer wants/needs, and verification checks to see if we are building that system correctly. Both verification and validation are necessary, but different components of any testing activity. The definition of testing according to the ANSI/IEEE 1059 standard is that testing is the process of analysing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item. Remember: The purpose of testing is verification, validation and error detection in order to find problems – and the purpose of finding those problems is to get them fixed. 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 How to validate data? I assume that you are doing ETL (extract, transform, load) and cleaning. If my assumetion is correct then 1. you are builing data warehouse/ data minning 2. you ask right question to wrong place 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. Which of the following Statements about gernerating test cases is false? 1. Test cases may contain multiple valid conditions 2. Test cases may contain multiple invalid conditions 3. Test cases may contain both valid and invalid conditions 4. Test cases may contain more than 1 step. 5. test cases should contain Expected results. Answer1: all the conditions mentioned are valid and not a single condition can be stated as false. Here i think, the condition means the input type or situation (some may call it as valid or invalid, positive or negative) Also a single test case can contain both the input types and then the final result can be verified (it obviously should not bring the required result, as one of the input condition is invalid, when the test case would be executed), this usually happens while writing secnario based test cases. For ex. Consider web based registration form, in which input data type for some fields are positive and for some fields it is negative (in a scenario based test case) Above screen can be tested by generating various scenario's and combinations. The final result can be verified against actual result and the registration should not be carried out sucessfully (as one/some input types are invalid), when this test case is executed. The writing of test case also depends upon the no. of descriptive fields the tester has in the test case template. So more elaborative is the test case template, more is the ease of writing test cases and generating scenario's. So writing of test cases totally depends on the indepth thinking of the tester and there are no predefined or hard coded norms for writing test case. This is according to my understanding of testing and test case writing knowledge (as for many applications, i have written many positive and negative conditions in a single test case and verified different scenario's by generating such test cases) Answer2: The answer to this question will be 3 Test cases may contain both valid and invalid conditions. Since there is no restriction for the test case to be of multiple steps or more than one valid or invalid conditions. But A test case whether it is feature ,unit level or end to end test case ,it can not contain both valid and invalid condition in a unit test case. Because if this will happen then the concept of test case for a result will be dwindled and hence has no meaning. What is “Quality Assurance”? “Quality Assurance” measures the quality of processes used to create a quality product.

Software Quality Assurance (‘SQA’ or ‘QA’) is the process of monitoring and improving all activities associated with software development, from requirements gathering, design and reviews to coding, testing and implementation. It involves the entire software development process - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with, at the earliest possible stage. Unlike testing, which is mainly a ‘detection’ process, QA is ‘preventative’ in that it aims to ensure quality in the methods & processes – and therefore reduce the prevalence of errors in the software. Organisations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers or quality managers. Quality Assurance and Software Development Quality Assurance and development of a product are parallel activities. Complete QA includes reviews of the development methods and standards, reviews of all the documentation (not just for standardisation but for verification and clarity of the contents also). Overall Quality Assurance processes also include code validation. A note about quality assurance: The role of quality assurance is a superset of testing. Its mission is to help minimise the risk of project failure. QA people aim to understand the causes of project failure (which includes software errors as an aspect) and help the team prevent, detect, and correct the problems. Often test teams are referred to as QA Teams, perhaps acknowledging that testers should consider broader QA issues as well as testing. Which things to consider to test a mobile application through black box technique? Answer1: Not sure how your device/server is to operate, so mold these ideas to fit your app. Some highlights are: Range testing: Ensure that you can reconnect when leaving and returning back into range. Port/IP/firewall testing - change ports and ips to ensure that you can connect and disconnect. modify the firewall to shutoff the connection. Multiple devices - make sure that a user receives his messages with other devices connected to the same ip/port. Your app should have a method to determine which device/user sent the message and only return to it. Should be in the message string sent and received. Unless you have conferencing capabilities within the application. Cycle the power of the server and watch the mobile unit reconnect automatically. Mobile unit sends a message and then power off the unit, when powering back on and reconnecting, ensure that the message is returned to the mobile unit. Answer2: Not clearly mentioned which area of the mobile application you are testing with. Whether is it simple SMS application or WAP application, you need to specify more details.If you are working with WAP then you can download simulators from net and start testing over it. 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 sub-systems. 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 non-functional 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's normal practices of the QA specialists with perspective of software? These are the normal practices of the QA specialists with perspective of software [note: these are all QC activities, not QA activities.] 1-Desgin Review Meetings with the System Analyst and If possible should be the part in Requirement gathering 2-Analysing the requirements and the desing and to trace the desing with respect to the requirements 3-Test Planning 4-Test Case Identification using different techniques (With respect to the Web Based Applciation and Desktoip Applications) 5-Test Case Writing (This part is to be assigned to the testing engineers) 6-Test Case Execution (This part is to be assigned to the testing engineers) 7-Bug Reporting (This part is to be assigned to the testing engineers) 8-Bug Review and thier Analysis so that future bus can be removed by desgining some standards from low-level to high level (Testing in Stages) Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-

systems, which are built out of modules that are composed of procedures and functions. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation. The most widely used testing process consists of five stages UNIT TESTING COMPONENT TESTING MODULE TESTING VERIFICATIO WHITE BOX TESTING TECHNIQUES N (TESTS THAT ARE DERIVED FROM KNOWLEDGE SUB-SYSTEM (PROCESS OF THE PROGRAM'S STRUCTURE AND INTEGRATED TESTING ORIENTED) IMPLEMENTATION) TESTING SYSTEM TESTING VALIDATION BLACK BOX TESTING TECHNIQUES USER ACCEPTANCE (PRODUCT (TESTS ARE DERIVED FROM THE PROGRAM TESTING TESTING ORIENTED) SPECIFICATION) HOWEVER, AS DEFECTS ARE DISCOVERED AT ANY ONE STAGE, THEY REQUIRE PROGRAM MODIFICATIONS TO CORRECT THEM AND THIS MAY REQUIRE OTHER STAGES IN THE TESTING PROCESS TO BE REPEATED. ERRORS IN PROGRAM COMPONENTS, SAY MAY COME TO LIGHT AT A LATER STAGE OF THE TESTING PROCESS. THE PROCESS IS THEREFORE AN ITERATIVE ONE WITH INFORMATION BEING FED BACK FROM LATER STAGES TO EARLIER PARTS OF THE PROCESS. How to test and to get the difference between two images which is in the same window? Answer1: How are you doing your comparison? If you are doing it manually, then you should be able to see any major differences. If you are using an automated tool, then there is usually a comparison facility in the tool to do that. Answer2: Jasper Software is an open-source utility which can be compiled into C++ and has a imgcmp function which compares JPEG files in very good detail as long as they have the same dimentions and number of components. Answer3: Rational has a comparison tool that may be used. I'm sure Mercury has the same tool. Answer4: The key question is whether we need a bit-by-bit exact comparison, which the current tools are good at, or an equivalency comparison. What differences between these images are not differences? Near-match comparison has been the subject of a lot of research in printer testing, including an M.Sc. thesis at Florida Tech. It's a tough problem. Testing Strategies Strategy is a general approach rather than a method of devising particular systems for component tests. Different strategies may be adopted depending on the type of system to be tested and the development

process used. The testing strategies are Top-Down Testing Bottom - Up Testing Thread Testing Stress Testing Back- to Back Testing 1. Top-down testing Where testing starts with the most abstract component and works downwards. 2. Bottom-up testing Where testing starts with the fundamental components and works upwards. 3. Thread testing Which is used for systems with multiple processes where the processing of a transaction threads its way through these processes. 4. Stress testing Which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations. 5. Back-to-back testing Which is used when versions of a system are available. The systems are tested together and their outputs are compared. 6. Performance testing. This is used to test the run-time performance of software. 7. Security testing. This attempts to verify that protection mechanisms built into system will protect it from improper penetration. 8. Recovery testing. This forces software to fail in a variety ways and verifies that recovery is properly performed. Large systems are usually tested using a mixture of these strategies rather than any single approach. Different strategies may be needed for different parts of the system and at different stages in the testing process. Whatever testing strategy is adopted, it is always sensible to adopt an incremental approach to sub-system and system testing. Rather than integrate all components into a system and then start testing, the system should be tested incrementally. Each increment should be tested before the next increment is added to the system. This process should continue until all modules have been incorporated into the system. When a module is introduced at some stage in this process, tests, which were previously unsuccessful, may now, detect defects. These defects are probably due to interactions with the new module. The source of the problem is localized to some extent, thus simplifying defect location and repai Debugging Brute force, backtracking, cause elimination. UNIT FOCUSES ON EACH MODULE AND WHETHER IT WORKS CODING TESTING PROPERLY. MAKES HEAVY USE OF WHITE BOX TESTING INTEGRATIO DESIGN CENTERED ON MAKING SURE THAT EACH MODULE WORKS N TESTING WITH ANOTHER MODULE. COMPRISED OF TWO KINDS:

TOP-DOWN AND BOTTOM-UP INTEGRATION. OR FOCUSES ON THE DESIGN AND CONSTRUCTION OF THE SOFTWARE ARCHITECTURE. MAKES HEAVY USE OF BLACK BOX TESTING.(EITHER ANSWER IS ACCEPTABLE) VALIDATION ANALYSIS ENSURING CONFORMITY WITH REQUIREMENTS TESTING MAKING SURE THAT THE SOFTWARE PRODUCT WORKS WITH SYSTEMS SYSTEMS THE EXTERNAL ENVIRONMENT, E.G., COMPUTER SYSTEM, TESTING ENGINEERING OTHER SOFTWARE PRODUCTS. DRIVER AND STUBS DRIVER: DUMMY MAIN PROGRAM STUB: DUMMY SUB-PROGRAM THIS IS BECAUSE THE MODULES ARE NOT YET STAND-ALONE PROGRAMS THEREFORE DRIVE AND OR STUBS HAVE TO BE DEVELOPED TO TEST EACH UNIT. When do we prepare a Test Plan? [Always prepared a Test Plan for every new version or release of the product? ] For four or five features at once, a single plan is fine. Write new test cases rather than new test plans. Write test plans for two very different purposes. Sometimes the test plan is a product; sometimes it's a tool. 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 quot;edgesquot; of the boundary. Describe methods to determine if you are testing an application too much? Answer1: While testing, you need to keep in mind following two things always: -- Percentage of requirements coverage -- Number of Bugs present + Rate of fall of bugs -- Firstly, There may be a case where requirement is covered quite adequately but number of bugs do not fall. This indicates over testing. --- Secondly, There may be a case where those parts of application are also being tested which are not affected by a CHANGE or BUG FIXTURE. This is again a case of over testing. -- Third is the case as you have suggested, with slight modification, i.e bug has sufficiently dropped off but still testing is being at SAME levels as before.

Methods to determine if an application is being over-tested are-- 1. Comparison of 'Rate of Drop in number of Bugs' & 'Effort Invested in Testing' (With all Requirements been met) That is, if bug rate is falling (as it generally happens in all applications), but effort invested in man hours does not fall, this implies Over testing. 2. Comparison of 'Achievment of bug rate threshold' & 'Effort Invested in Testing' (With all Requirements been met) That is, if bug rate has already achieved the agreed-upon value with business and still the testing efforts are being invested with no/little reduction. 3. Verifying if the 'Impact Analysis' for 'Change Requests' has been done properly and being implemented correctly. That is, to check and verify that the components of AUT which have got impacted by the new change are being tested only and no other unrequired component is being tested unneccessarily. If unaffected components are being tested, this implies Over testing. Answer2: If the bug find rate has dropped off considerably, the test group should shift its testing strategy. One of the key problems with heavy reliance on regression testing is that the bug find rate drops off even though there are plenty of bugs not yet found. To find new bugs, you have to run new tests. Every test technique is stronger for some types of bugs and weaker for others. Many test groups use only a few techniques. In our consulting, James Bach and I repeatedly worked with companies that relied on only one or two main techniques. When one technique, any one test technique, yields few bugs, shifting to new technique(s) is likely to expose new problems. At some point, you can use a measure that is only partially statistical -- if your bug find rate is low AND you can't think of any new testing approaches that look promising, THEN you are at the limit of your effectiveness and you should ship the product. That still doesn't mean that the application is overtested. It just means that YOU'RE not going to find many new bugs. Answer3: Best way is to monitor the test defects over the period of time Refer williams perry book, where he has mentioned the concept of 'under test' and 'over test', in fact the data can be plotted to see the criteria. Yes one of the criteria is to monitor the defect rate and see if it is almost zero second method would be using test coverage when it reach 100% (or 100% requirement coverage) Procedural Software Testing Issues Software testing in the traditional sense can miss a large number of errors if used alone. That is why processes like Software Inspections and Software Quality Assurance (SQA) have been developed. However, even testing all by itself is very time consuming and very costly. It also ties up resources that could be used otherwise. When combined with inspections and/or SQA or when formalized, it also becomes a project of its own requiring analysis, design and implementation and supportive communications infrastructure. With it interpersonal problems arise and need managing. On the other hand, when testing is conducted by the developers, it will most likely be very subjective. Another problem is that developers are trained to avoid errors. As a result they may conduct tests that prove the product is working as intended (i.e. proving there are no errors) instead of creating test cases that tend to uncover as many errors as possible. How do I start with testing? Think twice (or may be more) times before you choose a career. Are you interested in it or do u just want to jump on the bandwagon? Prerequisite You can join a software development company as a tester if you can convince the interviewer 1. You have a knack for breaking software

2. You are aware of basic Quality concepts and belive in them 3. You want to pursue Testing as a career and not just to try it OO Software Testing Issues A common way of testing OO software testing-by-poking-around (Binder, 1995). In this case the developer's goal is to show that the product can do something useful without crashing. Attempts are made to quot;breakquot; the product. If and when it breaks, the errors are fixed and the product is then deemed quot;testedquot;. Testing-by-poking-around method of testing OO software is, in my opinion, as unsuccessful as random testing of procedural code or design. It leaves the finding of errors up to a chance. Another common problem in OO testing is the idea that since a superclass has been tested, any subclasses inheriting from it don't need to be. This is not true because by defining a subclass we define a new context for the inherited attributes. Because of interaction between objects, we have to design test cases to test each new context and re-test the superclass as well to ensure proper working order of those objects. Yet another misconception in OO is that if you do proper analysis and design (using the class interface or specification), you don't need to test or you can just perform black-box testing only. However, function tests only try the quot;normalquot; paths or states of the class. In order to test the other paths or states, we need code instrumentation. Also it is often difficult to exercise exception and error handling without examination of the source code. 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: quot;What is the purpose of black box testing?quot; 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. quot;We do everything in white box testing: - we check each module's function in the unit testingquot; Who is quot;wequot;? 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. quot;- once unit test result is ok, means that modules work correctly (according to the requirement documemts)quot; 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?quot; No, the opposite: You'll lose money from having to repair errors you didn't catch with the white-box 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 quot;wequot;? 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 plan/design? Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking... * Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application. * Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases. * It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing. * Test scenarios are executed through the use of test procedures or scripts. * Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. * Test procedures or scripts include the specific data that will be used for testing the process or transaction. * Test procedures or scripts may cover multiple test scenarios. * Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope. * Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment. * Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing. * A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release. Inputs for this process: * Approved Test Strategy Document. * Test tools, or automated test tools, if applicable. * Previously developed scripts, if applicable. * Test documentation problems uncovered as a result of testing. * A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code, and software complexity data. Outputs for this process: * Approved documents of test scenarios, test cases, test conditions, and test data. * Reports of software design issues, given to software developers for correction. What is the purpose of a test plan? Reason number 1: We create a test plan because preparing it helps us to think through the efforts needed to validate the acceptability of a software product. Reason number 2: We create a test plan because it can and will help people outside the test group to understand the why and how of product validation. Reason number 3: We create a test plan because, in regulated environments, we have to have a written test plan. Reason number 4: We create a test plan because the general testing process includes the creation of a test plan. Reason number 5: We create a test plan because we want a document that describes the objectives, scope, approach and focus of the software testing effort. Reason number 6: We create a test plan because it includes test cases, conditions, the test environment, a list of related tasks, pass/fail criteria, and risk assessment. Reason number 7: We create test plan because one of the outputs for creating a test strategy is an approved and signed off test plan document. Reason number 8: We create a test plan because the software testing methodology a three step process, and one of the steps is the creation of a test plan. Reason number 9: We create a test plan because we want an opportunity to review the test plan with the project team. Reason number 10: We create a test plan document because test plans should be documented, so that they are repeatable.

Can we prepare Test Plan without SRS? It is not always mandatory that you should have SRS document to prepare a Test Plan. This kind of Documents Hierarchy is maintained to maintain Organizational standards and also to have clear understanding of the things. Yes you can Prepare a Test plan directly without SRS, When the Requirements are clear with your clients,and when your URD(User Requirement Document ) is supportive enough to clarify the issues. Though we don't have SRS clients will be giving some information SRS only contains mainly Product information But we will not know the Testing effort if we don't have SRS. SRS contains How many cycles we are testing, and on the platforms we are testing , etc. Actually there won't be any harm in doing so, becoz, ultimately you will send your Test plan document to your client and after getting approval from him only you start Testing. (Note:- SRS is the document which you get in the Analysis phase of your Software Development. Test plan is the document , which contains the details of Product interms of , Tset strategy , Scope of testing, Types of tests to be conducted,Risk Managemnet , Mention of Automation Tool ,About Bug tracking Tool, etc..,) How do test plan templates look like? The test plan document template helps to generate test plan documents that describe the objectives, scope, approach and focus of a software testing effort. Test document templates are often in the form of documents that are divided into sections and subsections. One example of a template is a 4-section document where section 1 is the description of the quot;Test Objectivequot;, section 2 is the the description of quot;Scope of Testingquot;, section 3 is the the description of the quot;Test Approachquot;, and section 4 is the quot;Focus of the Testing Effortquot;. All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. They also help in learning where information is located, making it easier for a user to find what they want. With standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions. A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to valid

Add a comment

Related pages

Tag Questions - Lesson 29, Part 1 - English Grammar (with ...

Topic: Introduction to tag questions: form and use. In Part 1, I limit the discussion to the two most common uses of tag questions and how tag ...
Read more

Lesson 10, Part 1 - Question Formation - Common Mistakes ...

Want to watch this again later? Sign in to add this video to a playlist. Topic: Review question formation. Part 1: yes-no questions and wh ...
Read more

Lesson 7: Lessons and Debates: Part 1 | Tavaana Course Lesson

In this lesson, we will examine some of the most contentious debates that surround the history of the Holocaust. To become familiar with different theories ...
Read more

English Grammar 101 - Parts of Speech

Learn more about the parts of speech and improve your writing with our online grammar ... Principal Parts of Verbs; Lesson 7 ... Lesson 1 : Adjectives ...
Read more

School of Biblical Evangelism

Lesson 1: The Forgotten Key to ... Scientific Facts in the Bible Part 1 : ... within reflect those of the writers and not necessarily that of School of ...
Read more

Learn Arduino Series - Adafruit Learning System

Learn Arduino, Lesson 11. LCD Displays - Part 1 by Simon Monk. This is Lesson 11 in the Learn Arduino Adafruit series. In this lesson, ...
Read more

Lesson 1 - Greeting - Dialog 1 - WordPress.com

Integrated Chinese - Level 1 Part 1 - Vocabulary by Lesson Lesson 6 - Appointments - Month and Week Lesson 6 - Appointments - Year and Day .
Read more

6/7 B: Section 1 Part 1: Environmental Problems - Lessons ...

In class we read A River Ran Wild by Lynne Cherry and witnessed how water becomes polluted. We then tried to figure out ways to clean the water. Watched ...
Read more

Learn German Online for Free at deutsch-lernen.com

... For Beginners and Advanced: 34 German lessons, German Grammar, Idioms, Quotes and 2 Online ... Exercise 1: Ich komme heute später aus dem ...
Read more