Question bank Q1. Why software needs to be tested? Ans. Every software product needs to be tested since; the development process is unable to produce defect free software. Even if the development process is able to produce defect free software, we will not be able to know unless & until we test it. Without testing it, we shall not be having enough confidence that it will work. Testing not only identifies and reports defect but also measures the quality of the product, which helps to decide whether to release the product, or not. Q2.
What is the reason that Software has Bugs? Ans. Following factors contribute to the presence of bugs in the software applications:- a. Software development tools like visual tools, class libraries, compilers, scripting tools, etc. usually introduce their own bugs in the system. b. To err is human. Likewise programmers do make mistakes while programming c. In fast-changing business environments continuously modified requirements are becoming a fact of life. Such frequent changes requested by the customer leads to errors in the application already nearing completion.
Last minute design changes leads to many chaos like redesign of the whole system, rescheduling of engineers, scrapping of the work already completed, fresh requirements of compatible hardware etc d. A quickly written but poorly documented code is bound to have bugs. It becomes difficult to maintain and modify such code that is badly written or poorly documented. – its tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code.
In fact, it’s usually the opposite: they get points mostly for quickly turning out code, and there as jobs security if nobody else can understand it (if it was hard to write, it should be hard to read). e. When project deadlines come too close & time pressures come, mistakes are bound to come Q3. What is the difference between QA and Testing? Ans. QA stands for “Quality Assurance”, and focuses on “Prevention” of defects in the product being developed. It is associated with the “Process” and activities related to the Process Improvement.
Quality Assurance measures the quality of the processes employed to create a quality product. Whereas “Testing” refers to “Quality Control”, and focuses on Detection of Defect and removal thereafter. Or Quality Control measures the quality of a product. Q4. What is the difference between Software Testing and Debugging? Ans. Testing is the process of locating or identifying the errors or bugs in a software system. Whereas Debugging is the process of Fixing the identified Bugs. It involves a process of analyzing and rectifying the syntax errors, logic errors and all other types of errors identified during the process of testing.
Q5. What is the difference between a Bug and a Defect? Ans. “Bug” is a problem or an error in the software code, which is found in the application during Testing. Bug is responsible for failure of the application to comply with the desired specifications. Whereas “Defect” is problem reported by the customer during usage of the software application. Q6. What is the difference between a Bug and an Enhancement? Ans. “Bug” is a problem or an error in the software code, which is found in the application during Testing.
Bug is responsible for failure of the application to comply with the desired specifications. Whereas “Enhancement” is the additional feature or functionality found and added to the application as desired by the end user / real word customer or tester during the testing process. Q7. What is the difference between Requirements & Specifications? Ans. “Requirements” are statements given by the customer as to what needs to be achieved by the software system. Later on these requirements are converted into specifications which are nothing but feasible or implementable requirements.
Whereas “Specifications” are feasible requirements derived from various statements given by the customer. These are the starting point for the product development team. Q8. What is the difference between Verification and Validation? Ans. “Verification” involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications to confirm whether items, processes, services, or documents conform to specified requirements or not. This can be done with the help of checklists, issues lists, walkthroughs, and inspection meetings. The purpose f verification is to determine whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase or not. Whereas “Validation” is the determination of the correctness of the final program or software product produced from a development project with respect to the user needs and requirements. This involves actual testing of the product and takes place after verifications are completed. “Software Verification” raises the question, “Are we building the Product Right? ” that is, does the software conform to its specification. Software Validation” raises the question, “Are we building the Right Product? ” that is, the software doing what the user really requires. Q9. What is difference between Waterfall Model and V Model? Ans. “Waterfall Model” Is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall)through the phases of requirements analysis, design, implementation, testing (validation),integration, and maintenance. To follow the waterfall model, we proceed from one phase to the next in a purely sequential manner.
In traditional waterfall model, testing comes at the far end of the development process. Whereas “V Model” or “Life Cycle Testing” involves carrying out verification of consistency, completeness and correctness of software at every stage of the development life cycle. It aims at catching the defects as early as possible and thus reduces the cost of fixing them. It involves continuously testing the system during all stages of the development process rather than just limiting testing to the last stage. Q10. What are Baseline Documents? Ans.
Baseline documents are the documents, which have been approved by the customer and will not have any more changes. Baseline Documents cover all the details of the project and have undergone “walkthrough” process. Once a document is Base-lined it cannot be changed unless there is a change request duly approved by the customer. Service Level Agreement (SLA) & Business Requirement Documents (BRD) are the examples of Baseline Documents. Q11. What is Defect Density? Ans. “Defect Density” Is a software metric defined as: Total number of defects per LOC (lines of code).
Alternatively it can be: Total number of defects per Size of the Project. Here the measure of “Size of the Project” can be number of Function Points, Number of Feature Points, number of Use Cases or KLOC (Kilo Lines of Code) etc. Q12. What is Quality? Ans. 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. Q13. What is an Inspection? Ans.
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 is 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. A14. What is Six Sigma? Ans. “Six Sigma” means Six Standard Deviations from the mean. It is a methodology aimed to reduce defect levels below 3. 4 Defects Per one Million Opportunities. Six Sigma approach improves the process performance, decreases variation and maintains consistent quality of the process output. This leads to defect reduction and improvement in profits, product quality and customer satisfaction.
Q15. What is difference between CMM and CMMI? Ans. “CMM” means “Capability Maturity Model” developed by the Software Engineering Institute (SEI). It is a process capability maturity model, which aids in the definition and understanding of an organization’s processes. CMM is intended as a tool for objectively assessing the ability of government contractors’ processes to perform a contracted software project. Whereas “CMMI” means “Capability Maturity Model Integration” & it has superseded CMM. The old CMM has been renamed to Software Engineering CMM (SE-CMM).
Q16. What is Verification? Ans. 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. Q17. What is Validation? Ans. 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. Q18.
What is a Test Plan? Ans. A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it. Q19. What is a Walkthrough? Ans.
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. Q20. What is Software Life Cycle? Ans. 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-ou Q21. What is the Difference between STLC & SDLC? Ans. STLC means ” Software Testing Life Cycle”. It starts with activities like : 1) Preparation of Requirements Document 2) Preparation of Test Plan 3) Preparation of Test Cases 4) Execution of Test Cases 5) Analysis of Bugs 6) Reporting of Bugs 7) Tracking of Bugs till closure.
Whereas SDLC means ” Software Development Life Cycle” is a software development process, used by a systems analyst to develop an information system. It starts with activities like : 1) Project Initiation 2) Requirement Gathering and Documenting 3) Designing 4) Coding and Unit Testing 5) Integration Testing 6) System Testing 7) Installation and Acceptance Testing 8) Support or Maintenance Q22. What is the Difference between Project and Product Testing? Ans. If any organization is developing the application according to the client specification then it is called as project.
Accordingly its testing is known as “Project Testing” Whereas If any organization is developing the application and marketing it is called as product. Hence its testing is known as “Product Testing” Q23. How do you introduce a new software QA process? Ans. 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. Q24. What is configuration Management? Ans.
Configuration Management (or CM) is the processes of controlling, coordinating and tracking the Standards and procedures for managing changes in an evolving software product. Configuration Testing is the process of checking the operation of the software being tested on various types of hardware. Q25. What is the role of QA in a software producing company? Ans. QA is responsible for managing, implementing, maintaining and continuously improving the Processes in the Company and enable internal projects towards process maturity and facilitate process improvements and innovations in the organization.
Tester is responsible for carrying out the testing efforts in the company. In many companies QA person is responsible both the roles of Testing as well as creating and improving the processes. Q26. What is Failure Mode and Effect Analysis (FMEA)? Ans. Failure Mode and Effect Analysis is a systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence. Q27. What is Test Maturity Model or TMM? Ans.
Test Maturity Model or TMM is a five level staged framework for test process improvement, related to the Capability Maturity Model (CMM) that describes the key elements of an effective test process. Q28. What is the difference between API & ABI? Ans. Application Programming Interface (API) is a formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services. Whereas Application Binary Interface (ABI) is a specification defining requirements for portability of applications in binary forms across different system platforms and environments.
Q29. What is I V & V? Ans. I V & V means Independent Verification and Validation. Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. Verification can be done with the help of checklists, issues lists, walkthroughs, and inspection meetings. Whereas Validation typically involves actual testing and takes place after verifications are completed. Q30. What are the benefits of Software Validation? Ans. Software validation is an important tool employed to assure the quality of the software products.
Few benefits are as under: 1) It increases the usability and reliability of the device software, resulting in reduced failure rates, less recalls and corrective actions, less liability to device manufacturers. 2) It reduces the long term costs by making it easier and less costly to reliably modify software and revalidate software changes. 3) It helps to reduce the long-term cost of software by reducing the cost of validation for each subsequent release of the software. Q31. What is the role of Design Reviews in Software Development Life Cycle? Ans.
Design review is a primary tool for managing and evaluating software development projects. Design reviews allow management to confirm that all goals defined in the software validation plan have been achieved. Formal design reviews are more structured and include participation from others outside the development team. Design reviews are documented, comprehensive, and systematic examinations of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems.
Design reviews include examination of development plans, requirements specifications, design specifications, testing plans and procedures, all other documents and activities associated with the project. Q32. What is the need of Software Validation after a change? Ans. When any change even a small one is made to the software, following activities need to be performed: 1) Re-establishment of the validation status of the software. 2) Conducting necessary validation analysis – not for the sake of validation of the individual change, but o to know the effect of the change on the entire software system. ) Conducting suitable level of regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. Regression testing is meant to provide a confidence that the software has been validated after the change. Q33. How would you convince upper management that company needs a formal QA testing team? How would you explain that Software quality would not improve if the company get rid of QA team? Ans. Developing amazing applications isn’t the same as testing them, ut a experienced QA tester, I would rather have a developers testing application than the testers who can just plainly submit bug reports.
QA team needs to build quality into software development life cycle. The bug in software design is 15times cheaper than a bug in code. QA productivity is really hard to measure. If QA team is doing testing right, , everything just happens smoothly, but if testers mess up even a little, everyone knows about it. To be successful, QA team must create test plans, create test harnesses, create test cases and use testing tools. QA should ensure whether the application code is effectively delivering on the business requirements provided.
The developers should unit test their own code and deliver ‘perfectly good code’ , while QA testers should deliver ‘code that actually addresses business needs’. For a company that make software applications, a rock-solid QA department is absolutely irreplaceable. Q34. WhatQuality Assurance and Quality Control activities are done differently for COTS / GOTS project than for a traditional custom development project? | Ans. The activities themselves are broadly the same, but with different stakeholders, and different detailed procedures for verification and validation.
Often the challenge for SQA is to pin down the ownership of the requirements, which may be represented by a complex debate between marketing departments, technical eggheads, user groups, customer focus groups and other interested parties. | | Q35. What in your opinion is the role of SQA personnel with respect to inspections or testing? | Ans. Formally, the role is to make the inspection process or testing process visible, both to the participants (so they can see what they are achieving, how effective they are being) and to management (so that they can assess progress and risk).
In practice, SQA personnel often need to act as facilitators or coaches. They are often regarded (wrongly) as the owners or custodians of the inspection or testing process, or even as the owners/custodians of the whole software process. Part of the training and mentoring for SQA personnel should address the difficult dilemma of how to be adequately engaged in the software process without being landed with the responsibility for it. | | Q36. What are the most likely quality consequences of choosing an inappropriate life cycle model for a software project? | Ans. The most likely consequence is that the project will not deliver anything at all.
Not because the lifecycle couldn? t be made to work technically, but because it will fail to contain the political tensions between stakeholders. | | Q37. What in your opinion, are the most important changes that occurred in the role of Software Quality Assurance during the last 5 to 10 years? Ho| Ans. rowing awareness and importance of public domain models such as SEI SW CMM, BOOTSTRAP and SPICE. Changing nature of software development, especially model-based development (CASE) and component-based development (CBD). Growing need to connect software of different ages and sources.
Software projects not pure software development, but including maintenance, package selection and implementation, and other software activities. (Perhaps software projects never were pure development, but such topics as project management, quality management and configuration management used to be taught as if they were. ) Faced with these changes, SQA needs to be both reductionist (giving close attention to the quality of components from various sources) and holistic (giving broad attention to the emergent properties of the whole assembled system, in terms of its overall fit to business requirements).
As I see it, the mandate of SQA is to make defects in software products and processes visible to management. SQA fits into a context of software quality management where this visibility leads to corrective and preventative action (not itself part of SQA), and to general software process improvement. | Q38. Someone complains that during system testing the application often crashes. What likely process problem does that indicate? | Ans. Systematic failure to carry out proper unit testing.
OR inconsistency between the development/unit test environment and the system test environment. AND ALSO management failure to respond promptly to the situation with corrective and preventative action. | | Q39. What exposure have you had to auditing? Internal? External? Certification related? | Ans. I have been trained as a lead assessor for ISO 9000 and also as an examiner for the European Quality Award. I have conducted internal audits and informal external assessments but not formal external audits. I have advised organizations on steps towards certification. | Q40. What in your opinion are the most significant fundamental differences between SEI SW-CMM and ISO 9000-3? | Ans. The main difference is what the two models tell you. ISO 9000-3 gives you a yes/no answer, whereas SEI SW-CMM gives you a more complex assessment. This implies different ways of using the models for SQA and process improvement. | 1. Difference is ISO is a standard and CMMI is a model with framework. 2. Other one is Specific practices should be determinded in ISO and where as CMMI model having predefined useful specific and general practices. | Q41. In your experience, who are the most important allies of SQA within an organization? | Ans. SQA is a form of risk awareness, and is therefore potentially allied to any senior management with a risk management focus. Within some companies/industries (e. g. insurance), software risks are seen as having mainly financial consequences, and so the main ally might be the financial director. Within other companies/industries (e. g. retail), software risks are seen as having mainly customer service implications, and so the main allies may be in marketing roles.
In one client, we had useful conversations with the Company Secretariat, because of the due diligence implications of some software risks. These conversations were triggered by Y2K issues, but ranged much more widely. In practice, SQA often fails to make these alliances, because it gets bogged down in obscure software technicalities and trivialities, which it is incapable of communicating effectively even to software engineers, let alone anybody else. | Q42. A company recruits its first and only SQA “specialist”. The person is new to the area.
The company is relatively young, operates in a competitive commercial domain and has no previous SQA presence. The SQA specialist feels he needs to show some results during the next 6 to 9 months. What advice will you give him? | Ans. Start with a risk assessment, to identify the significant software risks and their business implications. Identify managers directly affected by these implications, who may be recruited as allies. Select a small number of issues to address in the initial phase. Try to include some quick wins, as well as some improvements that could be achieved within 3-6 months.
Don? t try to do everything at once. At this stage, use whichever model you prefer (ISO 9000-3 or TickIT or SW-CMM or SPICE) merely as a framework, so that you know how what you? re doing fits into a larger picture. | Q43. What advice would you give to someone who asked you where to start to introduce to their company a metrics and quality reporting program? | Ans. Use the GQM approach to derive relevant metrics from personal and corporate goals. Select a small number of key metrics that will be directly relevant to project managers and/or software engineers.
Put the metrics into the hands of the workers, as a tool for personal performance improvement. | | | | Q44. What is Total Quality Management? Ans. A company commitment to develop a process that achieves high quality product and customer satisfaction. Q45. What is Quality Circle? Ans. A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality. | | | | | | | | | | | | | | | | |
You have to be 100% sure of the quality of your product to give a money-back guarantee. This describes us perfectly. Make sure that this guarantee is totally transparent.Read more
Each paper is composed from scratch, according to your instructions. It is then checked by our plagiarism-detection software. There is no gap where plagiarism could squeeze in.Read more
Thanks to our free revisions, there is no way for you to be unsatisfied. We will work on your paper until you are completely happy with the result.Read more
Your email is safe, as we store it according to international data protection rules. Your bank details are secure, as we use only reliable payment systems.Read more
By sending us your money, you buy the service we provide. Check out our terms and conditions if you prefer business talks to be laid out in official language.Read more