Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

QA > Notes > Flashcards

Notes Flashcards

1
Q

SDLC

A

Software Developmental Life Cycle - The process take to build / develop software from its initial conception to its release

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

QA - Quality Assurance

A

to assure the quality of an application or software system by testing through the development life cycle, and delivery of a bug/defect free product, making sure the software is built as expected

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Business Owner

A

director of overall product

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Product Owner

A

manager of a specific product

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Stake Holder

A

anyone who has an interest in the product, someone with influence. the people involved in or affected by a project’s activities.

stakeholders can include: project sponsor, project team, customers, project manager, support staff, suppliers, opponents to the project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Subject Matter Expert

A

Someone who specializes in the subject at hand, someone to consult with

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Developers

A

develop the code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Business Analyst

A

gives the requirements along with the Product Owner, tells you exactly what you need to do

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Architect

A

designs what the website/product should look like from looks to backend connections

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Scrum Master / Project Manager

A

makes sure everyone is able to do their part successfully

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Why are there bugs?

A
  • inaccurate understanding of end user (customer) needs
  • inability to deal with changing reqs
    as dev team is building a lot of changes for requirements can be made and this leads to inconsistencies
  • software that is hard to maintain
  • software and hardware can be incompatible
    all software needs to be compatible to all hardware/platforms put out
  • late discovery of serious flaws
  • lack of focus on quality
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Requirements

A

What you want or desire from a system

what is wanted is specified

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Functional Requirements

A

what you want the system to do

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Non-functional requirements

A

are restrictions on the types of solutions that will meet the functional requirements

  • usability, reliability, performance, supportability, compatibility, security
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Use Case

A

a set of scenarios that describes an interaction between user and a system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

User Stories

A

a very high level definition of a requirement, containing just enough information so that the devs can produce a reasonable estimate of the effort to implement it

  • As a (role) I want to (something) so that (benefit)

ex: As a student I want to purchase a parking pass so that I can drive to school.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Test Cases

A

a specific interaction (design steps) that a tester will have in order to test a single behavior of the software

(manually going through the features and testing each use case or user story to check if all acceptance criteria are working)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Test Script

A

program/script written in a scripting/programming language to record/script specific interactions (design steps) that a tester will have, in order to test a single behavior of the software

When you use an automated language or tool to help you confirm if requirements are working.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Test Suite

A

(a folder) a collection of Test Cases / Test Scripts that are intented to be used to test a software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

RTM

A

Requirements Traceability Matrix

a cross-reference between a test case document and the functional / design specification document

mapping between test cases and requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

SMART: Requirements Guideline

A

Specific
Measurable
Attainable
Realistic
Time-bound

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Test Case Components (TUPSIDOP)

A

Test Case Name
Unique Identifier
Pre-Condition
Step No.
Input
Design Steps
Output
Post-Condition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Test Artifacts

A

things we care about as a QA, the deliverables (test cases, test scripts, etc)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Unit Testing

A

testing each smallest individual module or unit of the application, normally performed by software test engineers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Integration Testing

A

Individual software modules are combined and tested as a group, taking two units that have been tested and testing the interface between them

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Smoke Testing (Build Acceptance Testing, Build Verification Testing, Ad-Hoc Testing)

A

Making sure the build is ready to be tested further by testing the most important functionalities for each module

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

System Testing (End to End testing, System Integration Testing)

A

testing the system as a whole system, making sure the system meets all the functional and quality requirements

28
Q

Functional Testing

A

Testing more detailed/functional behavior of the Application Under Test (AUT)

29
Q

Positive Testing (Under Functional Testing)

A

Making sure the system does what its supposed to do

30
Q

Negative Testing (Under Functional Testing)

A

Making sure the system does not do what its not supposed to do

31
Q

User Acceptance Testing (UAT)

A

a user version of system testing, the customers and end users run the software in a “production-like” environment

32
Q

Black Box Testing

A

testing everything you can see in a program / software (can be done at all testing levels)

33
Q

White Box Testing

A

(Unit Testing) testing the code and behind framework, done by devs

34
Q

Fundamental Testing Process

A
  1. Review Requirements
  2. Test Plan / Test Strategy
  3. Test Execution
  4. Report Results
  5. Perform Regression Testing
  6. Provide Sign Off
35
Q

SDLC Phases

A

Initial
Analysis
Design
Coding
Testing
Delivery & Maintenance

36
Q

Initial Phase

A

the project planning stage where you are gathering business requirements from your client or stakeholders. This phase is when you evaluate the feasibility of creating the product, revenue potential, the cost of production, the needs of the end-users, etc.

37
Q

Analysis Phase

A

formally defines the detailed functional user requirements using high-level requirements identified in the Initiation and Feasibility Phases. The requirements are defined in this phase to a level of detail sufficient for systems design to proceed.

38
Q

Design Phase

A

a stage where software developers define the technical details of the product. Depending on the project, these details can include screen designs, databases, sketches, system interfaces, and prototypes. Clients use these details to make final product design choices.

39
Q

Coding Phase

A

includes system design in an integrated development environment. It also includes static code analysis and code review for multiple types of devices.

40
Q

Testing Phase

A

In this phase, the developed software is tested thoroughly and any defects found are assigned to developers to get them fixed.

Retesting, regression testing is done until the point at which the software is as per the customer’s expectation. Testers refer SRS document to make sure that the software is as per the customer’s standard.

41
Q

Delivery & Maintenance Phase

A

The maintenance phase of the software development life cycle is where the software is monitored to ensure it continues to function as it was designed to, and repairs or upgrades are performed as needed.

42
Q

Software Development Methodologies

A

approach and strategy of developing a software application

Two Main Methodologies: Waterfall & Agile

43
Q

Waterfall Method

A

top-down approach to building an application from ground up. Complete all the steps of the SDLC in order.

44
Q

Waterfall Method Cons

A

Lack of flexibility, difficulty in predicting actual needs for the software, the loss of intangible knowledge between phases, discouragement of team cohesion, and the tendency to not discover design flaws until the testing phase.

45
Q

Agile Method

A

Iterative, starts with initial planning and ends with development with the cyclic iterations in between to develop a software system incrementally.

46
Q

Agile Manifesto

A

values of this method over waterfall
- individuals and interactions over process and tools
- working product over comprehensive documents
- customer collaboration over contract negotiation
- responding to change over following a plan

47
Q

Agile Method Pros

A
  • deployment team receives feedback at early stages in the overall development process
  • rapid feedback from actual user
  • flexibility to address evolving requirements
  • design flaws discovered quickly
  • easy to roll out new functionality in stages
  • higher motivation and great productivity
48
Q

Scrum

A

An agile methodology that uses ‘sprints’ defined in weeks (1-4) works on requirements for set sprint, works on them and delivers them. then moves onto the next continuous cycle.

49
Q

Product Backlog

A

a living document updated and prioritized by the product owner that contains a list of features to be implemented, containing user stories, use cases, defects, and SRCs.

50
Q

Sprint Backlog

A

features selected from the Product Backlog that are to be implemented by sprint and updated on a daily basis

51
Q

Burn Down Chart

A

graph representation of work done and left to be done in sprint, and updated everyday

52
Q

Product Owner (Scrum Team)

A

A representative from the business/client who creates and prioritizes product backing, manages releases, and describes features to a team.

53
Q

Scrum Master

A

responsible for the team to follow scrum/agile values, runs sprint planning and daily scrum meetings, assures teams productivity and efficient communication, guards the scrum team and removes impediments

54
Q

Scrum Team

A

estimate and implement features, sprint backlog to shippable product, track work progress every day, communicate with product owner, scrum master, and alert when there are projects.

55
Q

Sprint Planning Meeting

A

selection, discussion and estimation of features from Product Backlog for current sprint

56
Q

Backlog Grooming Session

A
  • user stories are well-documented
  • making sure requirements are clear
  • making sure every one is well aware of whats coming, or what’s on the queue
  • making sure everyone is updated with previous progress or any issues or problems left
57
Q

Daily Scrum Meeting

A

status of work progress meeting - same time, same place, everyday for 10-15 mins, stand up, no problem solving

each team answers three questions:
- what have i done?
- what am i going to do?
- what problems do i have?

58
Q

Sprint Review Meeting

A

Demonstration of implemented features/defects fixes to stakeholders/business

59
Q

Sprint Retrospective Meeting

A

discussion of goods and bads of the sprint

60
Q

🌟 Role of QA in Agile Environment 🌟

A
  • Continuously study and review all project documentations
  • attend various project/scrum meetings & keep QA team informed
  • capture complex and negative behaviors in AUT, think beyond the “happy path”
  • write Test Case, create Test Script, clarify questions/concerns with PO/PM/BA/DEV/SME
  • pair up with developer for reproducing defects, writing unit test cases and for QA test scenarios
  • perform & automate Regression Testing & Suites
  • perform negative, Boundary & Smoke/Ad-Hoc testing formally/informally
  • be amicable and flexible in providing immediate support to devs in retesting defect fixes and run Regression Test
  • cases/scripts/suites
  • stay focused and informed of new user stories, defect status, test deliverables
  • maintain criteria for DoD (Definition of Done) and improve quality of AUT
  • maintain all test artifacts - Test Strategy, Test Plan, RTM, TC, Minutes, etc.
61
Q

What is a Bug?

A

A software bug is the common term to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result or causes it to behave in unintended ways.

62
Q

How do you know if its a bug?

A
  • software doesn’t do and specs/recs says it should do
  • software does and specs/recs says it should not do
  • software does but specs/recs doesn’t mention
  • software doesn’t and specs/recs doesn’t mention but should
  • software is difficult to understand, hard to use, in the software testers eyes will be viewed by the end user as just plain not right
63
Q

Bug Life Cycle

A

from the start or discovery of a bug to the resolution or closure state of a bug as it goes through different stages

64
Q

Severity

A

how bad/dangerous/severe the bug is and the degree of impact when the user encounters the bug

65
Q

Priority

A

how soon/urgency of fixing the bug, how much emphasis should be placed on fixing the bug and the urgency of making the fix

66
Q

Best Practices of reporting Bugs

A
  1. reproduce the bugs two times before writing bug report and then ask a peer (peer reviews catch 80% of the defects)
  2. test the same bug occurrence on other similar modules/systems / data/environments
  3. report bug immediately
  4. write a good bug summary
  5. use diplomatic language
  6. properly define severity & priority
67
Q

Writing an effective bug report

A
  1. WHAT happened, WHEN, WHERE
  2. IMPACT on user/customer
  3. Clear, Concise, Correct

QA (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions