Thẻ ghi nhớ: Software Testing - Q1-20 | Quizlet

Buggy Program

Program that contains a large number of bugs and/or bugs that interfere with its functionality.

Quality Assurance

To assure the quality of an application or software by testing its security, performance and functionality throughout the Software Development Life Cycle and providing bug free software.

Software Testing

The process of finding bugs in software and verify/validate if the software works properly. Detect the defect.

Quality tested software?

Meets the customer's requirements/expectations

Time to market

Cost of product

99% defect free

Project Manager (PM)

Creates the plan and manages the project.

Responsible for consistent reporting, risk mitigation, timeline and cost control.

Project Manager (Subject Matter Expert)

Expert in the software, knows everything about it and how it should work.

If QA has questions or is uncertain, they ask the SME about the functionality of the application.

Business Analyst (BA)

The middle man between the client and the company.

Gathers all the information about the software that the team will build for the company.

Creates all the requirements in the BRD.

Developer/ Programmer

The Developer is responsible for developing the software by writing the code. Heart and soul of the software development team

QA Automation Engineer

Person who automates the testing process using QTP, Selenium or any automation tool.

Why is software testing important?

Software testing is important because bugs are expensive and dangerous.

Samsung Galaxy 7 phone recall cost the company 10 billion dollars

China Airline Airbus bug caused crash with 264 deaths in 1994

Software bug

Error, flaw or mistake in a computer program that causes it to behave incorrectly

QA Manager

Manager of QA team. Reports to the Director.

QA Lead

QA Tester Leader. Reports to the QA Manager.

QA Tester

Tests the software by testing it's secure, performance and functionality.

QA Analyst

Tests the software throughout the Software Testing Life Cycle (STLC).

UAT Tester

User Acceptance Tester

BRD

The document created by the BA that defines the customers requirements to be developed as software. Also known as CRS or URS

(Customer/Use Requirement Specification)

BDD & SRS and who creates it?

Software Requirement Specification & Business Design Document.

Created by the BA

DDD & TRD and who creates it?

Detail Design Document &

Technical Requirement Document.

Created by the Developer

GUI

Graphic User Interface

AUT

Application Under Test

SCR

Service Change Request

RTM

Requirement Traceability Matrix.

Map between the test case & requirement

SOP

Standard Operating Procedure used in a variety of different contexts.

Test Data

Real or fake/dummy data used during testing.

ETL

Extract Transform Load. 3 databases migrate data from one database to another; transfer data

DBA

Database Administrator. Manages the database, QA will ask DBA for data

Artifacts

Any document that goes into the project, test strategy, test plan, etc

Landing Page

Homepage

Showstopper

Major bug that prevents future testing

HotFix

A bug that should be fixed right away

Defect

A bug in the application or fault in the system.

Fundamentals of the Testing Process

(TTTTC)

1. Test Planning

2. Test Case Specification

3. Test Case Execution

4. Test Recording - Bug Reporting

5. Check for test completion (exit criteria)

Manual Testing

Manually testing the software or application for defects w/o test automation.

Tester plays role of end user and tests all features of application to ensure its correct.

Tester writes the plan & test cases to ensure test completeness.

Process of Manual Testing

(USPERC)

1. Understand the BRD

2. Specify Test Cases

3. Prepare the test environment

4. Execute test case manually

5. Record test result: pass/fail?

6. Check for test completion

What is Automated Testing?

Automating the manual testing process by writing a computer program to do testing.

Once the test has been automated, it can be ran over and over, reused later and executed faster.

Process of Automated Testing

(APAERA)

1. Analyze the application

2. Prepare the Testing Environment

3. Adding Steps to Test

4. Enhance Test

5. Running & Debugging Test

6. Analyzing Run Result and Reporting Defect

Benefits of Automated Testing

FERRP

Faster, eliminates human error, reusable, reliable and programmable

Disadvantages of Automated Testing

DNMT

1. Debugging testscript is major issue

2. Need Proficiency to write automation testscript

3. Maintenance of test data files is difficult

4. Test maintenance is costly.

What are the 6 types of Testing that can be automated?

(FRELPS)

1. Functional Testing: testing the functionality of the application to make sure it's working properly

2. Regression Testing: retesting the application to make sure behavior has not changed

3. Exception or Negative Testing: forcing error conditions in the system to test it's response

What are the 6 types of Testing? (4-6)

4. Load Testing: testing to determine at which point does the capacity & performance of the system begin to degrade to where hardware & software updates would be required

5. Performance Testing: testing if the application can meet the demand during peak & off peak times Ex. 200mill users on site, will it crash?

6. Stress Testing: determining the absolute capacities of the application

Use Stories

A conversation between the BA and the client during which the BA takes notes on how the app will need to work, and it answers the who, what and the why.

Use Case

A step by step sequence of actions between the user and the system. It's a document that describes the user action and system response for a particular functionality. BA creates.

Contents in a Use Case

General Information

Primary Flow

Alternative Flow

Assumption

Change Log

Data Source

Description of Process

Definitions of the contents in a Use Case

1. General Information: UC Names, ID, Project Name

7. Primary Flow: most common way to accomplish

5. Alternative Flow: other ways to accomplish

2. Assumption: Pre-condition and post condition

4. Change Log: Who is making the change and what is it?

5. Data Source: Where is needed data coming from? Client, DBA, etc

6. Description of Process: What, how, what?

Requirements

What the client wants or desires from a system, what they want the system to do?

Requirements should be in S.M.A.R.T.

Unclear or poor requirements are the biggest challenge in the QA industry.

What should requirements be?

(CCCDAT)

Clear, complete, cohesive, detailed, attainable and testable

S.M.A.R.T Requirements

Specific: Does it address a real business problem?

Measurable: Are we able to measure the problem and set targets for improvement?

Attainable: is goal achievable, is completion date realistic?

Relevant: Does it relate to a business objective?

Time Bound: Have we set a date for completion?

Non-Requirements

Non-Requirements may not be listed in BRD but you must have them.

Security: access level

Performance: how fast

Usability: User friendly, easy to use

Reliability: how often

Supportability: modify app updates

Test Case

A document that describes the step by step process on how to test the single behavior or function of an application

What does the Test Case include?

Test Case Name

Test Case ID

Design Steps

Description

Step #'s

Pre- Condition

Post-Condition

Input

Expected Output

Actual Output

Pass/Fail?

Remarks

Test Scripts

Test scripts are written in a scripting language to record specific interactions in order to test the single behavior of the application. Also known as Design Steps.

Test Suits

Test Suits are when you group the test case, requirements and test scripts together to test the application and show the relationship between them.

Test Plan

(FARSS)

The test plan is a document that describes the focus, approach, resources, scope and scheduling of a software testing effort

The test plan is the overall approach to testing as it identifies the test items, tasks and who will do each task, the features to be tested, and any risks/solutions

What does the Test Plan include?

(FFIRSTT, FASTTT, REGRASS)

Features to be tested

Features not to be tested

Introduction

References

Software Risk Issues

Test Plan ID

Test Items

Features Pass/Fail Criteria

Approach

Suspension Criteria

Testing Tasks

Testing Environment

Test Deliverables

Risks and Mitigations

Entrance and Exit Criteria

Glossary

Responsibilities

Approvals

Schedule

Staff and Training Needs

Test Strategy

The test strategy follows the testing portion of the SDLC. Its an overall description of how the software will be tested and is created to inform the PM, developers and testers about key issues in the testing process.

Test Strategy 1-6

(SBTTRC)

1. Scope and Objective: The objective of the company and the scope needed for testing

2. Business Issues: Budget, resources and time needed for the project

3. Testing Approach: Map between development stages and testing issues

4. Test Deliverables: Required testing documents needed before and during testing

5. Roles and Responsibilities: What are the roles in the testing team and their responsibilities during testing

6. Communication and Status Reporting: Required negotiation between every two consecutive jobs in the testing team

Test Strategy 7-12

(TTRCTD)

7. Test Automation and Testing Tools: Availability of testing tools and purpose of automation testing

8. Test Measurement and Matrics: QAM, TMM, PCM

9. Risks and Mitigations: Possible raised problems during testing and solutions to overcome

10. Change and Configuration Mngt: How to handle change requests from customers during testing and maintenance

11. Training Plan: Required training sessions for testing team to understand business logic

12. Defect Reporting and Tracking: Required negotiations between testing team and development team to fix and resolve defects

Waterfall methodology

Top down approach. Move to next step only after first step is completed. No jumping back or forward or performing 2 steps at once.

Follows the SDLC, so bugs can't be discovered until the testing phase.

Advantages of Waterfall

(SFD)

Simple to follow

Fewer resources are needed to implement

Documentation is produced at every stage making it easier to understand the product

Disadvantages of Waterfall

(NBC)

No working features get to client until software is ready

Bug/defects can't be discovered until testing phase

Can't go back a step or add new features in the middle of the phase

Iterative Methodology

Iterative develops software incrementally. Software is divided into various parts then developed then sub-parts are integrated when ready. Each iteration lasts 2-6 months

Advantages of Iterative

(R DMC)

Rapid feedback from client

Design flaws are discovered quickly

More communication between SDLC Team

Corrective actions can be taken at the end of each iteration

Disadvantages of Iterative

Difficult to manage and coordinate large teams

Difficult to freeze requirements as they may change in later iterations due to increasing customer demands

Agile Methodology

Agile, like iterative is broken into small increments referred to as "Timebox" or "Sprints" that last 2-4wks. Its currently the most acceptable and used methodology.

Agile Manifesto

(CRIW)

Customer collaboration over contract negotiation

Respond to change over following a plan

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Advantages of Agile

(CCWMD)

1. Customer satisfaction by rapidly delivering useful software

2. Can change requirements, even late in development

3. Working software is delivered frequently

4. More testing is done, so better software quality is delivered

5. Daily face to face co-operation between business people and developers

Development Methodologies that make up Agile

Feature Driver Development (FDD)

Extreme Pairing (XP)

Scrum

Crystal Clear (CC)

Scrum

Scrum is a cross-functional team effort where projects are divided into sprints that last 1-4 weeks. At the end of each Sprint, stakeholders and team members meet to assess the project's progress and plan next steps.

Extreme Paring XP (Agile)

In XP, once coding is complete, testing immediately starts. 1 tester for 1 developer.

Feature Driver Development FDD

FDD delivers tangible and working software repeatedly in a timely manner

Crystal Clear

Crystal Clear is people centric and focuses on enhancing the work of the people involved. Focuses on small tasks and then builds them into larger ones.

The Roles of Scrum

1. Scrum Master: person who maintains and manages the scrum process

2. Product Owner: represents client voice and takes ownership of the project. Knows what the product should look like and how it should work

3. Scrum Team: 1 developers = 3 tester

Scrum Process

Project is divided into Sprints that take 1-4wks during which the team creates working and tested software.

The set of features that go into a Sprint come from the Product Backlog, which prioritizes high level requirements to be completed.

The backlog items that go into the Sprint are determined during the Sprint Planning Meeting.

Scrum Process (continued)

During the Sprint Planning Meeting, the Product Owner informs the team about backlog items that need to be completed.

During the Sprint, requirements are frozen, so nobody can change the Sprint Backlog.

After the Sprint is complete, the team demonstrates the software which is called the Sprint Review Meeting. (demo)

Sprint Planning Meeting

The Sprint Planning Meeting is an 8hr meeting held with the team at the beginning of every Sprint cycle.

Identifies what work needs to be done, how long will it take (prepared in Sprint Backlog) and what work will be completed during the current Sprint.

Spirit Planning Meeting (continued)

Product Backlog prepared prior to meeting.

1st half of mtg, team selects items committing to complete.

2nd half, Product Owner is available for questions, tasks are assigned and Sprint Backlog is produced

Daily Standup Meeting

Daily Scrum is a 15min meeting with the SDT team every day during Sprint, same time & location, even if all members aren't present.

Daily Scrum is facilitated by the ScrumMaster and all members of the team come prepared w/ updates and answer the same 3 questions.

Scrum of Scrum

After the daily scrum, the manager or Lead from each team can have a mtg with their own team that mirrors the Daily Standup Meeting. They give updates and answer the same 3 question.

Sprint Review Meeting

After the Sprint is complete, the team (demo)nstrates the software. 4hr time limit.

Team presents "done" code to PO and stakeholders, feedback generated then Scrum Master schedules next Sprint Review.

Sprint Retrospective Meeting

Meeting held at the end of every sprint, after the sprint review meeting. Facilitated by the ScrumMaster, the team comes together to discuss what went well and ways to improve in the next sprint. The PO does not normally attend this 3hr mtg.

Product Backlog

The PB is an ordered list of requirements for the project.

Ordered based on risk, business value, dependencies, and date needed.

PO manages this document, any features added to the PB are written in story format.

Sprint Backlog

The Sprint Backlog is the list of work that the development team needs to address in the next Sprint

It describes how the team will implement those features and the features chosen from the PB go into the SB

Burn Down Chart

Publicly displayed chart updated daily by the PM that shows remaining work in SB. Gives view of what has been completed, any progress, what needs to be done.

V Model Methodology

Process where development and testing can be parallel. For every development phase, there is a testing phase. Development phases are called verifications, testing phases are called validations.

Glossary Terms

time box: period of time to finish a task. End date is set and cannot be changed.

Chickens: people that are not committed to the project and are not accountable for deliverables

Pigs: People who are accountable for the projects success

single wringable neck: Product Owner

Use Story (continued)

Each story is captured as a separate item on the Product Backlog

Story example: As a , I want so that

Story Points

Simple way to initially estimate the level of difficulty expected to develop. Usually

1= very easy 10 = difficult

Ex. "Shopping cart" Story points = 9

Business Value

Each user story in the Product Backlog should have a corresponding business value assigned (L,M,H) High value is prioritized.

Estimate Team Capacity

Capacity = #teammates (Product hrs x Sprint Days)

Capacity = 4members x 5hrs x 30days = 600hrs

Velocity

The rate at which the team converts items to "DONE" in a single Sprint

Scrum Master

Holds daily Scrum during sprint, removes obstacles and shields team from external interference.

At the end of the Sprint, facilitates the Sprint retrospective mtg.

Process of Scrum

SP -> SB -> Sprint-> Daily Scrum -> SReviewM (shippable product) -> SRetroM

Task Board

Board containing the daily sprint burndown chart, Sprint goals, backlog items and various tasks

Software Development Life Cycle Phases

Initial Concept Phase (initial concept)

Analysis Phase (information gathering)

Design Phase (architecture phase)

Coding Phase (development phase)

Testing Phase (single stage of testing phase)

Delivery & Maintenance (support phase)

Software Development Life Cycle

Information gathering specifies what and analysis specifies how.

Once information is gathered from the customer an analysis is formed on the collected information.

Then by using this information, architecture is prepared, known as design. The design is passed onto the development team for coding.

Software Development Life Cycle (continued)

Once the development team develops the software, it is passed through a single stage of testing.

Finally, after testing, software is then delivered to the customer..

Once the customer starts using the software, the maintenance of the software is the main concentration.... by giving the customer support in case any problems occur while they're using the software.

Initial Concept Phase

During the Initial Concept Phase,

Kick off meeting takes place, QA takes notes,

Project Manager develops proposal, Engagement Manager (EM) discusses all financial matters.

BA then gathers all the information and requirements into one template that goes to the client then prepares the BRD, URS, BDD etc

Analysis Phase

During the Analysis Phase,

Project Manager prepares the project plan on who is doing what, when and how and which environment is needed.

The BRD or BRS or SRS document will be taken only as input.

QA during analysis phase, reads project plan and all documents.

Design Phase

During the Design Phase, applications are designed in two leaves:

Functional Design and Internal Design.