Showing posts with label qa. Show all posts
Showing posts with label qa. Show all posts

## Monday, September 12, 2016

### QA: Decision Tables as specification-based test design technique

Decision Table Testing: A black-box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table.
Decision Table: A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.
This technique is using to test all possible combination of conditions, relationships, and constraints. Decision tables usually applied for the integration, system and acceptance test levels. Also, this technique could be used for component testing.
The table should describe relationships between conditions and actions.

Template of Decision Table:

Example:

At least one test case should be created for each column. The number of tests will increase in case of boundaries values in conditions. Boundary Value Analysis and Equivalence Partitioning are additional to the Decision Table technique

Type of defects: functional and non-functional defects

## Thursday, September 1, 2016

### QA: Boundary Value Analysis as specification-based test design technique

Let start from definition, per ISTQB glossary:
Boundary value analysis (BVA): a black-box design technique in which test cases are designed based on boundary values.
Boundary Value: an input or output value which is an the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum and maximum value of a range
This technique is an extension of equivalence partitioning technique.  There are two approaches of BVA exists:
• Two values testing.  Only two values selected for each boundary: one value on the boundary and the previous/following value outside the partition. For example, if an equivalent partition is integer range from 10 to 15, the following values should be tested: 9 (outside of the partition), 10 (boundary); 15 (boundary), 16 (outside of partition). Short description: MIN-1; MIN; MAX; MAX+1; Where "1" is the minimal incremental value
• Three values testing. This approach uses 3 value as the basis. One value outside of the boundary, the second value is boundary value, and the third value is inside of partition. For example, if the equivalent partition is an integer from 10 to 15, the following value should be tested: 9 (outside of the partition), 10 (boundary), 11 (inside of boundary); 14 (inside of boundary), 15 (boundary), 16 (outside of partition).Short description: MIN-1; MIN; MIN+1; MAX-1; MAX; MAX+1; Where "1" is the minimal incremental value
Which approach to select? The approach should be selected based on Risks which are associated to tested items. 3-values approach should be selected for the highest risks.
VBA could be applied for ONLY for ordered equivalent partitions. Type of ordered equivalent partitions:
• Numeric attributes of non-numeric variables (e.g., length)
• Loops, including those in use cases
• Stored data structures
• Physical objects (including memory)
• Time-determined activities

Type of defects: functional and non-functional

## Tuesday, August 16, 2016

### QA: Equivalence Partitioning as specification-based test design technique

Let start from definition, per ISTQB glossary:
Equivalence partitioning: a black-box test design technique in which test cases are designed to execute representative from equivalence partitions. In principle, test cases are designed to cover each partition at least once.
What does it mean?

Inputs, outputs, internal values and time-related values should be split into equivalent groups, where values on boundaries and inside of group will lead to the same result.
Each equivalence partition should be tested with valid and invalid values at least once. Multiple values for a single partition doesn't increase the coverage percentage.

Benefits: number of tests significantly descrise

Data set was split into 2 subset with selection of test case of each subset

Data set was split into 2 major subsets and 2 subsets of one of major subsets

Difficulties which can be faced: participation was identified incorrectly. That could mean that invalid values accepted or valid values rejected by the system.

Avoid errors:
a. Subsets shouldn't have a common elements. Each sub set should have unique data elements
b. Subsets shouldn't be empty. Element should exists in data set
c. Subsets union should be equivalent to original set

Types of defect: functional defects

## Sunday, August 14, 2016

### QA: Estimation Techniques

There is bunch of techniques which can be used to estimate QA work.

• Industry averages, metrics, predictive models. Usually it is 30% of development work, but this is the most tricky estimates, for example developers changed store procedure this is approximately 5-8hrs of work for developer, so QA will be 1.5-2.5hrs. For QA this could mean to do full regression of application because this store procedure is using across application.
• Tester-developer ratio. This technique usually based on organization history. For example 4 developers generate work for 1 QA engineers, so QA time will be 0.25 of full development work.
• Experience (intuition, guess) based estimate.
• Team estimation sessions. Estimates can be more accurate estimates when dev lead and BA participate in estimation sessions, more details can be provided and took into account.
• Test case based technique. This estimates can be used only when test cases created, or you can guess how many test cases you will create.
• Bottom-up approach of estimates. Work is breaking down on tasks, each task can be estimated individually and sum of tasks will be overall project estimates.
In addition to provided techniques add additional time for bugs creation and verification, for updating test case, and 30% of estimated time add as risks. Usually when QA starts estimate functionality no one know how this functionality will behave at the result. Better way to overestimate and use less time, than underestimate and use much more time of testing under pressure and not founded bugs.