QA ENGINEER

Fundamentals

What is Quality Assurance (QA)

Also know as QA Testing

Quality: "Fit for use or purpose". Meeting the needs and expectations of customers.
Assurance: Positive declaration of a product or service, which gives confidence.
Quality Assurance in Software Testing: A procedure to ensure the quality of the software products or services provided to the customers by an organization.
Testing: Process of evaluating a system or its components with the intent to find if satisfies specified requirements.

Testing vs QA

Goal of software tester is to find bugs.
Software QA person's main responsibility is to create and enforce standars to improve development process and prevent bugs.

The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.

Software Developmente Lifecycle

SDLC

Planning
Analysis
Design
Implementation
Testing and Integration
Maintenance

V Model

Graphical representation of a systems development lifecycle. Summarizes the main steps to be taken in conjunction with the corresponding deliverables.

Left side of the V represents the Verification/Developer's Lifecycle Right side of the V represents the Validation/Tester's Lifecycle

Verification: Quality Assurance. Built according to requirements. Before coding. Review.
- ARE WE BUILDING THE PRODUCT IN THE RIGHT WAY?
Validation: Quality Control. Ensure it meets the user's needs. After coding. Testing.
- ARE WE BUILDING THE RIGHT PRODUCT?

Sotware Testing Lifecycle

STLC

Knowledge Transfer: Review software requirements.
Test Scoping: Test strategy, cost, time, acceptance criteria.
Test Planning: Test plan document, test estimation, traceability matrix.
Test Design: Test cases, based on requirements.
Test Execution: Execute test. Generate Test Results.
Test Reporting.

Test Document

Test plan: describes overall method to be used to verify the software. Includes quality objectives, resource needs, schedules, assignments, methods, and so forth.
Test cases: List the specific items that will be tested and described the detailed steps to be followed.
Bug reports: Describe the problems found as the test cases are followed.
Metrics, statistics, and summaries to convey the progress.
RTM = Requirement Traceability Matrix: Document that links requirements and work products developed to implement and verify requirements.

Bug Lifecycle

Bug/Defect: Condition in a software product which does not meet a software requirement or end-user expectations.

Other names for Software failures:

Defect
Fault
Problem
Error
Failure
Inconsistency
Feature
Bug

At the end, no matter how you call them, a bug is a bug.

We can define a software bug when one or more of the following five rules is true:

Software doesn't do something the requirements says it should do.
Software does something that the requirements says it shouldn't do.
Software does something that the requirements doesn't mention.
Software does't do something the requirements doesn't mention but should.
Software is difficult to understand, hard to use, slow, or by tester's eyes, will be viewed by the end user as not right.

AKA Defect Lifecycle

Severity: How bad the bug is (impact on the software).
Priority: How important it is to fix.

Tester Mindset

POSITIVE PESSIMISM: High confidence not because you ignore the dangers, but precisely becasue you acknowledge and respect them, you do everything possible to avert, mitigate or deal with them.

Main goal: Look for the weak spots in a product, report them back, so that can be fixed, so the product you are working on can be of the highest quality possible.

THINK IN THE MOST DESTRUCTIVE WAY POSSIBLE AND BE AS CREATIVE AS POSSIBLE

Important thing to considerate:

Know the product you are testing.
Don't be afraid to thinkg outside of the box.
Don't be afraid to misuse it as much as possible.
Don't be afraid to break things.

Testing Approaches

White box testing

Technique in which software's internal structure, design and coding are tested to verify input-output flow.

Gray box testing

Technique to test a software product or application with partial knowledge of the internal structure of the application.

Black box testing

Testing method in wich the functionalities of software applications are tested without having knowledge of internal code structure, implementation, details and internal paths. AKA Behavioral Testing.

Static and Dynamic Testing

Static testing: testing something that is not running, examining and reviewing it. Dynamic testing: testing something as you usually do, running and using the software.

Test-to-Pass and Test-to-Fail

Test-to-Pass, assure only that the software minimally works. Make sure the software does what it's specified to do in ordinary circumstances. Test-to-Fail, designing and running test cases with the sole purpose of breaking the software, also called error-forcing.

Tools for Testing Management

Process of managing the testing activities in order to ensure high quality and high-end testing of the application.

Spreadsheets, text files

Something is better than nothing.

qTest

Test management tool used for Project Management, Bug Tracking, and Test Management.

TestRail

Web-based test case management tool. Used to manage, track, and organize software testing efforts.

HP ALM

Set of software tools for application development and testing. Requirements management, test planning and functional testing.

Testing Techniques

Functional Testing

WHAT an application does
Type of software testing that validates the software system against the functional requirements/specifications.
Specifies how the system must behave.

Types of functional testing

UAT
Exploratory Testing
Sanity Testing
Regression Testing
Smoke Testing
Unit Testing
Integration Testing

Non Functional Testing

HOW an application works
Type of software testing to test non-functional parameters such as reliability, load test, performance and accountability.
Describe how the system works, judge operation of a system. How the system should behave.

Types of non functional testing

Load Testing
Performance Testing
Stress Testing
Security Testing
Penetration Testing
Accessibility Testing

Manual Testing

Test Planning

Software test plan is the primary means by which software testers communicate to the product development team what they intend to do. Planning process needs to identify each component of the software and make known wheter it will be tested.

Test plan is simply a by-product of the detailed planning process that's undertaken to create it. It's the planning process that matters, not the resulting document.

Test Strategy: describes the apporach that the test team will use to test the software both overall and in each phase.

Test Cases and Scenarios

Test Design: The overall project test plan is written at a very high level. Breaks out the software into specific features and testable items, but doesn't specift exactly how those features will be tested. Refines the test apprach and identifies the features to be covered by the design.
Test Cases: A test case documents the actual values used for input along with the antifipated outputs. A test case also identifies any constraints on the test procedure resulting from use of that specific test case. Should include:
1. Identifiers: ID to reference in other documents.
2. Test Item: Describes detailed feature, code module, and so on being tested. The name.
3. Input Specification: List all the inputs or conditions given to the software to execute the test case.
4. Output Specification: Describes the result you expect from executing the test case.
5. Environmental Needs: Hardware, software, test tools, facilities, staff, and so on necessary to run the test case.
6. Special Procedural requirements: Anything unusual that ust be done to perform the test.
7. Intercase Dependencies: If a test case depends on another test case or might be affected by another.
Test Procedures: Identifies all the steps required to operate the system and exercise the specified test cases in order to implement the associated test design. AKA Test Script AKA Test Steps
- Identifier: Unique ID to link test cases and test design.
- Purpose: The purpose of the procedure.
- Special requirements: Other procedures, special equipment needed to run the procedure.
- Procedure steps: Detailed description of how to run the test:
  - Log
  - Setup
  - Start
  - Procedure
  - Measure
  - Shut down
  - Restart
  - Stop
  - Wrap up
  - Contingencies

Organization and Tracking

In your head: Just for the lols. Never.
Paper/documents: Possible, but a weak method.
Spreadsheet: Popular and very workable method of tracking test cases.
Custom database/Application: Many options in the market. Mentioned later on.

Reporting

Bug-Tracking Systems

System that allows to log the bugs you find and monitor them throughout their life cycle.

Standard Test Incident Report: Purpose is to document any event that occurs during the testing process which requires investigation.
- Identifier: Unique ID to link to other resources.
- Summary: Brief of the bug, concise statement of fact. Reference to the software, test procedure, test case, and so on.
- Incident Description: Detailed description of the bug with following information:
  - Date and time
  - Tester's name
  - Hardware and software
  - Inputs
  - Procedure steps
  - Expected results
  - Actual results
  - Attempts to reproduce
  - Any other observation that may help the programmer locate the bug (isolation)
- Impact: Severity and priority.

Random testing

Monkeys and Gorillas

Dumb monkeys: a simple program clicking or typing randomly while the applicatio is open. Easy to implement, but this monkey does not verify the software. It will end until it finish its loop or the system chrashes. You can let it run hours in a separate environment.
Semi-Smart Monkeys: If we limit the part of the app that our monkey will click, we give it a bit of intelligence. You can also design it to detect when it crash, so it can restart itself.
Smart Monkeys: Doesn't just pound - pounds with a purpose. Example: Koko.

Usability Testing

Usability is how appropriate, functional, and effective the interaction between the system/app with the user is.

User Interface Testing
Accessibility Testing

Foreign-Language Testing

The process of adapting software to a specific locale or region, taking into account its language, dialect, and culture, is called localization. Testing the software is called localization testing.

Translation issues: It's imnportant that you or someone on your test team be at least a little familiar with the language you're testing.

Compatibility

Software compatibility testing means checking that your software interacts with and shares information correctly with other software, as well as what other platforms and other applications is your software designed to be compatible with.

Backward compatible means it will work with previous versions of the software.
Forward compatible means it will work with future versions of the software.

To begint he task of compatibility testing, you need to equivalence partition all the possible software combinations. Some criteria to decide what programs/platforms to choose:

Popularity: How many people use the system
Age: Versions not older that 2 years
Type: Categories, like writing, accounting, databases, so on.
Manufacturer: Based on the company that created it