This action might not be possible to undo. Are you sure you want to continue?
Q1. What is verification?
A: Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings. You CAN learn to do verification, with little or no outside help. Get CAN get free information. Click on a link!
Q2. What is validation?
A: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.
Q3. What is a walkthrough?
A: A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. It's the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individual's or team's competency.
Q4. What is an inspection?
A: An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection.
Q5. What is quality?
A: 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.
Q6. What is good code?
A: A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards.
Q7. What is good design?
A: Design could mean to many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. 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.
Q8. What is software life cycle?
A: Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.
Q9. Why are there so many software bugs?
A: Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development. • There are unclear software requirements because there is miscommunication as to what the software should or shouldn't do. • Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications. • Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
• As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too. • Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too. • Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made. • Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code, or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read. • Software development tools , including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.
Q10. How do you introduce a new software QA process?
A: It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable.
Q11. Give me five common problems that occur during software development.
A: Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication. 1. Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems. 2. The schedule is unrealistic if too much work is crammed in too little time. 3. Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes. 4. It's extremely common that new features are added after development is underway. 5. Miscommunication either means the developers don't know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.
Personnel should be able to complete the project without burning out.) that can be a time-consuming task. or ongoing long-term projects. Has an attention to detail. Use prototypes early on so customers' expectations are clarified and customers can see what to expect. networked bug-tracking tools. Has a strong desire for quality. And he Has previous software development experience. Require walkthroughs and inspections when appropriate. the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of the change. detailed. 3. and plan for sufficient time for both testing and bug fixing. 1. tools of change management. with little or no outside help. . For larger projects. All players should agree to requirements. realistic schedules. firm requirements and good communication. complete. make extensive use of e-mail. new buttons are added. adequate testing. Give me five solutions to problems that occur during software development. If changes are necessary. changes and documentation. Ensure documentation is available and up-to-date. A common type of automated tool is the record/playback type. logs. Have schedules that are realistic.Q12. clear. Do testing that is adequate. Be prepared to defend design against changes and additions. Q14. in a GUI and has an automated testing tool record and log the results.g. What makes a good test engineer? A: Rob Davis is a good test engineer because he • • • • • • • Has a "test to break" attitude. too. bug fixing. not paper. Get CAN get free information. You CAN learn to use automated testing tools. One problem with such tools is that if there are continual changes to the product being tested. He's also Tactful and diplomatic and Has good a communication skill. Avoid new features. Stick to initial requirements as much as possible. data. For example. a test engineer clicks through all combinations of menu choices. dialog box choices. But for small projects. 2. Communicate. cohesive. Do automated testing tools make testing easier? A: Yes and no. they can be valuable. this will minimize changes later on. etc. the recordings have to be changed so often that it becomes a very time-consuming task to continuously update the scripts. etc. Allow adequate time for planning. Takes the point of view of the customer. Another problem with such tools is the interpretation of the results (screens. Start testing early on. 4. re-testing. 5. testing. design. both oral and written. Use prototypes to help nail down requirements. ensure they're adequately reflected in related schedule changes. re-test after fixes or changes. the time needed to learn and implement them is usually not worthwhile. attainable and testable. The recording is typically in the form of text. or some underlying code in the application is changed). Ensure the requirements are solid. Promote teamwork and cooperation. once development has begun and be prepared to explain consequences. Use documentation that is electronic. A: Solid requirements. Click on a link! Q13. based on a scripting language that the testing tool can interpret. buttons. If a change is made (e.
it will be read thoroughly Q17. Short resumes -. resume readers do not like eye strain either. but we can start with these. Why? Because. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Five. then you should change it. It all depends on who you are and how much experience you have. you have accomplished one of the goals of resume distribution. If the resume isn't getting you interviews. there are lots of resumes out there these days. your resume should tell your story. The followings are some of the comments I have personally heard: "Well. gives the test engineer an appreciation for the developers' point of view and reduces the learning curve in automated test tool programming. here's another comment." "Gosh. The real audience for these short resumes is people with short attention spans and low IQ. What makes a good resume? A: On the subject of resumes. Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. I read a book and it said you should have a one page resume. but I don't want to break the rules. the resume needs to be longer. in light of the current scanning scenario. If you have a longer story." "I can't really go into what I really did because if I did. and that is also part of the problem. should my resume be more than one page? I feel like it should. a one-page resume is just fine. Generally speaking. Three. more than one page is not a deterrent because many will scan your resume into their database. So what's the answer? There is no scientific answer about whether a one-page resume is right or wrong. scanners don't like odd resumes. for one." "I'm confused. Additionally. "People just don't read resumes that are longer than one page." Or. If the resume is getting you interviews. take the point of view of the customer. What makes a good QA/Test Manager? A: QA/Test Managers are familiar with the software development process. If you're a college graduate looking for your first job. and I was told to never make the resume more than one page long. The purpose of a resume is to get you an interview. The first thing to look at here is the purpose of a resume." "Well. able to promote teamwork to . Once the resume is in there and searchable. good test engineers. Small fonts can make your resume harder to read. have a strong desire for quality and an attention to detail. Previous software development experience is also helpful as it provides a deeper understanding of the software development process. Four. We.are not appropriate.Good test engineers have a "test to break" attitude. Communication skills and the ability to understand various sides of issues are important. I assure you that when your resume gets into the right hands. they just throw it aside for one that is easier on the eyes. resume readers don't like to guess and most won't call you to clarify what is on your resume. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people.for people long on experience -. Two. The biggest mistake you can make on your resume is to make it hard to read. Joe Blow (car salesman) said I should have a one-page resume. Please put your experience on the resume so resume readers can tell when and for whom you did what. If the resume is mechanically challenging. Q15. Rob Davis'communication skills and the ability to understand various sides of issues are important. Big mistake. it'd take more than one page on my resume. there seems to be an unending discussion of whether you should or shouldn't have a one-page resume. I wish I could put my job at IBM on my resume but if I did it'd make my resume more than one page. What makes a good QA engineer? A: The same qualities a good test engineer has are useful for a QA engineer. Some candidates use a 7-point font so they can get the resume onto one page." I have heard some more. able to maintain enthusiasm of their team and promote a positive atmosphere. then it is considered to be a good resume. Q16.
Q19. Specifications. or event and its expected result. Care should be taken to involve all of a project's significant customers in the requirements process. so that they are repeatable. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly. for example. if possible. What is a test plan? A: A software project test plan is a document that describes the objectives. cohesive. business rules. inspection reports. some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. have the people skills needed to promote improvements in QA processes. approach and focus of a software testing effort. action. What about requirements? A: Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications.. In some organizations. customer management. configurations. Use documentation change management.. Ideally. complete. functional specification documents. Objective. Click on a link! Q20. future software maintenance engineers. test cases. No matter what they are called. have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to. Requirements should be clear. user manuals should all be documented. able to promote cooperation between Software and Test/QA Engineers. or other documents at various levels of detail. A test case should contain particulars such as a. attainable and testable. testers. in order to determine if a feature of an application is working correctly.increase productivity. but not so thorough that none outside the test group will be able to read it. "the product shall allow the user to enter their previously-assigned password to access the application". salespeople and anyone who could later derail the project. customer acceptance test engineers. code changes. The completed document will help people outside the test group understand the why and how of product validation. test plans. A non-testable requirement would be. A testable requirement would be something such as. Q21. Get CAN get free information. as well as able to run meetings and keep them focused. Requirements are the details describing an application's externally perceived functionality and properties. designs. 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. scope. which is too subjective. . Customers could be in-house or external and could include end-users. with little or no outside help. If his/her expectations aren't met. reasonably detailed. bug reports. What is a test case? A: A test case is a document that describes an input. able to communicate with technical and non-technical people. • • • Test case identifier. It should be thorough enough to be useful. You CAN learn to capture requirements. What is the role of documentation in QA? A: Documentation plays a critical role in QA. "user-friendly". design documents. they should be included as a customer. if possible. customer contract officers. there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. QA practices should be documented. Q18. requirements may end up in high-level project plans. Test case name.
A variety of commercial. insufficient integration testing. software.• • • Test conditions/setup. coordinate and track code. hardware. documentation. If a problem-tracking system is in place. that complete testing can never be done. for regression testing to check the fixes didn't create other problems elsewhere. e. Please note. will give the team complete information so developers can understand the bug.g. determinations should be made regarding requirements. safety impact. Rob Davis can easily adapt to your software tool and process needs. with the detailed input of software test engineers. etc. poor design. change requests. What if the software is so buggy it can't be tested at all? A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up. Input data requirements/steps. Common factors in deciding when to stop are. libraries. Test budget has been depleted. After the problem is resolved. designs. Additionally. or Beta or alpha testing period ends. tools. changes made to them and who makes the changes. get an idea of its severity.. Q25. What should be done after a bug is found? A: When a bug is found. fixes should be re-tested. Q24. Test cases completed with certain percentage passed.. and Expected results. testing deadlines. it should encapsulate these determinations. improper build or release procedures. These tools. compilers. What is configuration management? A: Configuration management (CM) covers the tools and processes used to control. patches. For this reason. the process of developing test cases can help find problems in the requirements or design of an application. . problem-tracking/management software tools are available. requirements. such as insufficient unit testing. reproduce it and fix it. release deadlines. Coverage of code. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process. Q22. Rob Davis has had experience with a full range of CM tools and concepts.. managers should be notified and provided with some documentation as evidence of the problem. problems. or requirements reaches a specified point. since it requires you to completely think through the operation of the application. How do you know when to stop testing? A: This can be difficult to determine. Q23. • • • • • • Deadlines. it is useful to prepare test cases early in the development cycle. Bug rate falls below a certain level. it needs to be communicated and assigned to developers that can fix it. if possible. functionality. Many modern software applications are so complex and run in such an interdependent environment. with the focus being on critical bugs.
or write up a limited test plan based on the risk analysis. What if there isn't enough time for thorough testing? A: Since it's rarely possible to test every possible aspect of an application.. The checklist should include answers to the following questions: • 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? Q27. allow for some extra time to commensurate with probable changes.. • Ensure the code is well commented and well documented. . so that later changes do not require redoing the application from scratch. if extensive testing is still not justified. • In the project's initial schedule. move more difficult. not the size of the project. common sense and experience. so that alternate test plans and strategies can be worked out in advance. this will help customers feel sure of their requirements and minimize changes. What can be done if requirements are changing continuously? A: Work with management early on to understand how requirements might change. The test engineer then should do "ad hoc" testing. Q28. risk analysis is again needed and the considerations listed under "What if there isn't enough time for thorough testing?" do apply. or everything that could go wrong.Q26. • Negotiate to allow only easily implemented new requirements into the project. • Use rapid prototyping whenever possible. It is helpful if the application's initial design allows for some adaptability. this makes changes easier for the developers. This requires judgment skills. • Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version. Use risk analysis to determine where testing should be focused. However. What if the project isn't big enough to justify extensive testing? A: Consider the impact of project errors. every dependency. risk analysis is appropriate to most software development projects. new requirements into future versions of the application. Additionally. try to. every possible combination of events.
How can software QA processes be implemented without stifling productivity? A: Implement QA processes slowly over time. • Design some flexibility into test cases. There is no easy solution in this situation. . in order to minimize regression-testing needs. promote computer-based processes and automated tracking and reporting. especially talented technical types. • Devote appropriate effort to risk analysis of changes. minimize paperwork. Then let management or the customers decide if the changes are warranted. no one. hire Rob Davis) Ruthlessly prioritize quality issues and maintain focus on the customer. minimize time required in meetings and promote training as part of the QA process. • • • Hire good people (i. it should be removed. this is not easily done. such as minor improvements in the user interface. other than. Everyone in the organization should be clear on what quality means to the customer. Productivity will be improved instead of stifled. Panics and burnout will decrease and there will be improved focus and less wasted effort. inherent risks and costs of significant requirements changes.e. the best bet is to minimize the detail in the test cases. attempts should be made to keep processes simple and efficient. • Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails. design information will be needed to determine added testing needs or regression testing needs. • Focus initial automated testing on application aspects that are most likely to remain unchanged. Q31. as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. Q29.. However. What if the application has functionality that wasn't in the requirements? A: It may take serious effort to determine if an application has significant unexpected or hidden functionality. What if organization is growing so fast that fixed QA processes are impossible? A: This is a common problem in the software industry. like bureaucracy 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. At the same time. or set up only higher-level generic-type test plans. • Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes. If not removed. it may not be a significant risk. If the functionality only affects areas. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. especially in new technology areas. that's their job. but less time will be required for late-night bug fixing and calming of irate customers.. • Design some flexibility into automated test scripts. after all. which it would indicate deeper problems in the software development process. Q30. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality isn't necessary to the purpose of the application. Problem prevention will lessen the need for problem detection.• Ensure customers and management understand scheduling impacts.
standards and templates and test readiness reviews. is oriented to *prevention*. Q33. when Rob Davis does it. feedback to developers and communications among customers. Prevention is monitoring and improving the process. For more information. It involves the entire software development process. Once Rob Davis has learned and reviewed customer's business processes and procedures. Verify the design meets the requirements and is complete (specifies all relationships between modules. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary). he will follow them. when performed by Rob Davis. is also oriented to *detection*. making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. I/O devices and quick enough runtime for the final product. 1. How is testing affected by object-oriented designs? A: A well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. which include a mix of test engineers. A lot will depend on team leads or managers. Verify the design incorporates enough memory. efficient. compact.com Q35.. Q36. It depends on what best fits your organization's size and business structure. testable and maintainable. Sometimes they're the combined responsibility of one group or individual. what happens in exceptional circumstances. Rob Davis can provide QA and/or Software QA.. starting state of each module and how to guarantee the state of each module). They also ensure a process is repeatable. Process and procedures . with overall QA processes monitored by project managers. Why do you recommended that we test during the design phase? A: Because testing during the design phase can prevent defects later on.Q32.why follow them? A: Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. managers. developers' test engineers and testers. He will also recommend improvements and/or additions. 2. What is software quality assurance? A: Software Quality Assurance. If the application was well designed this can simplify test design. Rob Davis' QA service depends on the customers and projects. how to pass data. . Software Testing. Also common are project teams. Testing involves the operation of a system or application under controlled conditions and evaluating the results. This document details some aspects of how he can provide software testing/QA service. Verify the design is good. testers and developers who work closely together. Organizations vary considerably in how they assign responsibility for QA and testing. e-mail rob@robdavispe. white-box testing can be oriented to the application's objects. Q34. We recommend verifying three things. What is quality assurance? A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures.
Q39. Q38. User interviews. Q44. Q40. he documents the results. Programmers and developers are usually not appropriate as usability testers. It also helps in learning where information is located. Each level of testing is either considered black or white box testing. He will also recommend improvements and/or additions. . Standards and templates maintain document uniformity. with standards and templates. What is black box testing? A: Black box testing is functional testing. Lastly. not based on any knowledge of internal software design or code. Q43.what is supposed to be in a document? A: All documents should be written to a certain standard and template. What is usability testing? A: Usability testing is testing for 'user-friendliness'. What is functional testing? A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers *should* perform functional testing. he will use them. information will not be accidentally omitted from a document. branches. What are the different levels of testing? A: Rob Davis has expertise in testing at all testing levels listed below. Standards and templates . At each test level. Black box testing are based on requirements and functionality. Unit testing is performed after the expected test results are met or differences are explainable/acceptable. What is white box testing? A: White box testing is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements. video recording of user sessions and other techniques can be used. making it easier for a user to find what they want. paths and conditions. Clearly this is subjective and depends on the targeted end-user or customer. What is unit testing? A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Once Rob Davis has learned and reviewed your standards and templates. Q42. What is parallel/audit testing? A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.Q37. surveys. Q41.
using network communication. This may require that various aspects of an application's functionality are independent enough to work separately. software engineers. Before system testing. What is end-to-end testing? A: Similar to system testing. What is system testing? A: System testing is black box testing. Expected results from the baseline are compared to results of the software under test. application. What is incremental integration testing? A: Incremental integration testing is continuous testing of an application as new functionality is recommended. All discrepancies are highlighted and accounted for. Upon completion of integration testing. System testing simulates real life scenarios that occur in a "simulated real life" test environment and test all functions of the system that are required in real life. or that test drivers are developed as needed. performed by the Test Team. and at the start of the system testing the complete system is configured in a controlled environment. with little or no outside help. Integration testing is black box testing. the *macro* end of the test scale is testing a complete application in a situation that mimics real world use.Q45. Q50. when actual results and expected results are either in line or differences are explainable/acceptable based on client input. all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved. What is sanity testing? A: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. or interacting with other hardware. This type of testing may be performed by programmers. This activity is carried out by the test team. or test engineers. Get CAN get free information. such as interacting with a database. What is integration testing? A: Upon completion of unit testing. This level of testing is a subset of . You CAN learn system testing. system testing is started. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Q47. Integration testing is considered complete. What is regression testing? A: The objective of regression testing is to ensure the software remains intact. Q49. Q46. before all parts of the program are completed. based on client input. before testing proceeds to the next level. Click on a link! Q48. integration testing begins. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable. A baseline set of data and scripts is maintained and executed to verify changes introduced during the release have not "undone" any previous code. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels. The purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed. Test cases are developed with the express purpose of exercising the interfaces between the components. or system.
Q56. or install/uninstall processes. Performance testing verifies loads. What is load testing? A: Load testing is testing an application under heavy loads. Q58. Q53. printers. What is comparison testing? A: Comparison testing is testing that compares software weaknesses and strengths to those of competitors' products. The installation test for a release is conducted with the objective of demonstrating production readiness. When necessary. application servers. it is conducted with the full support of the project team. or willful damage. partial. This test includes the inventory of configuration items. or other catastrophic problems. however. Q54. etc. as defined by requirements. such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail. a sanity test is performed. it can be regarded as a distinct level of testing. following installation testing. Q57. What is performance testing? A: Although performance testing is described as a part of system testing. What is compatibility testing? A: Compatibility testing is testing how well software performs in a particular hardware. What is installation testing? A: Installation testing is testing full. volumes and response times. and dynamic tests focused on basic system functionality. Q51. performed by the application's System Administration. Q55. or network environment. hardware failures. The test . It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database. This type of testing usually requires sophisticated testing techniques. What is recovery/error testing? A: Recovery/error testing is testing how well a system recovers from crashes. operating system. Q52. upgrade. What is security/penetration testing? A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access. What is acceptance testing? A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager. the evaluation of data readiness. software.regression testing.
• Give you the evidence that your software is correct and operates properly. Depending on the project. scripts and generate data. System Administrator. Test Build Manager and Test Configuration Manager. Q59. Technical Analyst. • Maximize the value of your software. Minor design changes can still be made as a result of alpha testing.. We also. . We execute test procedures and scripts. We. procedures. • Maximize the value of the devices that use it. test engineers. Q61. before users get discouraged. communicates testing status to management and manages the test team. before shareholders loose their cool and before employees get bogged down. • Improve problem tracking and reporting. What is beta testing? A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. • Assure the successful launch of your product by discovering bugs and design flaws. Test Engineers.team also works with the client/customer/project manager to develop the acceptance criteria. Test/QA Manager. • Promote continual improvement. Q60. • Speed up the work of the development staff. What is alpha testing? A: Alpha testing is testing of an application when development is nearing completion. Test Build Manager and Test Configuration Manager. Q63. What testing roles are standard on most testing projects? A: Depending on the organization. or test engineers. create test cases. Test Engineers may also wear the hat of Technical Analyst. What is a Test/QA Team Lead? A: The Test/QA Team Lead coordinates the testing activity. Click on a link! Q62. • Reduce your organization's risk of legal liability. Beta testing is typically performed by end-users or others. analyze standards of measurements. software engineers. so the development team can devote its time to build up your product. one person may wear more than one hat. You CAN get a job in testing. evaluate results of system/integration/regression testing. • Help the work of your development staff. For instance. Test/QA Team Lead. software engineers.. not programmers. What is a Test Engineer? A: Test Engineers are engineers who specialize in testing. not programmers. Database Administrator. or test engineers. Alpha testing is typically performed by end-users or others. the following roles are more or less standard on most testing projects: Testers.
to both the application and the operating system. For instance. What is a Test Build Manager? A: Test Build Managers deliver current software versions to the test environment. Q64. Q67. FAA. Test Engineers may also wear the hat of a Test Configuration Manager. one person may wear more than one hat. install the application's software and apply software patches. System Administrators and Database Administrators deliver current software versions to the test environment. install the application's software and apply software patches. System Administrators. Depending on the project. a Test Engineer may also wear the hat of a Test Build Manager. Q65. What is software testing methodology? . For instance. install the application's software and apply software patches. What is a Technical Analyst? A: Technical Analysts perform test assessments and validate system/functional test requirements. • Save the reputation of your company by discovering bugs and design flaws. set-up. Depending on the project. one person may wear more than one hat.• Provide documentation required by FDA. Depending on the project. a schedule of all test activities and resource requirements. Q66. a Test Engineer may also wear the hat of a Database Administrator. one person may wear more than one hat. Depending on the project. For instance. scripts. to both the application and the operating system. or in the field. • Save money by discovering defects 'early' in the design process. before bugs and design flaws damage the reputation of your company. to both the application and the operating system. Depending on the project. For instance. before failures occur in production. one person may wear more than one hat. What is a System Administrator? A: Test Build Managers. maintain and back up test environment hardware. a Test Engineer may also wear the hat of a System Administrator. software and test data. set-up. maintain and back up test environment hardware. Database Administrators deliver current software versions to the test environment. set-up. What is a test schedule? A: The test schedule is a schedule that identifies all tasks required for a successful testing effort. Test Engineers may also wear the hat of a Technical Analyst. maintain and back up test environment hardware. What is a Database Administrator? A: Test Build Managers. Q70. Q69. one person may wear more than one hat. other regulatory agencies and your customers. What is a Test Configuration Manager? A: Test Configuration Managers maintain test environments. For instance. Q68.
Rob Davis believes that using this methodology is important in the development and in ongoing maintenance of his customers' applications.. • A description of roles and responsibilities of the resources required for the test and schedule constraints. change request. including test cases. This information comes from the test environment. e. technical and functional design documents. Test procedures define test conditions. How do you create a test strategy? A: The test strategy is a formal description of how a software product will be tested. Q72. system limitations. a list of related tasks. . Q73.. The test team analyzes the requirements. This is based on known standards. • Testing methodology.g. Creating a test strategy. test plan. 2. This information comes from requirements. The test plan may include test cases. conditions.A: One software testing methodology is the use a three step process of. and Executing tests. This information comes from man-hours and schedules. including test tool data. What is the general testing process? A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases).. the test environment. Q71. Creating a test plan/design.. This methodology can be used and molded to your organization's needs. A test strategy is developed for all levels of testing. • Requirements that the system can not provide. including database updates. • Testing issues requiring resolution. • Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application. pass/fail criteria and risk assessment. Inputs for this process: • A description of the required hardware and software components. creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests. file outputs. writes the test strategy and reviews the plan with the project team. How do you create a test plan/design? A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. including test tools. Generally speaking. as required. • Functional and technical requirements of the application. Usually this requires additional negotiation at the project management level. 1. Outputs for this process: • An approved and signed off test strategy document. data to be used for testing and expected results. 3. report results.
Test data is captured and base lined. Test procedures or scripts include the specific data that will be used for testing the process or transaction.g. or automated test tools. How do you execute tests? A: Execution of tests is completed by following the test documents in a methodical manner. to address and discuss testing issues. derived from general and detailed design documents. if applicable. test conditions and test data. Inputs for this process: • Approved Test Strategy Document. As each test procedure is performed. • A good understanding of software complexity and module path coverage. • Test tools. e. if applicable. Checkpoint meetings are held throughout the execution phase. if required. test cases. . Checkpoint meetings are held daily. with assistance of developers and clients. It is the test team who. Some output data is also base-lined for future comparison. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment. Q74. software design document. Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope. Test procedures or scripts may cover multiple test scenarios. A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. prior to testing. Test scenarios are executed through the use of test procedures or scripts. A test readiness document is created to indicate the status of the entrance criteria of the release. given to software developers for correction. Base-lined data is used to support future application maintenance via regression testing. status and activities. source code and software complexity data. Reports of software design issues. • Test documentation problems uncovered as a result of testing.• • • • • • • • • • Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases. Outputs for this process: • • Approved documents of test scenarios. • Previously developed scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. develops test cases and scenarios for integration and system testing. an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects.
is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool. • Test tools. All discrepancies/anomalies are logged and discussed with the software team lead. Outputs for this process: • Log and summary of the test results. usually part of problem tracking. programmers.g. Change Request Documents. Software QA Manager and/or Test Team Lead. hardware test lead. found during system testing. Examples are bug reports on code issues. • Proposed fixes are delivered to the testing environment. i. Requirements Document. • Developed scripts.e. • Changes to the code. Fixes are regression tested and flawless fixes are migrated to a new baseline. and results are recorded in a test summary report. • Formal record of test incidents. unit tested code. • A software that has been migrated to the test environment. based on the severity of the problem. • Availability of the test team and project team. Test results are evaluated by test engineers to determine whether the expected results have been obtained. also known as test fixes. Every company has a different process for logging and reporting bugs/defects uncovered during testing.e. • Changes to the design. e. This needs to be approved and signed-off with revised testing deliverables. Software Design Document. if applicable. Inputs for this process: • Approved test documents. • Base-lined package. • Test data. The summary report is reviewed by the Project Manager. Test Plan. Test Cases. • Test Readiness Document. i. via the Configuration/Build Manager. The severity of a problem. as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager's formal acceptance. • Test document problems uncovered as a result of testing. given to software developers for correction. members of the test team prepare a summary report. Following completion of the test.e. software engineers and documented for further investigation and resolution. it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level. Test Procedures. Examples are Requirements document and Design Document problems. • General and Detailed Design Documents. • After a particular level of testing has been certified. ready for migration to the next level . i. • Reports on software design issues. and update documents where appropriate. including automated test tools. • Document Updates. Usually this is part of the Test Report. also known as tested source and object code.• The output from the execution of test procedures is known as test results. • A pass/fail criteria is used to determine the severity of a problem. • The test team reviews test document problems identified during testing.
For example.Q75. Functional testing. Integration testing. with little or no outside help. Get CAN get free information. client/server models. Load testing. End-to-end testing. and various denial of service tools. at the same time. Unit testing. What is the difference between performance testing and load testing? A: Load testing is a blanket term that is used in many different ways across the . when a web server is stress tested. Alpha testing. Q76. including web servers. User acceptance testing. Recovery testing. Security testing. What testing approaches can you tell me about? A: Each of the followings represents a different testing approach: • • • • • • • • • • • • • • • • • • • • • • • • Black box testing. It tests something beyond its normal operational capacity. testing aims to find out how many users can be on-line. Incremental testing. Click on a link! Q79. Comparison testing. in order to observe any negative results. For example. by simulating multiple users that access the program's services concurrently. and Mutation testing. Exploratory testing. Acceptance testing. Performance testing. You CAN learn load testing. What is stress testing? A: Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions. Install/uninstall testing. Beta testing. Load testing is most useful and most relevant for multi-user systems. What is load testing? A: Load testing simulates the expected usage of a software program. without crashing the server. Regression testing. in order to test the system's response at peak loads. ad-hoc testing. Usability testing. Sanity testing. For example. the load placed on the system is increased above normal usage patterns. using scripts. System testing. White box testing. Stress testing tests the stability of a given system or entity. a web server is stress tested. Q77. Compatibility testing. bots.
Load testing generally stops short of stress testing. reliability testing. What is incremental testing? A: Incremental testing is partial testing of an incomplete product. First. load testing. performance testing. Click on a link! Q80. Actually. performance testing. testing cannot establish the correctness of software. Get CAN get free information. the software is tested by in-house developers. Q83. with little or no outside help. or hardware-assisted debuggers. load testing. load testing. (and this is called the first phase of alpha testing). performance testing. the software QA staff. completenes. Then. though there is gray area in between stress testing and load testing.professional software testing community. Q82. though there is gray area in between stress testing and load testing. During stress testing. What is the difference between reliability testing and load testing? A: Load testing is a blanket term that is used in many different ways across the professional software testing community. is often used synonymously with stress testing. What is alpha testing? A: Alpha testing is final testing before the software is released to the general public. but cannot prove there are no defects. reliability testing. and volume testing. the load is so great that errors are the expected results. What is the difference between volume testing and load testing? A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The goal of incremental testing is to provide an early feedback to software developers. What is automated testing? A: Automated testing is a formally specified and controlled method of formal testing approach. and volume testing. Load testing generally stops short of stress testing. You CAN learn testing. Load testing generally stops short of stress testing. During stress testing. Q85. The term. for additional testing in an environment that is similar to the intended use. The term. It can find defects. reliability testing. with little or no outside help. Q81. The term. and volume testing. The goal is to catch bugs quickly. What is software testing? A: Software testing is a process that identifies the correctness. though there is gray area in between stress testing and load testing. You CAN learn software testing. is often used synonymously with stress testing. the load is so great that errors are the expected results. Click on a link! Q84. the load is so great that errors are the expected results. Get CAN get free information. the software is handed over to us. . and quality of software. During stress testing. (and this is called second stage of alpha testing). is often used synonymously with stress testing. They use either debugger software.
it is the least formal testing approach. Q91. with little or no outside help. It is a testing approach that examines the application's program structure. Boundary values include maximum. and derives test cases from the application's program logic. The goal is to benefit the maximum number of future users. It is a testing approach that examines the application's program structure. Other times. in order to receive as much feedback as possible. The expectation is that. Q93. Beta testing is performed by the public. so that further testing can ensure the product has few bugs. just inside boundaries. What is open box testing? A: Open box testing is same as white box testing. What is glass box testing? A: Glass box testing is the same as white box testing. and derives test cases from the application's program logic. . if a systems works correctly for these extreme or special values. "beta versions" of the software are released to a group of people. a few select prospective customers.Q86. and derives test cases from the application's program logic. What is gamma testing? A: Gamma testing is testing of software that has all the required features. An effective way to test code. Q92. but it did not go through all the in-house quality checks. It is a testing approach that examines the application's program structure. Cynics tend to refer to software releases as "gamma testing". What is ad hoc testing? A: Ad hoc testing is a testing approach. A test engineer chooses values that lie along data extremes. Q87. What is clear box testing? A: Clear box testing is the same as white box testing. Q90. is to exercise it at its natural boundaries. You CAN learn clear box testing. Get CAN get free information. then it will work correctly for all values in between. beta versions are made available to the general public. and limited public tests are performed. What is boundary value analysis? A: Boundary value analysis is a technique for test data selection. and error values. Click on a link! Q89. What is the difference between alpha and beta testing? A: Alpha testing is performed by in-house developers and software QA personnel. minimum. What is beta testing? A: Following alpha testing. Q88. just outside boundaries. typical values. or the general public.
Black box testing considers neither the code itself. See quality standard ISO 9126 for more information on this subject Q99. What is functional testing? A: Functional testing is same as black box testing. because. All documents should be written to a certain standard and template. . where column 1 is the "Test Case ID Number". The objective of bottom-up testing is to call low-level components first. portability. Get CAN get free information. column 4 is the "Test Conditions/Setup".Q94. Black box testing a type of testing that considers only externally visible behavior. usability. for testing purposes. with little or no outside help. Q96. Lastly. nor the "inner workings" of the software. nor the "inner workings" of the software. What is software quality? A: The quality of the software does vary widely from system to system. Get CAN get free information. in order to determine if all features of an application are working correctly. Software faults are errors in the correctness of the semantics of computer programs. nor the "inner workings" of the software. What is closed box testing? A: Closed box testing is same as black box testing. column 3 is the "Test Objective". You CAN learn to do black box testing. actions. making it easier for users to find what they want. column 5 is the "Input Data Requirements/Steps". They also help in learning where information is located. Q98. What is black box testing? A: Black box testing a type of testing that considers only externally visible behavior. Test case templates contain all particulars of every test case. and their expected results. A test engineer creates and uses test drivers for components that have not yet been developed. information will not be accidentally omitted from a document. Black box testing a type of testing that considers only externally visible behavior. reliability. Click on a link! Q100. Black box testing considers neither the code itself. You CAN learn to create test case templates. Q97. One example of this table is a 6-column table. with little or no outside help. What is a software fault? A: Software faults are hidden programming errors. low-level components are tested first. Standards and templates maintain document uniformity. column 2 is the "Test Case Name". and column 6 is the "Expected Results". Some common quality attributes are stability. with bottomup testing. and maintainability. What is bottom-up testing? A: Bottom-up testing is a technique for integration testing. or events. with standards and templates. Black box testing considers neither the code itself. Often these templates are in the form of a table. Click on a link! Q95. How do test case templates look like? A: Software test cases are in a document that describes inputs.
Q103. before shareholders loose their cool and before employees get bogged down. What is the role of test engineers? A: Test engineers speed up the work of the development staff. A software fault. Or. We. A software fault becomes a software failure only when the exact computation conditions are met.. before. Q104. Instead of coaching. create test cases. so the development team can devote its time to build up the product. we. and the faulty portion of the code is executed on the CPU.. other regulatory agencies. are successful if people listen to us. test engineers help the work of software development staff. evaluate results of system/integration/regression testing. scripts and generate data. tend to be process people. Q102. We. Or. But I've never seen it. when the software is ported to a different hardware platform. when the software is ported to a different complier. also give the company the evidence that the software is correct and operates properly. test engineers. FAA.Q101. They provide documentation required by FDA. users get discouraged. Or. . What is the difference between a software fault and a software failure? A: A software failure occurs when the software does not do what the user expects to see. test engineers also promote continual improvement. We execute test procedures and scripts. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. if people use our tests. We. QA engineers. We. or in the field. This can occur during normal usage. before bugs and design flaws damage the reputation of your company. We also assure the successful launch of the product by discovering bugs and design flaws. We also improve problem tracking and reporting. What is a test engineer? A: Test engineers are engineers who specialize in testing. Q105. test engineers save your company money by discovering defects EARLY in the design process. We save the reputation of your company by discovering bugs and design flaws. procedures. I would love to see QA departments staffed with experienced software developers who coach development teams to write better code. QA engineers. when the software gets extended. is a hidden programming error. if people think that we're useful. and reduce the risk of your company's legal liability. before failures occur in production. analyze standards of measurements. and your customers. on the other hand. We. Communication skills and the ability to understand various sides of issues are important. and the value of the devices that use it. What is software failure? A: A software failure occurs when the software does not do what the user expects to see. What is a QA engineer? A: QA engineers are test engineers. but QA engineers do more than just testing. We. and if we're happy doing our work. maximize the value of the software. test engineers.
they will slack off on their testing. Statistics can be used. On the positive side. Click on a link! Q107. On the negative side. when actual results and expected results are either in line or differences are explainable/acceptable based on client input. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Metrics for bug tracking can be used to determine when to stop testing. Integration testing is black box testing. and tell the developers.e. e. integration testing begins. Q109. i. Click on a link! .Q106. The idea of statistical process control is a great one. Integration testing is considered complete. Get CAN get free information. What is the solution? We need to drop the QA label. so that they can be analyzed in terms of statistics. or when bug rate falls below a certain level. with little or no outside help. What metrics are used for bug tracking? A: Metrics that can be used for bug tracking include: total number of bugs. to determine when to stop testing. submit bug reports to the developers. one CAN use statistics. test cases completed with certain percentage passed. But. You CAN learn to perform integration testing. find all the bugs. as soon as the developers learn that there is a test department. What metrics can be used in software development? A: Metrics refer to statistical process control. We need to offer to help with quality assessment only. The problem is. What we CAN do is to detect lack of quality. unit testing has to be completed. What are the responsibilities of a QA engineer? A: Let's say. Test cases are developed with the express purpose of exercising the interfaces between the components. most software development projects are NOT sufficiently well defined and NOT sufficiently unvaried.e. why should we label them quality assurance tools? Q110. because taking this responsibility is a classic trap that QA people get caught in. but it has only a limited use in software development. You CAN learn to use defect tracking software. if these are project management tools. Upon completion of unit testing. Get CAN get free information. number of new bugs per week. and prevent low-quality products from going out the door. an engineer is hired for a small software company's QA role. i. What is role of the QA engineer? A: The QA Engineer's function is to use the system much like real users would. and to provide feedback to the developers. How do you perform integration testing? A: First. when bug rate falls below a certain level. testing and quality of the entire product? No. And because QA departments cannot create quality. and number of fixes per week. Statistics are excellent tools that project managers can use. with little or no outside help. The problem is. Should he take responsibility to set up a QA infrastructure/process.g. sometimes. they are responsible for the quality of their own work. total number of bugs that have been fixed. statistical process control works only with processes that are sufficiently well defined AND unvaried. Why? Because we QA engineers cannot assure quality. find ways to replicate the bugs. Q108. and there is no QA team. tell them if they've achieved the desired level of quality. This activity is carried out by the test team. for example.
On the negative side. This metric measures the degree of structuredness and the quality of the code. to determine when to stop testing. so that they can be analyzed in terms of statistics. most software development projects are NOT sufficiently well defined and NOT sufficiently unvaried. Essential Complexity is a measure of the degree to which a module contains unstructured constructs. Global Data Complexity Metric quantifies the cyclomatic complexity of a module's structure as it relates to global/parameter data. The problem is. What metrics are used for test report generation? A: Metrics refer to statistical process control. i. statistical process control works only with processes that are sufficiently well defined AND unvaried. The idea of statistical process control is a great one. Integration Complexity Metric (S1). test cases completed with certain percentage passed. and reflects the complexity of the module's calling patterns to its immediate subordinate modules. It can be no less than one and no more than the cyclomatic complexity of the original flowgraph. Design Complexity Metric (S0).e. Actual Complexity is the number of independent paths traversed during testing. Statistics can be used. if these are project management tools. Integration Complexity Metric measures the amount of integration testing necessary to guard against errors. Statistics are excellent tools that project managers can use. But. for example.Q111. Test cases are developed with the express purpose of exercising the interfaces between the components. and modules that simply contain complex computational logic. or when bug rate falls below a certain level. This metric is used to predict the required maintenance effort and to help in the modularization process. Module Design Complexity is the complexity of the design-reduced module. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. • • • • • • McCabe Data-Related Software Metrics . Cyclomatic Complexity is a measure of the complexity of a module's decision structure. but it has only a limited use in software development. Module Design Complexity Metric (iv(G)). Integration testing is considered complete. This metric differentiates between modules that seriously complicate the design of a program they are part of. This activity is carried out by the test team. Essential Complexity Metric (ev(G)). why should we label them quality assurance tools? The followings describe some of the metrics in quality assurance: McCabe Metrics • • • Cyclomatic Complexity Metric (v(G)). Pathological Complexity Metric is a measure of the degree to which a module contains extremely unstructured constructs. What is integration testing? A: Integration testing is black box testing. Object Integration Complexity Metric (OS1). the minimum number of paths that should be tested. Design Complexity Metric measures the amount of interaction between modules in a system. Q112. It is the basis upon which program design and integration complexities (S0 and S1) are calculated. Actual Complexity Metric (AC). when actual results and expected results are either in line or differences are explainable/acceptable based on client input. Global Data Complexity Metric (gdv(G)). It's the number of linearly independent paths and therefore. Object Integration Complexity Metric quantifies the number of tests necessary to fully integrate an object or class into an OO system. On the positive side. one CAN use statistics. Pathological Complexity Metric (pv(G)).
PCTCALL is the number of nonoverloaded calls in a system. Tested Data Reference Metric (TDR). therefore. McCabe Object-Oriented Software Metrics. PCTPUB is the percentage of public and proteced data within a class. Tested Data Complexity Metric (TDV). a measure of the testing effort with respect to datarelated variables. Other Object-Oriented Software Metrics . Maintenance Severity Metric (maint_severity). Polymorphism • Percent of Unoverloaded Calls (PCTCALL). Maintenance Severity Metric measures how difficult it is to maintain a module. Data Complexity Metric quantifies the complexity of a module's structure as it relates to data-related variables. It is the total number of times that data-related variables are used in a module. Data Reference Metric (DR). Global Data Severity Metric (gdv_severity). It is an indicator of high levels of data logic in test paths. therefore. • Maximum ev(G) (MAXEV). • Hierarchy Quality(QUAL). Data Reference Severity Metric measures the level of data intensity within a module. McCabe Object-Oriented Software Metrics. MAXV is the maximum cyclomatic complexity value for any single method within a class. a module is data dense if it contains data-related variables in a large proportion of its structures. Data Reference Metric measures references to data-related variables independently of control flow. Tested Data Complexity Metric quantifies the complexity of a module's structure as it relates to data-related variables. ROOTCNT is the total number of class hierarchy roots within a program. Data Complexity Severity Metric measures the level of data density within a module. It is an indicator of high levels of data related code. • Fan-in (FANIN). McCabe Object-Oriented Software Metrics. • Number of Roots (ROOTCNT). MAXEV is the maximum essential complexity value for any single method within a class. Global Data Severity Metric measures the potential impact of testing data-related basis paths across modules. Data Reference Severity Metric (DR_severity). • Access to Public Data (PUBDATA) PUBDATA indicates the number of accesses to public and protected data. It is the number of independent paths through data logic. Encapsulation • Percent Public Data (PCTPUB). a module is data intense if it contains a large number of data-related variables. Tested Data Reference Metric is the total number of tested references to data-related variables. and therefore. FANIN is the number of classes from which a class is derived. Data Complexity Severity Metric (DV_severity).• • • • • • • • Data Complexity Metric (DV). QUAL counts the number of classes within a system that are dependent upon their descendants. It is based on global data test paths. Quality • Maximum v(G) (MAXV). It is the number of independent paths through data logic that have been tested.
and section 4 is the "Focus of the Testing Effort". • Programming Time. You CAN learn to generate test plan templates. Test document templates are often in the form of documents that are divided into sections and subsections. Program level and program difficulty is a measure of how easily a program is comprehended. where section 1 is the description of the "Test Objective". information will not be accidentally omitted from a document. Error estimate calculates the number of errors in a program. scope. How do test plan templates look like? A: The test plan document template helps to generate test plan documents that describe the objectives. The completed document will help people outside the test group understand the why and how of product validation. Programming effort is the estimated mental effort required to develop a program. Depth indicates at what level a class is located within its class hierarchy. • Intelligent Content. he will use them. • Programming Effort. With standards and templates. • Weighted Methods Per Class (WMC). One example of this template is a 4-section document. Line Count Software Metrics • • • • Lines of Code Lines of Comment Lines of Mixed Code and Comments Lines Left Blank Q113. • Program Level and Program Difficulty. Standards and templates maintain document uniformity.• Depth (DEPTH). They also help in learning where information is located. approach and focus of a software testing effort. • Program Volume. Program length is the total number of operator occurences and the total number of operand occurences. Halstead Software Metrics • Program Length. Once Rob Davis has learned and reviewed your standards and templates. scope. approach and focus of a software testing effort. Get CAN get free . NOC is the number of classes that are derived directly from a specified class. Intelligent content shows the complexity of a given algorithm independent of the language used to express the algorithm. with little or no outside help. Program volume is the minimum number of bits required for coding the program. section 3 is the the description of the "Test Approach". • Number of Children (NOC). section 2 is the the description of "Scope of Testing". • Response For a Class (RFC). LOCM is a measure of how the methods of a class interact with the data in a class. All documents should be written to a certain standard and template. 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. A software project test plan is a document that describes the objectives. RFC is a count of methods implemented within a class plus the number of methods accessible to an object of this class type due to inheritance. making it easier for a user to find what they want. He will also recommend improvements and/or additions. • Error Estimate. WMC is a count of methods implemented within a class. Programming time is the estimated amount of time to implement an algorithm. • Lack of Cohesion of Methods (LOCM).
will give the team complete information so developers can understand the bug. it needs to be communicated and assigned to developers that can fix it. and ends when the bug is fixed. logs.e. What is your role in your current organization? A: I'm a Software QA Engineer. Q118. determinations should be made regarding requirements. . coding. Another problem with such tools is the interpretation of the results (screens. One problem with automated testing tools is that if there are continual changes to the product being tested. At any time during the software development life cycle errors can be made during the gathering of requirements. internal design.) that can be a time-consuming task. when the product is near the end of the software development life cycle. etc. Bug life cycle begins when a programmer. When do you choose automated testing? A: For larger projects. i. or ongoing long-term projects. testing. Click on a link! Q116. this ratio tends to be 10:1. When a product is first conceived. data. reproduce it and fix it. But for small projects. What is a "bug life cycle"? A: Bug life cycles are similar to software development life cycles. find ways to replicate the bugs. that it becomes a very time-consuming task to continuously update the scripts. heavily in favor of developers. documentation planning. maintenance. fixes should be retested. a bug. unit testing. i. Get CAN get free information. or 3:1. Q115.e. organized. submit bug reports to developers. You CAN learn to use automated tools. the recordings have to be changed so often. What should be done after a bug is found? When a bug is found. re-testing and phase-out. but depends on what phase of the software development life cycle the project is in. tell them if they've achieved the desired level of quality. Automated testing tools sometimes do not make testing easier. creates an unintentional software defect. or even 1:2. A variety of commercial. and provides feedback to the developers. i. I find all the bugs. get an idea of its severity. test planning. 5:1. it should encapsulate these determinations. In sharp contrast. Q117. After the problem is resolved. safety impact.e. problem-tracking/management software tools are available. etc. in favor of testers. functional design. software developer. for regression testing to check the fixes didn't create other problems elsewhere. this ratio tends to be 1:1. and developed. These tools. automated testing can be valuable. What is the ratio of developers and testers? A: This ratio is not a fixed one. with the detailed input of software test engineers. hardware. Click on a link! Q114. Should I take a course in manual testing? A: Learning how to perform manual testing is an important part of one's education. Additionally. software. requirements analysis.. I see no reason why one should skip an important part of an academic program. If a problem-tracking system is in place.information. I use the system much like real users would. or architect makes a mistake. the time needed to learn and implement the automated testing tools is usually not worthwhile. integration. and the bug is no longer in existence. document preparation. with little or no outside help. updates.
Rational ClearCase is a popular software tool. it is often a good idea to sign up for courses at nearby educational institutions. What software tools are in demand these days? A: The software tools currently in demand include LabView. Get CAN get free information. PVCS is a document version control tool. What is software configuration management? . LabView. DOORS. and that includes reading product description pamphlets. or "Dynamic Object Oriented Requirements System". and there are many others. LoadRunner. made by Rational Software. LoadRunner. without any outside help? A: I suggest you read all you can.Q119. or free. CVS. with little or no outside help. or "Concurrent Version System". and whatever information you can lay your hands on. tends to be cheap. I don't have a lot of money. with little or no outside help. information on the Internet. PVCS. for revision control of source code. there is a way! You CAN do it. CVS enables several. while one is getting paid to do a job that requires the use of WinRunner and many other software testing tools. education is sometimes provided on the job. To learn to use WinRunner. depending on the end client. especially non-degree courses in local. Q122. Then the next step is getting some hands-on experience on how to use WinRunner. books. based on "diff".e. Rational Tools. Q123. and their needs. Rational Tools. Diff is a UNIX command that compares contents of two files. Click on a link! Q125. open source version control system to keep track of changes in documents associated with software projects. How can I become a good tester with little or no cost to me? A: The cheapest. by an employer.and you want to pay special attention to LoadRunner and the Rational Toolset. by an employer. is a popular.but there are many others. DOORS. Get CAN get free information. You CAN learn to use SCM tools. and Winrunner -. Q124. often distant.) -. What are some of the software configuration management tools? A: Software configuration management tools include Rational ClearCase. developers to work together on the same source code. Q121. Which of these tools should I learn? A: I suggest you learn the most popular software tools (i. a competitor of SCCS. if you put your mind to it! You CAN learn to use WinRunner. In lieu of a job. or free. CVS. SCCS is an original UNIX program. How can I learn to use WinRunner. Winrunner. education is sometimes provided on the job. If there is a will. and preferences. Classroom education. community colleges. etc. while one is getting paid to do a job that requires the use of WinRunner and many other software testing tools.and especially the Loadrunner and Rational Toolset -. manuals. should I sign up for a course at a nearby educational institution? A: The cheapest. Click on a link! Q120. is a requirements version control software tool.
and "severity" is associated with standards. "Piority" means something is afforded or deserves prior attention. and Test/QA Managers. "An efficient engine saves gas". which. For instance. the following roles are more or less standard on most testing projects: Testers. using the skills. on the other hand. SCM covers the tools and processes used to control. Rob Davis has experience with a full range of CM tools and concepts. changes that are made to the software and documentation throughout the software development life cycle (SDLC). Test Build Managers. patches. in turn can lead to a reassessment and renegotiation of 'priorities'. and talents YOU have.A: Software Configuration management (SCM) is the control. The best job is the one that works for YOU. a precedence established by order of importance (or urgency). For example. System Administrators. Test Build Manager and Test Configuration Manager as well. A variety of commercial. What's the difference between efficient and effective? A: "Efficient" means having a high ratio of output to input. one person can and often wear more than one hat. reproduce it and fix it. and Test Configuration Managers. will lead to success. Test Engineers. Q129. tools. get an idea of its 'severity'. Database Administrators. severe is marked by or requires strict adherence to rigorous standards or high principles. Q127. What's the difference between priority and severity? A: "Priority" is associated with scheduling. or capable of producing. designs. "Effective". with the detailed input of software test engineers. a severe code of behavior. an intended result. severe implies adherence to rigorous standards or high principles and often suggests harshness. "Severity" is the state or quality of being severe. means producing. and changes made to them. and "play" different roles. problemtracking/management software tools are available. The fixes are based on project 'priorities' and 'severity' of bugs. documentation. Q128. if we count the number of applicants and resumes. and can easily adapt to an organization's software tool and process needs. A buggy software can 'severely' affect schedules. "For rapid long-distance transportation. Test/QA Team Leads. What other roles are in testing? A: Depending on the organization. you need to experiment. Persistence. and to keep track of who makes the changes. give the team complete information so developers can understand the bug. working or producing with a minimum of waste. resources. For example. and the recording of. problems. Test/QA Team Leads. requirements. The 'severity' of a problem is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool. libraries. Depending on the project. The "best" job is the job that makes YOU happy. These tools.g. or having a striking effect. combined with experimentation. compilers. Tester roles tend to be the most popular. Q126. coordinate and track code. Less popular roles are roles of System Administrators. The words priority and severity do come up in bug tracking. Test/QA Managers. the jet engine is more effective than a witch's broomstick". To find the best job. . Technical Analysts. Which of these roles are the best and most popular? A: As a yardstick of popularity. e. we Test Engineers often wear the hat of Technical Analyst. change requests.
is the actual testing of an actual product. plans. on the other hand. What is a user manual? A: User manual is a document that presents information necessary to employ software or a system to obtain the desired results. what is described are system and . The output of verification is a nearly perfect set of documents. The inputs of verification are checklists. and specifications. The output of validation. requirements. Q137. prepare inputs for. Verification evaluates documents. an upwardly compatible software is able to handle files created by a later version of itself. Q131. upward compression means a form of demodularization. actual product. What is usability? A: Usability means ease of use. tools. in which a subordinate module is copied into the body of a superior module. Q132. walkthroughs and inspection meetings. and interpret outputs of a software product. documentation. change requests. the ease with which a user can learn to operate. CM covers the tools and processes used to control. Q134. and requirements document. The input of validation. issues lists. Rob Davis can easily adapt to your software tool and process needs. designs. specifications. Up time is the sum of busy time and idle time. evaluates the product itself. What is up time? A: Up time is the time period when a system is operational and in service. libraries. What is upwardly compatible software? A: Upwardly compatible software is compatible with a later or more complex version of itself. is a nearly perfect. plans. What is documentation change management? A: Documentation change management is part of configuration management (CM). What is upward compression? A: In software design. For example. Q133. problems. Rob Davis has had experience with a full range of CM tools and concepts. changes made to them and who makes the changes. What is the difference between verification and validation? A: Verification takes place before validation. compilers.Q130. coordinate and track code. reviews and meetings. on the other hand. Q135. patches. requirements. Q136. What is user documentation? A: User documentation is a document that describes the way a software product or system should be used to obtain the desired results. Validation. on the other hand. and not vice versa. Typically. code.
divided by the time it is available. What is user interface? A: User interface is the interface between a human user and a computer system. It enables the passage of information between a human user and hardware or software components of a computer system. and special instructions. Q145. Q141. as one of the primary objectives of its design. It is a document that presents information necessary to employ a system or component to obtain the desired results. what is described are system and component capabilities. For example. Q142. What is user friendly software? A: A computer program is user friendly. limitations. as one of the primary objectives of its design. What is a utility? A: Utility is a software tool designed to perform some frequently used support function. options. and special instructions. What is the difference between user documentation and user manual? A: When a distinction is made between those who operate and use a computer system for its intended purpose. What is a user guide? A: User guide is the same as the user manual. options. Uilization is a useful measure in evaluating computer performance. What is a user friendly document? A: A document is user friendly. Q143. error messages. permitted inputs. Q144. Typically.component capabilities. Q139. a program to print files. Q138. a separate user documentation and user manual is created. . Q140. and users get user manuals. when it is designed with ease of use. expected outputs. expected outputs. What is V&V? A: V&V is an acronym for verification and validation. error messages. What is utilization? A: Utilization is the ratio of time a system is busy. permitted inputs. limitations. when it is designed with ease of use. Operators get user documentation.
What is variable trace? A: Variable trace is a record of the names and values of variables accessed and changed during the execution of a computer program. What is a version description document (VDD)? A: Version description document (VDD) is a document that accompanies and identifies a given version of a software product. Q153. Q148. and installation and operating information unique to this version of the software. and constants. For example: "capacitor_voltage". Q149. What is value trace? A: Value trace is same as variable trace. Q151. and identification of the software. What is a variant? A: Variants are versions of a program. Variants result from the application of software diversity. It stands for "version description document". It is a record of the names and values of variables accessed and changed during the execution of a computer program. identification of changes incorporated into this version. What is a software version? A: A software version is an initial release (or re-release) of a software associated with a complete compilation (or recompilation) of the software. as opposed to a revision resulting from issuing change pages to a previous release. What is a variable? A: Variables are data items whose values can change.Q146. and if the software of each development phase fulfills the requirements and conditions imposed by the previos phase. correct. Q150. What is verification and validation (V&V)? A: Verification and validation (V&V) is a process that helps to determine if the software requirements are complete. Q147. What is VDD? A: VDD is an acronym. Q154. and if the final software complies with the applicable software requirements. There are local and global variables. Q152. What is a document version? A: A document version is an initial release (or complete a re-release) of a document. . Typically the VDD includes a description.
portions of a user's program and data are placed in auxiliary storage. implementation phase. In virtual storage. and the operating system automatically swaps them in and out of main storage as needed. What is a virtual address? A: In virtual storage systems. Q157. rapid prototyping model. Q158. test phase. What is virtual memory? A: Virtual memory relates to virtual storage. Portions of a user's program and data are placed in auxiliary storage. or after rework by an approved method. found to depart from specified requirements. and checkout phase. requirements phase. in which auxiliary storage can be addressed as though it was part of main storage. Q159. Vertical microinstructions are short. Besides vertical microinstructions. installation phase. What is virtual storage? A: Virtual storage is a storage allocation technique. incremental development model.Q155. What is the waterfall model? A: Waterfall is a model of the software development process in which the concept phase. These 12 to 24 bit microinstructions instructions are required to carry out a single machine language instruction. and checkout phase are performed in that order. but with little or no iteration. and spiral model. installation phase. there are horizontal as well as diagonal microinstructions as well. 12 to 24 bit instructions. They're called vertical because they are normally listed vertically on a page. implementation phase. probably with overlap. Q161. What models are used in software development? A: In software development process the following models are used: waterfall model. design phase. Q162. Q156. and the operating system automatically swaps them in and out of main storage as needed. virtual addresses are assigned to auxiliary storage locations. test phase. . What are the phases of the software development process? A: The software development process consists of the concept phase. They allow those location to be accessed as though they were part of the main storage. but is nevertheless considered suitable for use "as is". What is a waiver? A: Waivers are authorizations to accept software that has been submitted for inspection. Q160. design phase. What is a vertical microinstruction? A: A vertical microinstruction is a microinstruction that specifies one of a sequence of operations needed to carry out a machine language instruction. requirements phase.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.