← all publishers

santoshhundekar-qa

@santoshhundekar-qa source repo

4 published skills

  1. Bug Report · santoshhundekar-qa bundle
    Draft a structured, reproducible bug report from a failure description, error log, stack trace, screenshot, or observed unexpected behavior. Always use this skill when asked to file a bug, write a defect, report an issue, or when the user pastes an error/log/screenshot and describes something not working as expected — even without the word "bug" (e.g. "this button doesn't do anything", "getting a 500 here", "this should say X but shows Y"). Do not use for feature requests or general questions about how something works.
    0 installs
  2. Test Case Design · santoshhundekar-qa bundle
    Design comprehensive, automation-ready test cases from a Jira story, user story, acceptance criteria, or feature description, in the team's Qase import format. Always use this skill whenever asked to write test cases, design test scenarios, prepare test coverage, or figure out what QA should check for a story or feature — even if the user doesn't say "test case" explicitly (e.g. "what should I test for this story", "get me ready to test this feature", "create TCs for JIRA-482", "give me minimal test cases for this"). Also use it when the user pastes a user story or acceptance criteria and asks what to do with it.
    0 installs
  3. Test Data Generation · santoshhundekar-qa bundle
    Generate sample/test datasets (valid, invalid, and boundary values) for a field, entity, or API payload, in CSV, JSON, or SQL insert format. Always use this skill when asked to generate test data, create fixtures, produce sample records, or build seed data for testing — even when phrased casually (e.g. "give me some sample users for this form", "I need dummy orders to test with", "generate 50 rows for the customers table"). Never use real customer/PII data — always synthetic.
    0 installs
  4. Field Validation Errors · santoshhundekar-qa bundle
    Define or review field-level validation rules and the exact error messages a form/API should show, and generate the test cases that verify them. Always use this skill when asked to design validation rules, write error message copy, review whether validation is consistent, or test that a field correctly rejects bad input — even when phrased as "what should happen if a user enters X", "check our error messages for consistency", or "what validation does this field need". Distinct from test-data-generation (which produces sample values) and test-case-design (which covers a whole story) — use this one when the focus is specifically the validation rule and its error message.
    0 installs