What will you do if developer is not able to reproduce defect ?

First ,try to Reproduce the defect at our side .If it reproduce again then write its Steps to Reproduce and Take the Screenshot then send back to developer .If not reproduce then its ok. If again Developers told they r unable to Reproduce then asked them to come at their own seat and show them .If again they r not agree then discuss the scenario wid TL of Testing & Development or float a mail to ur senior like PL or GL wid proper description .Now its Must Work. Re: What is Defect Acceptance ? Defect Acceptance is the Process in which Developers accept the Defect as a Valid Defect. Write Boundary value analysis , Equivalence partitioning & Error guessing cases on 1 liter Water Bottle. It should not include functionality Testing cases.? BVA:0 it means the can is empty invalid value 1 it fills the bottle valid value 2 water overflows invalid EQp:0-500ml = half the bottle or less than it 500-1000ml=fills the bottle or more than half the bottle

Re: we go to shopping. after completion of shopping we have to pay money. we swipe our credit/debit card in swiping machine. assume your card is icici card. and that machine is of hsbc .here with what name the bank of your card is called ? and that machine's bank name? Answer #1

issuer and acquirer

Re: what is non-functional testing? give 2 example..

Basically non-functional testing refers to the testing the quality attributes of the system like Performance, Reliability load testing etc. Or non functional testing: testing the speed of execution of an application under various load conditions is called non functional testing. examples: 1)security 2)load 3)volume 4)stress e.t.c....

Re: what is suspension criteria and exit criteria in test plan/????

temporary stopping of testing due to problems in either Hardware/Software/Human Recourses .... totally coming out of the application is called exit criteria OR Suspension/Resumption Criteria in a Software Test Plan : If any defects are found which seriously impact the test progress the test lead may choose to suspend testing. The criteria which are considered for suspension or resumption are :[a] hardware / software not available at the time indicated in the project schedule [b] the build contains many serious defects which seriously prevent or limit testing progress [c] Assigned test resources are not available when needed by the test team Resumption Criteria : If testing is suspended, resumption will only occur when

the problem(s) that caused the suspension have been resolved. When a critical defect is the cause of the suspension, the FIX must be verified by the testing team before testing is resumed Re: what are the -ve test cases for Railway Ticketing System? 1.check the invalid username and password is accept or not 2.check the lessthan today date accepted or not 3.check and Entered from and to place not appearing list is accept or not 4.Not select the Ticket type then click the find trains Msg display or not. 5.Not select the train Radio button then click the Show details system accept or not Assume you are handling multiple projects and the scheduled were clashing how would you mange about this I will reschedule the timing and create the schedule which will give same time to every project so that it will never crash OR i'll prioritize wrt delivery dad line & complexity & distribute wrt that to all projects

what is CMM Explain the difference between adhoc and smoke testing explain Bug life cycle Explain STLC What is severity and priority and example of high severity and low priority

1)CMM means "Capability Maturity Model". 2)adhoc testing : when we have less time and minimum knowledge then we go for adhoc testing.

smoke testing : testing the application on final build release to make sure that the application is ready for usage. 3)a step by step procedure for a rising a bug during testing process id called bug life cycle. different status in bug life cycle are: new, open, close, pending, reject, reopen. 4)STLC means software testing life cycle. it is a part of SDLC(software development life cycle) STLC involve 1)test initiation 2)test planning 3)test case designing 4)test execution 5)bug tracking 6)bug reporting 7)test close 5)severity : severity means seriousness of bug. it was given by PM r TL severity status : critical, major, seriousness priority : priority means which bug should rectify first. it was given by test engineer priority status : high ,medium ,low define defect lifecycle step by step Bug Life Cycle: Stage#1: New: Test Engg finds a bug, drafts it and post in Bug Tracking system (BugZilla, PVCS, JEERA..ect) Initially the bug is assigned to POC (testing) or Team Lead (development) or the test enggg directly assigns it to the concerned developer (if he knows)

Stage#2: I . Assigned: The Team lead or POC or the tester himself (if he is aware of teh developer working on that bug) assigns the bug to the Concerned developer OR The POC or the development lead thinks that the posted bug is NOT A BUG or NO PLAN TO FIX IN THIS RELEASE or ENHANCEMENT (future request), he changes the status and assigns the Bug back to the Test Engineer. The Test ENgg, then closes the bug as per the lead/poc comments. Stage#3: The concerned Developer to whom the bug is assigned, will look in to the issue I .He may not be able to reproduce the bug. NOT ABLE TO REPODUCE. He will assign it to the concerned test engg, the test engineer will verify and if repro he will add his comments (more detailed steps and assign) it to the developer. If not reproduces, he will add comments and close it. II . Developer will fix and cnahe the status to RESOLVED/FIXED and assigns it to Test Engineer Stage#4:The test engg will reverify the bug in the fixed build and if it si fixed, he will add comments admn close it if not fixed, he will add comments and assigns back to the developer. Again Stage#3 will come into picture and then Stage#4 until the bug is verified and closed. Bug States: New Assigned

No plan to fix/Not a bug Resolved/Fixed Not Fixed/Re-open Fixed/Closed

please give me Live example for 1. high severity & low priority 2. High severity & low Priority 3. low severity & high Priority 4. low sevrity & low Priority

Defect severity determines the defect criticality whereas defect priority determines the defect immediacy or urgency of repair 1. High Severity & Low Priority: Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request. 2. Low Severity & High Priority: Suppose there is a spelling mistake or content issue the homepage of BT.com website which has daily lakhs hits all over UK. In this case, though this fault is affecting the website or other functionalities but considering the status and popularity of the website the competitive market it is a high priority fault. 3. High Severity & High Priority: Suppose there is an application which gives some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will hamper the functionality of the application immediately within a week. It should be fixed urgently. on of not in

4. Low Severity & Low Priority: Suppose there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Which testing is used only in web based application but not for client-server applications?

There is not much difference between client server and web based applications testing. The main difference is URL testing and browser compatibility testing is involved in web based applications while it not applicable for Client server applications. Which method of testing we use to test LOGIN page? Simply, User authentication testing. This is a part of security testing. Validation testing, User Interface Testing, Functional testing. Why testing is required? Testing is required to check that the application satisfies the requirements. Testing is required to Build a Quality Product. Testing is required to Deliver a quality product. Testing will give confidence for the software development company that the software will work satisfactorily in client environment. Testing will improve the software quality. Testing will also reduces the maintenance cost also. Even the client of the software will get confidence on the software.

traceability matrix used for which purpose? traceability matrix is used to review the test case i.e to check that our test case covers maximum functionality and not to miss any thing of the application. TM is mapping the req to the test cases, that means in order to tell the client that we have covered all the requirements according to the SRS document. Using Traceability matrix we can able to know the test coverage completely... It gives the mapping in between Test cases along with Test result .. Its very important for a quick check of test coverage.. testing is a process or methodology ,diff between methodology and process? process:-the document specify a step by step procedure to execute written test cases Methodology: selection of required testing techniques to be applied on the built. Process: The high level procedural representation of the over all activities in the Testing phase. Methodology: The techniques or methods to be followed in order to execute the (Testing) activities. Client want to execute 1500 test cases and delivery within three days? But i have 5 resources? How its possible? By giving the severity to the test cases we can derive the test cases fastly and also using the RTM matrix we can able to execute the more number of test cases with respect to the severity ot the test cases.

OR Simply prioritize test cases, assign each test case a number derived from priority of test cases & Severity if it fails. Select all high priority test cases and medium priority test cases execute them. This is a risk based approach and if possible inform the stake holders about this situation. Or Increase Resources (Which is not going to happen in any case) or work for more than 16 hours for 3 days. explain fields of a bug 1) Bug id 2) Version No Of AUT 3) Module Name 4) Status 5) Detail Description 6) Steps To Reproduce 7) Severity 8) Priority 9) Reported By 10) Assigned To 11) Reported Date 12) Fixed Date 13) Comments If Any Suppose in your Project have 2 test engineers. Module A is tested by You and Module B is tested by another Test Engineer. module A and B has inter related functions. Then how you check the functionality of the module?? in this case if we want to test the inter related functionality, the module A and B is to be integrated. once the integration of module A and B is done, we can check the inter related functionality of both the modules.

can anybody tell me that what is a build note and what it contains? And build note is released to testing team with every new build or it release only when bugs are fixed by the developer?

As per my understanding build note is nothing but a release notes given by the development team, which contains the modules to be tested/not to be tested in the current release and availability of the modules for testing in the forthcoming releases...
OR

Build note is the note released to the test team along with the build which contains the informations like current version of product, key limitations of the build, known issues, features supported/not supported, installation procedure ,list of fixed bugs, compatibility information ,build in which non-supported features are going to be implemented etc.

As I mentioned in my earlier post smoke testing is done immediately after build is received from development team to check the stability of the build. Stability means to check whether all the forms, buttons, links, etc are working. once it is done we go for sanity testing i.e. to check complete functionalities of the module as per the requirement mentioned in the SRS and we execute our test cases. what are the bugs in job portals A COMMON BUG IN JOB PORTAL IS THE FUNCTIONALITY OF UPLOADING THE RESUME. USUALLY FAILS TO UPLOAD AS WORD DOCUMENT.

Diff. between system test cases & UAT test cases. In this we write test cases for all the main modules of the application. UAT Test cases: In this we wtite test cases which are understandable to any third party . How do u find duplicate test cases? in trm(traceability requirement matrix),we develop the mapping between the functional req &test cases. you can find out that whether any test case is missed or any duplicate test case is generated with the help of TRM. What is the bigbang approach in integration testing? it is a type of integration testing in which s/w elements, h/w elements, or both are combined all at once, rather than in stages Or In big bang Integration testing, individual modules of the programs are not integrated until every thing is ready. This approach is seen mostly in inexperienced programmers who rely on 'Run it and see' approach. how to write test case for triangle and sqaure? For Triangle: 1. Check if there are 3 sides 2. Check for the angles and their sum [should be 180 degrees] 3. Check if the triangle is equilateral or isosceles or Scalene 4. Check if the sides are coinciding or not 5. Check if the axioms SAS, SSS are followed. 6. Check if the user is able to draw the 3 circles

[Interior, exterior, circumcirlce] For Square: 1. 2. 3. 4. OR Check Check Check Check if if if if there are 4 sides the four angles should be in 90 degrees. the four sides are in equal length or not. the sides are coinciding or not.

For Triangle: 1. Check if there are 3 sides 2. Check for the angles and their sum [should be 180 degrees] 3. Check if the triangle is equilateral or isosceles or Scalene 4. Check if the sides are coinciding or not 5. Check if the axioms SAS, SSS are followed. 6. Check if the user is able to draw the 3 circles [Interior, exterior, circumcirlce] For Square: 1. 2. 3. 4. Check Check Check Check if if if if there are 4 sides the four angles should be in 90 degrees. the four sides are in equal length or not. the sides are coinciding or not.

Suppose there are three modules A-B-C, the output of A is responsible for B and output of B is responsible for C and if A & C is not ready & B module is ready then how can u check Module B Well in this case comes the concept of STUBS and Driver,here we can use a driver for B that will give the input to B and a stub for Module C which will get the input from Module B.Driver is a piece of code that passes test cases to another piece of code. Stub A piece of code that simulates the activity of missing components

OR

We can test the module B using the concepts of STUBS and DRIVERS.STUBS and DRIVERS are shell scripts which has no logic but simply accepts and passes input parameters to modules. What is diff. between System Testing and Integration Testing ? Both are the phase of the testing. In Integration testing we integrate all the module together and test as per the client specification. In System testing we will check system performance in case of more stress & load, hardware & software compatibility, whether the site is secure or not i.e security testing etc. OR In system testing we test both functional testing and non functional testing too . Non functional testing contains security testing , load testing , relability tesing , stress testing ,volume testing , GUI testing , compactibilty testing ,interoperability testing , we perfor benchmarking too , configuration testing so on In integration testing we test the functionality testing ,checking the of all the modules which are integrated . we check for the data flow betn the modules is done as per the requirement or not.

Performance Testing - It is mainly based on the speed of processing 1. load testing - Testing the Maximum load of the application while accession at the same time with out compromising with the response time

2. Stress testing - testing the behaviour of the system or application while applying heavy stress that is man power 3. Volume testing - testing the application for large volume for data is called volume testing. This is mainly conducted to check the memory leaks and capacity of the server handling huge volume of data. Wht is the Test Driver used in Integration Testing. Anybody can expalin in Detail. Thanks in advance. test driver is a dummy program which is used to replace the lower level module in bottom-up testing it is a calling component
OR

Test Driver: in bottom up approach, small modules r developed,to test them a dummy core module called driver is developed. so it is a dummy program which is used to replace the core module in bottom-up testing. what is manual testing process For Manual: Understanding Requirements Preparing Test Scenarios Preparation of test data. Designing Test Cases. Test case Review Execution of Test Cases. Preparing Defect Report. Functional Testing of Application. Defect Tracking & Reporting. these all are done by 100% involvement of tester is nothing but manual.
OR

Manual normal testing process so many types of testing process are there Each company follow the different methods v-model, agile method RUP model Every model start with the getting requirements conducting the reviews to identify the requirements preparing the TRS documents and scenario documents after we are preparing the test cases documents after getting the build we are execution test cases if getting any build execution test cases if getting the issues we are preparing the defect reporting finally preparing the summary reports this manual process
OR

Manual process is varies company to company. Testing start as soon as we get the requirements document. Most of the company follows th V model in this both the activity is going on side by side means verification and also validation .With the help of requirement doc. try to break it in different scenarios and try to write down the test cases once will get the build execute the test cases and reporting the bug. what is the difference between Test-bed, Test-lab & Test-environment ? explain it briefly ? Test bed: Sets of Test data which needs to be required set-up on the Test environment. Mean setting of data on test environment. Some time Test environment also called the Test Bed. Test Lab: Setting up the lab with required hardware and software for testing purpose. E.g. Network lab in which also devices like Modem, Splitter, Port etc are set-up Test environment: in which the testing will be happened. There should be different environment like development environment or testing environment. Developer will be uploading the same code into testing environment.

How you manage your test case (already written )when requirements changes? When a change in Requirement happened first we need to identify the affected test cases then we need to modify or edit or block the existing test case. Very first time after preparation of test cases we used to update the Traceability matrix. Traceability Matrix maps Requirements to Test case. In this matrix For every Requirement ID mapped with the prepared test case ID. When a particular requirement changed then we will look the traceability matrix to identify the corresponding test case ID's. According to the change in requirement we need to change the corresponding test case. The traceability matrix again should update for future reference. which test comes first installation testing or compatibility testing compatibility test bc its the part of functional testing which is checked with lost versions and installation is after the testing completes before going to check with client it is done with the environment settings as per customers environment A bank application with From a/c, To a/c, amount and a submit button - What are the conditions that you write for it. gui test cases check whether the acc in accepting how many digits according to test plan same with other account whether it is accepting alpha numeric characters then performance test cases try to enter submit button with out entering valid amount try to enter submit button with valid amount submit button try to enter submit button with entering any amount in acct transfers

An employee table, with the columns id, name, sal and dob.Query to select emp names of all highest salaries(there are 4-5 people having the same salary which happens to be the highest). select name from emp where sal=(select max(sal) from emp) Differences between waterfall and V model Waterfall Model: It includes all phases of SDLC but the drawback is once requirement made freezed it cannot be changed. V-Model: In this model all phases will be done correspondently development and testing etc.... 1.In Waterfall Model the tester role will take place only in the test phase but in V-Model role will take place in the requirement phase itself. 2.Waterfall model is a fixed process u can't make any changes in the requirement or in any phase. but in VModel u can make any changes in the requirements. 3.V-model is the simultaneous process but it is not in case of water fall model. 4.waterfall model used only the requirements are fixed but V-model can be used for the any type of requirement(Uncertain requirement). how we can define bug is an valid bug Deviation from expectation is known as bug. According to importance to fix the bug we will valid it. One Project is developed on VB+ Access it is working properly they are planning to change with backend Oracle . What type of test cases we can write? Here front end is same that is VB They just migrating from DBMS(Access) to RDBMS(oracle). we have to test the front end application interface

with back end database .The testing approach purely on backend database like tables, constraints, views ...etc. DBMS cannot provide relation between the tables as RDBMS do using foreign key constraint. RDBMS is more robust and powerful than DBMS. OR We can do Configuration testing for this. No need to test the front end because the front end is same. We have to test the back end which is RDBMS. Give me 2 examples for - High Priority with Low Severity? And - High Severity with Low Priority?? High Priority - Low severity: The name of company in an web app is not spelled correctly. Though it is not going to affect the functionality of the product but it will have a bad effect on end users. Low Priority - High severity: An application is not generating required report, but the report is generated once a year.

When the error is found before the software release that is called bug. When error is found after software release that is called defect. when the actual result is different from expected result called error. Test approach: Which testing techniques we are going to use for application. Test strategy: be performed. we decide on what features testing will

WHAT IS THE DIFFERENCE BETWEEN BUG , ERROR AND DEFECT? EXPLAIN WITH EXAMPLE. 2... WHAT IS DIFF BETWEEN TEST APPROACH , TEST STRATEGY, TEST PLAN AND TEST METHODOLOGY DOCUMENTS? 3...HOW TO TEST A WEBSITE WITH MANUAL TESTING? 4. WHAT METHODOLOGIES HAVE YOU USED TO DEVELOP TEST CASES?

Test plane: is detailed document that contains objective, scope of application, resources, deliverables, on what Feature testing is going to be performed, budget, Risk, time, who will perform testing etc. Test Methodology documents: is a document containing all Information about test case. who will infrom the testers when the build is ready to test from developement side? Usually the development Lead will inform the test lead when the build is ready. The Dev lead sends a mail to the Test lead saying that the build is ready to be deployed and places the build in the proj folder in VSS, from where the test lead will deploy. OR Yes.. Most of the time Dev. Lead tells Test Lead that build is ready for testing . If there is SCMs ( S/w configuration Managers ) in the Organization, they will drop a mail to the entire testing team , that a particular build is ready for testing and is available at some location , than path of which is also there in the mail.

Spiral Model

In last article we discussed about "Waterfall Model", which is one of the oldest and most simple model designed and followed during software development process. But "Waterfall Model" has its own disadvantages such as there is no fair division of phases in the life cycle, not all the errors/problems related to a phase are resolved during the same phase, instead all those problems related to one phase are carried out in the next phase and are needed to be resolved in the next phase, this takes much of time of the next phase to solve them. The risk factor is the most important part, which affects the success rate of the software developed by following "The Waterfall Model". In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new Software Development Model, which could help in ensuring the success of software project. One such model was developed which incorporated the common methodologies followed in "The Waterfall Model", but it also eliminated almost every possible/known risk factors from it. This model is referred as "The Spiral Model" or "Boehms Model". There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis

and Engineering. These four phases are iteratively followed one after other in order to eliminate all the problems, which were faced in "The Waterfall Model". Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time, planning and developing strategies to be followed while iterating through the phases. The phases in "Spiral Model" are: Plan: In this phase, the objectives, alternatives and constraints of the project are determined and are documented. The objectives and other specifications are fixed in order to decide which strategies/approaches to follow during the project life cycle. Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements. Engineering: In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same. Customer Evaluation: In this phase, developed product is passed on to the customer in order to receive customers comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase is very much similar to TESTING phase. The process progresses in spiral sense to indicate iterative path followed, progressively more complete software is built as we go on iterating through all four phases. The first iteration in this model is considered to be most important, as in the first iteration almost all possible risk factors, constraints, requirements are identified and in the next iterations all known strategies are used to bring up a complete software system. The radical dimensions indicate evolution of the product towards a complete system. However, as every system has its own pros and cons, "The Spiral Model" does have its pros and cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model", to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation etc. are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task.

VMODEL

Software development activity goes through a number of phases. The different models of software development have more or less the same phases, but it is the sequencing of these phases, which makes the different software development models stand apart from one another. While there are some models, where one can go back to the previous phase, there are some, where it is not possible. Similarly in some models, testing phases starts at the end of the development phase, while in some it is a simultaneous process. The two most commonly used software development models are the waterfall and the V model. They are among the oldest models in software development. In the waterfall model vs V model debate, no doubt there are going to be people, who will prefer one over the other. V Model The V model is often said to be an extension of the waterfall model. Unlike the waterfall model, the activities in this model are vent into a 'V' shape, with coding at the lower tip of the 'V'. Every phase in the software development cycle has a corresponding phase in the testing cycle. Therefore, this model is often also termed as the verification and validation

model. Where verification side is the development side and validation consists of the testing activities. The activities which fall under the verification side are as follows: Requirement Analysis: Information about the proposed system is gathered from the end user, using which the software requirement specification document is prepared, that makes for the base of the software to be prepared. System Design: It is also known as functional design, the aim of which is to prepare functional design of the software. In case of any functionality, that is not feasible the same is intimated to the user. Architecture Design: Once the system design is in place, the architecture required for the system is made, which is often also referred to as high level design. It is here the interface relationship, database tables, their dependencies, etc. are all worked upon. Coding: After the system architecture is in place starts the coding stage. For coding, the entire system is broken up into small modules, which in turn are later integrated to form the entire system. After the verification side comes the validation side of the V model. Let's see the phases, which are a part of the validation side. Unit Testing: This is the first phase of the validation side, where small modules developed are tested, to check if they are fit for purpose. Integration Testing: Once the modules are ready, they are integrated upon which testing is carried out. It helps in determining faults in the interface and the interaction between two different modules. System Testing: It is in this phase, that the actual is tested against the system specification. In this phase the testing is carried out from the perspective of the end user. Also there are chances that some of the functionality are visible only after the entire system has been integrated completely. User Acceptance Testing: The aim of this testing is to check, if the system is in line with the software requirement specification. It helps in determining whether the developed software is according to the acceptance criteria and whether the system is to be accepted or not. Also this phase of testing is carried out in simulated real time environment. Waterfall Model

The oldest model in software development is the waterfall model. It has its origin in the manufacturing and the construction industry. This model was adopted in the field of software development, as there was no model available then. The formal description of this model was made by Winston W. Royce, but he did not name the model as waterfall model. This model follows a sequential flow, where the progress is like that of waterfall from one step to another. The different phases of the waterfall model are as follows: Requirement Gathering and Analysis: In this phase the requirements of the client are gathered, and an analysis of the same conducted, using which requirement specification document is created. This document is used as the base for creating the system. Design: This is an important phase, where the entire software is designed, taking the software requirement specifications into consideration. The system architecture along with the hardware and software specifications required are worked upon. Implementation: After the design stage comes the implementation stage, where the code for the software is written. When the modules are ready, unit tests are carried out on them, which helps in checking, if there are problems with the software. In case of defects, the code is fixed, before proceeding to the next stage. Testing and Debugging: After the software has been developed completely, it is passed onto the testers. They run different tests on the software and the defects, if any are fixed.

Delivery: Once the software has been passed forward, after debugging, starts the implementation of the software at the client side. The client is given a thorough insight into the software, so he is able to use the software.

Maintenance: After the software has been installed, the client uses the software and may ask for changes. The changes and general maintenance of the software are taken care of in this phase.

Waterfall Model Vs. V Model The main difference between waterfall model and V model is that in waterfall model, the testing activities are carried out after the development activities are over. On the other hand in V model, testing activities start with the first stage itself. In other words, waterfall model is a continuous process, while the V model is a simultaneous process. As compared to a software made using waterfall model, the number of defects in the software made using V model are less. This is due to the fact, that there are testing activities, which are carried out simultaneously in V model. Therefore, waterfall model is used, when the requirements of the user are fixed. If the requirements of the user are uncertain and keep changing, then V model is the better alternative. Also making changes in the software in waterfall model is a difficult task, and also proves to be a costly affair. The vice versa is true of the V model. At this stage, I would like to bring it to your notice, that any defects in the software cannot be determined, till the software reaches the testing phase. However, defects are noticed in the initial phases, due to which they can be corrected easily. From the above discussion on waterfall model vs V model, it is clear that each of the models can be used depending on the system they are being developed for. Therefore, one can choose either waterfall model or V model taking the software and the user requirements into consideration. Often, for smaller systems, it is recommended that one use the waterfall model and for the bigger systems use the V model.

10. What kinds of testing should be considered? Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality. White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions. Unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the

programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses. Incremental integration testing - continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers. Integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Functional testing - black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.) System testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of a system. End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. Sanity testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down

systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state. Regression testing - re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing. Acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.Load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails. Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc. Performance testing 'stress' and 'load' any other 'type' of documentation or QA - term often used interchangeably with testing. Ideally 'performance' testing (and testing) is defined in requirements or Test Plans.

Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers. Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes. Recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques. Compatability testing - testing how well software performs in a particular hardware/software/operating system/network/etc. environment. Exploratory testing - often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it. Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it. User acceptance testing - determining if software is satisfactory to an end-user or customer. Comparison testing - comparing software weaknesses and strengths to competing products. Alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers. Beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers. Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources .
http://www.buzzle.com/articles/end-to-end-testing-vs-system-testing.html

How do we decide that test cases covers all the requirements? The coverage of test cases can be decided through Traceability Matrix with which we can explain the process of through requirements of the users. Generally the traceability matrix may include the following: 1. 2. 3. 4. 5. 6. User Requirements Reviews statements (SRS) Scenarios (Test Conditions) Test strategy Test Technique Test Summary Report

what is v.s.s. ?when it is used? VSS stands for visual source safe. b) VSS is nothing but configuration management tool c) VSS is a virtual library of computer files. d) VSS is a common repository e) In VSS store the information like FRS, SRS, TP, Test cases documents f) In VSS documents read only but not modifying g) If we want to modify that first we need to check out (download) the required file to our local system then modify the file and then check in (upload) the modified one. How to write Negative test cases? by providing input values of invalid scenarios.like if the user id text box can accept 6-12 characters then a negative test case can be sumthing like "enter 5 characters in the user id text box and press enter" What are the properties of a good requirement?

As a tester point of view, a good requirement is defined as a requirement which can be tested easily by creating test cases or by writting test scripts OR ood requirement : As per the testers point of view , the requirement should not be complex .its should be clearly understood and it should be one to one or one to many testing approaches required to cover the requirement ,not many to many . It should be clearly ensure that it should not escalate any defect in future for the application. It should be so clear that all flexibility of the requirement can be easily find out and theses things can be take care during the preparation and execution of the test cases of the application . ORClear, Complete Visible Consistent Measurable Traceable Resonable