QA Flashcards
[QA] Test Case
A set of conditions or variables under which a tester will determine whether a system under test satisfies requirements.
[QA] Test Plan
A document outlining the scope, approach, resources, and schedule of testing activities.
[QA] Defect or Bug
Any variance between expected and actual results in the software under test.
[QA] Regression Testing
Testing conducted to ensure that a recent code change has not adversely affected existing features. This is usually done before a release.
[QA] Black Box Testing
Testing where the tester is not concerned with the internal workings of the system but focuses on the inputs and outputs.
[QA] White Box Testing
Testing where the tester has knowledge of the internal workings of the system and can design test cases accordingly.
[QA] Smoke Testing
Preliminary testing to reveal simple failures that may lead to rejecting a software build.
[QA] User Acceptance Testing (UAT)
Testing conducted to determine whether a system satisfies the acceptance criteria and is acceptable for delivery to end users.
[QA] Automated Testing
Testing using tools and scripts to automate repetitive, but necessary, testing tasks.
[QA] Load Testing
Testing the system’s ability to handle a specified amount of load or traffic.
[QA] Performance Testing
Testing the system’s performance characteristics, such as response time, speed, and stability.
[QA] Scalability Testing
Testing to ensure that the application can handle an increase in the number of users or load.
[QA] Boundary Testing
Testing at the edges or boundaries of the input domain to ensure system stability. Ex: a number field only accepts numbers 1-50. You will want to test if -5, 0, 1, 25, 50, and 100 would work with the expectation of -5, 0, and 100 to not work
[QA] Ad Hoc Testing
Informal testing without predefined test cases; often exploratory in nature. This would be you just poking around the application.
[QA] Bug Tracking System
A tool used to track defects, issues, or bugs throughout their lifecycle. (Jira, TFS)
[QA] Traceability Matrix
A document or table that helps determine all the possible outcomes and the most efficient test coverage
[QA] Dynamic Testing
Testing technique where the code is executed to demonstrate the actual behavior of the system.
[QA] Static Testing
Testing technique where the code is not executed; it can include reviews and inspections.
[QA] Test Environment
The setup of software and hardware for testing, including servers, databases, and network configurations. Note there is usually a Dev, Test, Stage, and Prod environments.
Prod Environments are the live code the users use. Everything else is internal.
[QA] Test Suite
Test suites are the logical grouping or collection of test cases to run a single job with different test scenarios.
[QA] Negative Testing
A test strategy that ensures that your application can gracefully handle invalid input or unexpected user behavior. For example, if a user tries to type a letter in a numeric field, the correct behavior in this case would be to display the “Incorrect data type, please enter a number” message.
[QA] Severity
How badly the defect has affected the application’s functionality.
Ranked 0 -5 (0 being the highest)
A severity of 0 means this needs to be fixed now.
[QA] Priority
The order in which developers will fix defects (because priority describes business importance).
Ranked 0-5 (0 being the highest)
[QA] Repro Rate (Reproduction rate)
The rate at which the bug/defect can be reproduced. Typically when a bug is found I will test it 5 times, so I know the repro rate (it is rare that I test it more than 10 times)
example Rate: 1/5 meaning it can be reproduced 20% of the time, 5/5 meaning it can be repro’d 100% of the time
[Agile] Agile
A set of principles for software development that prioritizes flexibility, collaboration, and customer satisfaction.
[Agile] Scrum
An Agile framework that defines roles, events, and artifacts for effective project management.
[Agile] Sprint
A time-boxed iteration of work in Scrum, usually 2-4 weeks long, during which a potentially shippable product increment is created.
[Agile] Product Owner
The person responsible for defining and prioritizing the product backlog, representing the customer’s needs, and making decisions about what to build.
[Agile] Scrum Master
A facilitator and coach who helps the Scrum team follow the Agile principles and practices and removes impediments to progress.
[Agile] Scrum Team
A cross-functional team consisting of developers, a product owner, and a Scrum Master, responsible for delivering a potentially shippable product increment at the end of each sprint.
[Agile] Product Backlog
A prioritized list of features, enhancements, and bug fixes that make up the work to be done on a project.
[Agile] User Story
A brief, user-centric description of a feature or functionality, often written from the perspective of an end user.
[Agile] Daily Standup (Daily Scrum)
A short, daily meeting where team members discuss their progress, plans, and any impediments they are facing.
[Agile] Velocity
A measure of the amount of work completed by a team in a sprint, used for estimating future work and improving planning accuracy.
[Agile] Burndown Chart
A visual representation of the amount of work remaining in a sprint or project, helping teams track their progress.
[Agile] Acceptance Criteria (AC)
A set of criteria that must be met for a product increment to be considered complete and potentially shippable.
[Agile]Backlog Grooming (Refinement)
The process of reviewing, prioritizing, and refining items in the product backlog to ensure they are ready for inclusion in upcoming sprints.
[Agile] Sprint Retrospective (Retro)
A meeting held at the end of a sprint for the team to reflect on their process and identify areas for improvement.
[Agile] Continuous Integration
The practice of frequently merging code changes into a shared repository, with automated builds and tests to catch integration issues early.
[Agile] Story points
Units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. This is the combined effort between the Scrum team. Usually set in the fibonacci sequence
0,1,2,3,5,8,13
