Q15. How QA processes can be introduced in an organization?
Ans. 1. It depends on the size of the organization and the risks involved. e.g. for large organizations with high-risk projects a formalized QA process is necessary.
2. If the risk is lower, management and organizational buy-in and QA implementation may be a slower.
3. The most value for effort will often be in
– Requirements management processes
– Design inspections and code inspections
– post-mortems / retrospectives
Q16. What are the steps to perform software testing?
Ans.
– Understand requirements and business logic
– Get budget and schedule requirements
– Determine required standards and processes
– Set priorities, and determine scope and limitations of tests
– Determine test approaches and methods
– Determine test environment, test ware, test input data requirements
– Set milestones and prepare test plan document
– Write test cases
– Have needed reviews/inspections/approvals of test cases
– Set up test environment
– Execute test cases
– Evaluate and report results
– Bug Tracking and fixing
– Retesting or regression testing if needed
– Update test plans, test cases, test results, traceability matrix etc.
Q17. What is a test plan?
Ans. A document that describes the objectives, scope, approach, and focus of a software testing effort.
Q18. What are the contents of test plan?
Ans.
– Title and identification of software including version etc.
– Revision history
– Table of Contents
– Purpose of document and intended audience
– Objective and software product overview
– Relevant related document list and standards or legal requirements
– Naming conventions
– Overview of software project organization
– Roles and responsibilities etc.
– Assumptions and dependencies
– Risk analysis
– Testing priorities
– Scope and limitations of testing effort
– Outline of testing effort and input data
– Test environment setup and configuration issues
– Configuration management processes
– Outline of bug tracking system
– Test automation if required
– Any tools to be used, including versions, patches, etc.
– Project test metrics to be calculated
– Testing deliverables
– Reporting plan
– Testing entrance and exit criteria
– Sanity testing period and criteria
– Test suspension and restart criteria
– Personnel pre-training needs
– Relevant proprietary, classified, security and licensing issues.
– Open issues if any
– Appendix
Q19. What is a test case?
Ans. A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of a software application is working correctly.
Q20. What are the components of a bug report?
Ans.
– Application name
– The function, module, name
– Bug ID
– Bug reporting date
– Status
– Test case ID
– Bug description
– Steps needed to reproduce the bug
– Names and/or descriptions of file/data/messages/etc. used in test
– Snapshot that would be helpful in finding the cause of the problem
– Severity estimate
– Was the bug reproducible?
– Name of tester
– Description of problem cause (filled by developers)
– Description of fix (filled by developers)
– Code section/file/module/class/method that was fixed (filled by developers)
– Date of fix (filled by developers)
– Date of retest or regression testing
– Any remarks or comments
Q21. What is verification?
Ans. It involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. It can be done with checklists, issues lists, walkthroughs, and inspection meetings etc.
Q22. What is validation?
Ans. It involves actual testing and takes place after verifications are completed.
Q23. What is a walkthrough?
Ans. An informal meeting for evaluation or informational purposes.
Q24. What’s an inspection?
Ans. It is more formalized than a ‘walkthrough’, typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what’s missing, not to fix anything.
Q25. What is configuration management?
Ans. It covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools / compilers / libraries / patches, changes made to them, and who makes the changes.
Q26. When you can stop testing?
Ans.
– Deadlines (release deadlines, testing deadlines, etc.)
– Test cases completed with certain percentage passed
– Test budget depleted
– Coverage of code/functionality/requirements reaches a specified point
– Bug rate falls below a certain level Beta or alpha testing period ends
Q27. What if there isn’t enough time for thorough testing?
Ans. Consider the following scenarios:
– Which functionality is most important from business point of view?
– Which functionality is most visible to the user?
– Which functionality has the largest financial impact?
– Which aspects of the application are most important to the customer?
– Which parts of the code are most complex?
– Which parts of the application were developed in rush?
– Which aspects of similar/related previous projects caused problems?
– 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?
Q28. What if the project isn’t big enough to justify extensive testing?
Ans. Do risk analysis. See the impact of project errors, not the size of the project.
Q29. How can web based applications be tested?
Ans. Apart from functionality consider the following:
– What are the expected loads on the server and what kind of performance is expected on the client side?
– Who is the target audience?
– Will down time for server and content maintenance / upgrades be allowed?
– What kinds of security will be required and what is it expected to do?
– How reliable are the site’s Internet / intranet connections required to be?
– How do the internet / intranet affect backup system or redundant connection requirements and testing?
– What variations will be allowed for targeted browsers?
– Will there be any standards or requirements for page appearance and / or graphics throughout a site or parts of a site?
– How will internal and external links be validated and updated?
– How are browser caching and variations in browser option settings?
– How are flash, applets, java scripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
– From the usability point of view consider the following:
— Pages should be 3-5 screens longer.
— The page layouts and design elements should be consistent throughout the application / web site.
–Pages should be as browser-independent or generate based on the browser-type.
–There should be no dead-end pages. A link to a contact person or organization should be included on each page.
Q30. What is Extreme Programming?
Ans. Extreme Programming is a software development approach for risk-prone projects with unstable requirements. Unit testing is a core aspect of Extreme Programming. Programmers write unit and functional test code first – before writing the application code. Generally, customers are expected to be an integral part of the project team and to help create / design scenarios for acceptance testing.
Also see:
- Software Testing Interview Questions – 1
- LoadRunner Interview Questions
- QTP Interview Questions – Part 1
- QTP Interview Questions – Part 2
- WordPress Web Hosting for Small Businesses: Essential Tips - October 3, 2024
- Web Hosting for Online Startups: Scalability and Reliability - October 3, 2024
- 4 Best Upmetrics Alternatives for Your Business Planning [2024] - August 30, 2024
