The document discusses user stories and how they can be used to develop acceptance criteria and test scenarios for a team scoring feature in a game. It provides an example user story of wanting to introduce competitive elements by allowing teams to earn points for correct answers. Accompanying acceptance criteria and test scenarios are presented to validate the difficulty-based scoring system. Examples are also used to illustrate the acceptance criteria and help explore the different scoring outcomes.
Wie können die Vorgehensweisen aus agilen Teams in der Art auf die gesamte Organisation übertragen werden, dass Organisationsveränderungen von allen Mitarbeitern gemeinsam gestaltet werden können?
Ever looked at a requirement and wondered exactly what you should be testing?
Ever wasted time trying to figure out which of your tests are impacted by a change in the requirements?
Are your automated tests so clear that anyone on the team can read and write them - even the Product Owner?!
These are not unicorns, there is a better way to write clean, simple, easily maintainable tests.
Mentorship is a seemingly simple concept. Get some help from someone more experienced than you. So why do we bother teaching a class on it? Because, like anything else, it’s a skill to mentor and be mentored. And if we can learn that skill it can be a real gift, both to give and receive.
Wie können die Vorgehensweisen aus agilen Teams in der Art auf die gesamte Organisation übertragen werden, dass Organisationsveränderungen von allen Mitarbeitern gemeinsam gestaltet werden können?
Ever looked at a requirement and wondered exactly what you should be testing?
Ever wasted time trying to figure out which of your tests are impacted by a change in the requirements?
Are your automated tests so clear that anyone on the team can read and write them - even the Product Owner?!
These are not unicorns, there is a better way to write clean, simple, easily maintainable tests.
Mentorship is a seemingly simple concept. Get some help from someone more experienced than you. So why do we bother teaching a class on it? Because, like anything else, it’s a skill to mentor and be mentored. And if we can learn that skill it can be a real gift, both to give and receive.
Software contracts - Global Enterprise Agile 2023.pdfSeb Rose
The rise of micro-service architectures offers the promise of a more agile software development process.
Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organizations. But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith?
Contract testing offers an excellent solution.
Participants will be able to:
- Explain why contract testing is critically important
- Describe how to incorporate contract testing in your development practices
- Show their team where they can get an introduction to the open source tool, Pact.
Micro-service delivery - without the pitfallsSeb Rose
The days of delivering a monolithic desktop application once a year on physical media are long gone. Today we expect continuous (or at least frequent) delivery of upgrades and security patches with zero downtime. To support this, more and more companies are moving to a distributed, cloud-based architecture of collaborating micro-services. But managing and testing an evolving of a micro-service ecosystem is not without it’s challenges.
In this session we’ll examine what can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls. You’ll leave with an understanding of the techniques and tooling necessary to reap the benefits of increased flexibility and velocity without creating additional risk or deployment nightmares.
New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You will be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others. A new kid on the block is DevSecOps. What does that mean? Why is it important? How will it affect agile software teams? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome? In this session I’ll explore the origins of DevSecOps before going on to demonstrate how there’s often a distance between the label and the intent of DevSecOps. Finally I’ll discuss the impact that DevSecOps can have on our agile teams and organisations based on my perspective gathered over a 40 year career in software.
Microservices architecture has become the new norm in software development. CI/CD delivery had made releasing updates so frequent it’s almost a daily thing. Modern Software delivery allows no downtime and creates new challenges.
In this webinar, Seb Rose, Continuous Improvement Lead at SmartBear, and Alon Eizenman, CTO & Co-Founder at SeaLights will examine what can go wrong when organizations jump headfirst into microservices architectures without understanding the potential pitfalls.
Join this webinar to learn:
Techniques and tooling necessary to reap the benefits of increased flexibility and velocity without creating additional risk or deployment nightmares
How to gain visibility to ensure your coverage in each microservice
How to set quality gates without delaying release to production
Example mapping - slice any story into testable examples - SoCraTes 2022.pdfSeb Rose
Example mapping is a simple but powerful technique for structuring the conversation you need to have before a user story goes into development. If you are struggling with user stories that are too big, or hard to test, or you're finding that the team are not all on the same page about the scope of a user story, Example Mapping could be just what you need. Using a regular pack of coloured index cards, we'll work in groups to practice breaking down the details of a user story, capturing the business rules, examples of those rules, and any questions or assumptions that emerge. Example mapping is a great input to a BDD or ATDD process, but that's not essential. You'll still get a lot out of this conversation technique even if you don't turn the examples into automated tests.
Software testing - learning to walk again (expoQA22)Seb Rose
Software testing seems to advance at an ever increasing pace. However, lurking under the surface of relentless progress, Seb Rose believes there is a rich strata of continuity. In this session he will explore these foundational aspects of our trade - informally and illustrated by some pretty pictures.
The first article Seb wrote for a software journal was in 2003 (https://accu.org/index.php/articles/363) where he drew an awkward analogy between software projects and building a shed. Over the years, he has found that he has a penchant for analogies and this session will continue in that vein. Don’t worry, though, he’s not going to bore you with pictures of building sites or aphorisms from lean manufacturing.
Instead, he’ll take you on a gentle walk on some mountainous paths in the south of France. There’ll be red wine and automated testing; oak forests and scope creep; deep river gorges and CI pipelines. He’ll ask you to walk with him and take a close look at the concepts that underpin our trade.
“We must learn to walk before we can run” is an age-old adage. We all learned to walk decades ago. Many of us learnt how to test software shortly thereafter. However, just as running is not simply walking faster, neither is better software testing simply working with the latest shiny tools. By slowing down, observing our behaviour, considering alternatives, and deliberately practicing different approaches we can re-learn how to develop software. Or confirm that how we’re doing it now is just fine.
As Jon Jagger reminds us in the FAQ of the wonderful Cyber-Dojo: “Stop trying to go faster; start trying to go slower. Don’t think about finishing; think about improving. Think about practicing.”
From this keynote, you’ll enjoy a gentle walk on some mountainous paths in the south of France, some red wine with unit testing and above all understand how to walk before running.
DevSecOps - Unicom Agile and DevOps Expo (Adaptive Challenges) 2021Seb Rose
New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You will be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others.
A new kid on the block is DevSecOps. What does that mean? Where did it come from? Why is it important? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome?
In this session I’ll explore the origins of DevSecOps before going on to demonstrate the distance between the label and the intent of DevSecOps. Finally I’ll try to generalise the journey from “good idea” to “empty slogan” that seems to underpin many of the hyped transformations that I’ve lived through during my 40 year career in software.
A brief history of requirements - Unicom 2022Seb Rose
Was there a time before requirements? Can the product be created before the requirements? Is a product ever “finished”? These are just some of the questions considered in this session. It begins by reviewing the great requirement formalisms of yester-year, before delving into the secrets which still lie at the heart of agile product development, from user stories to living documentation, via confetti parties and Behaviour Driven Development (BDD)
* BDUF – Big Design Up Front
** JIT – Just In Time
Example mapping (with builds) - ProductWorld 2022Seb Rose
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
No code, low code, machine code QA ATL 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
No code, low code, machine code QA ATL 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
No code, low code, machine code - Unicom 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
BDD: from soup to nuts - The Future of Work Scotland 2021Seb Rose
Behaviour Driven Development (BDD) is an agile approach to delivering software that has been around for well over a decade. It was created to help developers care about quality, morphed into a collaboration approach, and found widespread mis-adoption as a test automation technique.
In this session Seb will explain how BDD is intended to work, what value it delivers when done well, and why much BDD in the workplace falls short.
Learning Objectives:
What can our attendees expect to take away from the session?
● enumerate the three core practices of BDD
● explain the difference between BDD and test automation
● argue that collaboration and learning are at the heart of successful software development
Contrasting test automation and BDD - 2020Seb Rose
Test automation and BDD are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.
In this session we’ll explore what test automation and BDD are - and how they separately contribute to successful inter-disciplinary agile delivery. We'll also spend some time describing how they're different, and look at several typical examples of what can go wrong when BDD and test automation get confused.
Are BDD and test automation the same thing? Automation Guild 2021Seb Rose
Test automation and behaviour-driven development (BDD) are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.
In this session we’ll explore what test automation and BDD are – and how they separately contribute to successful inter-disciplinary agile delivery. We’ll also spend some time describing how they’re different, and look at several typical examples of what can go wrong when BDD and test automation get confused.
"Our BDDs are broken!" Lean Agile Exchange 2020Seb Rose
Is the goal of your QA team to increase the number of automated tests? Are managers looking for tools that allow test-automation without the need for development skills? Are you using Given/When/Then phrasing to write automation tests?
In this session we’ll briefly define what BDD is, spend a bit longer describing what it isn’t, and look at several typical examples of what can go wrong if you use Cucumber when you’re not following a BDD approach.
User stories: from good intentions to bad advice - Agile Scotland 2019Seb Rose
These are the slides I wanted to use at Agile Scotland 2019. Unfortunately, my laptop refused to play ball and I ended up using an older version that was already on SlideShare.
User stories: from good intentions to bad advice - Lean Agile Scotland 2019Seb Rose
User stories are one of the most visible artefacts of most agile methods and, as such, have generated large quantities of expert advice. In my experience, much of that advice is open to misinterpretation.
In this session, we'll explore several classic pieces of advice, to see how misunderstandings can cause problems, despite the best intentions. The examples we'll look at are:
- an acronym: INVEST, created by Bill Wake
- a technique: relative estimation using story points, created by Ron Jeffries or Joseph Pelrine
- a template: Connextra (As-A/I-Want/So-That), created by Rachel Davies
Expert advice taken in good faith, that leads to bad outcomes, can cause us to become distrustful. It's time to reiterate that there is no magic formula, no silver bullet. At best, experts can lend you a framework within which to think, but their advice will never make thinking unnecessary.
Software contracts or: how I learned to stop worrying and love releasing. Agi...Seb Rose
The test automation pyramid suggests that we should favour unit and integration tests over end-to-end tests, which leads developers to use test doubles (fakes, stubs, mocks etc.). The risk is that the developer's test double does not behave in exactly the same way as the actual component that it is replacing. When this happens, the tests all pass in your build pipeline, but you get failures when it's released into an integration (or production) environment.
Contract testing is a technique that can give you confidence that your test doubles are accurately simulating the dependencies that they replace. This is not a new technique, but the extra investment in creating and maintaining (yet another) suite of tests has restricted its uptake. Instead, organizations mitigate the risks by investing in more and more integration environments and end-to-end tests. This was always expensive, but with the adoption of micro-service architectures across the industry, the cost and complexity has escalated to a point where this approach is no longer sustainable.
There is now an urgent need for organizations to revisit contract testing, with a specific focus on consumer driven contracts for micro-services. This need led to the creation of the Pact open source tool for HTTP based micro-services. The Pact project has created a multi-platform suite of tools that dramatically simplifies the adoption of contract testing.
In this session, you'll learn why contract testing is critically important, look at how you can incorporate contract testing in your development practices, and get an introduction to Pact.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Software contracts - Global Enterprise Agile 2023.pdfSeb Rose
The rise of micro-service architectures offers the promise of a more agile software development process.
Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organizations. But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith?
Contract testing offers an excellent solution.
Participants will be able to:
- Explain why contract testing is critically important
- Describe how to incorporate contract testing in your development practices
- Show their team where they can get an introduction to the open source tool, Pact.
Micro-service delivery - without the pitfallsSeb Rose
The days of delivering a monolithic desktop application once a year on physical media are long gone. Today we expect continuous (or at least frequent) delivery of upgrades and security patches with zero downtime. To support this, more and more companies are moving to a distributed, cloud-based architecture of collaborating micro-services. But managing and testing an evolving of a micro-service ecosystem is not without it’s challenges.
In this session we’ll examine what can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls. You’ll leave with an understanding of the techniques and tooling necessary to reap the benefits of increased flexibility and velocity without creating additional risk or deployment nightmares.
New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You will be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others. A new kid on the block is DevSecOps. What does that mean? Why is it important? How will it affect agile software teams? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome? In this session I’ll explore the origins of DevSecOps before going on to demonstrate how there’s often a distance between the label and the intent of DevSecOps. Finally I’ll discuss the impact that DevSecOps can have on our agile teams and organisations based on my perspective gathered over a 40 year career in software.
Microservices architecture has become the new norm in software development. CI/CD delivery had made releasing updates so frequent it’s almost a daily thing. Modern Software delivery allows no downtime and creates new challenges.
In this webinar, Seb Rose, Continuous Improvement Lead at SmartBear, and Alon Eizenman, CTO & Co-Founder at SeaLights will examine what can go wrong when organizations jump headfirst into microservices architectures without understanding the potential pitfalls.
Join this webinar to learn:
Techniques and tooling necessary to reap the benefits of increased flexibility and velocity without creating additional risk or deployment nightmares
How to gain visibility to ensure your coverage in each microservice
How to set quality gates without delaying release to production
Example mapping - slice any story into testable examples - SoCraTes 2022.pdfSeb Rose
Example mapping is a simple but powerful technique for structuring the conversation you need to have before a user story goes into development. If you are struggling with user stories that are too big, or hard to test, or you're finding that the team are not all on the same page about the scope of a user story, Example Mapping could be just what you need. Using a regular pack of coloured index cards, we'll work in groups to practice breaking down the details of a user story, capturing the business rules, examples of those rules, and any questions or assumptions that emerge. Example mapping is a great input to a BDD or ATDD process, but that's not essential. You'll still get a lot out of this conversation technique even if you don't turn the examples into automated tests.
Software testing - learning to walk again (expoQA22)Seb Rose
Software testing seems to advance at an ever increasing pace. However, lurking under the surface of relentless progress, Seb Rose believes there is a rich strata of continuity. In this session he will explore these foundational aspects of our trade - informally and illustrated by some pretty pictures.
The first article Seb wrote for a software journal was in 2003 (https://accu.org/index.php/articles/363) where he drew an awkward analogy between software projects and building a shed. Over the years, he has found that he has a penchant for analogies and this session will continue in that vein. Don’t worry, though, he’s not going to bore you with pictures of building sites or aphorisms from lean manufacturing.
Instead, he’ll take you on a gentle walk on some mountainous paths in the south of France. There’ll be red wine and automated testing; oak forests and scope creep; deep river gorges and CI pipelines. He’ll ask you to walk with him and take a close look at the concepts that underpin our trade.
“We must learn to walk before we can run” is an age-old adage. We all learned to walk decades ago. Many of us learnt how to test software shortly thereafter. However, just as running is not simply walking faster, neither is better software testing simply working with the latest shiny tools. By slowing down, observing our behaviour, considering alternatives, and deliberately practicing different approaches we can re-learn how to develop software. Or confirm that how we’re doing it now is just fine.
As Jon Jagger reminds us in the FAQ of the wonderful Cyber-Dojo: “Stop trying to go faster; start trying to go slower. Don’t think about finishing; think about improving. Think about practicing.”
From this keynote, you’ll enjoy a gentle walk on some mountainous paths in the south of France, some red wine with unit testing and above all understand how to walk before running.
DevSecOps - Unicom Agile and DevOps Expo (Adaptive Challenges) 2021Seb Rose
New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You will be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others.
A new kid on the block is DevSecOps. What does that mean? Where did it come from? Why is it important? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome?
In this session I’ll explore the origins of DevSecOps before going on to demonstrate the distance between the label and the intent of DevSecOps. Finally I’ll try to generalise the journey from “good idea” to “empty slogan” that seems to underpin many of the hyped transformations that I’ve lived through during my 40 year career in software.
A brief history of requirements - Unicom 2022Seb Rose
Was there a time before requirements? Can the product be created before the requirements? Is a product ever “finished”? These are just some of the questions considered in this session. It begins by reviewing the great requirement formalisms of yester-year, before delving into the secrets which still lie at the heart of agile product development, from user stories to living documentation, via confetti parties and Behaviour Driven Development (BDD)
* BDUF – Big Design Up Front
** JIT – Just In Time
Example mapping (with builds) - ProductWorld 2022Seb Rose
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
No code, low code, machine code QA ATL 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
No code, low code, machine code QA ATL 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
No code, low code, machine code - Unicom 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
BDD: from soup to nuts - The Future of Work Scotland 2021Seb Rose
Behaviour Driven Development (BDD) is an agile approach to delivering software that has been around for well over a decade. It was created to help developers care about quality, morphed into a collaboration approach, and found widespread mis-adoption as a test automation technique.
In this session Seb will explain how BDD is intended to work, what value it delivers when done well, and why much BDD in the workplace falls short.
Learning Objectives:
What can our attendees expect to take away from the session?
● enumerate the three core practices of BDD
● explain the difference between BDD and test automation
● argue that collaboration and learning are at the heart of successful software development
Contrasting test automation and BDD - 2020Seb Rose
Test automation and BDD are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.
In this session we’ll explore what test automation and BDD are - and how they separately contribute to successful inter-disciplinary agile delivery. We'll also spend some time describing how they're different, and look at several typical examples of what can go wrong when BDD and test automation get confused.
Are BDD and test automation the same thing? Automation Guild 2021Seb Rose
Test automation and behaviour-driven development (BDD) are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.
In this session we’ll explore what test automation and BDD are – and how they separately contribute to successful inter-disciplinary agile delivery. We’ll also spend some time describing how they’re different, and look at several typical examples of what can go wrong when BDD and test automation get confused.
"Our BDDs are broken!" Lean Agile Exchange 2020Seb Rose
Is the goal of your QA team to increase the number of automated tests? Are managers looking for tools that allow test-automation without the need for development skills? Are you using Given/When/Then phrasing to write automation tests?
In this session we’ll briefly define what BDD is, spend a bit longer describing what it isn’t, and look at several typical examples of what can go wrong if you use Cucumber when you’re not following a BDD approach.
User stories: from good intentions to bad advice - Agile Scotland 2019Seb Rose
These are the slides I wanted to use at Agile Scotland 2019. Unfortunately, my laptop refused to play ball and I ended up using an older version that was already on SlideShare.
User stories: from good intentions to bad advice - Lean Agile Scotland 2019Seb Rose
User stories are one of the most visible artefacts of most agile methods and, as such, have generated large quantities of expert advice. In my experience, much of that advice is open to misinterpretation.
In this session, we'll explore several classic pieces of advice, to see how misunderstandings can cause problems, despite the best intentions. The examples we'll look at are:
- an acronym: INVEST, created by Bill Wake
- a technique: relative estimation using story points, created by Ron Jeffries or Joseph Pelrine
- a template: Connextra (As-A/I-Want/So-That), created by Rachel Davies
Expert advice taken in good faith, that leads to bad outcomes, can cause us to become distrustful. It's time to reiterate that there is no magic formula, no silver bullet. At best, experts can lend you a framework within which to think, but their advice will never make thinking unnecessary.
Software contracts or: how I learned to stop worrying and love releasing. Agi...Seb Rose
The test automation pyramid suggests that we should favour unit and integration tests over end-to-end tests, which leads developers to use test doubles (fakes, stubs, mocks etc.). The risk is that the developer's test double does not behave in exactly the same way as the actual component that it is replacing. When this happens, the tests all pass in your build pipeline, but you get failures when it's released into an integration (or production) environment.
Contract testing is a technique that can give you confidence that your test doubles are accurately simulating the dependencies that they replace. This is not a new technique, but the extra investment in creating and maintaining (yet another) suite of tests has restricted its uptake. Instead, organizations mitigate the risks by investing in more and more integration environments and end-to-end tests. This was always expensive, but with the adoption of micro-service architectures across the industry, the cost and complexity has escalated to a point where this approach is no longer sustainable.
There is now an urgent need for organizations to revisit contract testing, with a specific focus on consumer driven contracts for micro-services. This need led to the creation of the Pact open source tool for HTTP based micro-services. The Pact project has created a multi-platform suite of tools that dramatically simplifies the adoption of contract testing.
In this session, you'll learn why contract testing is critically important, look at how you can incorporate contract testing in your development practices, and get an introduction to Pact.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
6. “User stories are slippery,
so we call them Product Backlog Items”
Tuesday, 22 April 14
7. We never
finish them in an
iteration
How do I trace
them to features
Hard to estimate
Not enough detail
to start coding
Nothing I can test
Difficult to
prioritise
Tuesday, 22 April 14
8. As a <role>
I want to <do something>
So that <I get some value>
Tuesday, 22 April 14
9. In order to <get some value>
<role> should be able to
<do something>
Tuesday, 22 April 14
11. “A
boundary
object
is
a
concept
in
sociology
to
describe
informa7on
used
in
different
ways
by
different
communi7es.
They
are
plas7c,
interpreted
differently
across
communi7es
but
with
enough
immutable
content
to
maintain
integrity”
-‐-‐Wikipedia
User Stories are Boundary Objects
Tuesday, 22 April 14
13. “They are weakly structured in common
use, and become strongly structured in
individual-site use. They may be abstract or
concrete.
-- Leigh & Griesemer
Tuesday, 22 April 14
14. “They are weakly structured in common
use, and become strongly structured in
individual-site use. They may be abstract or
concrete.
They have different meanings in different
social worlds but their structure is common
enough to more than one world to make
them recognizable means of translation.
-- Leigh & Griesemer
Tuesday, 22 April 14
15. “They are weakly structured in common
use, and become strongly structured in
individual-site use. They may be abstract or
concrete.
They have different meanings in different
social worlds but their structure is common
enough to more than one world to make
them recognizable means of translation.
The creation and management of boundary
objects is key in developing and maintaining
coherence across intersecting social worlds.”
-- Leigh & Griesemer
Tuesday, 22 April 14
26. •Must support VISA
•Does not need to support MasterCard, Switch
•...
•Customers should be prevented from entering
invalid credit card number
• ...
Credit Card Processing
Acceptance criteria:
Tuesday, 22 April 14
27. The one where ....
... we validate content of the card number
User Enters Outcome
@£$%@£$%@£$%@£$% Error message
4575 9879 6752 1245 Error message
4.57599E+15 OK
Tuesday, 22 April 14
31. In order to introduce a
competitive element
participants should be able to
get points for a successful
answer
SCORING THE GAME
Tuesday, 22 April 14
32. Get points for a correct answer
Acceptance criteria:
Tuesday, 22 April 14
33. Is it only the first
team that gets the
answer right that
scores?
Do teams start
with a score of 0?
Are all answers
worth the same?
Can the score be
negative?
What happens if the
answer is wrong?
Tuesday, 22 April 14
34. Teams start with a score of 0
Acceptance criteria:
Correct answers score points
Incorrect answers lose points
Score can’t be negative
Points awarded decrease ...
Tuesday, 22 April 14
35. Teams start with a score of 0
Acceptance criteria:
Tuesday, 22 April 14
36. Feature: Team Scoring
Teams start with zero score
Scenario: Score starts at 0
Given I register a team
When I retrieve my score
Then my score is 0
Tuesday, 22 April 14
39. Feature: Team Scoring
Teams start with zero score
Correct answer gets points
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct answer gets 10 points
Given I register a team
When I submit a correct answer
Then my score is 10
Tuesday, 22 April 14
40. Points awarded for an answer
depend on its difficulty
Acceptance criteria:
Tuesday, 22 April 14
41. Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
42. Acceptance
criteria
User Story
Examples
Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
43. Acceptance
criteria
User Story
Examples
Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
44. Acceptance
criteria
User Story
Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
45. Acceptance
criteria
User Story
Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
46. User Story
Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
47. User Story
Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14
48. Feature: Team Scoring
Teams start with zero score.
Correct answer gets points depending on
how difficult it is.
Scenario: Score starts at 0
Given I register a team
Then my score is 0
Scenario: Correct easy answer scores 10
Given I register a team
When I submit a correct easy answer
Then my score is 10
Scenario: Correct hard answer scores 50
Given I register a team
When I submit a correct hard answer
Then my score is 50
Tuesday, 22 April 14