Software Testing FAQ What is quality assurance? The set of support activities (including facilitation, training, measurement and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products that meet specifications and fit for use. What is the purpose of the testing? Testing provides information whether or not a certain product meets the requirements. What is the difference between QA and testing? Quality Assurance is that set of activities that are carried out to set standards and to monitor and improve performance so that the care provided is as effective and as safe as possible. Testing provides information whether or not a certain product meets the requirements. It also provides information where the product fails to meet the requirements. What is software quality'? OR Define software quality for me, as you understand it? Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is obviously a subjective term. It will depend on who the 'customer' is and their overall influence in the scheme of things. Each type of 'customer' will have their own slant on 'quality' - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free. What's the role of documentation in QA? Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible. Explain the software development lifecycle. There are seven stages of the software development lifecycle 1. Initiate the project – The users identify their Business requirements. 2.
Define the project – The software development team translates the business
requirements into system specifications and put together into System Specification Document. 3. Design the system – The System Architecture Team designs the system and write Functional Design Document. During design phase general solutions re hypothesized and data and process structures are organized. 4. Build the system – The System Specifications and design documents are given to the development team code the modules by following the Requirements and Design document. 5. Test the system - The test team develops the test plan following the requirements. The software is build and installed on the test platform after developers have completed development and Unit Testing. The testers test the software by following the test plan. 6. Deploy the system – After the user-acceptance testing and certification of the software, it is installed on the production platform. Demos and training are given to the users. 7. Support the system - After the software is in production, the maintenance phase of the life begins. During this phase the development team works with the development document staff to modify and enhance the application and the test team works with the test documentation staff to verify and validate the changes and enhancement to the application software. At what stage of the SDLC does testing begin in your opinion? QA process starts from the second phase of the Software Development Life Cycle i.e. Define the System. Actual Product testing will be done on Test the system phase (Phase-5). During this phase test team will verify the actual results against expected results. Explain the pre testing phase, acceptance testing and testing phase. Pre testing Phase: 1. Review the requirements document for the testability: Tester will use the requirement document to write the test cases. 2. Establishing the hard freeze date: Hard freeze date is a date after which system test team will not accept any more software and documentation changes from development team, unless they are fixes of severity 1 MR’s. The date is scheduled so that product test team will have time for final regression. 3. Writing master test plan: It is written by the lead tester or test coordinator. Master test plan includes entire testing plan, testing resources and testing strategy. 4. Setting up MR Tool: The MR tool must be set as soon as you know of the different modules in the product, the developers and testers on the product,
requirements into system specifications and put together into System Specification Document. 3. Design the system – The System Architecture Team designs the system and write Functional Design Document. During design phase general solutions re hypothesized and data and process structures are organized. 4. Build the system – The System Specifications and design documents are given to the development team code the modules by following the Requirements and Design document. 5. Test the system - The test team develops the test plan following the requirements. The software is build and installed on the test platform after developers have completed development and Unit Testing. The testers test the software by following the test plan. 6. Deploy the system – After the user-acceptance testing and certification of the software, it is installed on the production platform. Demos and training are given to the users. 7. Support the system - After the software is in production, the maintenance phase of the life begins. During this phase the development team works with the development document staff to modify and enhance the application and the test team works with the test documentation staff to verify and validate the changes and enhancement to the application software. At what stage of the SDLC does testing begin in your opinion? QA process starts from the second phase of the Software Development Life Cycle i.e. Define the System. Actual Product testing will be done on Test the system phase (Phase-5). During this phase test team will verify the actual results against expected results. Explain the pre testing phase, acceptance testing and testing phase. Pre testing Phase: 1. Review the requirements document for the testability: Tester will use the requirement document to write the test cases. 2. Establishing the hard freeze date: Hard freeze date is a date after which system test team will not accept any more software and documentation changes from development team, unless they are fixes of severity 1 MR’s. The date is scheduled so that product test team will have time for final regression. 3. Writing master test plan: It is written by the lead tester or test coordinator. Master test plan includes entire testing plan, testing resources and testing strategy. 4. Setting up MR Tool: The MR tool must be set as soon as you know of the different modules in the product, the developers and testers on the product,
the hardware platform, and operating system testing will be done. This information will be available upon the completion of the first draft of the architecture document. Both testers and developers are trained how to use the system. 5. Setting up the test environment: The test environment is set on separate machines, database and network. This task is performed by the technical support team. First time it takes some time, Afterwards the same environment can be used by the later releases. 6. Writing the test plan and test cases: Template and the tool is decided to write the test plan, test cases and test procedures. Expected results are organized in the test plan according to the feature categories specified in the requirement document. For each feature positive and negative test cases are written. Writing test plan requires the complete understanding of the product and its interfaces with other systems. After test plan is completed, a walkthrough is conducted with the developers and design team members to baseline the test plan document. 7. Setting up the test automation tool: Planning of test strategy on how to automate the testing. Which test cases will be executed for regression testing. Not all the test cases will be executed during regression testing. 8. Identify acceptance test cases: Select subsets that are expected on the first day of system test. These tests must pass to accept the product in the system test. Acceptance testing phase: 1. When the product enters system test, check it has completed integration test and must meet the integration test exit criteria. 2. Check integration exit criteria and product test entrance criteria in the master test plan or test strategy documents. 3. Check the integration testing sign off criteria sheet. 4. Coordinate release with product development. 5. How the code will be migrated from development environment to the test environment. 6. Installation and acceptance testing. Product testing phase: 1. Running the test: Execution of test cases and verify if actual functionality of application matches the expected results. 2. Initial manual testing is recommended to isolate unexpected system behavior. Once application is stable automated regression test could be generated. Issue MR’s upon detection of the bugs. 3.
What is the value of a testing group? How do you justify your work and budget? All software products contain defects/bugs, despite the best efforts of their development teams. It is important for an outside party (one who is not developer) to test the product from a viewpoint that is more objective and representative of the product user. Testing group test the software from the requirements point of view or what is required by the user. Testers job is to examine a program and see if it does not do what it is supposed to do and also see what it does what it is not supposed to do.
What is master test plan? What it contains? Who is responsible for writing it? OR What is a test plan? Who is responsible for writing it? What it contains. OR What's a 'test plan'? What did you include in a test plan? 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. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project: • Title • Identification of software including version/release numbers • Revision history of document including authors, dates, approvals • Table of Contents • Purpose of document, intended audience
• • •
Objective of testing effort Software product overview Relevant related document list, such as requirements, design documents, other test plans, etc. • Relevant standards or legal requirements • Trace ability requirements • Relevant naming conventions and identifier conventions • Overall software project organization and personnel/contactinfo/responsibilties • Test organization and personnel/contact-info/responsibilities • Assumptions and dependencies • Project risk analysis • Testing priorities and focus
• •
Scope and limitations of testing Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable • Outline of data input equivalence classes, boundary value analysis, error classes • Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems • Test environment validity analysis - differences between the test and production systems and their impact on test validity. • Test environment setup and configuration issues • Software migration processes • Software CM processes • Test data setup requirements • Database setup requirements • Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs • Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs • Test automation - justification and overview • Test tools to be used, including versions, patches, etc. • Test script/test code maintenance processes and version control • Problem tracking and resolution - tools and processes • Project test metrics to be used • Reporting requirements and testing deliverables • Software entrance and exit criteria • Initial sanity testing period and criteria • Test suspension and restart criteria • Personnel allocation • Personnel pre-training needs • Test site/location • Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues • Relevant proprietary, classified, security, and licensing issues. • Open issues • Appendix - glossary, acronyms, etc. The team-lead or a Sr. QA Analyst is responsible to write this document.
Why is test plan a controlled document? Because it controls the entire testing process. Testers have to follow this test plan during the entire testing process.
What information you need to formulate test plan? Need the Business requirement document to prepare the test plan. What are the entrance and exit criteria in the system test? Entrance and exit criteria of each testing phase is written in the master test plan. Enterence Criteria: Integration exit criteria have been successfully met. All installation documents are completed. All shippable software has been successfully built Syate, test plan is baselined by completing the walkthrough of the test plan. Test environment should be setup. All severity 1 MR’s of integration test phase should be closed. Exit Criteria: All the test cases in the test plan should be executed. All MR’s/defects are either closed or deferred. Regression testing cycle should be executed after closing the MR’s. All documents are reviewed, finilized and signed-off. If there are no requirements, how will you write your test plan? If there are no requirements we try to gather as much details as possible from: • Business Analysts • Developers (If accessible) • Previous Version documentation (if any) • Stake holders (If accessible) • Prototypes. What is White box testing/unit testing? 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. Difference between Black and White box testing? Black box testing: Functional testing based on requirements with no knowledge of the internal program structure or data. Also known as closed-box testing. White Box testing: Testing approaches that examine the program structure and device test data from the program logic. What are the roles of glass-box and black-box testing tools? Glass-box testing also called as white-box testing refers to testing, with detailed knowledge of the modules internals. Thus these tools concentrate more on the algorithms, data structures used in development of modules. These tools perform testing on
individual modules more likely than the whole application. Black-Box testing tools refer to testing the interface, functionality and performance testing of the system module and the whole system. What is Black box testing? Black Box testing is also called system testing which is performed by the testers. Here the features and requirements of the product as described in the requirement document are tested. What is Integration testing? 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. What knowledge you require to do white box, integration and black box testing? For white box testing you need to understand the internals of the module like data structures and algorithms and have access to the source code and for black box testing only understanding/functionality of the application. What is Regression testing? 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.. Why do we do regression testing? In any application new functionalities can be added so the application has to be tested to see whether the added functionalities have affected the existing functionalities or not. Here instead of retesting all the existing functionalities baseline scripts created for these can be rerun and tested. How do we regression testing? Various automation-testing tools can be used to perform regression testing like WinRunner, Rational Robot and Silk Test. What are positive scenarios? Testing to see whether the application is doing what it is supposed to do. What are negative scenarios? Testing to see whether the application is not doing what it is not suppose to do.
What is the difference between regression automation tool and performance automation tool? Regression testing tools capture test and play them back at a later time. The capture and playback feature is fundamental to regression testing. Performance testing tool determine the load a server can handle. And must have feature to stimulate many users from one machine, scheduling and synchronize different users, able to measure the network load under different number of simulated users. What is the difference between exception and validation testing? Validation testing aims to demonstrate that the software functions in a manner that can be reasonably expected by the customer. Testing the software in conformance to the Software Requirements Specifications. Exception testing deals with handling the exceptions (unexpected events) while the AUT is run. Basically this testing involves how to change the control flow of the AUT when an exception arises.
What is user acceptance testing? What is manual testing and what is automated testing?
What is smoke testing? What is soak testing? What is stress testing, performance testing, Security testing, Recovery testing and volume testing. What is MR? MR is a Modification Request also known as Defect Report, a request to modify the program so that program does what it is supposed to do. Why you write MR? MR is written for reporting problems/errors or suggestions in the software. What information does MR contain? OR Describe me to the basic elements you put in a defect report? OR What is the procedure for bug reporting?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available. The following are items to consider in the tracking process: • Complete information such that developers can understand the bug, get an idea of its severity, and reproduce it if necessary. • Current bug status (e.g., 'Released for Retest', 'New', etc.) • The application name or identifier and version • The function, module, feature, object, screen, etc. where the bug occurred • Environment specifics, system, platform, relevant hardware specifics • Test case name/number/identifier • One-line bug description • Full bug description • Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool • Names and/or descriptions of file/data/messages/etc. used in test
•
File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem • Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common) • Was the bug reproducible? • Tester name • Test date • Bug reporting date • Name of developer/group/organization the problem is assigned to • Description of problem cause • Description of fix • Code section/file/module/class/method that was fixed • Date of fix • Application version that contains the fix • Tester responsible for retest • Retest date • Retest results • Regression testing requirements • Tester responsible for regression tests • Regression testing results Which MR tool you used to write MR? What criteria you will follow to assign severity and due date to the MR?
If the functionality of an application had an inbuilt bug because of which the test script fails, would you automate the test?
You find a bug and the developer says “It’s not possible” what do u do? How do you help developer to track the fault s in the software? What are the different types of MRs? What is the role of a bug tracking system? What is a successful product? What Process/Methodologies are you familiar with? What are CMM and CMMI? What is the difference? What you will do during the first day of job? What was the test team hierarchy? What are the different automation tools you know? Automation tools provided by Mercury Interactive – Quick Test Professionl, WinRunner, LoadRunner; Rational – Rational Robot; Segue- SilkTest.
What is ODBC? Did you ever have problems working with developers? Describe your experience with code analyzers? How do you survive chaos?
Tell me about the worst boss you’ve ever had. What do you like about Windows? How will you describe testing activities? What is good code? How you will begin improve the QA process? What is UML and how it is used for testing? The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction. UML state charts provide a solid basis for test generation in a form that can be easily manipulated. This technique includes coverage criteria that enable highly effective tests to be developed. A tool has been developed that uses
UML state charts produced by Rational Software Corporation's Rational Rose tool to generate test data. When should testing be stopped? When do you start developing your automation tests?
What are benefits of the test automation? Describe some problems that you had with automation testing tools Can test automation improver test effectiveness? What are the main use of test automation? Does automation replace manual testing? How will you choose a tool for test automation? OR How we decide which automation tool we are going to use for the regression testing? What could wrong with automation testing? What type of scripting techniques for test automation do you know? What are good principles for test scripts? What type of document do you need for QA, QC and testing? What are the properties of a good requirement? Have you ever written test cases or did you just execute those written by others? How do you determine what to test?
How do you decide when you have ‘tested enough?’ Real isi ng you w on’t be abl e to t est eve ryt hi ng -how do you decide what to test first? OR What if there isn't enough time for thorough testing? Where do you get your expected results? If automating-what is your process for determining what to automate and in what order? OR Can you automate all the test scripts? Explain ? OR How do you plan test automation? OR What criteria do you use when determining when to automate a test or leave it
manual? 1. Test that need to be run for every build of the application 2. Tests that use multiple data values for the same actions( data driven tests) 3. Tests that require detailed information from application internals 4. Stress/ load testing
If you’re given a program that will average student grades, what kinds of inputs would you use? Name of student, Subject, Score How do you go about testing a project? 1. Analyze user requirement documents and other documents like software specifications, design document etc. 2. Write master test plan which describe the scope, objective, strategy, risk/contingencies, resources 3. Write system test plan and detailed test cases 4. Execute test cases manually and compare actual results against expected results. 5. Identify mismatches, report defect to the development team using defect reporting tool. 6. Track defect, perform regression test to verify that defect is fixed and did not disturb other parts of the application. 7. Once all the defects are closed and application is stabilized, automate the test scripts for regression and performance testing. How do you go about testing a web application? . What is configuration management? Tools used? What are Individual test case and Workflow test case? Why we do workflow scenarios How did you use automating testing tools in your job? What is data-driven automation? Describe me the difference between validation and verification? Is coding required in Regression testing tools?
What do you mean by “set up the test environment and provide full platform support?
What are the two ways to copy a file in windows? Were you able to meet deadlines?
What is test Metrics? What is the use of Metrics? If you have shortage of time, how would you prioritize you testing? Use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. Considerations can include: • Which functionality is most important to the project's intended purpose? • Which functionality is most visible to the user? • Which functionality has the largest safety impact? • Which functionality has the largest financial impact on users? • Which aspects of the application are most important to the customer? • Which aspects of the application can be tested early in the development cycle? • Which parts of the code are most complex, and thus most subject to errors? • Which parts of the application were developed in rush or panic mode? • Which aspects of similar/related previous projects caused problems? • Which aspects of similar/related previous projects had large maintenance expenses? • Which parts of the requirements and design are unclear or poorly thought out? • What do the developers think are the highest-risk aspects of the application? • What kinds of problems would cause the worst publicity? • What kinds of problems would cause the most customer service complaints? • What kinds of tests could easily cover multiple functionalities? • Which tests will have the best high-risk-coverage to time-required ratio?
What is the impact of environment on the actual results of performance testing? What is a pre-condition data? What are the different documents in QA? How do you rate yourself in software testing Is defect resolution a technical skill or interpersonal skill from QA view point? What is End to End business logic testing?
What is the task bar and where does it reside? How do you analyze your test results? what metrics do you try to provide?
OR How do you view test results? If you come onboard, give me a general idea of what your first overall tasks will be as far as as starting a quality effort? Try to learn about the application, Environment and Prototypes to have the better understanding of application and existing testing efforts How do you differentiate the roles of Quality Assurance Manager and Project Manager? What do you like about QA? Who in the company is responsible for Quality? Should we test every possible combination/scenario for a program? What is clientserver architecture? Client-server architecture, a client is defined as a requester of services and a server is defined as the provider of services. Communication takes place in the form a request message from the client to the server asking for some work to be done. Then the server does the work and sends back the reply.
How Intranet is different from client-server? What is three-tier and multi-tier architecture? What is Internet? What is Intranet? What is Extranet? What is ISO-9000? What is QMO? What is Object Oriented model? \ What is Procedural model?
What is an Object? What is class? What is encapsulation? Give one example. What is inheritance? Give example. What is the difference about web-testing and client server testing?
Is a “Fast database retrieval rate” a testable requirement?
What development model should programmers and the test group use? What are the key challenges of load testing? Have you done explanatory or specification-driven testing? What is the role of QA in development project? How do you promote the concept of phase containment and defect prevention?
What is Walkthrough? What is inspection? \ What is Software Review? What if the application has functionality that wasn't in the requirements?
Build Verification Test (BVT) 1.
What is verification?
2.
What is validation?
3.
What is a walkthrough?
4.
What is quality?
5.
What is good code?
6.
What is good design?
7. .
What is software life cycle?
8.
What is the role of documentation in QA?
9.
What about requirements?
10.
What is a test plan?
11.
What is a test case?
12. What is software quality assurance? A: Software Quality Assurance, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. 13. .
What is quality assurance?
14.
Standards and templates - what is supposed to be in a document?
15.
How do test case templates look like?
16.
Process and procedures - why follow them?
18.
How do you create a test strategy?
19.
What is the general testing process?
20.
What is a test schedule?
21.
What are the different levels of testing?
22.
What is black box testing?
23.
What is white box testing?
24.
What is unit testing?
25.
What is functional testing?
26.
What is integration testing?
27.
What is incremental integration testing?
28.
What is system testing?
29.
What is Gray Box testing?
30.
What is end-to-end testing?
31.
What is regression testing?
32.
What is sanity testing?
33.
What is performance testing?
34.
What is load testing?
35.
What is stress testing?
36.
What is recovery/error testing?
37.
What is compatibility testing?
38.
What is acceptance testing?
39.
What is alpha testing?
40.
What is beta testing?
41.
What is Traceability matrix?
42.
What is configuration management?
43.
What can be done if requirements are changing continuously?
44.
What if the application has functionality that wasn't in the requirements?
45.
Why do you recommend that we test during the design phase?
46. What makes a good test engineer? A: Has a "test to break" attitude, • Takes the point of view of the customer, • Has a strong desire for quality, • Has an attention to detail, He's also • Tactful and diplomatic and • Has good a communication skill, both oral and written. And he • Has previous software development experience, too.
47.
Why are there so many software bugs?
48.
Give me five common problems that occur during software development.
49.
What should be done after a bug is found?
50.
What if the software is so buggy it can't be tested at all?
51.
How do you know when to stop testing?
52.
What if the project isn't big enough to justify extensive testing?
What’s the role of a QA in a company that produces software? QA is responsible for managing, implementing, maintaining and continuously improving the Processes the Company and enables internal projects towards process maturity and facilitates process improvements and innovations in the organization. Tester is responsible for carrying the testing effort in the company. Who writes business requirements? What you do when you have BRD? Business Analyst writes the Business Requirements. Business requirements (BR) are sent to the software architect (SA) for validation. SA after understanding the BR makes use cases and UML diagrams and forwards them to QA manager. QA manager based on scope, BR, use case & UML diagram writes the overall testing strategy & high-level test cases and forward them to testers.
What is the difference between SRS and BRS? BRS is a document, which contains the requirements of a customer during initial phase. It is prepared by Business Analyst. It plays a vital role in all the phases of SDLC. SRS is also a document which is prepared on the basis of BRS. It is prepared by System Analyst/Project manager. It mainly contains tentative plan, technological selection etc.
What are the exit and entry criteria in a test plan? Exit criteria define when u stops the testing. It defines interims the following: All bug status cycle are closed, all functionalities are tested, and all high and medium bugs are resolved. Entry criteria define entry of test execution. It defines interims the following: Test environment established, Builder received from developer, Test case prepared and reviewed.
Sample Testing Plan A testing plan should include:
Software development lifecycle There are seven stages of the software development lifecycle 8. Initiate the project – The users identify their Business requirements. 9. Define the project – The software development team translates the business requirements into system specifications and put together into System Specification Document. 10. Design the system – The System Architecture Team designs the system and write Functional Design Document. During design phase general solutions re hypothesized and data and process structures are organized. 11. Build the system – The System Specifications and design documents are given to the development team code the modules by following the Requirements and Design document. 12. Test the system - The test team develops the test plan following the requirements. The software is build and installed on the test platform after developers have completed development and Unit Testing. The testers test the software by following the test plan. 13. Deploy the system – After the user-acceptance testing and certification of the software, it is installed on the production platform. Demos and training are given to the users. 14. Support the system - After the software is in production, the maintenance phase of the life begins. During this phase the development team works with the development document staff to modify and enhance the application and the test team works with the test documentation staff to verify and validate the changes and enhancement to the application software. QA process starts from the second phase of the Software Development Life Cycle i.e. Define the System. Actual Product testing will be done on Test the system phase (Phase- 5). During this phase test team will verify the actual results against expected results. Test plan A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. • Outside test organizations to be utilized and their purpose, responsibilities, deliverables, contact persons, and coordination issues Need the Business requirement document to prepare the test plan. Test plan controls the entire testing process. Testers have to follow this test plan during the entire testing process. Entrance and exit criteria of each testing phase is written in the master test plan. Enterence Criteria: Integration exit criteria have been successfully met.
plan. -
All installation documents are completed. All shippable software has been successfully built System, test plan is base lined by completing the walkthrough of the test Test environment should be setup.
All severity 1 MR’s of integration test phase should be closed. Exit Criteria: All the test cases in the test plan should be executed. All MR’s/defects are either closed or deferred. Regression testing cycle should be executed after closing the MR’s. All documents are reviewed, finilized and signed-off. White box testing/unit testing Black box testing Knowledge require to do white box and black box testing What is backend and front end testing? Testing Types:
2.
What is the difference between verifying and validating data?
3.
How can an object recognition problem be resolved?
4.
How do we calculate bug rate?
5.
How do you ensure comprehensive test coverage?
6.
When do you know testing is over?
7. What is QA methodology and what environment would you use to do your QA testing?
9.
What is Release acceptance testing?
10.
What is system integration testing?
11. What is the compatibility testing difference between testing IE explorer and testing in firefox? What is bug leakage? What is requirement traceability? Describe the basic elements you put in a defect report.
17. In a situation where actual result doesn’t match with expected result, what would you do? 19.
What is walkthrough and inspection?
20.
What is the difference between test scenario and test case?
21.
What is the difference between smoke testing and sanity testing?
22.
What are all the scenarios to be considered while testing reports?
23.
How do you know all the testing scenarios are covered?
24. If test cases are executed with existing requirements and the requirements are frequently changing, what steps should be taken for the test completion? 25.
What is a test strategy?
26.
What is a checklist?
28.
What type of testing does non- functional testing include?
29. What is the difference between boundary value analysis and equivalence portioning? 30. What are severity levels? 31. What is the diff between quality control and quality assurance?
What is Software Quality Assurance? What is ‘Software Testing’? Common interview questions QA:
1. FRD
What types of documents would you need for QA, QC, and Testing? BRD,
2. What did you include in a test plan? The detailed doc which gives scope and approach to the application 3.
Describe any bug you remember.
4.
What is the purpose of the testing? To have the applications bugs free
5.
What do you like (not like) in this job?
6. What is QA (quality assurance)? Testing of the applications for bugs or any defects and assuring the product is bug free
7. What is the difference between QA and testing? Read the answer for this interview question for software testers QA is assuring the application is bug free Testing is executing the applications, documenting all the results & defects. 8.
How do you scope, organize, and execute a test project? Through Test Plan
9. What is the role of QA in a development project? Write the test cases, execute the test cases, report the defects. Perform regression testing if there are any defects or new addition to the application 10. What is the role of QA in a company that produces software? To check if the application is bug free from end to end. 11. Define quality for me as you understand it Quality by itself says it all. For me quality means the application should not have any errors on the user end. 12. Describe to me the difference between validation and verification. Validation is boundary testing (tel No., zip code) Verification is verifying the insertion of data
13. Describe to me what you see as a process. Not a particular process, just the basics of having a process. 14. Describe to me when you would consider employing a failure mode and effect analysis.
15. Describe to me the Software Development Life Cycle as you would define it. Initiate, Define, Design, Build, Test, Deploy & Support 16. What are the properties of a good requirement? The req should be specified clearly with all the details of the application 17. How do you differentiate the roles of Quality Assurance Manager and Project Manager? QA Manager is the one who will manage all the QA Testers. Project Manager will be managing all the developers and the whole project. 18. Tell me about any quality efforts you have overseen or implemented. Describe some of the challenges you faced and how you overcame them.
19. How do you deal with environments that are hostile to quality change efforts?
20. In general, how do you see automation fitting into the overall process of testing? If the application is too big it should be tested by automation. Also if the application is going to be in regression testing it should be automated 21. How do you promote the concept of phase containment and defect prevention?
22. If you come onboard, give me a general idea of what your first overall tasks will be as far as starting a quality effort. Understanding the project thoroughly by reading the BRD, Creating test plans & documents for that project & attending the meetings to improve my knowledge of this new project 23.
What kinds of testing have you done?
The different kinds of testing which I was involved was manual testing, QTP automation testing, winrunner & loadrunner 24. Have you ever created a test plan? Yes the test plans for all the projects I have worked were created by me. 25. Have you ever written test cases or did you just execute those written by others? Most of the times I have written the test cases and executed them, but there were times when I had to execute the existing test case due to addition of new modules 26.
What did your base your test cases?
27. How do you determine what to test? To ensure the application is clean we have to check all the existing defects & rerun the test. Also check if the whole application is running without any errors 28. How do you decide when you have 'tested enough?' When the application is running smoothly from end to end without any errors. 29. How do you test if you have minimal or no documentation about the product? To run the test we have to have the proper documents but if there are no documents about the product we should have meetings with the developers and the users, discuss the product. 30. Describe me to the basic elements you put in a defect report? Priority, assigned to,
Character Traits
1. A. B. C.
Do you consider yourself to be a smart person? Yes. Depending on the way I handled with different situations Interacting with other people.
D. E.
Solving Business problems Making decisions
2. How important is job security to you? A. Security is the basic need. The only true job security comes from making a meaningful contribution to my employer. I am confident that I will be able to continue getting the work done always exceeding expectations.
3.
Do you get bored doing the same work over and over again? A. Not really, if the work involves my job. I don’t get bored because it is my responsibility to complete it. 4. Do you prefer working as a member of a team or alone? A. Working as a part of a team is one of the most important elements in a successful career. It really depends on the best way to complete it. I would work equally hard with the initiative required for success. 5. A. B. C. D. E.
What are the reasons for your success? When I do a job well, it gives me personal satisfaction. Paying attention to details I usually Recheck the things for missed ones Hard work Respect for others
6. Are you absent from work often? A. No. My attendance record is very good (unless I have a serious health problem) 7. Hoe do you show your interest in your co-workers? A. By keeping my eyes and ears open. I try to remember the things that are important to the people around me. If I am a supervisor, I usually call a quick closed-door conference to see if there is something that can be done before a problem occurs. 8. If you could be anyone, who would you like to be? A. Generally I am pretty happy with who I am. B. If it could be anyone I wanted, it would be a person who used his/her business skills to make the world a better place. C. The best way to succeed is by helping others to succeed. 9. How did you react to criticism superiors? A. I always learned to receive criticism as a feedback to my actions.
10. What would you do if it were your last day on earth? A. I would gather the people who are important to me and let them know how much they have contributed to my happiness. 11. Do you have a competitive nature? A. Yes. It is necessary to be successful in a corporate environment. If I do my work well the rewards will come and that is the way to succeed. 12.
What is your idea of success?
13. 14.
How would you feel about working with a female executive? What types of people try your patience?
15. How well do you cope with your tension? 16. Do you speak up if your point of view differs from that of your superiors? 17.Are you an innovative person? A. . 18.
How often do you lose your temper?
19. How have you benefited from your disappointments? 20.Do you get along with your co-workers? 21.What can you tell me about yourself? 22.What do you think you do best? 23.What have you learned from mistakes? 31. How do you perform regression testing? 32. At what stage of the life cycle does testing begin in your opinion? 33. How do you analyze your test results? What metrics do you try to provide? 34. Realising you won't be able to test everything - how do you decide what to test first? 35. here do you get your expected results? 36. If automating - what is your process for determining what to automate and in what order? 37. In the past, I have been asked to verbally start mapping out a test plan for a common situation, such as an ATM. The interviewer might say, "Just thinking out loud, if you were tasked to test an ATM, what items might you test plan include?" These type questions are not meant to be answered conclusively, but it is a good way for the interviewer to see how you approach the task. 38. If you're given a program that will average student grades, what kinds of inputs would you use? 39. Tell me about the best bug you ever found. 40. What made you pick testing over another career?
41. What is the exact difference between Integration & System testing, give me examples with your project. 42. How did you go about testing a project? 43. When should testing start in a project? Why? 44. How do you go about testing a web application? 45. Difference between Black & White box testing 46. What is Configuration management? Tools used? 47. What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?) 48. Would you like to work in a team or alone, why? 49. Give me 5 strong & weak points of yours 50. Why do you want to join our company? 51. When should testing be stopped? 52. What sort of things would you put down in a bug report? 53. Who in the company is responsible for Quality? 54. Who defines quality? 55. What is an equivalence class? 56. Is a "A fast database retrieval rate" a testable requirement? 57. Should we test every possible combination/scenario for a program? 58. What criteria do you use when determining when to automate a test or leave it manual? 59. When do you start developing your automation tests? 60. Discuss what test metrics you feel are important to publish an organization? 61. In case anybody cares, here are the questions that I will be asking: 62. Describe the role that QA plays in the software lifecycle. 63. What should Development require of QA? 64. What should QA require of Development? 65. How would you define a "bug?" 66. Give me an example of the best and worst experiences you've had with QA. 67. How does unit testing play a role in the development / software lifecycle? 68. Explain some techniques for developing software components with respect to testability. 69. Describe a past experience with implementing a test harness in the development of software. 70. Have you ever worked with QA in developing test tools? Explain the participation Development should have with QA in leveraging such test tools for QA use. 71. Give me some examples of how you have participated in Integration Testing. 72. How would you describe the involvement you have had with the bug-fix cycle between Development and QA? 72. What is unit testing? 73. Describe your personal software development process. 74. How do you know when your code has met specifications?
75. How do you know your code has met specifications when there are no specifications? 76. Describe your experiences with code analyzers. 77. How do you feel about cyclomatic complexity? 78. Who should test your code? 79. How do you survive chaos? 80. What processes/methodologies are you familiar with? 81. What type of documents would you need for QA/QC/Testing? 82. How can you use technology to solve problem? 83. What type of metrics would you use? 84. How to find that tools work well with your existing system? 85. What automated tools are you familiar with? 86. How well you work with a team? 87. How would you ensure 100% coverage of testing? 88. How would you build a test team? 89. What problem you have right now or in the past? How you solved it? 90. What you will do during the first day of job? 91. What would you like to do five years from now? 92. Tell me about the worst boss you've ever had. 93. What are your greatest weaknesses? 94. What are your strengths? 95. What is a successful product? 96. What do you like about Windows? 97. What is good code? 99. What are basic, core, practises for a QA specialist? 100. What do you like about QA? 101. What has not worked well in your previous QA experience and what would you change? 102. How you will begin to improve the QA process? 103. What is the difference between QA and QC? 104. What is UML and how to use it for testing? 105. What is CMM and CMMI? What is the difference? 106. What do you like about computers? 107. Do you have a favourite QA book? More than one? Which ones? And why. 108. What is the responsibility of programmer’s vs QA? 109.What are the properties of a good requirement? 110. Ho to do test if we have minimal or no documentation about the product? 111. What are all the basic elements in a defect report? 112. Is an "A fast database retrieval rate" a testable requirement? 113.Why should you care about objects and object-oriented testing? 114. What does 100% statement coverage mean? 115. How do you perform configuration management with typical revision control systems? 116. What is code coverage? 117. What types of code coverage do you know? 118. What tools can be used for code coverage analysis? 119. Is any graph is used for code coverage analysis? 120. At what stage of the development cycle software errors are least costly to correct?
121. What can you tell about the project if during testing you found 80 bugs in it? 122. How to monitor test progress? 123. Describe a few reasons that a bug might not be fixed. 124. What are the possible states of software bug�s life cycle? 125. What books about QA (software testing) did you read? 126. What type of testing based specifically on a program code? 127. What type of testing based on any document that describes the "structure of the software"? 128. Please describe test design techniques like: state-transition diagrams, decision tables, activity diagrams. 129. Describe business process testing and what test design technique would you use for it?
Test Automation job interview questions: 1. What automating testing tools are you familiar with? 2. How did you use automating testing tools in your job? 3. Describe some problem that you had with automating testing tool. 4. How do you plan test automation? 5. Can test automation improve test effectiveness? 6. What is data - driven automation? 7. What are the main attributes of test automation? 8. Does automation replace manual testing? 9. How will you choose a tool for test automation? 10. How you will evaluate the tool for test automation? 11. What are main benefits of test automation? 12. What could go wrong with test automation? 13. How you will describe testing activities? 14. What testing activities you may want to automate? 15. Describe common problems of test automation. 16. What types of scripting techniques for test automation do you know? 17. What are principles of good testing scripts for automation? 18. What tools are available for support of testing during software development life cycle? 19. Can the activities of test case design be automated? 20. What are the limitations of automating software testing? 21. What skills needed to be a good test automator? 22. How to find that tools work well with your existing system? 23. Describe some problem that you had with automating testing tool. 24. What are the main attributes of test automation? 25. What testing activities you may want to automate in a project?
26. How to find that tools work well with your existing system? 27. What are some of the common misconceptions during implementation of an automated testing tools for the first time?
Testing Interview Questions
Why did you ever become involved in QA/testing? What is the testing lifecycle and explain each of its phases? What is the difference between testing and Quality Assurance? What is Negative testing? What was a problem you had in your previous assignment (testing if possible)? How did you resolve it? What are two of your strengths that you will bring to our QA/testing team? How would you define Quality Assurance? What do you like most about Quality Assurance/Testing? What do you like least about Quality Assurance/Testing? What is the Waterfall Development Method and do you agree with all the steps? What is the V-Model Development Method and do you agree with this model? What is the Capability Maturity Model (CMM)? At what CMM level were the last few companies you worked? What is a "Good Tester"? Could you tell me two things you did in your previous assignment (QA/Testing related hopefully) that you are proud of? List 5 words that best describe your strengths. What are two of your weaknesses? What methodologies have you used to develop test cases? In an application currently in production, one module of code is being modified. Is it necessary to re- test the whole application or is it enough to just test functionality associated with that module? Define each of the following and explain how each relates to the other: Unit, System, and Integration testing. Define Verification and Validation. Explain the differences between the two. Explain the differences between White-box, Gray-box, and Black-box testing. How do you go about going into a new organization? How do you assimilate?
Define the following and explain their usefulness: Change Management, Configuration Management, Version Control, and Defect Tracking. What is ISO 9000? Have you ever been in an ISO shop? When are you done testing? What is the difference between a test strategy and a test plan? What is ISO 9003? Why is it important What are ISO standards? Why are they important? What is IEEE 829? (This standard is important for Software Test DocumentationWhy?) What is IEEE? Why is it important? Do you support automated testing? Why? We have a testing assignment that is time-driven. Do you think automated tests are the best solution? What is your experience with change control? Our development team has only 10 members. Do you think managing change is such a big deal for us? Are reusable test cases a big plus of automated testing and explain why. Can you build a good audit trail using CPWR's QACenter products. Explain why. How important is Change Management in today's computing environments? Do you think tools are required for managing change. Explain and please list some tools/practices which can help you managing change. We believe in ad-hoc software processes for projects. Do you agree with this? Please explain your answer. When is a good time for system testing? Are regression tests required or do you feel there is a better use for resources? Our software designers use UML for modeling applications. Based on their use cases, we would like to plan a test strategy. Do you agree with this approach or would this mean more effort for the testers. Tell me about a difficult time you had at work and how you worked through it. Give me an example of something you tried at work but did not work out so you had to go at things another way. How can one file compare future dated output files from a program which has change, against the baseline run which used current date for input. The client does
not want to mask dates on the output files to allow compares. - Answer-Rerun baseline and future date input files same # of days as future dated run of program with change. Now run a file compare against the baseline future dated output and the changed programs' future dated output. Interviewing Suggestions If you do not recognize a term ask for further definition. You may know the methodology/term but you have used a different name for it. Always keep in mind that the employer wants to know what you are going to do for them, with that you should always stay/be positive. Preinterview Questions What is the structure of the company? Who is going to do the interview-possible background information of interviewer? What is the employer's environment (platforms, tools, etc.)? What are the employer's methods and processes used in software arena? What is the employer's philosophy? What is the project all about you are interviewing for-as much information as possible. Any terminologies that the company may use.
Test Automation: 1. What automating testing tools are you familiar with? 2. How did you use automating testing tools in your job? 3. Describe some problem that you had with automating testing tool. 4. How do you plan test automation? 5. Can test automation improve test effectiveness? 6.
What is data - driven automation?
7. What are the main attributes of test automation? 8. Does automation replace manual testing? 9. How will you choose a tool for test automation? 10. How you will evaluate the tool for test automation? 11. What are main benefits of test automation? 12. What could go wrong with test automation? 13. How you will describe testing activities? 14. What testing activities you may want to automate? 15. Describe common problems of test automation. 16. What types of scripting techniques for test automation do you know? 17. What are principles of good testing scripts for automation? 18. What tools are available for support of testing during software development life cycle? 19. Can the activities of test case design be automated? 20. What are the limitations of automating software testing? 21. What skills needed to be a good test automator? 22. How to find that tools work well with your existing system? 23.Describe some problem that you had with automating testing tool. 24.What are the main attributes of test automation? 25.What testing activities you may want to automate in a project? 26.How to find that tools work well with your existing system?
Load Testing: 1. What criteria would you use to select Web transactions for load testing? 2. For what purpose are virtual users created? 3. Why it is recommended to add verification checks to your all your scenarios? 4. In what situation would you want to parameterize a text verification check? 5. Why do you need to parameterize fields in your virtual user script? 6. What are the reasons why parameterization is necessary when load testing the Web server and the database server? 7. How can data caching have a negative effect on load testing results? 8. What usually indicates that your virtual user script has dynamic data that is dependent on you parameterized fields? 9. What are the benefits of creating multiple actions within any virtual user script?
General questions: 1. 2.
What types of documents would you need for QA, QC, and Testing? What did you include in a test plan?
3. Describe any bug you remember. 4. What is the purpose of the testing? 5. What do you like (not like) in this job? 6. What is quality assurance? 7. What is the difference between QA and testing? 8. How do you scope, organize, and execute a test project? 9. What is the role of QA in a development project? 10. What is the role of QA in a company that produces software? 11. Define quality for me as you understand it 12. Describe to me the difference between validation and verification. 13. Describe to me what you see as a process. Not a particular process, just the basics of having a process. 14. Describe to me when you would consider employing a failure mode and effect analysis. 15. Describe to me the Software Development Life Cycle as you would define it. 16. What are the properties of a good requirement? 17. How do you differentiate the roles of Quality Assurance Manager and Project Manager? 18. Tell me about any quality efforts you have overseen or implemented. Describe some of the challenges you faced and how you overcame them. 19. How do you deal with environments that are hostile to quality change efforts? 20. In general, how do you see automation fitting into the overall process of testing? 21. How do you promote the concept of phase containment and defect prevention? 22. If you come onboard, give me a general idea of what your first overall tasks will be as far as starting a quality effort. 23. What kinds of testing have you done? 24. Have you ever created a test plan? 25. Have you ever written test cases or did you just execute those written by others? 26. What did your base your test cases? 27. How do you determine what to test? 28. How do you decide when you have 'tested enough?' 29. How do you test if you have minimal or no documentation about the
product? 30. Describe me to the basic elements you put in a defect report? 31. How do you perform regression testing? 32. At what stage of the life cycle does testing begin in your opinion? 33. How do you analyze your test results? What metrics do you try to provide? 34. Realising you won't be able to test everything - how do you decide what to test first? 35. Where do you get your expected results? 36. If automating - what is your process for determining what to automate and in what order? 37. In the past, I have been asked to verbally start mapping out a test plan for a common situation, such as an ATM. The interviewer might say, "Just thinking out loud, if you were tasked to test an ATM, what items might you test plan include?" These type questions are not meant to be answered conclusively, but it is a good way for the interviewer to see how you approach the task. 38. If you're given a program that will average student grades, what kinds of inputs would you use? 39. Tell me about the best bug you ever found. 40. What made you pick testing over another career? 41. What is the exact difference between Integration & System testing, give me examples with your project. 42. How did you go about testing a project? 43. When should testing start in a project? Why? 44. How do you go about testing a web application? 45. Difference between Black & White box testing 46. What is Configuration management? Tools used? 47. What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?) 48. Would you like to work in a team or alone, why? 49. Give me 5 strong & weak points of yours 50. Why do you want to join our company? 51. When should testing be stopped? 52. What sort of things would you put down in a bug report? 53. Who in the company is responsible for Quality? 54. Who defines quality? 55. What is an equivalence class? 56. Is a "A fast database retrieval rate" a testable requirement? 57. Should we test every possible combination/scenario for a program? 58. What criteria do you use when determining when to automate a test or leave it manual? 59. When do you start developing your automation tests? 60. Discuss what test metrics you feel are important to publish an organization? 61. In case anybody cares, here are the questions that I will be asking: 62. Describe the role that QA plays in the software lifecycle.
63. What should Development require of QA? 64. What should QA require of Development? 65. How would you define a "bug?" 66. Give me an example of the best and worst experiences you've had with QA. 67. How does unit testing play a role in the development / software lifecycle? 68. Explain some techniques for developing software components with respect to testability. 69. Describe a past experience with implementing a test harness in the development of software. 70. Have you ever worked with QA in developing test tools? Explain the participation Development should have with QA in leveraging such test tools for QA use. 71. Give me some examples of how you have participated in Integration Testing. 72. How would you describe the involvement you have had with the bug-fix cycle between Development and QA? 72. What is unit testing? 73. Describe your personal software development process. 74. How do you know when your code has met specifications? 75. How do you know your code has met specifications when there are no specifications? 76. Describe your experiences with code analyzers. 77. How do you feel about cyclomatic complexity? 78. Who should test your code? 79.How do you survive chaos? 80. What processes/methodologies are you familiar with? 81. What type of documents would you need for QA/QC/Testing? 82. How can you use technology to solve problem? 83. What type of metrics would you use? 84. How to find that tools work well with your existing system? 85. What automated tools are you familiar with? 86. How well you work with a team? 87. How would you ensure 100% coverage of testing? 88. How would you build a test team? 89. What problem you have right now or in the past? How you solved it? 90. What you will do during the first day of job? 91. What would you like to do five years from now? 92. Tell me about the worst boss you've ever had. 93. What are your greatest weaknesses? 94. What are your strengths? 95. What is a successful product? 96. What do you like about Windows? 97. What is good code? 99. What are basic, core, practises for a QA specialist?
100. What do you like about QA? 101. What has not worked well in your previous QA experience and what would you change? 102. How you will begin to improve the QA process? 103. What is the difference between QA and QC? 104. What is UML and how to use it for testing? 105. What is CMM and CMMI? What is the difference? 106. What do you like about computers? 107. Do you have a favourite QA book? More than one? Which ones? And why. 108. What is the responsibility of programmers vs QA? 109.What are the properties of a good requirement? 110. Ho to do test if we have minimal or no documentation about the product? 111. What are all the basic elements in a defect report? 112. Is an "A fast database retrieval rate" a testable requirement?
1. What is software quality assurance? 2. What is the value of a testing group? How do you justify your work and budget? 3. What is the role of the test group vis-à¶is documentation, tech support, and so forth? 4. How much interaction with users should testers have, and why? 5. How should you learn about problems discovered in the field, and what should you learn from those problems? 6. What are the roles of glass-box and black-box testing tools? 7. What issues come up in test automation, and how do you manage them? 8. What development model should programmers and the test group use? 9. How do you get programmers to build testability support into their code? 10. What is the role of a bug tracking system? 11. What are the key challenges of testing? 12. Have you ever completely tested any part of a product? How? 13. Have you done exploratory or specification-driven testing? 14. Should every business test its software the same way? 15. Discuss the economics of automation and the role of metrics in testing. 16. Describe components of a typical test plan, such as tools for interactive products and for database products, as well as cause-and-effect graphs and dataflow diagrams.
17. When have you had to focus on data integrity? 18. What are some of the typical bugs you encountered in your last assignment? 19. How do you prioritize testing tasks within a project? 20. How do you develop a test plan and schedule? Describe bottom-up and top-down approaches. 21. When should you begin test planning? 22. When should you begin testing? 23. Do you know of metrics that help you estimate the size of the testing effort? 24. How do you scope out the size of the testing effort? 25. How many hours a week should a tester work? 26. How should your staff be managed? How about your overtime? 27. How do you estimate staff requirements? 28. What do you do (with the project tasks) when the schedule fails? 29. How do you handle conflict with programmers? 30. How do you know when the product is tested well enough? 31. What characteristics would you seek in a candidate for test-group manager? 32. What do you think the role of test-group manager should be? Relative to senior management? Relative to other technical groups in the company? Relative to your staff? 33. How do your characteristics compare to the profile of the ideal manager that you just described? 34. How does your preferred work style work with the ideal test-manager role that you just described? What is different between the way you work and the role you described? 35. Who should you hire in a testing group and why? 36. What is the role of metrics in comparing staff performance in human resources management? 37. How do you estimate staff requirements? 38. What do you do (with the project staff) when the schedule fails? Describe some staff conflicts youÂ’ve handled. 39. Here are some questions you might be asked on a job interview for a testing opening: (from MU COSC 198 Software Testing by Dr. Corliss) Why did you ever become involved in QA/testing? What is the testing lifecycle and explain each of its phases? What is the difference between testing and Quality Assurance? What is Negative testing? What was a problem you had in your previous assignment (testing if possible)? How did you resolve it? What are two of your strengths that you will bring to our QA/testing team? How would you define Quality Assurance?
What do you like most about Quality Assurance/Testing? What do you like least about Quality Assurance/Testing? What is the Waterfall Development Method and do you agree with all the steps? What is the V-Model Development Method and do you agree with this model? What is the Capability Maturity Model (CMM)? At what CMM level were the last few companies you worked? What is a "Good Tester"? Could you tell me two things you did in your previous assignment (QA/Testing related hopefully) that you are proud of? List 5 words that best describe your strengths. What are two of your weaknesses? What methodologies have you used to develop test cases? In an application currently in production, one module of code is being modified. Is it necessary to re- test the whole application or is it enough to just test functionality associated with that module? Define each of the following and explain how each relates to the other: Unit, System, and Integration testing. Define Verification and Validation. Explain the differences between the two. Explain the differences between White-box, Gray-box, and Black-box testing. How do you go about going into a new organization? How do you assimilate? Define the following and explain their usefulness: Change Management, Configuration Management, Version Control, and Defect Tracking. What is ISO 9000? Have you ever been in an ISO shop? When are you done testing? What is the difference between a test strategy and a test plan? What is ISO 9003? Why is it important What are ISO standards? Why are they important? What is IEEE 829? (This standard is important for Software Test DocumentationWhy?) What is IEEE? Why is it important? Do you support automated testing? Why? We have a testing assignment that is time-driven. Do you think automated tests
are the best solution? What is your experience with change control? Our development team has only 10 members. Do you think managing change is such a big deal for us? Are reusable test cases a big plus of automated testing and explain why. Can you build a good audit trail using Compuware's QACenter products. Explain why. How important is Change Management in today's computing environments? Do you think tools are required for managing change. Explain and please list some tools/practices which can help you managing change. We believe in ad-hoc software processes for projects. Do you agree with this? Please explain your answer. When is a good time for system testing? Are regression tests required or do you feel there is a better use for resources? Our software designers use UML for modeling applications. Based on their use cases, we would like to plan a test strategy. Do you agree with this approach or would this mean more effort for the testers. Tell me about a difficult time you had at work and how you worked through it. Give me an example of something you tried at work but did not work out so you had to go at things another way. How can one file compare future dated output files from a program which has change, against the baseline run which used current date for input. The client does not want to mask dates on the output files to allow compares. - Answer-Rerun baseline and future date input files same # of days as future dated run of program with change. Now run a file compare against the baseline future dated output and the changed programs' future dated output. Interviewing Suggestions If you do not recognize a term ask for further definition. You may know the methodology/term but you have used a different name for it. Always keep in mind that the employer wants to know what you are going to do for them, with that you should always stay/be positive. Preinterview Questions
What is the structure of the company? Who is going to do the interview-possible background information of interviewer? What is the employer's environment (platforms, tools, etc.)? What are the employer's methods and processes used in software arena? What is the employer's philosophy? What is the project all about you are interviewing for-as much information as possible. Any terminologies that the company may use.
Software Quality Assurance (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which products are developed or manufactured.
What's difference between client/server and Web Application ? Client/server based is any application architecture where one server application and one or many client applications are involved like your mail server and MS outlook Express, it can be a web application as well, where the Web Application is a kind of client server application that is hosted on the web server and accessed over the internet or interanet. There are lots of things that differs between testing of the two type above and cann't be posted in one post but you can look into the data flow, communication and servside variable like session and security etc
Software Quality Assurance Activities
Application of Technical Methods (Employing proper methods and tools for developing software)
Conduct of Formal Technical Review (FTR)
Testing of Software
Enforcement of Standards (Customer imposed standards or management imposed standards)
Control of Change (Assess the need for change, document the change)
Measurement (Software Metrics to measure the quality, quantifiable)
Records Keeping and Recording (Documentation, reviewed, change control etc. i.e. benefits of docs).
What's the difference between STATIC TESTING and DYNAMIC TESTING? Answer1: Dynamic testing: Required program to be executed static testing: Does not involve program execution The program is run on some test cases & results of the program‟s performance are examined to check whether the program operated as expected E.g. Compiler task such as Syntax & type checking, symbolic execution, program proving, data flow analysis, control flow analysis
Answer2: Static Testing: Verification performed with out executing the system code Dynamic Testing: Verification and validation performed by executing the system code
What is software testing
What black box testing types can you tell me about? Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality. Functional testing is also a blackbox type of testing geared to functional requirements of an application. System testing is also a black box type of testing. Acceptance testing is also a black box type of testing. Functional testing is also a black box type of testing. Closed box testing is also a black box type of testing. Integration testing is also a black box type of testing. What is software testing methodology? One software testing methodology is the use a three step process of... 1. Creating a test strategy; 2. Creating a test plan/design; and 3. Executing tests. This methodology can be used and molded to your organization's needs. Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his clients' applications. What’s the difference between QA and testing? TESTING means “Quality Control”; and QUALITY CONTROL measures the quality of a product; while QUALITY ASSURANCE measures the quality of processes used to create a quality product. Why Testing CANNOT Ensure Quality Testing in itself cannot ensure the quality of software. All testing can do is give you a certain level of assurance (confidence) in the software. On its own, the only thing that testing proves is that under specific controlled conditions, the software functioned as expected by the test cases executed. s regression testing performed manually? The answer to this question depends on the initial testing approach. If the initial testing approach was manual testing, then the regression testing is usually performed manually. Conversely, if the initial testing approach was automated testing, then the regression testing is usually performed by automated testing.
How to choose which defect to remove in 1000000 defects? (because It will take too much resources in order to remove them all.)
Answe2: As a tester we don't fix the defects but we surely can prioritize them once detected. In our org we assign severity level to the defects depending upon their influence on other parts of products. If a defect doesnt allow you to go ahead and test test the product, it is critical one so it has to be fixed ASAP. We have 5 levels as 1-critical 2-High 3-Medium 4-Low 5-Cosmetic Dev can group all the critical ones and take them to fix before any other defect. Answer3: Priority/Severity P1 P2 P3 S1 S2 S3 Generally the defects are classified in aboveshown gr id. Every organization / software has some target of fixing the bugs. Example P1S1 -> 90% of the bugs reported should be fixed. P3S3 -> 5% of the bugs reported may be fixed. Rest are taken in letter service packs or versions. Thus the organization should decide its target and act accordingly. Basically bugfree software is not possible. Answer4: Ideally, the customer should assign priorities to their requirements. They tend to resist this. On a large, multi-year project I just completed, I would often (in the lack of customer guidelines) rely on my knowledge of the application and the potential downstream impacts in the modeled business process to prioritize defects. If the customer doesn't then I fell the test organization should based on r isk or other, similar considerations. What is Software “Quality”? Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is a subjective term. It will depend on who the „customer‟ is and their overall
influence in the scheme of things. A wide- angle view of the „customers‟ of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organisation‟s management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine reviewers, reviewe rs, etc. Each type of „customer‟ will have their own view on „quality‟ - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free. What are the five dimensions of the Risks? Schedule: Unrealistic schedules, exclusion of certain activities when chalking out a schedule etc. could be deterrents to project delivery on time. Unstable communication link can be considered as a probable risk if testing is carried out from a remote location. Client: Ambiguous requirements definition, clarifications on issues not being readily available, frequent changes to the requirements etc. could cause chaos during project execution. Human Resources: Non-availability of sufficient resources with the skill level expected in the project are not available; Attrition of resources - Appropriate training schedules must be planned for resources to balance the knowledge level to be at par with resources quitting. Underestimating the training effort may have an impact in the project delivery. System Resources: Non-availability of /delay in procuring all critical computer resources either hardware and software tools or licenses for software will have an adverse impact. Quality: Compound factors like lack of resources along with a tight delivery schedule and frequent changes to requirements will have an impact on the quality of the product tested. What is good code? A good code code is code that works, works, is free of of bugs and and is readable readable and maintainable. maintainable. Organizations Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards. How do you perform integration testing? To perform integration testing, first, all unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable, or acceptable, based on client input. Why back-end testing is required, if we are going to check the front-end ....? 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 that you're thinking client-server client-server or web. If you you test the application application on the front end only only you can see if the data was stored and retrievd correctly. You can't see if the servers are in an error state or not. many server processes are monitored by another process. If they crash, they are restarted. You can't see that without looking at it. The data may not be stored correctly either but the front end may have cached data lying around and it will use that instead. The least you should be doing is verifying the data as stored in the database. It is easier to test data being transferred on the boundaries and see the results of those transactions when you can set the data in a driver. Answer2: Back-End testing : Basically the requirement of this testing depends on ur project. like Say if ur project is .Ticket booking system,Front end u will provided with an Interface , where u can book the ticket by giving the appropriate details ( Like Place to go, and Time when u wanna go etc..). It will have a Data storage system (Database or XL sheet etc) which is a Back end for storing details entered by the user. After submitting submitting the details ,U might have provided with a correct correct acknowledgemen acknowledgement.But t.But in back back end , the details might not updated correctly in Database becoz of wrong logic development. Then that will cause a major problem. and regarding Unit level testing and System testing Unit level testing is for testing the basic checks whether the application is working fyn with the basic requirements.This will be done by developers before delivering to the QA.In System testing , In addition to the unit checks ,u will be performing all the checks ( all possible integrated checks which required) .Basically this will be carried out by tester Answer3: Ever heard about divide and conquer tactic ? It is a same method applied in backend and frontend testing. A good back back end test will help help minimize the burden of frontend test. Another point point is you you can test the backend backend while while develope develope the frontend. frontend. A true true pararelism pararelism could be achived. Backend testing has another problem which must addressed before front end could use it. The problem is concurency. Building a scenario to test concurency is formidable task. A complex thing thing is hard hard to test. test. To create create such scenarios scenarios will make you unsure unsure which test you already done and which you haven't. What we need is an effective methods to test our application. The simplest method i know is using divide and conquer. Answer4: A wide range range of errors errors are hard to see ifif you don't don't see the code. For example, there there are many
optimizations in programs that treat special cases. If you don't see the special case, you don't test the optimization. Also, a substantial portion of most programs is error handling. Most programmers anticipate more errors than most testers. Programmers find and fix the vast majority of their own bugs. This is cheaper, because there is no communication overhead, faster because there is no delay from tester-reporter to programmer, and more effective because the programmer is likely to fix what she finds, and she is likely to know the cause of the problems she sees. Also, the rapid feedback gives the programmer information about the weaknesses in her programming that can help her write better code. Many tests -- most boundary tests -- are done at the system level primarily because we don't trust that they were done at the unit level. They are wasteful and tedious at the system level. I'd rather see them properly done and properly automated in a suite of programmer tests. What is retesting? Answer1: Retesting is usually equated with regression testing (see above) but it is different in that is follows a specific fix--such as a bug fix--and is very narrow in focus (as opposed to testing entire application again in a regression test). A product should never be released after any change has been applied to the code, with only retesting of the bug fix, and without a regression test. Answer2: 1. Re-testing is the testing for a specific bug after it has been fixed.(one given by your definition). 2. Re-testing can be one which is done for a bug which was raised by QA but could not be found or confirmed by Development and has been rejected. So QA does a re-test to make sure the bug still exists and again assigns it back to them. when entire project is tested & client have some doubts about the quality of testing, Re-Testing can be called. It can also be testing the same application again for better Quality. Answer3: Regression Testing is, the selective retesting of a system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the reparations and that newly added features have not created problems with previous versions of the software. Also referred to as verification testing It is important to determine whether in a given set of circumstances a particular series of tests has been failed. The supplier may want to submit the software for re-testing. The contract should deal with the parameters for retests, including (1) will test program which are doomed to failure be allowed to finish early, or must they be completed in their entirety? (2) when can, or must, the supplier submit his software for retesting?, and (3) how many times can the supplier fail tests and submit software for retesting ñ is this based on time spent, or the number of attempts? A well drawn contract will grant the customer options in the event of failure of
acceptance tests, and these options may vary depending on how many attempts the supplier has made to achieve acceptance. So the conclusion is retesting is more or less regression testing. More appropriately retesting is a part of regression testing. Answer4: Re-testing is simply executing the test plan another time. The client may request a re-test for any reason - most likely is that the testers did not properly execute the scripts, poor documentation of test results, or the client may not be comfortable with the results. I've performed re-tests when the developer inserted unauthorized code changes, or did not document changes. Regression testing is the execution of test cases "not impacted" by the specific project. I am currently working on testing of a system with poor system documentation (and no user documentation) so our regression testing must be extensive. Answer5: * QA gets a bug fix, and has to verify that the bug is fixed. You might want to check a few things that are a “gut feel” if you want to and get away by calling it retesting, but not the entire function / module / product. * Development Refuses a bug on the basis of it being “Non Reproducible”, then retesting, preferably in the presence of the Developer, is needed.
How to establish QA Process in an organization? 1.CURRENT SITUATION The first thing you should do is to put what you currently do in a piece of paper in some sort of a flowchart diagram. This will allow you to analyze what is being currently done. 2.DEVELOPMENT PROCESS STAGE Once you have the "big picture", you have to be aware of the current status of your development project or projects. The processes you select will vary depending if you are in early stages of developing a new application (i.e.: developing a version 1.0), or maintaining an existing application (i.e.: working on release 6.7.1). 3. PRIORITIES The next thing you need to do is identify the priorities of your project, for example: - Compliance with industry standards - Validation of new functionality (new GUIs, etc) - Security - Capacity Planning ( You should see "Effective Methods for Software Testing" for more info). Make a list of the priorities, and then assign them values of (H)igh, (M)edium and (L)ow. 4. TESTING TYPES Once you are aware of the priorities, focus on the High first, then Medium, and finally evaluate whether the Low ones need immediate attention. Based on this, you need to select those Testing Types that will provide coverage for your priorities. Example of testing types:
- Functional Testing - Integration Testing - System Testing - System-to-System Testing (for testing interfaces) - Regression Testing - Load Testing - Performance Testing - Stress Testing Etc. 5. WRITE A TEST PLAN Once you have determined your needs, the simplest way to document and implement your process is to elaborate a "Test Plan" for every effort that you are engaged into (i.e.: for every release). For this you can use generic Test Plan templates available in the web that will help you brainstorm and define the scope of your testing: - Scope of Testing (defects, functionality, and what will be and will not be tested). - Testing Types (Functional, Regression, etc). - Responsible people - Requirements traceability matrix (match test cases with requirements to ensure coverage) - Defect tracking - Test Cases DURING AND POST-TESTING ACTIVITIES Make sure you keep track of the completion of your testing activities, the defects found, and that you comply with an exit criteria prior to moving to the next stage in testing (i.e. User Acceptance Testing, then Production Release). Make sure you have a mechanism for: - Reporting - Test tracking
What is the testing lifecycle? There is no standard, but it consists of: Test Planning (Test Strategy, Test Plan(s), Test Bed Creation) Test Development (Test Procedures, Test Scenarios, Test Cases) Test Execution Result Analysis (compare Expected to Actual results) Defect Tracking Reporting What is quality?
Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free What is Benchmark? How it is linked with SDLC (Software Development Life Cycle)? or SDLC and Benchmark are two unrelated things.? What are the compoments of Benchmark? In Software Testing where Benchmark fits in? A Benchmark is a standard to measure against. If you benchmark an application, all future application changes will be tested and compared against the benchmarked application.
What is the general testing process? The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests. Test data are inputs that have been devised to test the system Test Cases are inputs and outputs specification plus a statement of the function under the test. Test data can be generated automatically (simulated) or real (live). The stages in the testing process are as follows: 1. Unit testing: (Code Oriented) Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. 2. Module testing: A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures and functions. A module encapsulates related components so it can be tested without other system modules. 3. Sub-system testing: (Integration Testing) (Design Oriented) This phase involves testing collections of modules, which have been integrated into subsystems. Sub-systems may be independently designed and implemented. The most common problems, which arise in large software systems, are sub-systems interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by
rigorously exercising these interfaces. 4. System testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors that result from unanticipated interactions between sub-systems and system components. It is also concerned with validating that the system meets its functional and nonfunctional requirements. 5. Acceptance testing: This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data. Acceptance testing may reveal errors and omissions in the systems requirements definition( user - oriented) because real data exercises the system in different ways from the test data. Acceptance testing may also reveal requirement problems where the system facilities do not really meet the users needs (functional) or the system performance (non-functional) is unacceptable. Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for a single client. The alpha testing process continues until the system developer and the client agrees that the delivered system is an acceptable implementation of the system requirements. When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the system builders. After this feedback, the system is modified and either released fur further beta testing or for general sale. What is boundary value analysis? Boundary value analysis is a technique for test data selection. A test engineer chooses values that lie along data extremes. Boundary values include maximum, minimum, just inside boundaries, just outside boundaries, typical values, and error values. The expectation is that, if a systems works correctly for these extreme or special values, then it will work correctly for all values in between. An effective way to test code is to exercise it at its natural boundaries. Boundary Value Analysis is a method of testing that complements equivalence partitioning. In this case, data input as well as data output are tested. The rationale behind BVA is that the errors typically occur at the boundaries of the data. The boundaries refer to the upper limit and the lower limit of a range of values or more commonly known as the "edges" of the boundary. What is the purpose of black box testing?
Answer1: The main purpose of BB Testing is to validate that the application works as the user will be operating it and in the environments of their systems. How do you do system testing and integration testing? You may lose time and money but you may also lose Quality and eventually Customers! Answer2: "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. It's used in functional and system testing. "We do everything in white box testing: - we check each module's function in the unit testing" Who is "we"? Are you programmers or quality assurance testers? Usually, unit testing is done by programmers, and white-box testing would be how they'd do it. "- once unit test result is ok, means that modules work correctly (according to the requirement documemts)" Not quite. It means that on a stand-alone basis, each module is okay. White box testing only tests the internal structure of the program, the code paths. Functional testing is needed to test how the individual components work together, and this is best done from an external perspective, meaning by using the software the way an end user would, without reference to the code (which is what black-box testing is). if we doing testing again in black box will we lose time and money?" No, the opposite: You'll lose money from having to repair errors you didn't catch with the whitebox testing if you don't do some black-box testing. It's far more expensive to fix errors after release 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 the programming; they should be the QA team -- also some end users for the usability testing. Now that I've said that, good programmers will run some basic black-box tests before handing the application to QA for testing. This isn't a substitute for having QA do the tests, but it's a lot quicker for the programmer to find and fix an error right away than to have to go through the whole process of reporting a bug, then fixing and releasing a new build, then retesting.
How do you create a test strategy? The test strategy is a formal description of how a software product will be tested. A test strategy is 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 include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment. Inputs for this process: * A description of the required hardware and software components, including test tools. This
information comes from the test environment, including test tool data. * A description of roles and responsibilities of the resources required for the test and schedule constraints. 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 from requirements, 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 project management level.
What is the purpose of test strategy? Reason number 1: The number one reason of writing a test strategy document is to "have" a signed, sealed, and delivered, FDA (or FAA) approved document, where the document includes a written testing methodology, test plan, and test cases. Reason number 2: Having a test strategy does satisfy one important step in the software testing process. 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 the resources required for the test and schedule constraints. Reason number 6: When we create a test strategy document, we have to put into writing any testing issues requiring resolution (and usually this means additional negotiation at the project management level). Reason number 7: The test strategy is decided first, before lower level decisions are made on the test plan, test design, and other testing issues
Why Q/A should not report to development? Based on research from the Quality Assurance Institute, the percent of quality groups in each location is noted, 50% - reports to Senior IT Manager - This is the best positioning because it gives the Quality Manager immediate access to the IT Manager to discuss and promote Quality issues, when the quality manager reports elsewhere, quality issues may not be raised to the appropriate level or receive the necessary action. 25% - reports to Manager of systems/programming 15 % reports to Manger oprerations. 10 % outside IT function.
What is a requirements test matrix? The requirements test matrix is a project management tool for tracking and managing testing efforts, based on requirements, throughout the project's life cycle. The requirements test matrix is a table, where requirement descriptions are put in the rows of the table, and the descriptions of testing efforts are put in the column headers of the same table. The requirements test matrix is similar to the requirements traceability matrix, which is a representation of user requirements aligned against system functionality. The requirements traceability matrix ensures that all user requirements are addressed by the system integration team and implemented in the system integration effort. The requirements test matrix is a representation of user requirements aligned against system testing. Similarly to the requirements traceability matrix, the requirements test matrix ensures that all user requirements are addressed by the system test team and implemented in the system 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 you create 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 and 360 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 requirement numbers, 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 360 test 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 90 requirements they satisfy. If, for the sake of this example, test case number 64 satisfies requirement 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-referencing purposes
What metrics are used for bug tracking? Metrics that can be used for bug tracking include the followings: the total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and the number of fixes per 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.
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, on the 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 an actual product. The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect, actual product.
What stage of bug fixing is the most cost effective? Bug prevention techniques (i.e. inspections, peer design reviews, and walk-throughs) are more cost 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 it's a Bug) In Progress (when a person is working to resolve the issue-defect) Resolved (once the defect resolved) Completed (Some one who can take up the responsibly Team lead) Closed/reopened (Retested by TE and he will update the Status of the bug) Answer2: Defect Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported. A general Interview answer can be given as: 1. New or Opened 2. Assinged 3. Fixed 4. Tested
What's the difference between priority and severity? The word "priority" is associated with scheduling, and the word "severity" is associated with standards. "Priority" means something is afforded or deserves prior attention; a precedence established by urgency or order of or importance. Severity is the state or quality of being severe; severe implies adherence to rigorous standards
or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles. For example, a severe code of behavior. How do you write test cases? When I write test cases, I concentrate on one requirement at a time. Then, based on that one requirement, I come up with several real life scenarios that are likely to occur in the use of the application by an end user. When I write test cases, I describe the inputs, action, or event, and their expected results, in order to determine if a feature of an application is working correctly. To make the test case complete, I also add particulars e.g. test case identifiers, test case names, objectives, test conditions (or setups), input data requirements (or steps), and expected results. Additionally, if I have a choice, I like writing test cases as early as possible in the development life cycle. Why? Because, as a side benefit of writing test cases, many times I am able to find problems in the requirements or design of an application. And, because the process of developing test cases makes me completely think through the operation of the application.
Freshers Jobs In India | Interview Preparation | Puzzles www.fresherventure.net
Frequently Asked Manual Software Testing Interview Questions with Answers
1) What is difference etween ug! error and defect" #ug and defect essentially $ean the sa$e% It is the flaw in a co$&onent or syste$! which can cause the co$&onent or syste$ to fail to &erfor$ its required function% If a ug or defect is encountered during the e'ecution &hase of the software develo&$ent! it can cause the co$&onent or the syste$ to fail% (n the other hand! an error is a hu$an error! which gives rise to incorrect result% ou $ay want to know aout! how to log a ug *defect)! contents of a ug! ug life cycle! and ug and statuses used during a ug life cycle! which hel& you in understanding the ter$s ug and defect etter% +) ,'&lain white o' testing% (ne of the testing ty&es used in software testing is white o' testing% -ead in detail on white o' testing% .) Tell $e aout / $odel in $anual testing% / $odel is a fra$ework! which descries the software develo&$ent life cycle activities right fro$ require$ents s&ecification u& to software $aintenance &hase% Testing is integrated in each of the &hases of the $odel% The &hases of the $odel start with user require$ents and are followed y syste$ require$ents! gloal design! detailed design! i$&le$entation and ends with syste$ testing of the entire syste$% ,ach &hase of $odel has the res&ective testing activity integrated in it and is carried out &arallel to the develo&$ent activities% The four test levels used y this $odel include! co$&onent testing! integration testing! syste$ testing and acce&tance testing% 0) What are stus and drivers in $anual testing" #oth stus and drivers are a &art of incre$ental testing% There are two a&&roaches! which are used in incre$ental testing! na$ely otto$ u& and to& down a&&roach% rivers are used in otto$ u& testing% They are $odules! which test the co$&onents to e tested% The look of the drivers is si$ilar to the future real $odules% A skeletal or s&ecial &ur&ose i$&le$entation of a
Freshers Jobs In India | Interview Preparation | Puzzles www.fresherventure.net
co$&onent! which is used to develo& or test a co$&onent! that calls or is otherwise de&endent on it% It is the re&lace$ent for the called co$&onent% 2) ,'&lain lack o' testing% Find the answer to the question in the article on lack o' testing% 3) ,'&lain co$&atiility testing% The answer to this question is in the article on co$&atiility testing% 4) What are the check lists! which a software tester should follow" -ead the link on check lists for software tester to find the answer to the question% 5) What are the different ty&es of software testing" There are a nu$er of ty&es of software testing which you will learn in the &receding link% 6) What are the &hases of ST78" 7ike there are different &hases of the software develo&$ent life cycle! there are different &hases of software testing life cycle as well% -ead through software testing life cycle for $ore e'&lanation% 19) What is a -eview" A review is an evaluation of a said &roduct or &ro:ect status to ascertain any discre&ancies fro$ the actual &lanned results and to reco$$end i$&rove$ents to the said &roduct% The co$$on e'a$&les of reviews are infor$al review or &eer review! technical review! ins&ection! walkthrough! $anage$ent review% This is one of the manual testing interview questions% 11) ,'&lain eta testing% For answer to this question! refer to the article on eta testing% 1+) ,'&lain equivalence class &artition% It is either s&ecification ased or a lack o' te chnique% ;ather infor$ation on equivalence &artitioning fro$ the article on equivalence &artitioning% 1.) What is a test case" Find the answer to this question in the article titled test ca ses% 10) What is a test suite"
Freshers Jobs In India | Interview Preparation | Puzzles www.fresherventure.net
A test suite is a set of several test cases designed for a co$&onent of a software or syste$ under test! where the &ost condition of one test case is nor$ally used as the &recondition for the ne't test% 12) What is acce&tance testing" -efer to the article on acce&tance testing for the answer% 13) What is oundary value analysis" A oundary value is an in&ut or an out&ut value! which resides on the edge of an equivalence &artition% It can also e the s$allest incre$ental distance on either side of an edge! like the $ini$u$ or a $a'i$u$ value of an edge% #oundary value analysis is a lack o' testing technique! where the tests are ased on the oundary values% 14) What is co$&atiility testing" 8o$&atiility testing is a &art of noning and re$oving the causes of failures in the software% (n the other hand! testing consists of oth static and dyna$ic testing life cycle activities% It hel&s to deter$ine that the software does satisfy s&ecified require$ents and it is fit for &ur&ose% 16) ,'&lain in short! sanity testing! ad
Freshers Jobs In India | Interview Preparation | Puzzles www.fresherventure.net
given constraints regarding &rocessing ti$e and through&ut rate% Therefore! &erfor$ance testing is the &rocess to test to deter$ine the &erfor$ance of software% +1) What is e'&loratory testing" -ead the &age on e'&loratory testing t o find the answer% ++) What is integration testing" (ne of the software testing ty&es! where tests are conducted to test interfaces etween co$&onents! interactions of the different &arts of the syste$ with o&erating syste$! file syste$! hardware and etween different software% It $ay e carried out y the integrator of the syste$! ut should ideally e carried out y a s&ecific integration tester or a test tea$% +.) What is $eant y functional defects and usaility defects in general" ;ive a&&ro&riate e'a$&le% We will take the e'a$&le of B7ogin windowC to understand functionality and usaility defects% A functionality defect is when a user gives a valid user na$e ut invalid &assword and the user clicks on login utton% If the a&&lication acce&ts the user na$e and &assword! and dis&lays the $ain window! where an error should have een dis&layed% (n the other hand a usaility defect is when the user gives a valid user na$e! ut invalid &assword and clicks on login utton% The a&&lication throws u& an error $essage saying Dlease enter valid user na$eE when the error $essage should have een Dlease enter valid assword%E +0) What is &ilot testing" It is a test of a co$&onent of a software syste$ or the entire syste$ under the real ti$e o&erating conditions% The real ti$e environ$ent hel&s to fi nd the defects in the syste$ and &revent costly ugs een detected later on% or$ally a grou& of users use the syste$ efore its co$&lete de&loy$ent and give thei r feedack aout the syste$% +2) ,'&lain state$ent coverage% It is a structure ased or white o' technique% Test coverage $easures in a s&ecific way the a$ount of testing &erfor$ed y a set of tests% (ne of the test coverage ty&e is state$ent coverage% It is the &ercentage of e'ecutale state$ents which have een e'ercise y a &articular test suite% The for$ula which is used for state$ent coverage isG State$ent 8overage H u$er of state$ents e'ercised Total nu$er of state$ents 199J +3) ,'&lain stress testing% Find the answer to this question in this article on stress testing% +4) What is regression testing" -egression testing is the testing of a &articular co$&onent of the software or the entire software after $odifications have een $ade to it% The ai$ of regression testing is to ensure
Freshers Jobs In India | Interview Preparation | Puzzles www.fresherventure.net
new defects have not een introduced in the co$&onent or software! es&ecially in the areas where no changes have een $ade% In short! regression testing is the tes ting to ensure nothing has changed! which should not have changed due to changes $ade% +5) What is security testing" -ead on security testing for an a&&ro&riate answer% +6) What is syste$ testing" Syste$ testing is testing carried out of an integrated syste$ to verify! that the syste$ $eets the s&ecified require$ents% It is concerned with the ehavior of the whole syste$! according to the sco&e defined% More often than not syste$ testing is the final test carried out y the develo&$ent tea$! in order to verify that the syste$ develo&ed does $eet the s&ecifications and also identify defects which $ay e &resent% .9) What is the difference etween retest and regression testing" -etesting! also known as confir$ation testing is testing which runs the test cases that failed the last ti$e! when they were run in order to verify the success of corrective actions taken on the defect found% (n the other hand! regression testing is testing of a &reviously tested &rogra$ after the $odifications to $ake sure that no new defects have een introduced% In other words! it hel&s to uncover defects in the unchanged areas of the software% .1) ,'&lain &riority! severity in software testing% riority is the level of usiness i$&ortance! which is assigned to a defect found% (n the other hand! severity is the degree of i$&act! the defect can have on the develo&$ent or o&eration of the co$&onent or the syste$% .+) ,'&lain the ug life cycle in detail% This is one of the $ost co$$only asked interview questions! hence this question is always a &art of software testing interview questions and answers for e'&erienced as well as fresherCs% The ug life cycle is the stages the ug or defect goes through efore it is fi'ed! deferred or re:ected% -ead in detail on ug life cycle% ..) What is the difference etween volu$e testing and load testing" /olu$e testing checks if the syste$ can actually co$e u& with the large a$ount of data% For e'a$&le! a nu$er of fields in a &articular record or nu$erous records in a file! etc% (n the other hand! load testing is $easuring the ehavior of a co$&onent or a syste$ with increased load% The increase in load can e in ter$s of nu$er of &arallel users and?or &arallel transactions% This hel&s to deter$ine the a$ount of load! which can e handled y the co$&onent or the software syste$% .0) What is usaility testing" -efer to the article titled usaility testing for an answer to this question%
Freshers Jobs In India | Interview Preparation | Puzzles www.fresherventure.net
.2) ,'&lain the test case life cycle% (n an average a test case goes through the following &hases% The first &hase of the test case life cycle is identifying the test scenarios either fro$ the s&ecifications or fro$ the use cases designed to develo& the syste$% (nce the scenarios have een identified! the test cases a&t for the scenarios have to e develo&ed% Then the test cases are reviewed and the a&&roval for those test cases has to e taken fro$ the concerned authority% After the test cases have een a&&roved! they are e'ecuted% When the e'ecution of the test cases start! the results of the tests have to e recorded% The test cases which &ass are $arked accordingly% If the test cases fail! defects have to e raised% When the defects are fi'ed the failed test case has to e e'ecuted again% .3) What is verification and validation" -ead on the two techniques used in software testing na$ely verification and validation in the article on verification and validation% .4) Which are the different $ethodologies used in software testing" -efer to software testing $ethodologies for detailed infor$ation on the different $ethodologies used in software testing% .5) ,'&lain the waterfall $odel in testing% Waterfall $odel is a &art of software develo&$ent life cycle! as well as software testing% It is one of the first $odels to e used for software testing% .6) ,'&lain is /alidation" The &rocess of evaluating software at the end of the software develo&$ent &rocess t o ensure co$&liance with software require$ents% The techniques for validation are testing! ins&ection and reviewing% 09) What is /erification" The &rocess of deter$ining whether or not the &roducts of a given &hase of the software develo&$ent cycle $eet the i$&le$entation ste&s and can e traced to the inco$ing o:ectives estalished during the &revious &hase% The t echniques for verification are testing! ins&ection and reviewing%
1. What is Acceptance Testing? Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria. 2. What is Accessibility Testing? Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.). 3. What is Ad Hoc Testing? A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing. 4. What is Agile Testing? Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development. 5. What is Application Binary Interface (ABI)? A specification defining requirements for portability of applications in binary forms across diff erent system platforms and environments. 6. What is Application Programming Interface (API)? A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services. 7. What is Automated Software Quality (ASQ)? The use of software tools, such as automated testing tools, to improve software quality. 8. What is Automated Testing? Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing. The use of software to control the execution of tests, t he comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. 9. What is Backus-Naur Form? A metalanguage used to formally describe the syntax of a language. 10. What is Basic Block? A sequence of one or more consecutive, executable statements containing no branches. 11. What is Basis Path Testing? A white box test case design technique that uses the algorithmic flow of the program to design tests. 12. What is Basis Set? The set of tests derived using basis path testing. 13. What is Baseline? The point at which some deliverable p roduced during the software engineering process is put under formal change control. 14. What you will do during the first day of job? What would you like to do f ive years from now? 15. What is Beta Testing? Testing of a release of a software product conducted by customers. 16. What is Binary Portability Testing? Testing an executable application for portability across system platforms and en vironments, usually for conformation to an ABI specification. 17. What is Black Box Testing? Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component. 18. What is Bottom Up Testing? An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested. 19. What is Boundary Testing?
Test which focus on the boundary or limit conditions of the software being test ed. (Some of these tests are stress tests).
20. What is Bug? A fault in a program which cause it to perform in an unintended or unanticipated manner. 20. What is Defect? If software misses some feature or function from w hat is there in requirement it is called as defect. 21. What is Boundary Value Analysis? BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001. 22. What is Branch Testing? Testing in which all branches in the program source code are tested at least once. 23. What is Breadth Testing? A test suite that exercises the full functionality of a product but does not test features in detail. 24. What is CAST? Computer Aided Software Testing. 25. What is Capture/Replay Tool? A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.
26. What is CMM? The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identify ing the key practices that are required to increase the maturity of these processes. 27. What is Cause Effect Graph? A graphical representation of inputs and the associated outputs effects which can be use d to design test cases. 28. What is Code Complete? Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented. 29. What is Code Coverage? An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention. 30. What is Code Inspection? A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing th e code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards. 31. What is Code Walkthrough? A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually moni tored, to analyze the programmer's logic and assumptions. 32. What is Coding? The generation of source code. 33. What is Compatibility Testing? Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware. 34. What is Component? A minimal software item for which a separate specification is available. 35. What is Component Testing? Testing of individual software components (Unit Testing). 36. What is Concurrency Testing?
Multi-user testing geared towards determining th e effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.
37. What is Conformance Testing? The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard. 38. What is Context Driven Testing? The context-driven school of software testing is f lavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now. 39. What is Conversion Testing? Testing of programs or procedures used to convert data f rom existing systems for use in replacement systems. 40. What is Cyclomtic Complexity? A measure of the logical complexity of an algorithm, used in white-box testing. 41. What is Data Dictionary? A database that contains definitions of all data ite ms defined during analysis. 42. What is Data Flow Diagram? A modeling notation that represents a functional decomposition of a system. 43. What is Data Driven Testing? Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common t echnique in Automated Testing. 44. What is Debugging? The process of finding and removing th e causes of software failures. 45. What is Defect? Nonconformance to requirements or functional / program specification 46. What is Dependency Testing? Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality. 47. What is Depth Testing? A test that exercises a feature of a product in full detail. 48. What is Dynamic Testing? Testing software through executing it. See also Static Testing. 49. What is Emulator? A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system. 50. What is Endurance Testing? Checks for memory leaks or other problems that may occur with prolonged execution. 51. What is End-to-End testing? Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or int eracting with other hardware, applications, or systems if appropriate. 52. What is Equivalence Class? A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification. 53. What is Equivalence Partitioning? A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes. 54. What is Exhaustive Testing? Testing which covers all combinations of input values and preconditions for an element of the software under test. 55. What is Functional Decomposition?
A technique used during planning, analysis an d design; creates a functional hierarchy for the software.
54. What is Functional Specification? A document that describes in detail the characteristics of the product with regard to its intended features. 55. What is Functional Testing? Testing the features and operational behavior of a product to ensure they correspond to its specifications. Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. or Black Box Testing. 56. What is Glass Box Testing? A synonym for White Box Testing. 57. What is Gorilla Testing? Testing one particular module, functionality heavily.
58. What is Gray Box Testing? A combination of Black Box and White Box testing m ethodologies? testing a piece of software against its specification but using some knowledge of its internal workings. 59. What is High Order Tests? Black-box tests conducted once the software has been integrated. 60. What is Independent Test Group (ITG)? A group of people whose primary responsibility is software testing, 61. What is Inspection? A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection). 62. What is Integration Testing? Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems. 63. What is Installation Testing? Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include s hortage of disk space, unexpected loss of communication, or power out conditions. 64. What is Load Testing? See Performance Testing.
65. What is Localization Testing? This term refers to making software specifically designed for a specific locality. 66. What is Loop Testing? A white box testing technique that exercises program loops. 67. What is Metric? A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective m easurement of something such as number of bugs per lines of code. 68. What is Monkey Testing? Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out. 69. What is Negative Testing? Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing. 70. What is Path Testing? Testing in which all paths in the program source code are tested at least once. 71. What is Performance Testing?
Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".
72. What is Positive Testing? Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing. 73. What is Quality Assurance? All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer. 74. What is Quality Audit? A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives. 75. What is Quality Circle? A group of individuals with related inte rests that meet at regular intervals to consider problems or other matters related to the q uality of outputs of a process and to the correction of problems or to the improvement of quality.
76. What is Quality Control? The operational techniques and the activities used to fulfill and verify requirements of quality. 77. What is Quality Management? That aspect of the overall management function that determines and implements the quality policy. 78. What is Quality Policy? The overall intentions and direction of an organization as regards qua lity as formally expressed by top management. 79. What is Quality System? The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management. 80. What is Race Condition? A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access. 81. What is Ramp Testing? Continuously raising an input signal until the system breaks down. 82. What is Recovery Testing? Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk s pace, unexpected loss of communication, or power out conditions. 83. What is Regression Testing? Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made. 84. What is Release Candidate? A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released). 85. What is Sanity Testing? Brief test of major functional elements of a piece of software to determine if its basically operational. See also Smoke Testing. 86. What is Scalability Testing? Performance testing focused on ensuring the a pplication under test gracefully handles increases in work load. 87. What is Security Testing? Testing which confirms that the program can res trict access to authorized personnel and that the authorized personnel can access the functions available to their security level. 88. What is Smoke Testing?
A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a n ew piece of hardware for the first time and considering it a success if it does not catch on fire.
89. What is Soak Testing? Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of tra nsactions have been executed. 90. What is Software Requirements Specification? A deliverable that describes all data, functional and b ehavioral requirements, all constraints, and all validation requirements for software/ 91. What is Software Testing? A set of activities conducted with t he intent of finding errors in software. 92. What is Static Analysis? Analysis of a program carried out without executing the program.
93. What is Static Analyzer? A tool that carries out static analysis. 94. What is Static Testing? Analysis of a program carried out without executing the program. 95. What is Storage Testing? Testing that verifies the pr ogram under test stores data files in th e correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage. 96. What is Stress Testing? Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load. 97. What is Structural Testing? Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing. 98. What is System Testing? Testing that attempts to discover defects that are properties of the entire system rather than of its individual components. 99. What is Testability? The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. 100. What is Testing? The process of exercising software to verify that it satisfies specified requirements and to detect errors. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829). The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. What is Test Automation? It is the same as Automated Testing. 101. What is Test Bed? An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other a pplication or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used. 102. What is Test Case? Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing . A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc. 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. Test Driven Development? Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development.
Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.
103. What is Test Driver? A program or test tool used to execute a tests. Also known as a Test Harness. 104. What is Test Environment? The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers. 105. What is Test First Design? Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that programmers do not write any production code until t hey have first written a unit test. 106. What is Test Harness? A program or test tool used to execute a tests. Also known as a Test D river. 107. What is Test Plan? A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. 108. What is Test Procedure? A document providing detailed instructions for the execution of one or more test cases. 109. What is Test Script? Commonly used to refer to the i nstructions for a particular test that will be carried out by an automated test tool. 110. What is Test Specification? A document specifying the test approach for a software feature or combination or features and th e inputs, predicted results and execution conditions for the associated tests. 111. What is Test Suite? A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together h undreds or thousands of tests related by what they are intended to test. 112. What is Test Tools? Computer programs used in the testing of a system, a component of the system, or its documentation. 113. What is Thread Testing? A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels. 114. What is Top Down Testing? An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested. 115. What is Total Quality Management? A company commitment to develop a process that achieves high quality product and customer satisfaction. 116. What is Traceability Matrix? A document showing the relationship between Test Requirements and Test Cases. 117. What is Usability Testing? Testing the ease with which users can learn and use a product.
118. What is Use Case? The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities. 119. What is Unit Testing? Testing of individual software components.
120. What is Validation? The process of evaluating software at the en d of the software development process to ensure compliance with software requirements. The techniques f or validation is testing, inspection and reviewing. 121. What is Verification? The process of determining whether or not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing. 122. What is White Box Testing? Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing. Contrast with Black Box Testing.
123. What is Workflow Testing? Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user. 124. What's the difference between load and stress testing ? One of the most common, but unfortunate misuse of terminology is treating “load testing” and “stress testing” as synonymous. The consequence of this ignorant semantic abuse is usually that the system is neither properly “load tested” nor subjected to a meaningful stress test. Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) neede d to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) i n a decent manner (e.g., not corrupting or losing data). Bugs an d failure modes discovered under stress testing may or may not be repaired depending on the application, the failure mode, consequences, etc. The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion. Load testing is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term 'load testing' by itself is too vague and imprecise to warrant use. For example, do you mean representative load,' 'overload,' 'high load,' etc. In performance testing, load is varied f rom a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions >suffer (application-specific) excessive delay. A third use of the term is as a test whose objective is to determine the maximum sustainable load the system can handle. In this usage, 'load testing' is merely testing at the highest transaction arrival rate in performance testing. 125. What's the difference between QA and testing? QA is more a preventive thing, ensuring quality in the company and therefore the product rather than just testing the product for software bugs? TESTING means 'quality control' QUALITY CONTROL measures the quality of a product QUALITY ASSURANCE measures the quality of processes used to create a quality product. 126. What is the best tester to developer ratio? Reported tester: developer ratios range from 10:1 to 1:10. There's no simple answer. It depends on so many things, Amount of reused code, number and type of interfaces, platform, quality goals, etc. It also can depend on the development mo del. The more specs, the less test ers. The roles can play a big part also. Does QA own beta? Do you include process auditors or planning activities? These figures can all vary very widely depending on how you define 'tester' and 'developer'. In some organizations, a 'tester' is anyone who happens to be testing software at the time -- such as their own. In other organizations, a 'tester' is only a member of an independent test group. It is better to ask about the test labor content than it is to ask about the tester/developer ratio. The test labor content, across most applications is generally accepted as 50%, when peo ple do honest accounting. For life-critical software, this can go up to 80%. 127. How can new Software QA processes be introduced in an existing organization? - A lot depends on the size of the organizattion and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary. - Where the risk is lower, management and orrganizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity s o as to keep
bureaucracy from getting out of hand. - For small groups or projects, a more ad-hooc process may be appropriate, depending on the ty pe of customers and projects. A lot will depend o n team leads or managers, feedback to deve lopers, and ensuring adequate communications among customers, managers, developers, and testers. - In all cases the most value f or effort willl be in requirements management processes, with a goal of clear, complete, testable requirement specifications or expectations.
128. What are 5 common problems in the software development process? 1. poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems. 2. unrealistic schedule - if too much work is crammed in too little time , problems are inevitable. 3. inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash. 4. featuritis - requests to pile on new features after development is underway; extremely common. 5. miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are guaranteed. 129. What are 5 common solutions to software development problems? 1. solid requirements - clear, complete, detailed, cohesive, attainable, t estable requirements that are agreed to by all players. Use p rototypes to help nail down requirements. 2. realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out. 3. adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. 4. stick to initial requirements as much as possible - be prepared to defend against changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, use rapid prototyping during the design phase so that customers can see what to ex pect. This will provide them a higher comfort level with their requirements decisions and minimize changes later on. 5. communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - e-mail, groupware, networked bug-tracking tools and change management tools, intranet capabilities, etc.; insure that documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use prototypes early on so that customers' expectations are clarified.
130. What is 'good code'? 'Good code' is code that works, is bug free, and is readable and maintainable. Some organi zations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity . 'Peer reviews', 'buddy checks' code analysis tools, etc. can be used to check f or problems and enforce standards. For C and C++ coding, here are some ty pical ideas to consider in setting rules/standards; these may or may not apply to a particular situation: - minimize or eliminate use of global variabbles. - use descriptive function and method names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be a dequately descriptive (use of more t han 20 characters is not out of line); be consistent in naming conventions. - use descriptive variable names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions. - function and method sizes should be minimiized; less than 100 lines of code is good, less than 50 lines is preferable. - function descriptions should be clearly sppelled out in comments preceding a function's code. - organize code for readability. - use whitespace generously - ve rtically andd horizontally - each line of code should contain 70 characcters max. - one code statement per line. - coding style should be consistent t hroughtt a program (eg, use of brackets, i ndentations, naming conventions, etc.) - in adding comments, err on the side of tooo many rather t han too few comments; a common rule of thumb is that there should be at least as many lines of comments (including header blocks) as lines of code. - no matter how small, an application shouldd include documentaion of the overall program function
and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation. - make extensive use of error handling proceedures and status and error logging. - for C++, to minimize complexity and increaase maintainability, avoid too many levels of inheritance in class heirarchies (relative to the size and complexity of the application). Minimize use of multiple inheritance, and minimize use of operator overloading (note t hat the Java programming language eliminates multiple inheritance and operator overloading.) - for C++, keep class methods small, less t hhan 50 lines of code per method is preferable. - for C++, make liberal use of exception hanndlers
131. What is 'good design'? 'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented. Good fu nctional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. For programs that have a user interface, it's often a good idea to assume that the end user will have little computer knowledge and may not read a user manual or even the on-line help; some common rules-of-thumb include: - the program should act in a way that leastt surprises the user - it should always be evident to the user whhat can be done next and how to exit - the program shouldn't let the users do sommething stupid without warning them. 132. What makes a good test engineer? A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, an d reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk areas of an application on which to focus tes ting efforts when time is limited.
133. What makes a good Software QA engineer? The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development p rocess and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in th e early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to fin d problems as well as to see 'what's mi ssing' is important for inspections and reviews. 134. What makes a good QA or Test manager? A good QA, test, or QA/Test(combined) manager should: - be familiar with the software development process - be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative' process (e.g., looking for or preventing p roblems) - be able to promote teamwork to increase productivity - be able to promote cooperation between sof tware, test, and QA engineers - have the diplomatic skills needed to promote improvements in QA processes -have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to - have people judgment skills for hiring and keeping skilled personnel - be able to communicate with technical and non-technical people, engineers, managers, and customers. - be able to run meetings and keep them focused 135. What's the role of documentation in QA? Critical. (Note that documentation can be electronic, not n ecessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, use r manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible. 136. What's the big deal about 'requirements'?
One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. Requirements are t he details describing an application's externally-perceived functionality and properties. Requirements sh ould be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A te stable requirement would be something like 'the user must enter their previously-assigned password to access the application'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. 'Customers' could be i n-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible. Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as ' The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be t raceable back to the requirements. In some organizations requirements may end u p in high level project plans, f unctional specification documents, in design documents, or in ot her documents at various levels of det ail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
137. What steps are needed to develop and run software tests? The following are some of the ste ps to consider: - Obtain requirements, functional design, annd internal design specifications and other necessary documents - Obtain budget and schedule requirements - Determine project-related personnel and thheir responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.) - Identify application's higher-risk aspectss, set p riorities, and determine scope and limitations of tests - Determine test approaches and methods - unnit, integration, functional, system, load, usability tests, etc. - Determine test environment requirements (hhardware, software, communications, etc.) -Determine testware requirements (record/plaayback tools, coverage analyzers, test tracking, problem/bug tracking, etc.) - Determine test input data requirements - Identify tasks, those responsible for taskks, and labor requirements - Set schedule estimates, timelines, mi lestoones - Determine input equivalence classes, bounddary value analyses, error classes - Prepare test plan document and have neededd reviews/approvals - Write test cases - Have needed reviews/inspections/approvals of test cases - Prepare test environment and testware, obttain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking p rocesses, set up logging and archiving processes, set up or obtain test i nput data - Obtain and install software releases - Perform tests - Evaluate and report results - Track problems/bugs and fixes - Retest as needed - Maintain and update test plans, test casess, test environment, and testware through life cycle 138. What is 'configuration management'? Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, an d who makes the changes. 139. What if the software is so buggy it can't really be tested at all? The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with t he focus being on critical bugs. Since this ty pe of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, im proper
build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem.
140. How can it be known when to stop testing? This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are: - Deadlines (release deadlines, testing deadlines, etc.) - Test cases completed with certain percentage passed - Test budget depleted - Coverage of code/functionality/requirements reaches a specified point - Bug rate falls below a certain level > - Beta or alpha testing period e nds 141. What if there isn't enough time for t horough testing? Use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense , and experience. (If warranted, formal methods are also available.) Considerations can include: - Which functionality is most important to the project's intended purpose? - Which functionality is most visible to the user? - Which functionality has the largest safety impact? - Which functionality has the largest financial impact on users? - Which aspects of the application are most important to the customer? - Which aspects of the application can be teste d early in the development cycle? - Which parts of the code are most complex, and thus most subject to errors? - Which parts of the application were dev eloped in rush or panic mode? - Which aspects of similar/related previous projects caused problems? - Which aspects of similar/related previous projects had large maintenance expenses? - Which parts of the requirements and design are unclear or poorly thought out? - What do the developers think are the highest-risk aspects of the application? - What kinds of problems would cause the worst publicity? - What kinds of problems would cause the most customer service complaints? - What kinds of tests could easily cover multiple functionalities? - Which tests will have the best high-risk-coverage to time-required ratio? 142. What can be done if requirements are changing continuously? A common problem and a major headache. - Work with the project's stakeholders earlyy on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible. - It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch. - If the code is well-commented and well-doccumented this makes changes easier for the developers. - Use rapid prototyping whenever possible too help customers feel sure of their requirements and minimize changes. - The project's initial schedule should alloow for some extra time commensurate with the possibility of changes. - Try to move new requirements to a 'Phase 22' version of an application, while using the original requirements for the 'Phase 1' version. - Negotiate to allow only easily-implementedd new requirements into the project, while moving more difficult new requirements into future versions of the application. - Be sure that customers and management undeerstand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not t he developers or testers) decide if the changes are warranted - after all, that's their job. - Balance the effort put into setting up auttomated testing with the expected effort required to redo them to deal with changes. - Try to design some flexibility into automaated test scripts. - Focus initial automated testing on applicaation aspects that are most likely to remain unchanged. - Devote appropriate effort to risk analysiss of changes to minimize regression testing needs. - Design some flexibility into test cases (tthis is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans) - Focus less on detailed test plans and testt cases and more on ad hoc testing (with an understanding of the added risk that this entails).
143. What if the project isn't big enough to justify extensive testing? Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as d escribed previously in 'What if there isn't enough time for thorough testing?' apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis. 144. What if the application has functionality that wasn't in t he requirements? It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems i n the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may not be a significant risk. 145. How can Software QA processes be implemented without stifling productivity? By implementing QA processes slowly over time, usin g consensus to reach agreement on processes, and adjusting and experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burnout will decrease, and there will be improved focus and less wasted effort. At t he same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimi ze time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or bureacracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug-fixing and calming of irate customers. 146. What if an organization is growing so f ast that fixed QA processes are impossible? This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this situation, other than: - Hire good people - Management should 'ruthlessly prioritize' quality iss ues and maintain focus on the customer - Everyone in the organization should be cleear on what 'quality' means to the customer 147. How does a client/server environment affect testing? Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing. 148. How can World Wide Web sites be tested? Web sites are essentially client/server applications - with web servers and 'browser' clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes sig nificant differences between them, variations in connection speeds, rapidly c hanging technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort. Other considerations might include: - What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can b e adapted, web robot downloading tools, etc.)? - Who is the target audience? What kind of bbrowsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)? - What kind of performance is expected on thhe client side ( e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)? - Will down time for server and content mainntenance/upgrades be allowed? how much? - What kinds of security (fi rewalls, encrypttions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
- How reliable are the site's Internet conneections required to be? And how does that affect backup system or redundant connection requirements and testing? - What processes will be required to manage updates to the web site's conte nt, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.? - Which HTML specification will be adhered tto? How strictly? What variations will be allowed for targeted browsers? - Will there be any standards or requirementts for page appearance and/or graphics throughout a site or parts of a site?? - How will internal and external links be vaalidated and updated? how often? - Can testing be done on the production systtem, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and realworld internet 'traffic congestion' problems to be accounted for in testing? - How extensive or customized are t he serverr logging and reporting requirements; are t hey considered an integral part of the system and do they require testing? - How are cgi programs, applets, javascriptss, ActiveX components, etc. to be maintained, tracked, controlled, and tested? - Pages should be 3-5 screens max unless conntent is tightly focused on a single topic. If larger, provide internal links within the page. - The page layouts and design elements shoulld be consistent throughout a site, so that it's clear to the user that they're still within a site. - Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type. - All pages should have links external to thhe page; there should be no dead-end pages. - The page owner, revision date, and a link to a contact person or organiza tion should be included on each page.
149. How is testing affected by object-oriented designs? Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-designed this can simplify test design. 150. What is Extreme Programming and what's it got to do with testing? Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable requirements. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained'. Testing ('extreme testing') is a core aspect of Extreme Programming. Programmers are expected to write unit and functional test code first - before the application is developed. Test code is under source control along with the rest of the code. Customers are expected to be an integral part of the project team and to help develope scenarios for acceptance/black box testing. Acceptance tests are preferably automated, and are modified a nd rerun for each of the frequent development iterations. QA and test personnel are also required to be an integral part of the project team. Detailed requirements documentation is not used, and frequent re-scheduling, re-estimating, and re-prioritizing is expected. 151. Will automated testing tools make testing easier? - Possibly. For small projects, the time needed to learn and implement them may not be worth it. For larger projects, or on-going long-term projects they can be valuable. - A common type of automated tool is the 'record/playback' type. For example, a tester could click through all combinations of menu choices, dialog box choices, buttons, etc. i n an application GUI and have them 'recorded' and the results logged by a tool. The 'recording' is typically in the form of text based on a scripting language that is interpretable by the testing tool. If new buttons are added, or some underlying code in the application is changed, etc. the application can then b e retested by just 'playing back' the 'recorded' actions, and comparing the logging results to check effects of the changes. The problem with such tools is that if there are continual changes to the system being tested, the 'recordings' may have to be changed so much that it becomes very time-consuming to continuously update the scripts. Additionally, interpretation of results (screens, data, logs, etc.) can be a difficult task. Note that there are record/playback tools for text-based interfaces also, and for all types of platforms. - Other automated tools can include: code analyzers - monitor code complexity, adherence to standards, etc. coverage analyzers - these tools check which parts of the code have been exercised by a test, and may be oriented to code statement coverage, condition coverage, path coverage, etc. memory analyzers - such as bounds-checkers and leak detectors.
load/performance test tools - for testing client/server and web applications under various load levels. web test tools - to check that links are valid, HTML code usage is correct, client-side and server-side programs work, a web site's interactions are secure. other tools - for test case management, documentation management, bug reporting, and configuration management.
151. What's the difference between black box and white box testing? Black-box and white-box are test design methods. Black-box test design treats the system as a “black-box”, so it doesn't explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional re quirements. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box. White-box test d esign allows one to peek inside the “box”, and it focuses specifically on using internal knowledge of the software to guide the selection of test data. Synonyms for whit e-box include: structural, glass-box and clear-box. While black-box and white-box are terms that are still in popular use, many people prefer the terms 'behavioral' and 'structural'. Behavioral test design is slightly different f rom black-box test design because the use of internal knowledge is n't strictly forbidden, but it's sti ll discouraged. In practice, it hasn't proven useful to use a single test design method. One has to use a mixture of different methods so that they aren't hindered by the limitations of a particular one. Some call this 'gray-box' or 'translucent-box' test design, but others wish we'd stop talking about boxes altogether. It is important to understand that these methods are used during the test design phase, and their influence is hard to see in the tests once they're implemented. Note that any level of testing (unit testing, system testing, etc.) can use any test design methods. Unit testing is usually associated with structural test design, but this is because testers usually don't have well-defined requirements at the unit level to validate. 152. 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 un less 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 ind ependent 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 teste rs. 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 oth er hardware, applications, or systems if appropriate. sanity testing or smoke 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 corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state. regression testing - re-testing after f ixes 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 f or this type of testing. acceptance testing - final testing based o n 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 n umerical values, large complex queries to a database system, etc. performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA 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 teste rs 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. failover testing - typically used interchangeably with 'recovery testing' 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. context-driven testing - testing driven by an understanding of the environment, culture, and intended use of software. For e xample, the testing approach for life -critical medical equipment software would be completely different than that for a low-cost computer game. 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.
151. Why is it often hard for management to get serious about quality assurance? Solving problems is a high-visibility process; preventing problems i s low-visibility. This is illustrated by an old parable: In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, "I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords." "My elder brother cures sickness when it just begins to take root, and his skills are k nown among the local peasants and neighbors." "My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home." 152. Why does software have bugs? 1. Miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements). 2. Software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Multi-tiered applications, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. programming errors - programmers, like anyone else, can make mistakes. 3. Changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and t he complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business
environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control. 3. Poorly documented code - it's tough to maintain and modify code t hat is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, mai ntainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read'). 4. software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.
153. How can new Software QA processes be introduced in an existing organization? A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary. Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with producti vity so as to keep bureaucracy from getting out of hand. For small groups or projects, a more ad-hoc process may be appropriate, depe nding on the type of customers and projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications among customers, managers, developers, and testers. The most value for effort will often be in (a) requirements management processes, with a goal of clear, complete, testable requirement specifications embodied in requirements or design documentation, or in 'agile'-type environments extensive continuous coordination with end-users, (b) design inspections and code inspections, and (c) post-mortems/retrospectives.
GROUP 1 QUESTIONS 1. 2. 3. 4.
In your own words briefly define what is meant by software verification Briefly explain the approaches to verification Explain the experimental test of software verification Explain integration and functional testing aspect of software verification
SOLUTION (1) Software verification is a software engineering practise that is carried out through the developmental cycle of the software product which is targeted at ensuring that software produced meet specified requirement and specification defined in the development document. Some of the needs for software verification are listed below 1.
To ensure that the customer’s desires as stated in the requirement and specification document are fully implemented in the software.
2. To provide a predictable functionality of the software system when delivered to the customer For software to fully meet its specification, several defects like faults, errors, bugs, and failures and other anomalies has to be identified and eliminated. So indirectly software verification collaborates with (or comprises) other techniques like testing and debugging to achieve its goals. Simply put “Software verification means developing software in the right way.” The verification of software encompasses correctness, consistency and other attributes that can show that software has been developed in the right way. During verification faults, bugs and other defects and anomalies are identified and removed for the software to conform to its specifications. (2)
The approaches to software verification are i.
Dynamic verification
ii.
Static verification
DYNAMIC VERIFICATION: This encompasses testing / experimentation and it is a verification approach that periodically checks the software being produce, at each stage of development, with the requirement defined. In Dynamic Verification, there is every possibility that the behaviour of the system or the deliverables at each stage
doesn’t conform to that expected as a result of defects, this need to be identified and removed. The following activities are performed in dynamic verification i. ii. iii.
Execution of software system up to the point reached in development process. Selection of valid test cases/ input which consist of test data Examining the output to ensure that it results from the input data
Dynamic verification is target and ensuring that the software system meets it specifications and requirement by fixing all the bugs and anomalies which may prohibit this and requesting that the actions needed to fix them are taken. It encompasses the following testing: unit, module, integration, functional testing e.t.c. This verification approach has a great advantage in that it can easily identify defects because it involving the running of part of the whole system. STATIC VERIFICATION: This is an approach of software verification that ensures that software product conforms to the specified requirement, as stated in the specification and requirement document, by performing a physical inspection, work-through and review of the software system. This could be applied as various stage of the software development like requirement, design, test data etc, An advantage of this is that it can be used even before the executable version of the software is developed. Static verification encompasses what is known as program proving. The approaches to static verification are i. ii. iii.
Formal verification Model checking Automated static analyser
Formal Verification: This involves the use of strong and rigorous mathematical argument and constructs to show that software conforms to its specification. We can simply say that it depends on the use of formal methods to show that software is correct. Model Checking: This involves the building the model of the system the checking the model’s correctness specialised tools. The behaviour of the system could be modelled through the help of the finite state machine, where all the states and state transition are identified in the system. Automatic static Analyser: This approach assumes that there are some common errors found in different programming language, this could be collected in a list and then an
automated process could then check the program codes against this list of errors. This is a good approach to easy finding bugs like syntactic errors in programs. But can only identify those bugs listed. (3) Experimental Test of Dynamic verification is simply choosing some valid test cases (containing test data) as inputs and passing it to the program or software. We then examine the output to know whether it results out of the input and that it confirms to the specification in the development document. In other words, it implies showing that the software product produces valid output which results from the input supplied to it.
VALID INPUT
PROGRAM
VALID OUTPUT
(4) Integration Testing is a testing process which involves checking that all software components and modules work in interoperable manner, that is, it checks that modules really provide the correct interfaces needed for other modules to interoperate with it and that the right set of data are passed between modules. This is a kind of White Box Testing because the tester is expected to be knowledgeable in the program code But functional testing involves identifying and testing all the functionality which the system is expected to provide, as specified in the specification document, by supplying valid input cases to the software and examining the output, whether is the expected not. This kind of testing is BLACK BOX TESTING because the tester is not expected to be knowledgeable of program code. The tester just passes in
GROUP 2 1. Why is it that software debugging takes 60% - 70% of the overall development time 2. In your own words explain brief five major debugging techniques Debugging by printing (tracing) The most common debugging technique is monitoring, in which in applications programming is done by calling printf at suitable points. Debugging by querying The debugging by printing has a disadvantage that massive use of print statements can slow down the system noticeably. The best way to get relevant information is to query the system when you need information, instead of continually producing data. Debugging by Watching Sometimes minor problems can be tracked down by watching the behavior of an application in user space. Watching programs can also help in building confidence that a driver is working correctly. There are various ways to watch a user-space program working. You can run a debugger on it to step through its functions, add print statements, or run the program under trace. Using the compiler’s features A good compiler can do a great deal of static analysis of your code: the analysis of those aspects of a piece of code that can be studied without executing that code. Static analysis can help in detecting a number of basic semantic problems such as type mismatches and dead code. Remote Debugging This is the process of debugging a program running on a system different than the debugger. To start remote debugging, debugger connects to a remote system over a network. Once connected, debugger can control the execution of the program on the remote system and retrieve information about its state. Post-mortem debugging This is debugging of the program after it has already crashed. Related techniques often include various tracing techniques, analysis of memory dump (or core dump) of the crashed process. The dump of the process could be obtained automatically by the system (for example, when process has terminated due to an unhandled exception), or by a programmer-inserted instruction, or manually by the interactive user. 3. Explain how automatic debugging is different from other debugging One common limitation of manual debugging is their reliance on a set of strong assumptions on how developers behave when debugging.
Automatic debugging is real time in its approach. They help identify system or application faults as soon as they stop responding. Here the automatic debugger creates a crash dump file when the system or application stops responding. The file can later be examined by the developers. 4. Can we refer users as testers Yes. User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing. Users are involved in Alpha testing, Beta testing, Acceptance testing. 5. Distinguish between black and white box test Black box testing is a testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. White box testing is a testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester. Black Box Testing
White Box Testing
Mainly applicable during system testing
Mainly applicable during unit testing, Acceptance testing, integration testing
Done by software testers
Usually done by developers
Programming knowledge not required
Programming knowledge required
Implementation knowledge not required
Implementation knowledge required
Basis for test – requirement specification
Basis for test – Detailed Design
6. What are the differences between software debugging, testing and verification Debugging: The process of debugging involves analyzing and possibly expanding (with debugging statements) the given program that does not meet the specification in order to find a new program that is close to the original and does satisfy the specification. Thus it is the process of “diagnosing the precise nature of a known error and then correcting it” Debugging = diagnosis Debugging = error finding and fixing Debugging is done by developers Debuggers fix the errors Debugging = done in development phase Debugging = white box testing
In contrast, given a program, and a set of specification, verification is the process of proving or demonstrating that the program correctly satisfies the specification. Verification = functional correctness. Verification can be done by customers Whereas verification proves conformance with a specification, testing finds cases where a program does not meet its specification. Based on this definition, any activity that exposes the program behavior violating a specification can be called testing. Testing = trying to break the program Testing is done by testers Testers don’t fix problems but return it t o programmer’s for fixing. Testing is done in the testing phase Testing = black box testing Testing does not show the absence of error but the presence Testing does not include efforts associated with tracking down bugs and fixing them Testing doesn’t ensure quality 7. If symbolic execution could not handle non-linear problems what method do we use We could formal methods like the Hoare Triple. 8. Differentiate among various debugging execution types Forward Symbolic Execution: This begins execution at the start of main Shortest-distance Symbolic Execution(SDSE): This priorities the path with the shortest distance to the target line as computed over an inter-procedural control flow graph Call-chain backward Symbolic Execution(CCBSE): this will start at the target li ne and work backward until it finds a realizable path from the start of the program, using standard forward (inter-procedural ) symbolic execution as a subroutine Mixed-strategy call-chain backward (mixed – CCBSE) Symbolic execution: this combines CCBSE with another forward search. Here we alter CCBSE with some forward search strategy S.
GROUP 3 1. What do you mean by quality of conformance? Quality of conformance is the degree to which the design specifications are followed during production. The greater the degree of conformance, the higher is the level of quality of conformance. 2. What are the components of quality of design? Requirements Quality of Design Encompasses:
Specifications
Design of the System Side note:
Quality of design refers to the characteristics that designers specify for an item. The grade of materials, tolerances, and performance specifications all contribute to the quality of design. As higher-grade materials are used, tighter tolerances and greater levels of performance are specified, the design quality of a product increases, if the product is manufactured according to specifications.
3. What are the components of user satisfaction? User Satisfaction = Compliant Product + Good Quality + Delivered within Budget and Schedule
4. *Define a Mathematical Proof of Correctness for Software Quality Assurance Skipped
5. What is the Significance of Software Review? Software reviews are a "filter" for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors and defects that can then be removed. Software reviews "purify" the software engineering activities that we have called analysis, design, and coding.
6. State the Measures of Reliability and Availability A simple measure of reliability is meantime-between-failure (MTBF), where: MTBF = MTTF + MTTR
The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to-repair, respectively. In addition to a reliability measure, we must develop a measure of availability. Software availability is the probability that a program is operating according to requirements at a given point in time and is defined as: Availability = [MTTF/ (MTTF + MTTR)] × 100%
Group 4 1. Failure intensity is the failure occurring with respect to time and it is the alternative way of expressing software reliability. 2.
3. A failure corresponds to unexpected runtime behavior observed by a user of the software. A fault is a static software characteristic which causes a failure to occur.
4. Whenever we want to predict software reliability, we need to choose the best growth model for the system under consideration since several exist. Some
common models are Musa Basic Model, Musa-Okumoto Model, JelsinskyMoranda Model, Littlewood Verrall Model, and Rayleigh Model. After selecting the appropriate model, one need to then take into consideration the various assumptions under the selected model. After that, we can start observing system’s behavior in order to get parameters in selected models’. We then use these parameters to calculate failure intensity (µ) and mean time to failure (MTTF). We can then draw conclusion on the expected system reliability from the value of µ and MTTF. The model that uses equation to determine values before predicting reliability is estimation while the one that often uses graphs is prediction. In conclusion no onereliability model is superior to the other since each has its strength and weakness.
GROUP 5 Group 5 Questions AND Answers 1. What are the conditions that can lead to project initiation? ANSWER: Project initiation can emanate from these three key sources such as: a) Managers and business units who want to replace or extend an existing system in order to gain needed information or to provide a new service to customers. b) Information systems managers who want to make a system more efficient, less costly to operate, or want to move a system to a new operating environment. c) Formal planning groups that want to improve an existing system in order to help the organization meet its corporate objectives, such as providing better customer service 2. Explain in brief the various Project Attributes ANSWER: Projects come in all shapes and sizes. The following attributes help us to define a project further: a) A project has a unique purpose. Every project should have a well-defined objective. For example, many people hire firms to design and build a new house, but each house, like each person, is unique. b) A project is temporary. A project has a definite beginning and a definite end. For a home construction project, owners usually have a date in mind when they’d like to move into their new homes. c) A project is developed using progressive elaboration or in an iterative fashion. d) A project requires resources, often from various areas. Resources include people, hardware, software or other assets. e) A project should have a primary customer or sponsor. Most projects have many interested parties or stakeholders, but someone must take the primary role of sponsorship. The project sponsor usually provides the direction and funding for the project.
f) Projects are often defined broadly when they begin, and as time passes, the specific details of the project become clearer. 3. Enumerate the constraint under which projects need to be performed and delivered ANSWER: Projects are performed and delivered under certain constraints, which are scope, time and cost. The time constraint refers to amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.
4. Distinguish between GANTT and PERT . ANSWER: 1. GANTT chart visually shows the duration of Tasks whereas a PERT chart visually shows the sequence dependencies between tasks. 2. GANTT visually shows the Time overlap of Tasks whereas a Network does not show time overlap but does show which tasks could be done in parallel. 3. Some form of GANTT chart can visually show Slack Time available within an Earliest Start and Latest finish time. 4. Most Project Managers find PERT very helpful for scheduling, monitoring and controlling Projects. 5. PERT is recommended for Large Projects with high inter-task dependencies and the GANTT chart for simpler Projects.
Group 6 1. Why is software maintenance the most costly aspect of software development life cycle : The maintenance phase of the software development life cycle is often the longest and the most expensive. After the software product has been released, the maintenance phase keeps the software up to date with environment changes and changing user requirements, also defects and bugs are fixed during this phase. It continues throughout the lifespan of the software application to ensure the value of the application is preserved over time. 2. Describe the three main causes of corrective maintenance: The 3 main causes of corrective maintenance are as follows: a. Design errors: these occur when changes made to the software are incorrect, incomplete, wrongly communicated or the change request is misunderstood. b. Logic errors: these result from invalid tests and conclusions, incorrect implementation of design specifications, faulty logic flow or incomplete test of data. c. Coding errors: these are caused by incorrect implementation of detailed logic design and incorrect use of the source code logic 3. Explain in brief software maintenance process Software Maintenance process is made up of the following phases: a. Problem/modification identification, classification, and prioritization: In this phase, software modifications are identified, classified, and assigned an initial priority ranking. b. Analysis: In this phase the repository information and the modification request validated in the previous phase, along with system and project documentation are used to study the feasibility and scope of the modification and preliminary plan for design, implementation, test, and delivery are devised. c. Design: In this phase, all current system and project documentation, existing software and databases, and the output of the analysis phase are used to design the modification to the system. d. Implementation: In this phase, the results of the design phase, the current source code, and project and system documentation (i.e., the entire system as updated by the analysis and design phases) are used to drive the implementation effort.
e. System testing: In this phase, system testing e.g. regression r egression testing is performed on the modified system to validate v alidate that the modified code does not introduce i ntroduce faults that did not exist prior to the maintenance activity. f. Acceptance testing: In this phase, acceptance tests are conducted on a full y integrated system either by the customer, the user of the modification package, or a third party designated by the customer. g. Delivery: This sub-clause describes the requirements for the delivery of a modified software system. 4. Software maintenance tools Software Maintenance tools can be defined as anything functional that can assist the software maintainer in addressing maintenance problems. CASE (ComputerAided Software Engineering) tools are used in the phases of software development life cycle, while CAME (Computer. Assisted Software Measurement and Evaluation) tools are used for code analysis and measurement. E.g. VIFOR 2, xVue, RETIRE, VIFOR 2. 5. Software maintenance problems: The major problems associated with software maintenance include: the need for more mo re effective software maintenance tools a lack of software documentation, the low status of maintainers, and software designed without maintenance in view (Note: these problems are discussed fully i n the documentation if you want further details pls check the doc.).
6. How is P-type different from evolutionary system : P-type systems, or practical-type systems, practical-type systems, are those that can be described formally, but whose solutions are not immediately apparent. Such systems are not subject to evolution since their solutions are usually consistent with a given paradigm. Hence, they do not change with changing user requirements. On the other hand, evolutionary systems are systems that serve to model mo del real-world processes, and through their use, become a component of the world in which they intend to model. They are subject changing user requirements as a result of their nature. 7. Describe maintenance types a. Corrective Maintenance: Maintenance : this involves changing a software application to remove errors. Examples of errors corrected in this phase include design errors, logic errors, coding errors and defects. b. Adaptive Maintenance: Maintenance : this is any maintenance effort that is carried out as a result of changes in a software application’s operating environment. environment. Such
changes may include Rules, laws, and regulations that affect the application, Hardware configurations, File structures and data formats etc c. Perfective maintenance: Perfective maintenance is software maintenance implemented to improve the maintainability of software. It I t mainly deals with accommodating new or changed user requirements, functional enhancements to the system system and activities to increase the system’s performance. d. Preventive maintenance: is defined as maintenance performed for the purpose pu rpose of preventing problems before they happen.
GROUP 7
INTERNAL REUSE Use of company or self-built components
EXTERNAL REUSE Usage of components built by an external/3rd part firm
Cannot result in litigation from licensing issues
Many software litigation claims are due to improper license before usage of 3 rd part components
Less time is spent in understanding the components as it is built by the t he firm itself
Considerable time is spent in understanding the component and reading its documentation Considerable amount of paperwork and licensing is needed before permissions for modification can be granted. (most time such permissions are never granted)
Freely customizable as it is built by the firm, it can be reshaped as pleased
No cost is incurred(free)
Can be free or expensive but when used for commercial purposes they can get quite expensive
2. Merits and Demerits of Forked Reuse MERITS:
Easier and more direct approach Does not require full knowledge of the source except for the excerpt or snippet being used Isolated from the source hence more greater flexibility to change the reused code; as source will not be affected by modifications Easier packaging, deployment and version management.
DEMERITS Code duplication Every bug corrected in one copy will not be corrected in others (because they are disjointed) or else they become out of date.
3 i) METRIC BASED MODELS: This measures the amount or size of reuse by viewing reuse fro m a metric standpoint reuse hence can be measured in terms of LOC (Lines of code). ii)ECONOMIC MODELS: This measures reuse from an economic standpoint. The Impact of reuse is measured relative to the effort required to develop from all-new code. It can help organizations to estimate the trade-off btw proportion of reuse and the cost of developing and reusing components. Economic models show methods of improving cost-effectiveness of reuse based on the metric introduced e.g cost and benefits of reuse, the number of projects necessary for reuse to pay off can be calculated. 4. Just Explain OOP 5. overloading of Methods: Declaration of methods or functions with name that is same as an existing method but different signature as the already existing methods.
