QaNote

Testing Mindset: Testing is the process of executing a program with the intent of finding errors.

=Psychology= =Test Types= acceptance{ stress/load{ functional{ integration{ unit; } // out of integration } // out of functional } // out of stress/load } // out of acceptance
 * Testing is the process of executing a program with the intent of finding errors
 * prove the existence of defect
 * Integration tests, ...different units of work are combined into a workflow.
 * Functional tests, corresponds to testing application use cases.
 * Stress and load tests, ...how well will the application perform when many people are using it at once.
 * Acceptance tests, ...the application must also meet the customer’s needs.

Three flavors of unit tests: logic, integration, and functional. functional unit test{ integration unit test{ logic unit test; } // out of integration }
 * Unit Testing
 * Logic unit test
 * A test that exercises code by focusing on a single method. You can control the boundaries of a given test method using mock objects or stubs.


 * Integration unit test
 * A test that focuses on the interaction between components in their real environment (or part of the real environment). For example, code that accesses a database has tests that effectively call the database


 * Functional unit test
 * A test that extends the boundaries of integration unit testing to confirm a stimulus response.

=Testing Techniques=
 * Black Box Test
 * Functionality Testing
 * GUI Testing
 * Performance Testing
 * Stress and Load Testing
 * Compatibility Test
 * White Box Testing
 * Code Coverage
 * Path Coverage
 * Code Analysis


 * Manual Test
 * Automation Test
 * Development Process Study
 * Testing Tools Selection
 * Implementation

=Strategies=
 * Black-Box Testing
 * exhaustive input testing (impractical)
 * unconcerned about the internal behaviour and structure;
 * concentrate on finding circumstances in which the program does not behave according to its specifications.


 * White-Box Testing
 * aka: logic-driven testing (may NOT cover the specification)
 * exhaustive path testing (impractical, missing critical path, insufficient without exhaustive input test)

Test Design

 * 1) Identifying Equivalence Classes - EC
 * 2) If the input condition is a range of values,
 * 3) * identify one valid EC (between) and
 * 4) * two invalid ECs (lower and greater);
 * 5) If the input condition specifies a set of input values and there is reason to believe that the program handles each one differently,
 * 6) * identify a valid EC for each input and
 * 7) * one invalid EC.
 * 8) If the input condition specifies a 'must be' situation,
 * 9) * identify one valid EC and
 * 10) * one invalid EC.
 * 11) If there is reason to believe that the program does not handle elements in an EC identically, split the EC into smaller ECs.
 * 12) Defining the test cases
 * 13) Assign a unique identifier to each EC.
 * 14) Write test cases to cover all the valid ECs. A single test case can cover more than one EC.
 * 15) Write test cases to cover all the invalid ECs. A single test case can cover one and only one invalid EC.

Black Box

 * 1) Equivalence Partitioning;
 * 2) Boundary-value analysis;
 * 3) Cause-effect graphing;
 * 4) Error guessing.

White Box
Refer to test case design
 * 1) Statement coverage;
 * 2) Decision coverage;
 * 3) Condition coverage;
 * 4) Decision/condition coverage;
 * 5) Multiple-condition coverage.

=Testing Principles= Refer to basic principles
 * 1) A test case must include a definition of the expected output or result.
 * 2) An explicit description of the input
 * 3) A precise description of the correct output for that set of input
 * 4) A programmer should not test his/her own program.
 * 5) A programming organization should not test its own programs.

=Full Life cycle=
 * 1) Identify Requirements
 * 2) Acceptance Criteria
 * 3) Strategy and Design
 * 4) Planning
 * 5) Executing
 * 6) Defect Tracking and Bug Fix
 * 7) Review and Audit
 * 8) Acceptance and Baseline
 * 9) Identify Requirements

=Testing Process=
 * V-Model open
 * Defect prevention
 * Detect the abnormality.
 * Stop what you’re doing.
 * Fix or correct the immediate problem.
 * Investigate the root cause and install a countermeasure.

=Methodologies=
 * Agile click
 * Waterfall click

=Agile Testing Challenges=
 * Team may not value testers;
 * Testers may not value team;
 * Unclear role of testers on the team;
 * Testing is often squeezed to the deadlines;
 * Developers and tester are often in different operational silos;
 * Team may not have the skills/domain expertise/time/attention to develop/execute test cases effectively.

Reference click

=Automation Testing=

Concepts

 * TDD
 * BDD / DDD
 * CDT
 * James Bash
 * Context-Driven-Testing

Automation Frameworks
Why automation?
 * Provides safety net
 * Supports rapid iterations
 * Provides footholds to keep notching upward
 * Provides rapid feedback
 * Focuses effort on what is valuable
 * Frees people to do their best work

TDD Test Driven Development

 * Test Driven Development / Test First Development
 * JUnit
 * TestNG


 * Parallel
 * Run JUnit in parallel click
 * Maven fork option click

Web Testing

 * Links
 * Random name generator fakename listofrand-name


 * Selenium Note
 * s free and open source
 * have a large user base and helping communities
 * have cross Browser compatibility
 * have great platform compatibility
 * supports multiple programming languages
 * has fresh and regular repository developments
 * supports distributed testing
 * soapUI
 * Browsers
 * Firefox + XPath Checker (Right click -> View XPath)
 * Chrome + XPath Helper (X + Shift + Ctrl)

Mobile Testing
See also: xamarin, appium
 * Appium
 * click
 * dmg
 * SauceLab
 * sauce-lab-java
 * nativedriver click

Android Testing

 * What to test
 * 1) Activity Testing
 * 2) Content Provider Testing
 * 3) Service Testing


 * How to test
 * UiAminator click
 * By api

Espresso

 * guide
 * kit
 * guide
 * cheat-sheet
 * configure and guideline
 * ViewMatcher api withId hamcrest cheat sheet
 * Espresso api onView
 * Setup and launch click
 * ViewActions api click
 * Advanced Android Espresso click/slide

Instrumentation
See also
 * Instrumentation api
 * seledroid click
 * uiautomator click
 * android-uiautomator-server click
 * android-uiautomator-json-rpc-server click
 * python wrapper uiautomator click
 * trade federation click
 * google testing-support-lib click
 * top-5 frameworks click
 * robotium solo ext-solo
 * robolectric click
 * monkeyrunner click
 * Android ChromeDriver click

iOS Testing

 * iOS testing guide click
 * iOS click
 * ios-driver click

Cloud Testing

 * SauceLab java+mobile+saucelab

BDD Behavior Driven Development

 * Cucumber Ruby
 * Cucumber Learning Note incomplete
 * Watir / Watij
 * Cucumber-jvm
 * Cucumber-jvm Learning Note in-progress
 * Parallel click
 * IBM Automated testing with Selenium and Cucumber click
 * RSpec
 * Concordion (readable bdd)
 * fitnesse (wiki to bdd cases)
 * JBehave
 * jBehave Learning Note

Defect Detection
Tbd

Defect Prevention
Tbd Refer software-defect-prevention-nutshell

=Test Management=

TestLink

 * Get Started with TestLink click
 * TestLink requires httpd server, Apacheloungh click
 * TestLink and LDAP click
 * How to Update TestLink Test Case Execution Status Remotely Through Selenium click

Zephyr

 * REST API click click jira-rest
 * Create test step click
 * Zephyr SOAP API v4.6

=Continuous Integration=
 * Continuous Integration
 * Jenkins

=Mobile Test=

Likely Failure Criteria
Refer to https://selenium2automate.wordpress.com/tag/symptoms/
 * 1) You are using indexes in too many places so as to identify elements in your screen.
 * 2) You are using Image recognition or OCR extensively and not for content verification.
 * 3) When running the same script on a device with different screen sizes, it never works on the first try.
 * 4) Scrolling the device screen is coordinate-based and very hard to stabilize.
 * 5) You are wasting more time in stabilizing your tests than on building them.
 * 6) You feel frustrated every time you open the test environment due to its slowness and unpredictability
 * 7) You are working for several months but only have a dozen tests
 * 8) You can’t remember the last time that all the tests ran successfully.
 * 9) You aren't controlling all the parts of your automation environment such as devices and versions
 * 10) You are masking the project status from your managers.
 * 11) You don’t have a process where the tests run 24/7.
 * 12) Deploying the build production (IPA / APK) from the R&D is a manual process.

=Oogler Testing=

Roles
SET/TE who can programs effectively in multiple languages.
 * SWE - Software Engineer
 * SET - Software Engineer in Test
 * TE - Test Engineer

Responsibilities

 * SWE write test code
 * SET - write test infrastructure
 * TE - execute, track, coordinate and ... the tests.

=Certificate=

ISTQB

 * http://swtestengineers.blogspot.com.au/2012/04/full-study-material-for-istqb.html
 * http://istqbexamcertification.com/category/fundamentals-of-testing/

=Blogs=
 * Pairing With Developers: A Guide For Testers click