Portnov Software Quality Assurance
How can a tester be sure that bug was fixed?
- execute the steps in the bug report - make sure the fixed bug does not result in new bugs in same area
If you find a bug and the developer says it is as-designed, what can you do?
- find an exact requirement, which defines the way it should be designed - if there is no specific requirement compare to same feature implemented in quality applications (ask your manager which applications to compare to)
What is a test plan?
Document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.
What is a Test Case?
Set of conditions and/or variables under which a tester will determine if a requirement upon an application is satisfied
What is the bug life cycle?
The bug should go through the life cycle to be closed. Here are the stages: - bug found - bug reported - bug assigned to developer - bug fixed by developer - fix verified by tester - bug closed
What is black/white box testing?
· Black box software testing is done without access to the source code. · White box testing is done with access to the code. Bugs are reported at the source code level, not behavioral.
Beside test case & test plan, what documents are required to write?
· Check Lists · Test matrices · Test design specs · End-to-end tests · Test summary reports · Bug reports
What is the most important impact QA can have on a product development process?
· Clarifying requirements · Bringing down percentage of code re-written due to the change in requirements
What is Negative testing? Positive?
· Positive testing aimed at showing software works as intended when user does what he/she does correct actions. · Negative testing aimed at showing that software handles properly situations in which user acts not as user is supposed to act (invalid inputs, unreasonable selections of settings, etc.)
What are Bug Report components? What fields do you fill out in a Bug Report? Describe to me the basic elements you put in a defect/bug report?
· Report number: Unique number given to the report · Application / Module being tested · Version & release number · Problem Summary / Short Description / Synopsis · Steps to reproduce (Detailed Description) · Severity (Critical, Serious, Minor, Suggestion) · Priority (High, Medium, Low) · Environment (Software and/or hardware configuration) · Reported by · Assigned to · Status (Open, Pending, Fixed, Closed, cannot reproduce, etc.) · Resolution / Notes · Keywords
How do you write a bug report?
· Rule of WWW - What happened, Where it happened, under Which circumstances · Write one bug report for each fix to be verified · Bug report should be as complete as possible · Bug reports are as concise as possible · Report a bug immediately, do not postpone · Use technical terms, not "people off the street" language
What is Software Quality Assurance?
· Software QA is the process of monitoring and improving all activities associated with software development, from requirements gathering, design and reviews to coding, testing and implementation.
What is the most important part of bug report?
· Steps to reproduce · Short Description · Severity · Priority · Status
What is the difference between Software Testing and Software QA?
· Testing is mainly an 'error detection' process · Software QA is 'preventative'. It aims to ensure quality in the methods & processes. ("Quality Assurance" measures the quality of processes used to create a quality product)
Is it possible to find/fix all the bugs in a software product before it goes to the customers? Why test?
· To establish and to enforce business systems of the QA Organization (Test planning, bug tracking, bug reporting, test automation, release certification, and others)
Which documents would you refer to when creating Test Cases?
All business and technical documentation available: - PRD - Product Requirements Document - BRD - Business Requirements Document - Functional Specifications - Manuals and Help - Use Cases - Test Design - Third party publications (books, published by independent authors)
What is Business Requirements Document (BRD)?
BRD is written by the Business Analysts. It details the business solution for a project including the documentation of customer needs and expectations. The most common objectives of the BRD are: - To gain agreement with stakeholders - To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer's and business' needs - To provide input into the next phase for this project - To describe what not how the customer/business needs will be met by the solution
What is Test matrix
Data collection mechanism. It provides a structure for testing the effect of combining two or more variables, circumstances, types of hardware, or events. Row and column headings identify the test conditions. Cells keep the results of test execution.
Describe risk analysis
Risk analysis means the actions taken to avoid things going wrong on a software development project, things that might negatively impact the scope, quality, timeliness, or cost of a project. This is, of course, a shared responsibility among everyone involved in a project. However, there needs to be a 'buck stops here' person who can consider the relevant tradeoffs when decisions are required, and who can ensure that everyone is handling their risk management responsibilities.
If there are so many settings/options to choose, how to write test cases?
Test cases should be developed for all most common potential scenarios They should cover most of the positive input
What does Test Plan include?
The following are some of the items that might be included in a test plan, depending on the particular project: * Title * Identification of software including version/release numbers * Revision history of document including authors, dates, approvals * Table of Contents * Purpose of document, intended audience * Objective of testing effort * Software product overview * Relevant related document list, such as requirements, design documents, other test plans, etc. * Relevant standards or legal requirements * Traceability requirements * Relevant naming conventions and identifier conventions * Overall software project organization and personnel/contact-info/responsibilities * Test organization and personnel/contact-info/responsibilities * Assumptions and dependencies * Project risk analysis * Testing priorities and focus * Scope and limitations of testing * Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable * Outline of data input equivalence classes, boundary value analysis, error classes * Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems * Test environment validity analysis - differences between the test and production systems and their impact on test validity. * Test environment setup and configuration issues * Software migration processes * Software CM processes * Test data setup requirements * Database setup requirements * Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs * Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs * Test automation - justification and overview * Test tools to be used, including versions, patches, etc. * Test script/test code maintenance processes and version control * Problem tracking and resolution - tools and processes * Project test metrics to be used * Reporting requirements and testing deliverables * Software entrance and exit criteria * Initial sanity testing period and criteria * Test suspension and restart criteria * Personnel allocation * Personnel pre-training needs * Test site/location * Outside test organizations to be utilized and their purpose, responsibilities, deliverables, contact persons, and coordination issues * Relevant proprietary, classified, security, and licensing issues * Open issues * Appendix - glossary, acronyms, etc.
What does Test Case include?
When planning for testing the test case: Test case ID The purpose (Title, Description) of the test case An instruction on how to get from the application base state to a verifiable application output or expected result Expected result When execute test cases we need two more columns: Actual result PASS/FAIL indication
