Q A Testing

1.what is bugtracking tool ? A tool used to track the defect/issues/concerns logged by tester. This is very much required in any testing environment.Some common features of any bug tracking tool allow you to priortize the defects ,keep track of bug status (like open/close/verified) ,date logged etc.. This is also a Software Application that helps the Test team in end-to-end Defect Life Cycle Management. The advantage of this tool is that all the stake holders of the Testing Project can keep track of the latest Status of all the Bugs logged in by the Test team. Also, it will be help in the following: 1. Defect Categorization based on Priority, Severity. 2. Generating a variety of Bug reports such as Daily & Weekly and also Application wise and Module wise Bug lists.

3. Also the tool can be configured for sending automated mail messages to all the concerned people whenever a Bug is logged in the tool and change occurs to the same. 4. Some tools have more features such as generating Graphical reports based on the Bug Data.

2.What is the difference between verification and Validation in software testing Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, and walkthroughs and inspection meetings. Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed Verification is a process in which information is checked using accurate measures. E.g. when you enter a new password you are asked to retype it to verify that the password supplied is correct. Validation however is the automatic process in which rules are applied in order to make information correct,e.g. if the right type of data is entered in a certain cell in a database. 3.what do u mean by Testing plan?in software development life... A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation For a application or product to be success....testing phase or plan is a must. Testing plan explains the scope of testing, Objectives, Test strategies(what are the kind of testing to be conducted to find the bugs), Acceptance Criteria(At what point the testing should be stopped to adhere for the bugs) and test case procedure which explains how the testing should be conducted.

"All the above put together makes a testing plan" TestPlan is an roadmap to acheive your testing activity.ie what are the process that u are going to follow in ur testing. 4.How do I test web-related applications? First u have to test web tier testing 1.browser compatible 2.compatible testing. middle tier testing 1.security testing 2.performence testing database tier 1.data integrity 2.database web testing is done in three tiers 1. first tier of testing check is on look and feel,colors,fonts, evrrything. 2.secnd tier comes database testing,perfrmance testing 3.third tier comes security like network security,transaction security all other tests which are common for all 5.stress testing? Just try some extreme conditions for your system : unplug the net cable, shut down the DB Server, kill a running process of the system,. Stress testing is subjecting the system under heavy load but, denying the required resources for the system to perform (like RAM,Disc..etc). Even if the system fails, it is not cause of worry. The Idea is basically to confirm that the system does not fail in Improper manner. The system should not Corrupt the data / Lose the existing data when it Fails. Stress Testing is nothing but testing the software/product with resources. That is Stress testing is a type of software Testing where we test the software with minimum and Maximum condition. Here we reduce the software Resources. For Ex: One software is recommended condition is 64 MB RAM. For this software we will run it is 32 MB RAM,in this environment software should run.IT shouldn't crash the system,it should have a Graceful exit. 6.what is stub & driver in intgration testing ? Stub is a piece of code emulating a called function, a driver is a piece of code emulating a calling function

Stub: A piece of code that simulates the activity of missing component. Driver: A piece of code that passes test case to another piece of code. 7.What is BVT in Testing field? BVT is nothing but a build verification Test and will be done , after the integration of all modules/components with the corresponding backend has been completed taken from the repository using some perl scripts(usually).Also it can be considered to be given for alpha/beta testing. 8.difference between load and stress testing Load testing is stressing within maximum limits - focus is on Performance Criteria.. Stress testing is stressing beyond maximum limits - focus is to know failure behavior of the system. Load Testing is a process to check where exactly the system/server starts to degrade. Stress testing is negative testing.eg.if a system can response properly for say 100 users.Bulk of users will be accessed to check the systems performance,there by reducing the no. of users if the system degrades. 9.Exact difference bet Bug, Error & Defect? Error : Is an undesirable deviation from requirements Bug : Is an error found BEFORE the application goes into production Defect :Is an error found AFTER the application goes into production Error : Deviation for actual and the expected/theoritical value . Bug : An Error found in the development environment before the product is shipped to the customer . Defect : An Error found in the product itself after it is shipped to the customer . 10.What weaknesses within a computer network can have direct effect on the functionality of the system The weakness may be from server to installation and unavalaiability and inability to retrieve the required data or files to the system 11.What is Testing? What is Test Plan? What is Test case? Testing: Executeing a program with a intent of finding bugs. TestPlan: It is a roadmap for testing the system Testcase:To check the behaviour of particular attidue test plan: A record of the test planning process detailing the degree of tester indedendence, the test environment, the test case design techniques and test measurement techniques to be used, and the rationale for their choice. test case: A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. After

[IEEE,do178b] Test: The process of executing the system satisfies specific requirements and detecting the errors Test Plan: Test Plan is a document which gives object,scope,and focus software testing efforts. Test case: Test case is a document which gives action,event expected results in future that object perfectly working or not. 12.actually ,what is software testing? Software testing is nothing but verification and validation of the Software Product / Application. Verification ============ - to see that the product is built right. - Here we will determine that the Work Products of a given phase of a Software Development Life Cycle, meets the requirements established in the previous phase. - We will also see that the work is complete, correct and consistent enough to support the next phase. Validation ========== - to see that the right product is built. - It is the process of evaluating the Software throughout the Software Development Life Cycle to ensure compliance to requirements. - Here we will see that the Actual Results are in conformance with Expected Results when subjected to anticipated events. - No unexpected behavior is observed when subjected to unanticipated events. - Under the given operational conditions the Systems behaves as per the Users Expectations. 13.What is difference between win runner and rational robot. rational robot deals with functional,regression and performance testing whereas loadrunner is only performance testing and winrunner is for functional and regression testing Winrunner is used for testing GUI applications on windows OS mostly.Rational robot can be used for any application irrespective of OS.In addition Rational Robot is Project management tool.While for Winrunner we need Test director to prepare test plan,manage test scripts and track defects.

14.what are the stages present in bug life cycle STATUS RESOLUTION: The status field indicates the general health of a bug. Only certain status transitions are allowed. The resolution field indicates what happened to this bug. UNCONFIRMED: This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED. NEW: This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED. ASSIGNED: This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED. REOPENED: This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. No resolution yet. All bugs which are in one of these "open" states have the resolution set to blank. All other bugs will be marked with one of the following resolutions. RESOLVED: A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED. VERIFIED: QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ships, at which point they become CLOSED. CLOSED: The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. Bugs can broadly under go following stages: 1)Open stage:A defect originated by a tester 2)Assign :Raised defect assigned to Developer 3)Resolved stage: Developer provides the code fix for the bug and make it resolved 4) Closed stage : Tester re-tests the bug and closes it , if its working.Otherwise he will re-open the defect and it will go back to stage 1.

There is no standard that bug life cycle should have the above stages. You can define your own sub stages according to your convenience 15.it possible to record the commands that we type in DOS-prompt?

Test can be executed in dos as analog mode.but re execution of a particular command is not possible. You can run the dos_system("any dos command"); (qa.com,softwaretest.com,qaform.com) 16. What is test case management? How can effective test cases be written? Test Case Management is nothing but maintaining the test cases with a process in a storage medium which can be anything from CVS/RCS database txt file etc. Any product company would have a defined process and management to maintain their huge numbers of testcases. The TC Management also have procedural guidelines to the users while recording the testcases. 17.What is the difference between a Software application and Software product? It should be Software Project and Software Product. Software Project is done for a specific clients of your company. For this some of the testing may be done at client's side. For example, Acceptance Testing.. Software Product is not done for a single client and it is released as a product of the company. Any doubts, you are welcome at: [email protected] Application is more specific for a particular business requirement where as product is more generic. In other words, application is used for solving particular problem or specific need, where as product looks at broader sense. Requirement Phase: When you build an application you look at particular user/client and understand their requirements. But for building a product the requirements are gathered not by looking at a single user but one does market survey and come up with most likely features that cross section of users will look at. These requirements are not only functional requirements but also platform/hardware requirements. Typically product offers set of features then it's up to the organizations to use some or all of them. In some cases Product don't have all the required features, in such case it is customized to suite the need, in such case this implementation/customized version of product can be considered as application. Testing:

Typically application is supported on single platform, the one that target organization has. For products it's variety of OS, hardware etc, you must have see typically product matrix. Hence it is necessary to test the product on all the combinations. Releases: Though it is not completely true but in most cases, once application is developed there are few enhancements. Also bug fixes are typically completed before User Acceptance testing. Since for product there is not a single customer, there is no UAT as such, once QA certifies product is released to market. Very fact that product is generic and is suppose to work in different scenarios it's very difficult to exhaust all the scenarios during QA testing, and as you know the defects are found in released product. The bug fixes for these are handled by patch releases (Microsoft is very good example for these patch releases, you must have seen SP1, SP2 etc even for OS). This means configuration management is complex for Products. Otherwise rest of the software lifecycle stages like specs, development, impact analysis are identical. 18.how to evaluate system testing tools?? System testing is a serious of different test who's primary purpose to execute the system fully exercise computer based system.each test have different purpose it will work,and properly integrating and allocating fuctions 19.WHAT IS SOFTWARE TESTING? Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should happen'). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection' 20. Basis path testing: To execute every statement in a program at least one time.By using basis path test will find out the execute path of the statement Data Flow testing: select statement in a program and uses the variable of the definition 21.What are the parameters for performance testing Response Time during data retrieval ,calculations, TurnAround time, Bandwidth, Web Page loadtime during Multiple user logins. 22.Regression test Regression test is nothing about Retesting the test which is already executed to compare the actual result with expected result after fixing the bug/ 23.can you explain the testing life cycles

Testing LifeCycle 1. Preparation of Testing Project Plan which includes Test Strategy. 2. Preparation of TestScripts which contains Test Scenarios. 3. Preparation of Testing Bed. ie: Setting up the Test Environment 4. Executiong the TestScripts ( Automated as well as Manual Tests). Note: Confidence Testing has to be done to check whether all the top level functionalities are working fine. 5. Defect Tracking with any bug tracking tools. 6. Preparation of Test Completion Report and Test Incident Report. 7. Preparation of Test Metrics for Continous Process Improvement. Software Test Life Cycle comprise of following activities: Test Planning: 1- Plan Test (Prepare a comprehensive Test Plan to define the proposed scope, techniques, strategies and testing sequence and risk & assumptions) 2- Design Test (Documenting the Test Specifications; identifying Logical Test Scenarios; writing Physical TestCases/Scripts (fully dressed with data) and developing Trace-ability Matrix) 3- Test Scheduling: Effort estimation in terms of Time and Resources. 4- Preparation of the Test Environment. 5- Execution of the Test Cases and Scripts. 6- Bug Reporting. 7- Test Execution and Bug Status Reporting. 8- Documenting experience and conclusions for future reference and process improvements. 24.TEST CASE Test Case ========= Test cases should be designed and developed based on the User requirements and System architecture and Functionality. Also this varies based on what testing and at what stage the testing is carried out. If it is Unit Testing then the Test Cases will be developed to test the smallest part of the overall user's requirements or the small component of the overall system architecture. If it is an Integration testing then the Test case will be developed to verify a function of the User requirements or an interface between two modules of the System. If it is a System Testing then the Test Case will be developed to validate the System as a whole End-to-end, while combining it with the required HW, Database, Networking and any other connections such as Printers, Fax or any other external supporting SW application. Here, while an input is given to the System, the System's behavior to handle the input data and its final expected out put will be verified. And finally if it is User Acceptance Testing, then the Test Cases will be developed from the User's requirements perspective.

Sanity Testing ============= It is to test the basic required functionality of the developed system. Verification and Validation =========================== Verification is basically to see that the "Right product is built". Validation is to see that the "Product is built right". Test case: test case is a document which describes action,event,expected result,in future that object is perfectly working or not. Test case should be developed based on to the input requirement,and to check that object perfectly working or not. Test plan: Test plan is a document which describes object,scope and focus on the software testing efforts. Test plan should be developed whenever requirement is getting at the time test plan should developed. Sanity testing: sanity testing is a cursor testing it is performed whenever the cursor testing is sufficient to prove the application is functioning according to the specification. Verification: verification refers set of activities that ensure built into traceable to the customer requirement. Validation:Validation refers different set of activities that ensure software is correctly implement or not. 25.When does software-testing finish? Depends on the software being tested, the purpose of the software, and the complexity of the software. The time of year can also affect the testing phase (software often has its testing time cut in November-December in order to have the software available for Christmas). On-line Games, for example, are very complex and difficult to make. Testing can sometimes take around a year. Simple word processors may take a week to test, however. It all depends on how many things can go wrong (the more complex, the more things to test). It's always possible that testing times will get cut short, as well. Furthermore, it's impossible to find every bug in the program no matter how much testing you do. In that sense, the testing phase never really ends.

26.tell me about v model 'V' shape model describes about the process about the construting the application at a time all the Analysing, designing, coding and testing will be done at a time. i.e once coding finishes it'll go to tester to test for bugs if we got OK form tester we can immediately start coding after coding again send to tester he'll check for BUGS and will send back to programmer then he,programmer can finish up by implementing the project. it is the model what is using by most of the companies. 27.how test dircter is used Test Director is a management tool that gives systematic control over the testing process. if your using win runner,you can integrated to test director by using tools menu you can click test director command,otherwise you can going directly to test director you can built the automated tool which you want to use. 28.What is E-Learning Content testing? the orderly areanging the e-learning process by the way of some rules& regulations are predefined are verified and to validate the task 29.what is traceability phase matrix?were it has been used and what is need for it? It can be used to trace the functionality of the module. It is created before writing the test cases. Then the test case ids can be added Typically, in test situations, traceability matrices are used to trace requirements to test cases in order to ensure that there are test cases for all the requirements. Some tools, such as Rational Suite Enterprise, will help analysts trace requirements and then allow the tester to trace from the use cases and/or requirements to test cases. Of course, many types of traceability matrices may be created or reverse engineered. For example, you may back trace defects-->test cases-->use cases and vice versa. The default term likely applies to tracing requirements to test cases though 30.what is the difference between REGRESSION TESTING AND RETESTING. Why regression testing is vital in object oriented programing after retesting only we can for regression testing. retesting is the process of testing of application after fixing the bugs. regession testing is the process of reexecuting the application whether it affects the other parts of application or not.

Regression testing is verifing that previously passed tests are still OK after any change to the software or the

environment, usually to verify that a change in one area doesn't affect other or unrelated areas. Retesting? just running the same tests and conditions over and over again, to verify reproducability (precision) 31.What are the tools and techniques of black box testing? Black Box Testing has 5 types of techniques like: 1. Decision Table 2. Equivalence Partitioning 3. Boundary Value Analysis 4. Cause & Effect Method 5. State Transition Method 32.What is traceability metrics Its a mapping document that maps defects with test cases and test cases with functional specifications and functional specifications with business requirements.In order trace back the defects The Traceability Matrix is a very good document that gives us the complete overview / confidence on the end-toend activities of the SDLC. But it needs to be done carefully as we need to capture a lot of complex data at all stages of an SDLC Using the Traceability Matrix we will be able to confidently say that all the User Requirements are properly documented and respectively addressed well in the following also: 1. Functional Requirements Document 2. Design Documents (HLDD and LLDD) 3. Coding and Unit Testing 4. System Test Plans 5. Test Execution Reports So precisely, a Traceability Matrix gives us the end-to-end visibility of the Requirements. 33.How pass word testing is performed. 1)Check for Null values 2)Check for Alpha characters only(small and caps letters) 3)Check for numeric characters only 4)Check for alphanumeric values.(small and caps letters) 5)Check for sniffing of password when the user enters his/her username , password and clicks the submit button, The password should be displayed in encrpyted/hash format when viewed by external user. 6)Check for password entry in the database it should be displayed in encrypted/decrypted format based on the requirement of the user 34.what do u test for in database testing other than data integrity(insert, delete, update...) This will not be exact Testing but can be done as verification. Field size validation with the Front End or with the Design. Field size validation, if application is having data for multiple language.

Return type of each function and Out Parameter for each procedure. If Data base is any file Generation routine that can be tested. In DB testing we need to check for 1. The field size validation 2. Check constraints. 3. Indexes are done or not (for performance related issues) 4. Stored procedures 5. The field size defined in the application is matching with that in the db.

35.When should a Test to be Automated ? Automation is carried out of based on the following conditions 1. Regression testing 2. when there is a need of working with large input. 3. Batch testing 4. Frequently changing requirements 36. BlockBoxTest: Testing process is done without knowing internal process is BlockBox testing WhiteBox Test: Testing process is done with knowing internal process is whitebox testing 37.Describe the fundamental difference between Quality Assurance and Quality Control? quality assurance meant for developing,organising the best quality process. quality control meant for implementing the process developed by former team 38.What is smoke test?Can u send me a case study of smoke test Smoke Test is covering all the functionality in less time to make sure that the application works fine in the normal condition. Smoke test is done during the daily build It verifies the major functionality at high level in order to determine if further testing is possible. The Smoke test scenarios should emphasize breadth more than depth. All components should be touched, and every major feature should be tested briefly. If test fails, the build is returned to developers un-tested 39.how do we assign priority and seviority levels seviority is assigned based on the impact on the risk.The risk may be human life or huge amount of money business specific. example If a bug in financial application wrong calculation of interest which may cause the bank to suffer huge financial losses(legal and may need the bank to close) then sevority is given as 1 (highest) and need to be fixed.the bug

may be related to printing first name first and last name second.which willl have less impact on the business seviority is less say 4. Priority comes when we are fixing the bug which one needs to be taken first for fixing.This decision is taken by the schedule of the project. If you take the above case if additional information is required for interest calculation and the delivery got enough time then priority can be given to less seviority bug then high seviority bug 40.A bug is raised by the tester and it was told that it is not a bug by the programmer. What to do? Its a tester who has to say if that is a bug..a programmer would never accept it a bug though in all probability he would sneakily fix it. The tester needs to take a call. If there is a disagreement by the programmer after posting the bug, then he should discuss it through the manager 41.what is 'front end testing' and 'back end testing' This isn't a textbook answer but in casual environments, I've found that people mean black box functional,and interface testing when they refer to the front end. Backend testing seems to be used to refer to any number of things such as white box testing, or simply lower level testing sans GUI if applicable. These terms aren't formalized and should not be used in test plans. Refer to a good template to find the proper terms to use in place of "front-end" and "back-end" testing Front end testing is testing GUI and functionality Back-end focuses on data stored in the database QATester he knowing about the testing process,at the same time evaluation is also performed 42.What are the different testing methodologies Object Oriented Software Testing Methodologies Top to bottom Software Testing Methodologies Bottom to Top Software Testing Methodologies Heuristic Software Testing Methodologies 43.What is the difference between user acceptance testing and beta testing By User acceptance testing we mean validating whether all the user requirements specified in SRS is met after code freeze. Beta Testing is done at 90-95% of code freeze. Any modifications to be done at this stage is a high level decision 44.What are the types of Test cases? Negative, Positive and GUI related 45.whether it is possible to test strees by winrunner howit is done

stress tests cannot be performed on win runner as the tool is particularly meant for the functionality of the application Winrunner does support stress testing. To create test conditions for determining the limits of your application, use the 'looping' concept. Create TSL tests using the 'for', 'while' and 'do/while' 46.what are the importance of software verification verification involves checking the application in terms of papers, means reviewing the requirements, test cases reports so that it works as per the specifications. (experience people might found odd in this solution) whereas in validation real time testing is done on the application 47.What is testing? __ Testing is the process of identifying defects, where a defect is any variance between actual and expected results 48.How to Write a Fully Effective Bug Report One of the most important (and most common) things an SQA Engineer does is to write "bug reports". How well you report a bug directly affects how likely the programmer is to fix it. You should spend a minimum of time needed to describe a problem in a way that maximizes the probability that it will be fixed. The content and manner of your reports affect that probability To write a fully effective report you must: - Explain how to reproduce the problem - Analyze the error so you can describe it in a minimum number of steps. - Write a report that is complete and easy to understand. Write bug reports immediately; the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten. Writing a one-line report summary (Bug's report title) is an art. You must master it. Summaries help everyone quickly review outstanding problems and find individual reports. The summary line is the most frequently and carefully read part of the report. When a summary makes a problem sound less severe than it is, managers are more likely to defer it. Alternatively, if your summaries make problems sound more severe than they are, you will gain a reputation for alarmism. Don't use the same summary for two different reports, even if they are similar. The summary line should describe only the problem, not the replication steps. Don't run the summary into the description (Steps to reproduce) as they will usually be printed independently of each other in reports. Ideally you should be able to write this clearly enough for a developer to reproduce and fix the problem, and another QA engineer to verify the fix without them having to go back to you, the author, for more information. It is much better to over communicate in this field than say too little. Of course it is ideal if the problem is reproducible and you can write down those steps. But if you can't reproduce a bug, and try and try and still can't reproduce it, admit it and write the report anyway. A good programmer can often track down an irreproducible problem from a careful description. The most controversial thing in a bug report is often the bug Impacts: Low, Medium, High, and Urgent. Report should show the priority which you, the bug submitter, believes to be appropriate and does not get changed. Bug Impacts __________________________________________

Low impact This is for Minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal use, or minor errors in layout/formatting. These problems do not impact use of the product in any substantive way. Medium impact This is a problem that a) Effects a more isolated piece of functionality. b) Occurs only at certain boundary conditions. c) Has a workaround (where "don't do that" might be an acceptable answer to the user). d) Occurs only at one or two customers. or e) Is very intermittent High impact This should be used for only serious problems, effecting many sites, with no workaround. Frequent or reproducible crashes/core dumps/GPFs would fall in this category, as would major functionality not working. Urgent impact This should be reserved for only the most catastrophic of problems. Data corruption, complete inability to use the product at almost any site, etc. For released products, an urgent bug would imply that shipping of the product should stop immediately, until the problem is resolved.

Black-Box testing basic practical hints: Editable Fields Checking and Validation: Valid/invalid characters/strings data in all editable fields Valid minimum/maximum/mid range values in fields Null strings (or no data ) in required fields Record length (character limit)in text/memo fields Cut/copy/paste into/from fields when possible Not Editable Fields Checking: Check for all test/spelling in warnings and error messages/dialogs Invoke/check all menu items and their options Application Usability: Appearance an outlook (Placement an alignment of objects on screen) User Interface Test (open all menus, check all items) Basic functionality checking (File+Open+Save, etc..) Right mouse clicking sensitivity Resize/min/max/restore app, windows (check min app size) Scrollability when applicable (scrollbars, keyboard, autoscrolling) Keyboard and mouse navigation, highlighting, dragging, drag/drop Print in landscape an portrait modes

Check F1, What's This , Help menu Short-cut and Accelerator keys Tab Key order and Navigation in all dialog boxes and menus Basic compatibility: 16 bit OS (Win 3.x, Win95, OS/2, WinNT3.x) 32 bit OS (Win95, Win98, Win200, WinNT4.x) UNIX

How to create a Test Plan without docs? 1. Try to break up your huge application into modules that are functionally independent. 2. Within each module you start with the functions one by one. 3. For a simple function write all possible test cases that arise to be tested, while using the application as there are no specs. 4. In this way you could complete one function and in turn whole application. 5. To prepare test cases or plan make use of Excel sheet. Each sheet will define each function within the module. This is best way to organize the test cases. Important areas of "black box" when QA engineer write test plans: * Acceptance test (into testing) * Data flow and integrity * Configuration and compatibility * Stress test * Regressions * Performance * Potential bugs * Beta tests * Release tests * Utility * User interfaces 11:14 PM