Skip to content

Instantly share code, notes, and snippets.

Last active September 7, 2017 12:43
Show Gist options
  • Save vpalos/a4d018e6a923a6007722d635229c044d to your computer and use it in GitHub Desktop.
Save vpalos/a4d018e6a923a6007722d635229c044d to your computer and use it in GitHub Desktop.
company: DevFactory
version: 2.0
# This document represents an L1 specification which describes in thorough
# technical detail a single Milestone; it can consist of a single file, or
# multiple files, imported via referencing.
# Syntax is [SpecL Markdown](https://...) (i.e. Markdown + Gherkin).
title: >
L1 Spec: {/Metadata/Product Name} -
{/Metadata/Release Name} -
M{/Metadata/Milestone Number}
header: >
L1 Spec: **Milestone {/Metadata/Milestone Number}**
Release {/Metadata/Release Name}
{/Metadata/Product Name}
footer: >
L1 schema version {schema: version} - Author: {/Metadata/Owner | "Unknown"} - {schema: company | "DF"}
# This is expected to be the first section of the Spec and it contains
# complete identification information.
# Short Capitalized Product Name.
Product Name: "MySuperProduct"
# Usually a version number, but can be a name also.
Release Name: 1.23
# (optional) Link to the parent L2 Spec (if any).
L2 Spec Link: ""
# A simple integer denoting the milestone count.
Milestone Number: 3
# A name for this milestone.
Milestone Name: "Optimization"
# A ticket code, such as JIRA-123.
JIRA Ticket: "CMSP-291"
Owner: ""
# URI always pointing to the original spec.
Original: "{this}"
# Complete this list to introduce any acronyms or jargon used in this spec.
# Capabilities fall into a number of different Capability Types. This is expected
# to expand over time as our product management and engineering practices evolve.
# Any TPM should feel empowered to define a new capability type and template and
# add it to this repository.
Summary: All GET API calls return under 20ms.
Definition: >
Feature: Some terse yet descriptive text of what is desired
Textual description of the business value of this feature
Business rules that govern the scope of the feature
Any additional information that will make the feature easier to understand
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: The system is responsive with 100k users registered
Given there are 100,000 users registered on the system
When I create a new account
Then I should be taken to my dashboard within 5ms
Scenario: The system is responsive with 1000 concurrent users on the homepage
Given 1000 users are hitting the homepage simultaneously
Then each user should get a response within 2ms
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment