Posts

BDD with SpecFlow - Features Scenarios Steps and Contexts

Image
SpecFlow is a tool that bridges the gap between business-level behavior specification and the technical implementations of automated testing. SpecFlow is an acceptance criteria definition and testing tool that makes it easier to integrate Behavior Driven Specifications into software projects earlier, in a shift-left fashion. Business value is defined and modeled as Business Features. Those features are built from more granular components, often called User Stories.  The Feature and User Stories contain sets of Acceptance Criteria that represent the target state for the Feature. The Feature is the top-level construct in Specflow/BDD. Gherkin Business Features are made up of a set of Scenarios.   Each Scenario represents one or more acceptance criteria.  Each SCenario is validated as a single automated unit test or a parameter-driven unit test with a list of parameter sets.  One or more features and their associated scenarios def...

Behavior Driven Acceptance Criteria for Features, User Stories and Tests

Image
Behaviour Driven Development (BDD) is an evolutionary outcome of  Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). BDD focuses on business values and is designed to remind everyone that business outcomes are the top priority. Drive repeated iteration around the desired business outcomes. Projects can often get distracted and drift away from the desired functions. Think “from the outside in”. Focus on the behavior that directly targets the desired business outcomes. Do not start inside a system or with a discussion on how tools can be used. Use a standard notation for describing behaviors and acceptance criteria. Select a form that can be understood by Subject Matter Experts and delivery. Some teams pick a syntax that is friendly to automated test tools. Apply these techniques at the top, working down into the dif...

Why do internet sites trust that they know who we are talking to or who they are talking about?

Image
We're flooded with data.  Customers and fraudsters have the ability to submit data, purchase services or products, and interact with corporate edge systems.  Every transaction should be wrapped with the following questions. Who are we talking to?  What is the risk if we don't know? Who are we talking about?   What is the risk if we tie it to someone we already know about? What is the risk of poisoning other data? Be skeptical my friend. Video Presentation Presentation Content Speakers notes will be added later

A sordid tale of customer identifiers - the complexity of knowing when we know

Image
Customer identifiers are the keys we use to bind different bits of information together that we believe represent the same person. This can be more complex than it sounds when you take into account the changing amount of what we know, corporate acquisitions, and partner company interactions. Video Presentation Content Speaker's notes to be added at some future date. A corporation, with divisions that each have apps and with partners. The corporation runs with a single id per person and handles any merge or separation actions by updating all parties. Conway's law: Architecture and communication paths align with organizational structure. Every team does their own thing. Division IDs are bound to the corporate ID at the corporate level. Corporate IDs are bound to the division at the division level.   The corporation creates link ids there shared with the other orgs. The other orgs create link ids and share with the parent corporation.

Non Functional Requirements - NFRs - in Software Systems

Image
NFRs are requirements that do not relate to business functionality. They relate to attributes like reliability, efficiency, and portability. Non Functional Requirements are architecturally significant requirements because they impact the system architecture. They are properties of a system that sit outside of specific business features or functionality. NFRs are sometimes called constraints. Other times they are called Quality Attributes. Constraints generally change the shape of architecture or design. Capturing NFRs early is part of a shift left where we surface the non-business value needs earlier in the process. Non-functional requirements impact the system as a whole and are cross-cutting across business features. when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.   Credit: Jamsoft Project efforts really need to be explicit about capturing their NFRs and updating them. Everyone has been on projects where some techni...