Transcript of "Software testing q as collection by ravi"
Software Testing and Technical FAQs - Ravi S
Software QA/Testing Technical FAQsAre you a Software QA engineer or Software tester? Need to update your software QA/testingknowledge or need to prepare for a job interview? Check out this collection of SoftwareQA/Testing Technical FAQs ...Software Quality Assurance(1) A planned and systematic pattern of all actions necessary to provide adequate confidencethat an item or product conforms to established technical requirements.(2) A set of activities designed to evaluate the process by which products are developed ormanufactured.Whats difference between client/server and Web Application ?Client/server based is any application architecture where one server application and one ormany client applications are involved like your mail server and MS outlook Express, it can be aweb application as well, where the Web Application is a kind of client server application that ishosted on the web server and accessed over the internet or internet. There are lots of thingsthat differs between testing of the two type above and cannt be posted in one post but you canlook into the data flow, communication and server side variable like session and security etcSoftware 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).Whats the difference between STATIC TESTING and DYNAMIC TESTING?
Answer1:Dynamic testing: Required program to be executedstatic testing: Does not involve program executionThe program is run on some test cases & results of the program’s performance are examined tocheck whether the program operated as expectedE.g. Compiler task such as Syntax & type checking, symbolic execution, program proving, dataflow analysis, control flow analysisAnswer2:Static Testing: Verification performed with out executing the system codeDynamic Testing: Verification and validation performed by executing the system codeSoftware TestingSoftware testing is a critical component of the software engineering process. It is an element ofsoftware quality assurance and can be described as a process of running a program in such amanner as to uncover any errors. This process, while seen by some as tedious, tiresome andunnecessary, plays a vital role in software development.Testing involves operation of a system or application under controlled conditions and evaluatingthe results (eg, if the user is in interface A of the application while using hardware B, and doesC, then D should happen). The controlled conditions should include both normal and abnormalconditions. Testing should intentionally attempt to make things go wrong to determine if thingshappen when they shouldnt or things dont happen when they should. It is oriented todetection.Organizations vary considerably in how they assign responsibility for QA and testing.Sometimes theyre the combined responsibility of one group or individual. Also common areproject teams that include a mix of testers and developers who work closely together, withoverall QA processes monitored by project managers. It will depend on what best fits anorganizations size and business structure.Whats difference between QA/testingThe quality assuranceprocess is a process for providing adequate assurance that the software products andprocesses in the product life cycle conform to their specific requirements and adhere to theirestablished plans."The purpose of Software Quality Assurance is to provide management with appropriate visibilityinto 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 designor 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 oftesting. Functional testing is also a black box type of testing. Closed box testing is also a blackbox 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; and3. Executing tests. This methodology can be used and molded to your organizations needs.Rob Davis believes that using this methodology is important in the development and ongoingmaintenance of his clients applications.What’s the difference between QA and testing?TESTING means “Quality Control”; andQUALITY CONTROL measures the quality of a product; whileQUALITY ASSURANCE measures the quality of processes used to create a quality product.Why Testing CANNOT Ensure QualityTesting in itself cannot ensure the quality of software. All testing can do is give you a certainlevel of assurance (confidence) in the software. On its own, the only thing that testing proves isthat under specific controlled conditions, the software functioned as expected by the test casesexecuted.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 wasencountering the same problems. What I ended up doing was going back over a few releasecycles and analyzing the types of defects found and when (in the release cycle including thevarious 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 priorphase (lots of things were being found in the Systems test phase that should have been caught
earlier). If so, why wasnt it caught? Could it have been caught even earlier (say via a peerreview)? If so, why not? This led me to start examining the various processes and found adefinite problem with peer reviews (not very thorough IF they were even being done) and withthe testing process (not rigorous enough). We worked with the customer and folks doing thetesting to start educating them and improving the processes. The result was the number ofdefects found in the latter test stages (System test for example) were cut by over half! It wasgetting harder to find problems with the product as they were discovering them earlier in theprocess -- saving time & money!Answer2:There could be several reasons for not catching a showstopper in the first or second build/rev. Afound 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 toanother path or physiologically the tester who found the first defect knows the app must go backand be rewritten so he/she procedes halfheartedly on and misses the second one. Ive seenboth cases. It is difficult to keep testing on a known defective app. The testers seem to loseinterest 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 professionalattitude.Answer3:The best way is to prevent bugs in the first place. Also testing doesnt fix or prevent bugs. It justprovides 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 forthese bugs.Bugs in early cycles inhibit exploration. Additionally, a testers understanding of the applicationand its relationships and interactions will improve with time and thus more interesting bugs tendto 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 previouslyunthought of tests. Exposure to the application will trigger new thoughts as well, thus the longeryour testing goes, the more new tests (and potential bugs) are going to be found. Iterativedevelopment is a good way to counter this, as testers get to see something physical earlier, butthis issue will always exist to some degree as the passing of time, and exploration of theapplication 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 testingapproach was manual testing, then the regression testing is usually performed manually.
Conversely, if the initial testing approach was automated testing, then the regression testing isusually performed by automated testing.How to choose which defect to remove in 1000000 defects? (because It will take toomuch resources in order to remove them all.)Answe1:Are you the programmer who has to fix them, the project manager who has to supervise theprogrammers, the change control team that decides which areas are too high risk to impact, thestakeholder-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 thedevelopment team do the prioritization.When I say "indicate the severity", I dont just mean writing S3 on a piece of paper. Test groupsoften 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 tocomplete the change, which stakeholders are affected by the bug, the other commitments beinghandled by the person most knowledgeable about fixing a certain bug, etc. Many of thesefactors are not within the knowledge of most test groups.Answe2:As a tester we dont fix the defects but we surely can prioritize them once detected. In our orgwe assign severity level to the defects depending upon their influence on other parts ofproducts. If a defect doesnt allow you to go ahead and test test the product, it is critical one so ithas to be fixed ASAP. We have 5 levels as1-critical2-High3-Medium4-Low5-CosmeticDev can group all the critical ones and take them to fix before any other defect.Answer3:Priority/Severity P1 P2 P3S1S2S3
Generally the defects are classified in aboveshown grid. Every organization / software has sometarget 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 orversions.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 alarge, multi-year project I just completed, I would often (in the lack of customer guidelines) relyon my knowledge of the application and the potential downstream impacts in the modeledbusiness process to prioritize defects.If the customer doesnt then I fell the test organization should based on risk or other, similarconsiderations.What is Software “Quality”?Quality software is reasonably bug-free, delivered on time and within budget, meetsrequirements and/or expectations, and is maintainable.However, quality is a subjective term. It will depend on who the ‘customer’ is and their overallinfluence in the scheme of things. A wide-angle view of the ‘customers’ of a softwaredevelopment project might include end-users, customer acceptance testers, customer contractofficers, customer management, the development organisation’smanagement/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-usermight 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 isfollows a specific fix--such as a bug fix--and is very narrow in focus (as opposed to testing entireapplication again in a regression test). A product should never be released after any change hasbeen 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 yourdefinition).2. Re-testing can be one which is done for a bug which was raised by QA but could not befound or confirmed by Development and has been rejected. So QA does a re-test to make surethe 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-Testingcan 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 thatany bugs have been fixed and that no other previously working functions have failed as a resultof the reparations and that newly added features have not created problems with previousversions of the software. Also referred to as verification testingIt is important to determine whether in a given set of circumstances a particular series of testshas been failed. The supplier may want to submit the software for re-testing. The contractshould deal with the parameters for retests, including (1) will test program which are doomed tofailure be allowed to finish early, or must they be completed in their entirety? (2) when can, ormust, the supplier submit his software for retesting?, and (3) how many times can the supplierfail tests and submit software for retesting ñ is this based on time spent, or the number ofattempts? A well drawn contract will grant the customer options in the event of failure ofacceptance tests, and these options may vary depending on how many attempts the supplierhas made to achieve acceptance.So the conclusion is retesting is more or less regression testing. More appropriately retesting isa part of regression testing.Answer4:Re-testing is simply executing the test plan another time. The client may request a re-test forany reason - most likely is that the testers did not properly execute the scripts, poordocumentation of test results, or the client may not be comfortable with the results.Ive performed re-tests when the developer inserted unauthorized code changes, or did notdocument changes.Regression testing is the execution of test cases "not impacted" by the specific project. I amcurrently working on testing of a system with poor system documentation (and no userdocumentation) 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 thingsthat 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 SITUATIONThe first thing you should do is to put what you currently do in a piece of paper in some sort of aflowchart diagram. This will allow you to analyze what is being currently done.2.DEVELOPMENT PROCESS STAGEOnce you have the "big picture", you have to be aware of the current status of yourdevelopment project or projects. The processes you select will vary depending if you are in earlystages of developing a new application (i.e.: developing a version 1.0), or maintaining anexisting application (i.e.: working on release 6.7.1).3. PRIORITIESThe next thing you need to do is identify the priorities of your project, for example: - Compliancewith industry standards - Validation of new functionality (new GUIs, etc) - Security - CapacityPlanning ( You should see "Effective Methods for Software Testing" for more info). Make a list ofthe priorities, and then assign them values of (H)igh, (M)edium and (L)ow.4. TESTING TYPESOnce you are aware of the priorities, focus on the High first, then Medium, and finally evaluatewhether the Low ones need immediate attention.Based on this, you need to select those Testing Types that will provide coverage for yourpriorities. Example of testing types:- Functional Testing- Integration Testing- System Testing- System-to-System Testing (for testing interfaces)- Regression Testing- Load Testing- Performance Testing- Stress TestingEtc.5. WRITE A TEST PLANOnce you have determined your needs, the simplest way to document and implement yourprocess is to elaborate a "Test Plan" for every effort that you are engaged into (i.e.: for everyrelease).For this you can use generic Test Plan templates available in the web that will help youbrainstorm 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 CasesDURING AND POST-TESTING ACTIVITIESMake sure you keep track of the completion of your testing activities, the defects found, and thatyou comply with an exit criteria prior to moving to the next stage in testing (i.e. User AcceptanceTesting, then Production Release).Make sure you have a mechanism for:- Reporting- Test trackingWhat is software testing?1) Software testing is a process that identifies the correctness, completenes, and quality ofsoftware. Actually, testing cannot establish the correctness of software. It can find defects, butcannot prove there are no defects.2) It is a systematic analysis of the software to see whether it has performed to specifiedrequirements. What software testing does is to uncover errors however it does not tell us thaterrors are still not present.Any recommendation for estimation how many bugs the customer will find till goldrelease?Answer1:If you take the total number of bugs in the application and subtract the number of bugs youfound, 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 questionwith much accuracy. If you could refernce a previous application release, it might give you arough idea. The best thing to do is insure your test coverage is as good as you can make it thenhope youve 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-20principle.2.)You can also look at the deepening of your test cases e.g. how much unit level testing andhow much life cycle teting have you performed (Believe that most of the bugs from customercomes 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 optimumestimation.
Answer3:You can look at the customer issues mapping from previous release (If you have the sameproduct line) to the current release ,This is the best way of finding estimation for gold release ofmigration of any product.Secondly, till gold release most of the issues comes from variouscombination of installation testing like cross-platform,i18 issues,Customization,upgradation andmigration.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 forconsideration 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 buildverification 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. Thatmeans 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-overThe only way we could really reject a build without any testing, would be a failure of the turn-over procedure. There may, but shouldnt be, politics involved. The only way the test phase canproceed is for the test team to have all components required to perform successful testing. Youwill have to define entrance (and exit) criteria for each phase of the SDLC. This is an effort to betaken together by the whole development team. Developments entrance criteria would includesigned requirements, HLD doc, etc. Having this criteria pre-established sets everyone up forsuccessAnswer3:The primary reason to reject a build is that it is untestable, or if the testing would be consideredinvalid.For example, suppose someone gave you a "bad build" in which several of the wrong files hadbeen 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 seta build verification test and the program fails it, the agreement in your company might be toreject the program from testing. Some BVTs are designed to include relatively few tests, andthose 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 begrounds for rejecting a build.In some companies, there are firm entry criteria to testing. Many companies pay lipservice toentry criteria but start testing the code whether the entry criteria are met or not. Neither of theseis right or wrong--its the culture of the company. Be sure of your corporate culture beforerejecting a build.Answer4:Generally a company would have set some sort of minimum goals/criteria that a build needs tosatisfy - if it satisfies this - it can be accepted else it has to be rejectedFor eg.Nil - high priority bugs2 - Medium Priority bugsSanity test or Minimum acceptance and Basic acceptance should pass The reasons for the newbuild - say a change to a specific case - this should pass Not able to proceed - non - testabilityor even some more which is in relation to the new build or the product If the above criterias dontpass 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 itbehaves “as specified”; (2) to detect errors, and (3) to validate that what has been specified iswhat the user actually wanted.Verification is the checking or testing of items, including software, for conformance andconsistency by evaluating the results against pre-specified requirements. [Verification: Are webuilding the system right?]Error Detection: Testing should intentionally attempt to make things go wrong to determine ifthings 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 beenspecified 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, andverification checks to see if we are building that system correctly. Both verification and validationare 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.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 ExecutionResult Analysis (compare Expected to Actual results)Defect TrackingReportingHow to validate data?I assume that you are doing ETL (extract, transform, load) and cleaning. If my assumetion iscorrect then1. you are builing data warehouse/ data minning2. you ask right question to wrong placeWhat 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 subjectiveterm. Quality depends on who the customer is and their overall influence in the scheme ofthings. Customers of a software development project include end-users, customer acceptancetest engineers, testers, customer contract officers, customer management, the developmentorganizations 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 mightdefine 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 futureapplication changes will be tested and compared against the benchmarked application.
Which of the following Statements about gernerating test cases is false?Which of the following Statements about gernerating test cases is false?1. Test cases may contain multiple valid conditions2. Test cases may contain multiple invalid conditions3. Test cases may contain both valid and invalid conditions4. 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, whenthe 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 arepositive and for some fields it is negative (in a scenario based test case)Above screen can be tested by generating various scenarios and combinations. The final resultcan 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 testcase template. So more elaborative is the test case template, more is the ease of writing testcases and generating scenarios. So writing of test cases totally depends on the indepth thinkingof 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 manyapplications, i have written many positive and negative conditions in a single test case andverified different scenarios 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 orinvalid conditions. But A test case whether it is feature ,unit level or end to end test case ,it cannot 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 hencehas 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 andreviews 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 thatproblems are found and dealt with, at the earliest possible stage. Unlike testing, which is mainlya ‘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 areproject teams that include a mix of testers and developers who work closely together, withoverall QA processes monitored by project managers or quality managers.Quality Assurance and Software DevelopmentQuality Assurance and development of a product are parallel activities. Complete QA includesreviews of the development methods and standards, reviews of all the documentation (not justfor standardisation but for verification and clarity of the contents also). Overall QualityAssurance processes also include code validation.A note about quality assurance: The role of quality assurance is a superset of testing. Itsmission is to help minimise the risk of project failure. QA people aim to understand the causesof 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, perhapsacknowledging 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. Somehighlights 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 tothe same ip/port. Your app should have a method to determine which device/user sent themessage and only return to it. Should be in the message string sent and received. Unless youhave 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 andreconnecting, 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 itsimple SMS application or WAP application, you need to specify more details.If you are workingwith 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 thecreation of test cases), creation of a test plan/design (which usually includes test cases and testprocedures) and the execution of tests. Test data are inputs that have been devised to test thesystemTest 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 istested independently, without other system components.2. Module testing:A module is a collection of dependent components such as an object class, an abstract datatype or some looser collection of procedures and functions. A module encapsulates relatedcomponents 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 commonproblems, which arise in large software systems, are sub-systems interface mismatches. Thesub-system test process should therefore concentrate on the detection of interface errors byrigorously exercising these interfaces.4. System testing:The sub-systems are integrated to make up the entire system. The testing process is concernedwith finding errors that result from unanticipated interactions between sub-systems and systemcomponents. 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 notreally meet the users needs (functional) or the system performance (non-functional) isunacceptable.Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for asingle client. The alpha testing process continues until the system developer and the clientagrees 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 isoften used.Beta testing involves delivering a system to a number of potential customers who agree to usethat system. They report problems to the system developers. This exposes the product to realuse and detects errors that may not have been anticipated by the system builders. After thisfeedback, the system is modified and either released fur further beta testing or for general sale.Whats 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 inRequirement gathering2-Analysing the requirements and the desing and to trace the desing with respect to therequirements3-Test Planning4-Test Case Identification using different techniques (With respect to the Web BasedApplciation 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 somestandardsfrom low-level to high level (Testing in Stages)Except for small programs, systems should not be tested as a single unit. Large systems arebuilt out of sub-systems, which are built out of modules that are composed of procedures andfunctions. The testing process should therefore proceed in stages where testing is carried outincrementally in conjunction with system implementation.The most widely used testing process consists of five stages
Unit TestingComponenttesting Module Testing White Box Testing Techniques Verification (Tests that are derived from knowledge of Sub-system (Process the programs structure andIntegrated Testing Oriented) implementation)testing System Testing Validation Black Box Testing Techniques AcceptanceUser testing (Product (Tests are derived from the program Testing Oriented) specification)However, as defects are discovered at any one stage, they require program modifications tocorrect 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 toearlier 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 tosee any major differences. If you are using an automated tool, then there is usually acomparison facility in the tool to do that.Answer2:Jasper Software is an open-source utility which can be compiled into C++ and has a imgcmpfunction which compares JPEG files in very good detail as long as they have the samedimentions and number of components.Answer3:Rational has a comparison tool that may be used. Im sure Mercury has the same tool.Answer4:The key question is whether we need a bit-by-bit exact comparison, which the current tools aregood at, or an equivalency comparison. What differences between these images are notdifferences? Near-match comparison has been the subject of a lot of research in printer testing,including an M.Sc. thesis at Florida Tech. Its a tough problem.Testing Strategies
Strategy is a general approach rather than a method of devising particular systems forcomponent tests.Different strategies may be adopted depending on the type of system to be tested and thedevelopment process used. The testing strategies areTop-Down TestingBottom - Up TestingThread TestingStress TestingBack- to Back Testing1. Top-down testingWhere testing starts with the most abstract component and works downwards.2. Bottom-up testingWhere testing starts with the fundamental components and works upwards.3. Thread testingWhich is used for systems with multiple processes where the processing of a transactionthreads its way through these processes.4. Stress testingWhich relies on stressing the system by going beyond its specified limits and hence testing howwell the system can cope with over-load situations.5. Back-to-back testingWhich is used when versions of a system are available. The systems are tested together andtheir 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 improperpenetration.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 singleapproach. Different strategies may be needed for different parts of the system and at differentstages in the testing process.
Whatever testing strategy is adopted, it is always sensible to adopt an incremental approach tosub-system and system testing. Rather than integrate all components into a system and thenstart testing, the system should be tested incrementally. Each increment should be testedbefore the next increment is added to the system. This process should continue until allmodules have been incorporated into the system.When a module is introduced at some stage in this process, tests, which were previouslyunsuccessful, may now, detect defects. These defects are probably due to interactions with thenew module. The source of the problem is localized to some extent, thus simplifying defectlocation and repaiDebuggingBrute force, backtracking, cause elimination. Focuses on each module and whether it works properly.Unit Testing Coding Makes heavy use of white box testing Centered on making sure that each module works with another module. Comprised of two kinds: Top-down andIntegration Design Bottom-up integration.Testing 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 requirementsTesting Making sure that the software product works with theSystems Systems external environment, e.g., computer system, otherTesting Engineering software products.Driver and StubsDriver: dummy main programStub: dummy sub-programThis is because the modules are not yet stand-alone programs therefore drive and or stubshave to be developed to test each unit.When do we prepare a Test Plan?
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 testplans. Write test plans for two very different purposes. Sometimes the test plan is a product;sometimes its a tool.What is boundary value analysis?Boundary value analysis is a technique for test data selection. A test engineer chooses valuesthat lie along data extremes. Boundary values include maximum, minimum, just insideboundaries, just outside boundaries, typical values, and error values. The expectation is that, ifa systems works correctly for these extreme or special values, then it will work correctly for allvalues 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. Inthis case, data input as well as data output are tested. The rationale behind BVA is that theerrors typically occur at the boundaries of the data. The boundaries refer to the upper limit andthe lower limit of a range of values or more commonly known as the "edges" 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 ofbugs do not fall. This indicates over testing.--- Secondly, There may be a case where those parts of application are also being tested whichare 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 sufficientlydropped 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 allRequirements been met) That is, if bug rate is falling (as it generally happens in allapplications), 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 allRequirements 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 beingimplemented correctly. That is, to check and verify that the components of AUT which have gotimpacted by the new change are being tested only and no other unrequired component is beingtested 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 dropsoff even though there are plenty of bugs not yet found. To find new bugs, you have to run newtests.Every test technique is stronger for some types of bugs and weaker for others. Many testgroups use only a few techniques. In our consulting, James Bach and I repeatedly worked withcompanies that relied on only one or two main techniques.When one technique, any one test technique, yields few bugs, shifting to new technique(s) islikely to expose new problems.At some point, you can use a measure that is only partially statistical -- if your bug find rate islow AND you cant think of any new testing approaches that look promising, THEN you are atthe limit of your effectiveness and you should ship the product. That still doesnt mean that theapplication is overtested. It just means that YOURE not going to find many new bugs.Answer3:Best way is to monitor the test defects over the period of timeRefer williams perry book, where he has mentioned the concept of under test and over test, infact 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 methodwould be using test coverage when it reach 100% (or 100% requirement coverage)Procedural Software Testing IssuesSoftware testing in the traditional sense can miss a large number of errors if used alone. That iswhy processes like Software Inspections and Software Quality Assurance (SQA) have beendeveloped. However, even testing all by itself is very time consuming and very costly. It also tiesup resources that could be used otherwise. When combined with inspections and/or SQA orwhen formalized, it also becomes a project of its own requiring analysis, design andimplementation and supportive communications infrastructure. With it interpersonal problemsarise and need managing. On the other hand, when testing is conducted by the developers, itwill most likely be very subjective. Another problem is that developers are trained to avoiderrors. 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 errorsas 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 ujust want to jump on the bandwagon?PrerequisiteYou can join a software development company as a tester if you can convince the interviewer1. You have a knack for breaking software2. You are aware of basic Quality concepts and belive in them3. You want to pursue Testing as a career and not just to try itOO Software Testing IssuesA common way of testing OO software testing-by-poking-around (Binder, 1995). In this case thedevelopers goal is to show that the product can do something useful without crashing. Attemptsare made to "break" the product. If and when it breaks, the errors are fixed and the product isthen deemed "tested".Testing-by-poking-around method of testing OO software is, in my opinion, as unsuccessful asrandom 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, anysubclasses inheriting from it dont need to be.This is not true because by defining a subclass we define a new context for the inheritedattributes. Because of interaction between objects, we have to design test cases to test eachnew 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 classinterface or specification), you dont need to test or you can just perform black-box testing only.However, function tests only try the "normal" paths or states of the class. In order to test theother paths or states, we need code instrumentation. Also it is often difficult to exerciseexception 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 beoperating it and in the environments of their systems. How do you do system testing andintegration testing?You may lose time and money but you may also lose Quality and eventually Customers!Answer2:"What is the purpose of black box testing?"Black-box testing checks that the user interface and user inputs and outputs all work correctly.
Part of this is that error handling must work correctly. Its used in functional and system testing."We do everything in white box testing: - we check each modules function in the unit testing"Who is "we"? Are you programmers or quality assurance testers? Usually, unit testing is doneby programmers, and white-box testing would be how theyd do it."- once unit test result is ok, means that modules work correctly (according to the requirementdocumemts)"Not quite. It means that on a stand-alone basis, each module is okay. White box testing onlytests the internal structure of the program, the code paths. Functional testing is needed to testhow the individual components work together, and this is best done from an externalperspective, meaning by using the software the way an end user would, without reference to thecode (which is what black-box testing is).if we doing testing again in black box will we lose time and money?"No, the opposite: Youll lose money from having to repair errors you didnt catch with the white-box testing if you dont do some black-box testing. Its far more expensive to fix errors afterrelease than to test for them and fix them early on.But again, who is "we"? The black box testers should not be the people who did theprogramming; they should be the QA team -- also some end users for the usability testing.Now that Ive said that, good programmers will run some basic black-box tests before handingthe application to QA for testing. This isnt a substitute for having QA do the tests, but its a lotquicker for the programmer to find and fix an error right away than to have to go through thewhole 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 releaseand preparing logical groups of functions that can be further broken into test procedures. Testprocedures define test conditions, data to be used for testing and expected results, includingdatabase updates, file outputs, report results. Generally speaking...* Test cases and scenarios are designed to represent both typical and unusual situations thatmay occur in the application.* Test engineers define unit test requirements and unit test cases. Test engineers also executeunit test cases.* It is the test team that, with assistance of developers and clients, develops test cases andscenarios 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 testscenarios.* Test procedures or scripts include the specific data that will be used for testing the process ortransaction.* 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 forunit 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 supportfuture application maintenance via regression testing.* A pretest meeting is held to assess the readiness of the application and the environment anddata to be tested. A test readiness document is created to indicate the status of the entrancecriteria 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 generaland detailed design documents, e.g. software design document, source code, and softwarecomplexity 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 theefforts 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 testgroup to understand the why and how of product validation.Reason number 3: We create a test plan because, in regulated environments, we have to havea written test plan.Reason number 4: We create a test plan because the general testing process includes thecreation of a test plan.Reason number 5: We create a test plan because we want a document that describes theobjectives, scope, approach and focus of the software testing effort.Reason number 6: We create a test plan because it includes test cases, conditions, the testenvironment, 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 isan approved and signed off test plan document.Reason number 8: We create a test plan because the software testing methodology a three stepprocess, 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 testplan 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. Thiskind of Documents Hierarchy is maintained to maintain Organizational standards and also tohave clear understanding of the things.Yes you can Prepare a Test plan directly without SRS, When the Requirements are clear withyour clients,and when your URD(User Requirement Document ) is supportive enough to clarifythe issues.Though we dont have SRS clients will be giving some information SRS only contains mainlyProduct informationBut we will not know the Testing effort if we dont have SRS.SRS contains How many cycles we are testing, and on the platforms we are testing , etc.Actually there wont be any harm in doing so, becoz, ultimately you will send your Test plandocument 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 SoftwareDevelopment. Test plan is the document , which contains the details of Product interms of , Tsetstrategy , Scope of testing, Types of tests to be conducted,Risk Managemnet , Mention ofAutomation 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 theobjectives, scope, approach and focus of a software testing effort. Test document templates areoften in the form of documents that are divided into sections and subsections. One example of atemplate is a 4-section document where section 1 is the description of the "Test Objective",section 2 is the the description of "Scope of Testing", section 3 is the the description of the "TestApproach", and section 4 is the "Focus of the Testing Effort".All documents should be written to a certain standard and template. Standards and templatesmaintain document uniformity. They also help in learning where information is located, making iteasier for a user to find what they want. With standards and templates, information will not beaccidentally omitted from a document. Once Rob Davis has learned and reviewed yourstandards and templates, he will use them. He will also recommend improvements and/oradditions.A software project test plan is a document that describes the objectives, scope, approach andfocus of a software testing effort. The process of preparing a test plan is a useful way to thinkthrough the efforts needed to validate the acceptability of a software product. The completeddocument will help people outside the test group understand the why and how of productvalidation.
How to Test a desktop systems ?You will likely have to use a programming or scripting language to interact with the servicedirectly. You will have more control over the raw information that way.You will have to determine what the service is supposed to do and how it is supposed to interactwith other applications and services. A data dictionary likely exists. It may not be called thathowever. What this document does is explain what commands the service will respond to andwhat sort of data should be sent. You will have to use this document to do your testing. Getclose to the person or people who created the document or the service and expect them to keepyou in the loop when changes take place (it doesnt help anyone if you report a defect and itsreally only reflecting an expected change in the operation of the service).Desktop applications are generally designed to run and quit. You have to be concerned withmemory leaks and system usage.How do you create a test strategy?The test strategy is a formal description of how a software product will be tested. A test strategyis developed for all levels of testing, as required. The test team analyzes the requirements,writes the test strategy and reviews the plan with the project team. The test plan may includetest cases, conditions, the test environment, a list of related tasks, pass/fail criteria and riskassessment.Inputs for this process:* A description of the required hardware and software components, including test tools. Thisinformation comes from the test environment, including test tool data.* A description of roles and responsibilities of the resources required for the test and scheduleconstraints. This information comes from man-hours and schedules.* Testing methodology. This is based on known standards.* Functional and technical requirements of the application. This information comes fromrequirements, change request, technical and functional design documents.* Requirements that the system can not provide, e.g. system limitations.Outputs for this process:* An approved and signed off test strategy document, test plan, including test cases.* Testing issues requiring resolution. Usually this requires additional negotiation at the projectmanagement level.How to do Estimating Testing effort ?Time Estimation method for Testing ProcessNote : folloing method is based on use case driven specification.Step 1 : count number of use cases (NUC) of systemstep 2 : Set Avg Time Test Cases(ATTC) as per test plan
step 3 : Estimate total number of test cases (NTC)Total number of test cases = Number of usecases X Avg testcases per a use caseStep 4 : Set Avg Execution Time (AET) per a test case (idelly 15 min depends on your system)Step 5 : Calculate Total Execution Time (TET)TET = Total number of test cases * AETStep 6 : Calculate Test Case Creation Time (TCCT)useually we will take 1.5 times of TET as TCCTTCCT = 1.5 * TETStep 7 : Time for ReTest Case Execution (RTCE) this is for retestinguseually we take 0.5 times of TETRTCE = 0.5 * TETStep 8 : Set Report generation Time (RGTusually we take 0.2 times of TETRGT = 0.2 * TETStep 9 : Set Test Environment Setup Time (TEST)it also depends on test planStep 10 : Total Estimation time = TET + TCCT+ RTCE + RGT + TEST + some buffer...;)ExampleTotal No of use cases (NUC) : 227Average test cases per Use cases(AET) : 10Estimated Test cases(NTC) : 227 * 10 = 2270Time estimation execution (TET) : 2270/4 = 567.5 hrTime for creating testcases (TCCT) : 567.5*4/3 = 756.6 hrTime for retesting (RTCE) : 567.5/2 = 283.75 hrReport Generation(RGT) = 100 hrTest Environment Setup Time(TEST) = 20 hr.-------------------Total Hrs 1727.85 + buffer-------------------here 4 means Number of testcases executed per houri.e 15 min will take for execution of each test caseWhat is the purpose of test strategy?Reason number 1: The number one reason of writing a test strategy document is to "have" asigned, sealed, and delivered, FDA (or FAA) approved document, where the document includesa written testing methodology, test plan, and test cases.Reason number 2: Having a test strategy does satisfy one important step in the software testingprocess.Reason number 3: The test strategy document tells us how the software product will be tested.Reason number 4: The creation of a test strategy document presents an opportunity to review
the test plan with the project team.Reason number 5: The test strategy document describes the roles, responsibilities, and theresources required for the test and schedule constraints.Reason number 6: When we create a test strategy document, we have to put into writing anytesting issues requiring resolution (and usually this means additional negotiation at the projectmanagement level).Reason number 7: The test strategy is decided first, before lower level decisions are made onthe test plan, test design, and other testing issues.Whats Quality Approach document? what should be the contents and things like that...Answer1:you should start thinking from your company business type, and according to it define differentprocesses for your organization. like procurment, CM etcThen think over different matrices you will be calculating for each process, and define them withformula, the kind of analysis will be doing and when shall the red flag to be raised,Decide on your audit policies frequencies etc. Think on the change control board if any processneeds modification.Answer2:By defining the process i mean the structured collection of practices that describe thecharacteristics of the work and its quality. writting process means creating a system with whichevery one will work, the benefits of it are like common language and a shared vision acrossorganization, its will be a frame work for prioritizing actions.From implementation point of view first you need to break the complete life cycle of your productin diffrent meaningful steps, and setting the goals for each phase.you can create different document templates which every one shall follow, Define thedependencies among different groups for each project, Define risks for each project and what ismitigation plan for each risk. etcYou can read the CMMI model, customize that as per your organization goal. for a start upcompany As per my personal opinion, its better to define and reach at the process for Level 3First and then go for level 5.What does a test strategy document contain?The test strategy document contains test cases, conditions, the test environment, a list ofrelated tasks, pass/fail criteria and risk assessment. The test strategy document is a formaldescription of how a software product will be tested. What is the test strategy documentdeveloped for? It is developed for all levels of testing, as required. How is it written, and who
writes it? It is the test team that analyzes the requirements, writes the test strategy, and reviewsthe plan with the project team.Why Q/A should not report to development?Based on research from the Quality Assurance Institute, the percent of quality groups in eachlocation is noted,50% - reports to Senior IT Manager - This is the best positioning because it gives the QualityManager immediate access to the IT Manager to discuss and promote Quality issues, when thequality manager reports elsewhere, quality issues may not be raised to the appropriate level orreceive the necessary action.25% - reports to Manager of systems/programming15 % reports to Manger oprerations.10 % outside IT function.Which of the following statements about Regression statements are true?Which of the following statements about Regression statements are true?1---Regression testing must consist of a fixed set of tests to create a base line2---Regression tests should be used to detect defects in new feature3---Regression testing can be run on every build4--- Regression testing should be targeted areas of high risk and known code change5---Regression testing when automated, is highly effective in preventing defects.Answer1:1---Regression testing must consist of a fixed set of tests to create a base lineDont think it is true as a "must" -- itdepends on whether your regression testing style involves repeating identical tests or redoingtesting in previously tested areas with similar tests or tests that address the same risks. Forexample, some people do regression testing with tests whose specific parameters aredetermined randomly. They broaden the set of values they test while achieving essentially thesame testing. Second example--some regression test suites include random stringing togetherof test cases (they include load testing and duration testing in their regression series, reportingtheir results as part of the assessment of each build). Depending on your theory of the _point_of regression testing, these may or may not be entirely valid regression tests.2---Regression tests should be used to detect defects in new featureHow do you create new regression tests? Should you design new tests as standalone, or shouldyou develop a strategy in which the tests you use for bug-hunting are designed to be reusableas regression tests? If the latter, and I have certainly heard some skilled testers argue that thelatter approach worked well in their sistuation, then #2 is sometimes true.
3---Regression testing can be run on every buildThis is true, though it might be silly and a big waste of time.4--- Regression testing should be targeted areas of high risk and known code changeHmmm, theres a area of computer science called program slicing and one of the objectives ofthis class of work is to figure out how to restrict the regression test suite to a smaller number oftests, which test only those things that might have been impacted by a change. Bob Glass hascriticized the results of some of this work, but if #4 is false, some Ph.D.s and big researchgrants should be retracted.5---Regression testing when automated, is highly effective in preventing defects.Unit-level automated regression testing is highly effective in preventing defects--read up on test-driven development.Answer2:Let me explain why I think 2 & 5 are false2---Regression tests should be used to detect defects in new featureSince regression tests only address existing features and functionality, it cant find defects innew features. It can only find where existing features and functionality have been broken bychanges.5---Regression testing when automated, is highly effective in preventing defects.Since no tests prevent defects, they only find them, its impossible to prevent defects with aregression test. I will add, however, that if a developer can use an automated regression test totest their own code before submitting it to the code repository (say in the form a series of unittests coupled to a library, etc.) then you could in some way prevent defects with a regressiontest.I also dont like 1- and 4. 1- since a regression test suite grows as the product does. Thereforethe tests are not fixed. 4- because a regression test tests the whole application, not just atargeted area. In the past, I have used the concept of test depth (level 1 being the basicregression tests--higher number reflect additional functionality) so you could run a level oneregression on the whole program but do level three on the transport layer "because weveupdated the library". Tan automated set of tests would be the most likely way to make 3- a possibility. It is unlikely thatwith daily builds, as many companies run their build process, that anything short of anautomated regression test suite would be able to be run daily with any efficacy. if the buildswere weekly, then a manual regression test would be likely.
Answer3:As per the difinition of regression testing and actual workaround if you have to have answer thisquestion then option 3 & 4 is the best choice among all.The reason behind it is :3---Regression testing can be run on every build It is a normal phenomenon if there is buildcoming on weekly basis or it is a RC build.Since,there is nothing mention about daily build ,onlything mention is every build so it can be correct.4---Regression testing should be targeted areas of high risk and known code change This isalso true in most of the situation,it is not universally true but in certain condition where there iscode change and the related modules are only tested in regression automation rather thanwhole code.5 is not true coz in regression we detect the defect not prevent normally.How do you execute tests?Execution of tests is completed by following the test documents in a methodical manner. Aseach test procedure is performed, an entry is recorded in a test execution log to note theexecution of the procedure and whether or not the test procedure uncovered any defects.Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are helddaily, if required, to address and discuss testing issues, status and activities.* The output from the execution of test procedures is known as test results. Test results areevaluated by test engineers to determine whether the expected results have been obtained. Alldiscrepancies/anomalies are logged and discussed with the software team lead, hardware testlead, programmers, software engineers and documented for further investigation and resolution.Every company has a different process for logging and reporting bugs/defects uncovered duringtesting.* A pass/fail criteria is used to determine the severity of a problem, and results are recorded in atest summary report. The severity of a problem, found during system testing, is defined inaccordance to the customers risk assessment and recorded in their selected tracking tool.* Proposed fixes are delivered to the testing environment, based on the severity of the problem.Fixes are regression tested and flawless fixes are migrated to a new baseline. Followingcompletion of the test, members of the test team prepare a summary report. The summaryreport is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead.* After a particular level of testing has been certified, it is the responsibility of the ConfigurationManager to coordinate the migration of the release software components to the next test level,as documented in the Configuration Management Plan. The software is only migrated to theproduction environment after the Project Managers formal acceptance.* The test team reviews test document problems identified during testing, and updatedocuments where appropriate.Inputs for this process:* Approved test documents, e.g. Test Plan, Test Cases, Test Procedures.* Test tools, including automated test tools, if applicable.
* Developed scripts.* Changes to the design, i.e. Change Request Documents.* Test data.* Availability of the test team and project team.* General and Detailed Design Documents, i.e. Requirements Document, Software DesignDocument.* A software that has been migrated to the test environment, i.e. unit tested code, via theConfiguration/Build Manager.* Test Readiness Document.* Document Updates.Outputs for this process:* Log and summary of the test results. Usually this is part of the Test Report. This needs to beapproved and signed-off with revised testing deliverables.* Changes to the code, also known as test fixes.* Test document problems uncovered as a result of testing. Examples are Requirementsdocument and Design Document problems.* Reports on software design issues, given to software developers for correction. Examples arebug reports on code issues.* Formal record of test incidents, usually part of problem tracking.* Base-lined package, also known as tested source and object code, ready for migration to thenext level.What is a requirements test matrix?The requirements test matrix is a project management tool for tracking and managing testingefforts, based on requirements, throughout the projects life cycle.The requirements test matrix is a table, where requirement descriptions are put in the rows ofthe table, and the descriptions of testing efforts are put in the column headers of the sametable.The requirements test matrix is similar to the requirements traceability matrix, which is arepresentation of user requirements aligned against system functionality. The requirementstraceability matrix ensures that all user requirements are addressed by the system integrationteam and implemented in the system integration effort.The requirements test matrix is a representation of user requirements aligned against systemtesting. Similarly to the requirements traceability matrix, the requirements test matrix ensuresthat all user requirements are addressed by the system test team and implemented in thesystem testing effort.
Can you give me a requirements test matrix template?For a requirements test matrix template, you want to visualize a simple, basic table that youcreate for cross-referencing purposes.Step 1: Find out how many requirements you have.Step 2: Find out how many test cases you have.Step 3: Based on these numbers, create a basic table. If you have a list of 90 requirements and360 test cases, you want to create a table of 91 rows and 361 columns.Step 4: Focus on the the first column of your table. One by one, copy all your 90 requirementnumbers, and paste them into rows 2 through 91 of the table.Step 5: Now switch your attention to the the first row of the table. One by one, copy all your 360test case numbers, and paste them into columns 2 through 361 of the table.Step 6: Examine each of your 360 test cases, and, one by one, determine which of the 90requirements they satisfy. If, for the sake of this example, test case number 64 satisfiesrequirement number 12, then put a large "X" into cell 13-65 of your table... and then you have it;you have just created a requirements test matrix template that you can use for cross-referencingpurposes.What metrics are used for bug tracking?Metrics that can be used for bug tracking include the followings: the total number of bugs, totalnumber of bugs that have been fixed, number of new bugs per week, and the number of fixesper week. Metrics for bug tracking can be used to determine when to stop testing, for example,when bug rate falls below a certain level. You CAN learn to use defect tracking software.In QA team, everyone talks about process. What exactly they are taking about? Are thereany different type of process?Answer1:When you talk about "process" you are generally talking about the actions used to accomplish atask.Heres an example: How do you solve a jigsaw puzzle?You start with a box full of oddly shaped pieces. In your mind you come up with a strategy formatching two pieces together (or no strategy at all and simply grab random pieces until you finda match), and continue on until the puzzle is completed.If you were to describe the *way* that you go about solving the puzzle you would be describingthe process.Some follow-up questions you might think about include things like:- How much time did it take you to solve the puzzle?- Do you know of any skills, tricks or practices that might help you solve the puzzle quicker?
- What if you try to solve the puzzle with someone else? Does that help you go faster, orslower? (why or why not?) Can you have *too* many people on this one task?- To answer your second question, Ill ask *you* the question: Are there different ways thatpeople can solve a jigsaw puzzle?There are many interesting process-related questions, ideas and theories in Quality Assurance.Generally the identification of workplace processes lead to the questions of improvement inefficiency and productivity. The motivation behind that is to try and make the processes asefficient as possible so as to incur the least amount of time and expense, while providing ageneral sense of repeatability, visibility and predictability in the way tasks are performed andcompleted.The idea behind this is generally good, but the execution is often flawed. That is what makesQA so interesting. You see, when you work with people and processes, it is very different thanworking with the processes performed by machines. Some people in QA forget that distinctionand often become disillusioned with the whole thing.If you always remember to approach processes in the workplace with a people-centric view, youshould do fine.Answer2:There is:* Waterfall* Spiral* Rapid prototype* Clean room* Agile (XP, Scrum, ...)What metrics are used for test report generation?Metrics that can be used for test report generation include...McCabe metrics: cyclomatic complexity metric (v(G)), actual complexity metric (AC), moduledesign complexity metric (iv(G)), essential complexity metric (ev(G)), pathological complexitymetric (pv(G)), design complexity metric (S0), integration complexity metric (S1), objectintegration complexity metric (OS1), global data complexity metric (gdv(G)), data complexitymetric (DV), tested data complexity metric (TDV), data reference metric (DR), tested datareference metric (TDR), maintenance severity metric (maint_severity), data reference severitymetric (DR_severity), data complexity severity metric (DV_severity), global data severity metric(gdv_severity).McCabe object-oriented software metrics: encapsulation percent public data (PCTPUB), accessto public data (PUBDATA), polymorphism percent of unoverloaded calls (PCTCALL), number ofroots (ROOTCNT), fan-in (FANIN), quality maximum v(G) (MAXV), maximum ev(G) (MAXEV),and hierarchy quality (QUAL).Other object-oriented software metrics: depth (DEPTH), lack of cohesion of methods (LOCM),number of children (NOC), response for a class (RFC), weighted methods per class (WMC),
Halstead software metrics program length, program volume, program level and programdifficulty, intelligent content, programming effort, error estimate, and programming time.Line count software metrics: lines of code, lines of comment, lines of mixed code andcomments, and lines left blank.What is quality plan?Answer1:the test plan is the document created before starting the testing process, it includes that types oftesting that will be performed, high level scope of the project, the envirnmental requirements ofthe testing process, what automated testing tools will be used (If available), the schedule ofeach test, when it will start and end.Answer2:you should not only understand what a Quality Plan is, but you should understand why youremaking it. I dont beleieve that "because I was told to do so" is a good enough reason. If theperson who told you to create it cant tell you 1) what it is, and 2) how to create it, I dont thinkthat they actually know why its needed. That breaks the primary rule of all plans used in testing:We write quality plans for two very different purposes. Sometimes the quality plan is a product;sometimes its a tool. Its too easy, but also too expensive, to confuse these goals.If its not being used as a tool, dont waste your time (and your companys money) doing this.What are the five dimensions of the Risks?Schedule: Unrealistic schedules, exclusion of certain activities when chalking out a scheduleetc. could be deterrents to project delivery on time. Unstable communication link can beconsidered 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 theproject are not available; Attrition of resources - Appropriate training schedules must be plannedfor 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 eitherhardware 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 andfrequent 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. Organizationsusually have coding standards all developers should adhere to, but every programmer andsoftware engineer has different ideas about what is best and what are too many or too fewrules. We need to keep in mind that excessive use of rules can stifle both productivity andcreativity. Peer reviews and code analysis tools can be used to check for problems and enforcestandards.Why back-end testing is required, if we are going to check the front-end ....?Why we need to do unit testing, if all the features are being tested in System testing.What extra things are tested in unit testing, which can not be tested in System testing.Answer1:Assume that youre thinking client-server or web. If you test the application on the front end onlyyou can see if the data was stored and retrievd correctly. You cant see if the servers are in anerror state or not. many server processes are monitored by another process. If they crash, theyare restarted. You cant see that without looking at it.The data may not be stored correctly either but the front end may have cached data lyingaround and it will use that instead. The least you should be doing is verifying the data as storedin the database.It is easier to test data being transferred on the boundaries and see the results of thosetransactions 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 urproject is .Ticket booking system,Front end u will provided with an Interface , where u can bookthe 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 storingdetails entered by the user.After submitting the details ,U might have provided with a correct acknowledgement.But in backend , 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 basicchecks whether the application is working fyn with the basic requirements.This will be done bydevelopers before delivering to the QA.In System testing , In addition to the unit checks ,u willbe performing all the checks ( all possible integrated checks which required) .Basically this willbe carried out by testerAnswer3:
Ever heard about divide and conquer tactic ? It is a same method applied in backend andfrontend 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 couldbe achived.Backend testing has another problem which must addressed before front end could use it. Theproblem 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 youalready done and which you havent. What we need is an effective methods to test ourapplication. The simplest method i know is using divide and conquer.Answer4:A wide range of errors are hard to see if you dont see the code. For example, there are manyoptimizations in programs that treat special cases. If you dont see the special case, you donttest the optimization. Also, a substantial portion of most programs is error handling. Mostprogrammers anticipate more errors than most testers.Programmers find and fix the vast majority of their own bugs. This is cheaper, because there isno communication overhead, faster because there is no delay from tester-reporter toprogrammer, and more effective because the programmer is likely to fix what she finds, and sheis likely to know the cause of the problems she sees. Also, the rapid feedback gives theprogrammer information about the weaknesses in her programming that can help her writebetter code.Many tests -- most boundary tests -- are done at the system level primarily because we donttrust that they were done at the unit level. They are wasteful and tedious at the system level. Idrather see them properly done and properly automated in a suite of programmer tests.What is the difference between verification and validation?Verification takes place before validation, and not vice versa.Verification evaluates documents, plans, code, requirements, and specifications. Validation, onthe other hand, evaluates the product itself.The inputs of verification are checklists, issues lists, walkthroughs and inspection meetings,reviews and meetings. The input of validation, on the other hand, is the actual testing of anactual product.The output of verification is a nearly perfect set of documents, plans, specifications, andrequirements document. The output of validation, on the other hand, is a nearly perfect, actualproduct.
What is the difference between efficient and effective?"Efficient" means having a high ratio of output to input; which means working or producing witha minimum of waste. For example, "An efficient engine saves gas." Or, "An efficient testengineer saves time"."Effective", on the other hand, means producing or capable of producing an intended result, orhaving a striking effect. For example, "For rapid long-distance transportation, the jet engine ismore effective than a witchs broomstick". Or, "For developing software test procedures,engineers specializing in software testing are more effective than engineers who aregeneralists".How effective can we implement six sigma principles in a very large software servicesorganization?Answer1:Effective way of implementing sixsigma.there are quite a few things one needs1. management buyin2. dedicated team both drivers as well as adopters3. training4. culture building - if you have a pro process culture, life is easy5. sustained effort over a period towards transforming, people, thoughts and actions Personallytechnical content is never a challenge, but adoption is a challenge.Answer2:"Six sigma" is a combination of process recommendations and mathematical model. The name"six sigma" reflects the notion of reducing variation so much that errors -- events out oftolerance -- are six standard deviations from a desired mean. The mathematics are at the coreof the process implementation.The problem is that software is not hardware. Software defects are designed in, not the result ofmanufacturing variation.The other side of six sigma is the drive for continuous improvement. You dont need the sixsigma math for this and the concept has been around long before the six sigma movement.To improve anything, you need some type of indicator of its current state and a way to tell that itis improved. Plus determination to improve it. Management support helps.Answer3:There are different methodologies adopted in sixsigma. However, it is commonly referencedfrom the variance based approach. If you are trying to look at sixsigma from that, for softwareservices, fundamentally the measurement system should be reliable - industry has not reached
the maturity level of manufacturing industry where it fits to a T. The differences between SWand HW/manufacturing industry is slightly difficult to address.There are some areas you can adopt sixsigma in its full statistical form(eg in-process error rate,productivity improvements etc), some areas are difficult.The narrower the problem area is, the better it gets even in software services to addressadopting the statistical method.There are methodologies that have a bundle of tools,along with statistical techniques, are usedon the full SDLC.A generic observation is ,SS helps if we look for proper fitment of methodology for the purpose.Else doubts creep in.What stage of bug fixing is the most cost effective?Bug prevention techniques (i.e. inspections, peer design reviews, and walk-throughs) are morecost effective than bug detection.What is Defect Life Cycle.?Answer1:Defect life cycle is....different stages after a defect is identified.New (When defect is identified)Accepted (when Development team and QA team accepts its 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 orreported.A general Interview answer can be given as:1. New or Opened2. Assinged3. Fixed4. Tested5. Closed.
What is the difference between a software bug and software defect?"Software bug" is nonspecific; it means an inexplicable defect, error, flaw, mistake, failure, fault,or unwanted behavior of a computer program. Other terms, e.g. "software defect", or "softwarefailure", are more specific.While the word "bug" has been a part of engineering jargon for many-many decades; many-many decades ago even Thomas Edison, the great inventor, wrote about a "bug" - today thereare many who believe the word "bug" is a reference to insects that caused malfunctions in earlyelectromechanical computers.In software testing, the difference between "bug" and "defect" is small, and also depends on theend client. For some clients, bug and defect are synonymous, while others believe bugs aresubsets of defects.Difference number one: In bug reports, the defects are easier to describe.Difference number two: In my bug reports, it is easier to write descriptions as to how to replicatedefects. In other words, defects tend to require only brief explanations.Commonality number one: We, software test engineers, discover both bugs and defects, beforebugs and defects damage the reputation of our company.Commonality number two: We, software QA engineers, use the software much like real userswould, to find both bugs and defects, to find ways to replicate both bugs and defects, to submitbug reports to the developers, and to provide feedback to the developers, i.e. tell them if theyveachieved the desired level of quality.Commonality number three: We, software QA engineers, do not differentiate between bugs anddefects. In our reports, we include both bugs and defects that are the results of software testing.Are developers smarter than tester? Any suggestion about the future prospects andtechnicality involvedin the testing job?Answer1:QA & Testing are thankless jobs. In a software development company developer is a coreperson. As you are a fresh graduate, it would be good for you to work as a developer. Fromdevelopment you can always move to testing or QA or other admin/support tasks. But fromTesting or QA it is little difficult to go back to development, though not impossible(as u are BEcomp)Seeing the job market, it is not possible for each & every fresher to get into development. Butyou can keep searching for it.Some big companys have seperate Verifiction & Validation groups where only testing projectsare executed. Those teams have TLs, PLs who are testing experts. They earn good salarysame as development people.In technical projects the testing team does lot of technical work. You can do certifications toimprove your technical skills & market value.
It all depends on your way of handling things & interpersonal, communication and leadershipskills. If it is difficult for you to get a job in developement or you really like testing, just go ahead.Try to achieve excellence as a testing professional. You will never have a job problem .Also youwill always get onsite opportunities too!! Yuo might have to struggle for initial few years like allother freshers.Answer2:QA and Testing are thankless only in some companies.Testing is part of development. Rather than distinguish between testing anddevelopment,distinguish between testing and programming.Programming is also thankless in some companies.Not suggesting that anyone should or should not go into testing. It depends on your skills andinterests. Some people are better at programming and worse at testing, some better at testingand worse at programming, some are not suited for either role. You should decide what you aregood at and what fascinates you. What type of work would make you WANT to stay at work for60-80 hours a week for a few years because it is so interesting?Suggesting that there are excellent testing jobs out there, but there are bad ones too (in testingand in programming, both).Have not seen any certification in software testing that improves the technical skill of anyone.Apparently, testing certification improves a testers market value in some markets.Most companies mean testing when they say "QA". Or they mean Testing plus Metrics, wherethe metrics tasks are low-skill data collection and basic data analysis rather than thinking up andjustifying measurement systems appropriate to the questions at hand. In terms of skill, salary,intellectual challenge and value to the company, testing+metrics is the same as testing. Somecompanies see QA more strategically, and hire more senior people into their groups. Here is ahint--if you can get a job in a group called QA with less than 5 years of experience, its a testinggroup or something equivalent to it.Answer3:Nothing is considered as great or a mean job. As long as you like and love to do, everything inthat seems to be interesting.I started as a developer and slowly moved to Testing. I find testing to be more challenging andinteresting. I have solid 6 years of testing experience alone and many sernior people are therein my team, who are professional testers.Answer4:testing is low-skill work in many companies.Scripted testing of the kind pushed by ISEB, ISTQB, and the other certifiers is low skill, lowprestige, offers little return value to the company that pays for it, and is often pushed to offsitecontracting firms because it isnt worth doing in-house. In many cases, it is just a process of"going through the motions" -- pretending to do testing (and spending a lot of money in the