Built-in Quality through Vertical Slicing of User Story, BDD scenario writing and Test Pyramid

Developing product with Built-in quality is always desired outcome. Organizations follow various strategies for the same such as horizontal slicing, acceptance criteria and end-to-end automation testing. In this session I'm going to explain how it can be achieved through:

Vertical slicing is a technique used to develop software by driving a thin vertical slice (cross-sectional slice through the layers), which is functionally coherent and demonstrable, then progressively widening it with consecutive slices

BDD stands for Behavior Driven Development and BAs, Dev and testers collaborate and write scenarios to cover expected behavior of application

Test Pyramid highlights that we should have more low-level tests (such unit tests) than high-level tests (end-to-end tests).

I have used them effectively while coaching various teams. I'm going to share my experience supporting real time examples through this session.

 
2 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Introduction User story tasking: 5 mins
Horizontal Vs. Vertical Slicing: 5 mins
Techniques for vertical slicing: 10 mins
BDD scenario writing and vertical slicing: 5 mins
Test Pyramid in vertical slicing: 10 mins
Conclusion and Questions: 10 mins

Learning Outcome

Understand the importance of vertical slicing of user story
Importance of BDD scenario writing
Effective usage of Test Pyramid in vertical slicing
Challenges
Learning from case study

Target Audience

BA, PO, Developer, Tester

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Sergey Shishkin
    By Sergey Shishkin  ~  1 year ago
    reply Reply

    Hi Vinay,

    Thanks for your proposal! To make your talk more appealing to the audience, would you mind expanding the abstract a little bit? In particular:

    • You mention terms like vertical slicing, BDD, test pyramid, which the audience might not be familiar with. Could you describe each in a sentence?
    • Could you elaborate which other strategies teams are using today to achieve the same goal? Audience might relate better to the talk if they see familiar practices. Are those practices effective? How do they relate to the ones you propose?
    • Vinay Krishna
      By Vinay Krishna  ~  1 year ago
      reply Reply

      Hi Sergey - Thanks for your comments. Please find below the details as per your comments:

      Vertical slicing is a technique used to develop software by driving a thin vertical slice (cross-sectional slice through the layers), which is functionally coherent and demonstrable, then progressively widening it with consecutive slices

      BDD stands for Behavior Driven Development and BAs, Dev and testers collaborate and write scenarios to cover expected behavior of application

      Test Pyramid highlights that we should have more low-level tests (such unit tests) than high-level tests (end-to-end tests).

      Other strategies

      Horizontal slicing - The traditional approach to building a big feature was to decompose in into the work that had to be done at architectural layers. This leads to a situation of many un-finished work at specific layers at the end of sprint which are non-demonstrable

      Acceptance Criteria - This is written along with user story. While it's good to have acceptance criteria along with user story, however scenarios are more effective and easy way to write criteria and also helps to find more about the domain

      More end-to-end test automation and less low-level tests also lots of manual end-to-end test. 

      Let me know if you need further details.

      • Vinay Krishna
        By Vinay Krishna  ~  1 year ago
        reply Reply

        Thanks Sergey! I have updated the abstract now. Please have a look and provide your expert opinion.

        Thanks,

        Vinay

    • Vinay Krishna
      By Vinay Krishna  ~  1 year ago
      reply Reply

      Hello Sergey - Any update from your end?

      Thanks,

      Vinay

      • Sergey Shishkin
        By Sergey Shishkin  ~  1 year ago
        reply Reply

        Hi Vinay,

        My comments were aimed to improve your abstract, not to check your knowledge of those terms. The abstract is what attendees will decide upon.

        Sergey


  • Liked Ranjith Tharayil
    keyboard_arrow_down

    Ranjith Tharayil - Change Vector Tracking in emergent design

    45 mins
    Talk
    Intermediate

    A reflective design approach to achieve software design agility by modelling change as a vector and tracking it to aid refactoring decisions.

     

    Preface about the talk

    Software design is a field that has always fascinated me and I have tried to be an obedient student trying to learn this art. Like any other design problem, software design is also a wicked problem. Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.

    Hence you need an architect with magical powers to get your design correct in the first go .This is the core philosophy behind emergent design in which we do not think too much about future . As Uncle Bob sarcastically points out, your customers somehow knows your design and they will come up with a requirement that will break your assumptions and thus your design. In emergent design you embrace aggressive refactoring religiously and few teams rebelliously for the good. It has also been observed that during emergent design refactoring step more focus is towards class design than higher abstract architecture elements. This creates technical debt which can go unnoticed for a long time.

    In this talk I will be introducing a novel technique called change vector tracking that will address the above described problem. Change Vector Tracking is a reflective design approach to achieve software design agility by modelling change as a vector and tracking it through ceremonies like Change Vector Tracking meetings.

    Change vector tracking doesn’t prevent customers from coming up with requirements that would invalidate previous design assumptions, it helps us in monitoring these changes and aids in making informed decisions of where and when to redesign. It helps us keep a check on design debt which otherwise would be overseen and not addressed at the right time .Design debt is invisible to tools initially, only when it grows beyond a scale tools can catch it. Change vector tracking is a technique to capture this design debt in a very early stage. “A stitch in time saves nine”.

  • Liked Ranjith Tharayil
    keyboard_arrow_down

    Ranjith Tharayil - When to embrace Behaviour Driven Development?

    45 mins
    Talk
    Intermediate

    Abstract

    Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This talk focuses on answering two questions;  What are the ideal conditions when teams should adopt it? How to adopt it the right way ?

    In this talk we come up with a BDD adoption matrix to help us answer the above questions. We also assert that for successful product development it is crucial to bridge the gap between the problem space and solution space, each of which has its own set of complexities. We conclude that Behavior Driven Development can be one of the effective techniques to bridge this gap especially if the problem space is complex. In case the problem space is simple it might be an over kill and teams might not find real value practicing BDD. We also observe that teams whose problem space is simple can continue to document scenarios and automate acceptance testing but they need not spend elaborate time and effort towards discussing and debating scenarios.

     

    Preface about the talk 

    Behaviour driven development has been a buzz word in the recent years and many teams are adopting it. The core of BDD is the collaboration angle that enables teams to build the right product. As a side effect BDD gives you a very essential output, which is an automated acceptance test suite. BDD team members work together in identifying different scenarios elaborated in the form of examples. High performing teams ensure through working agreements to only pull those features in which scenarios are well defined. These scenarios define the acceptance criteria of the feature. The scenario identification process involves full team participation and in these meeting its essential that the three amigos i.e. the entire development team, QA engineers and product owner should participate.  Along with the three amigos any other members who can constructively contribute in scenario identification are also welcomed.

    During these interactions technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying and discussing scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it helps them shape their product ,  saying so few teams are yet to find value in investing time and effort towards these meetings and ceremonies . One should keep in mind that for BDD to be effective we require full team participation.

    In this talk I am making an assumption that these teams who are not finding much value in adopting BDD, were practicing it in fullest of its spirits and not just documenting scenarios for creating an automated test suite. This talk discuss on how to effectively adopt it ,the right way based on problem space complexity of the feature .

  • Liked Vinay Krishna
    keyboard_arrow_down

    Vinay Krishna - DevOps or Devops - Living in silos with Tools or Living as one team

    Vinay Krishna
    Vinay Krishna
    Agile / DevOps Practitioner
    Self
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The moment I ask about Devops, I start hearing about lots of tools and automation. While working with various organizations I observed that we read about importance of communication and collaboration for Devops. However we ignore that and focus more on tool adoption and automation as learning new tool is easy and more interesting to any technical person. In this session I’m going to talk about how we could make communication and collaboration between two teams, Dev and Ops, more effective. How we could break down the silos between these two teams so that they can work as a single team for same goal and reach the state of Devops in reality.