Pypict Skill

Pypict Skill

Overview

This skill is for pairwise test generation using a PICT-style model: define parameters, reduce raw inputs into meaningful value classes, encode invalid combinations as constraints, preserve must-run scenarios, then review the generated set before execution.

Use it when you need to shrink a large combination space into a manageable test set without pretending pairwise coverage is the whole strategy.

This skill keeps the original community identity and scope, but the workflow below is written for execution rather than intake packaging. Provenance can still be preserved when needed, but the primary goal is to help the operator produce a sound pairwise model and a defensible test set.

When to Use This Skill

Use this skill when:

• you have multiple independent or semi-independent parameters and the full Cartesian product is too large to run
• you need a representative combination set for configuration matrices, form inputs, compatibility testing, API option combinations, feature flags, browser/device matrices, or role/content-type/mode combinations
• the task depends on modeling valid and invalid combinations clearly before generating tests
• you already know that some cases are mandatory and want to retain bug repros, regressions, or required scenarios alongside generated pairwise coverage
• you need a practical first-pass combinatorial test design method before adding deeper targeted tests

Do not use this skill alone when the request is primarily about:

• authentication, authorization, privilege transitions, or abuse-case testing
• stateful workflows, sequencing, retries, timing, concurrency, or race conditions
• cryptographic behavior, protocol correctness, or safety-critical logic
• boundary-value analysis for numeric parsing, length limits, or serialization edge cases
• fuzzing, malformed input exploration, or attacker-driven negative testing
• situations where known defects are likely to require 3-way or higher-order interactions rather than pairwise only

If the request includes those concerns, use pairwise generation as one input to the test plan, then add targeted tests separately.

Operating Table

Workflow

1. Confirm the real objective

Before modeling anything, identify:

• what system or interface is under test
• which dimensions actually interact
• what type of defect you are trying to expose
• whether pairwise coverage is a reasonable default or only a partial helper

Good fit:

• browser × auth mode × MFA state × account state
• API method × content type × auth role × feature flag
• OS × runtime × locale × storage backend

Poor fit unless supplemented:

• multi-step purchase or approval workflows
• privilege escalation scenarios
• sequence-sensitive state machines
• malformed-input or parser-hardening work

2. Model parameters as behaviorally distinct values

Do not dump every literal production value into the model.

Instead, reduce each parameter to values that represent distinct behavior, risk, compatibility mode, or boundary bucket.

Ask for each value:

• does this value behave differently from the others?
• does it represent a different rule, permission, protocol path, rendering path, or failure mode?
• is it a meaningful boundary or compatibility bucket?

Prefer:

• Role: Anonymous, User, Admin
• ContentType: JSON, Form, Multipart
• AccountState: Active, Locked, Unverified

Over:

• dozens of usernames
• every locale variant when only a few behavior classes matter
• many feature-flag permutations that collapse to the same code path

Record assumptions for anything you merge or omit.

3. Encode invalid combinations as constraints

The model should represent what is validly testable.

Add constraints for combinations that cannot or must not occur, such as:

• anonymous users cannot have MFA enabled
• a locked account cannot complete a normal login success path
• multipart upload is unavailable for a specific API route
• browser-specific features are unsupported on some platforms

Constraint guidance:

• keep each constraint narrow and readable
• attach a plain-English reason in your notes
• build constraints incrementally rather than all at once
• prefer explicit business-rule constraints over vague cleanup after generation

If the generator produces unrealistic cases, you likely missed a constraint. If generation fails or output collapses too far, you may have over-constrained the model.

4. Preserve must-run scenarios

Pairwise generation should not displace:

• known bug reproductions
• regression cases
• compliance-required scenarios
• security abuse cases
• critical-path business flows

Keep these as seeded scenarios in the model when supported, or maintain them as a separate always-run list if your local workflow handles them outside the generator.

5. Generate the pairwise set using your local PICT-compatible workflow

Use the generator available in your environment according to its official documentation or team wrapper.

At generation time, verify:

• the model loads cleanly
• the resulting set size is plausible for the modeled dimensions
• obvious must-cover interactions appear to be represented
• no generated row violates known business rules

Do not treat generation success as proof that the model is good.