Acceptance Testing with Executable Specifications
HTML-код
- Опубликовано: 15 авг 2024
- Acceptance Testing is best practiced through the creation of “Executable Specifications” of the behaviour of the system. This sophisticated automated software testing & software engineering approach allows for the automation of UAT, as well as working as a procedural backbone to driving the development process.
You can get Dave Farley's FREE "How To..." guide on Acceptance Testing here
➡️ www.subscribep...
MORE ABOUT THIS VIDEO:
In this episode, Dave Farley examines system-level software testing, looks at the properties of effective acceptance tests and provides some acceptance testing examples, all from the perspective of the use of executable specifications. This approach is an effective driver for Continuous Delivery and take a BDD approach helps to create a bridge between the developers and the rest of the business.
---------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd...
📖 The original award-winning “Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES ➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST ➡️ bit.ly/MailListCD
Keep up to date with the latest discussions, free "How To..." guides, events and online courses through our email updates!
---------------------------------------------------------------------------------------
Continuous Delivery Ltd. ➡️ bit.ly/Continu...
Dave Farley's Blog ➡️ bit.ly/DaveFWe...
Dave Farley on Twitter ➡️ bit.ly/DaveFTw...
Dave Farley on LinkedIn ➡️ bit.ly/DaveF-LI
-------------------------------------------------------------------------
Other Useful Books on this topic:
(Please note, if you buy a book from these links I get a small fee, without increasing the cost to you)
Domain Driven Design, by Eric Evans ➡️ amzn.to/2WXJ94m
Specifcation By Example, by Gojko Adzic ➡️ amzn.to/2TlfYaH 
Наука
Let me know what you consider as valuable properties of acceptance testing in the comments below 👇
The collaboration opportunity for the SME and Devs to ask and validate in code the question: "What if ...."
And quickly they can write a test that answers that question
Great explanation. I'd appreciate an example of how to produce an acceptance test in practice. You might even consider this a suggestion for a forthcoming video!!
Thanks for the suggestion!
I do intend to do more on Acceptance Testing, including with some examples.
I just recently started writing specifications with SpecFlow for C#, which uses the Gherkin language, which is still really exciting, because you can literally write out a userstory and extend it into user readable steps that are immedeately usable for further discussion/feedback. What I really love about your videos is, that everything you say either makes complete sense to me or shifts my point of view to a new angle, which is always interesting. Thanks a lot!
This is by far the best RUclips channel about software development.
Thanks Dave!
I have bought your book and I will soon buy your course about testing and about CD.
Awesome, thank you!
Valuable Properties of Acceptance Testing
1. The collaboration opportunity for the SME and Devs to ask and validate in code the question: "What if ...."
And quickly they can write a test that answers that question
2. The ease to write new tests especially for Bugs that we want to fix. (Bug First Driven Development)
I take a pretty DDD approach to solving problems, and one of the things that I really like about the approach that I describe here, is how it helps you to establish the "ubiquitous language" of the system.
Another great lesson. Making the “one acceptance test per acceptance criteria” rule work sounds very dependent on how you write your acceptance criteria - else you could end up in a mess. Would be great to see some examples of what level of abstraction you think acceptance criteria should be for this to be effective
I plan to do more stuff on acceptance testing. It is a complex topic though so finding pieces that make a good, short video is a bit tricky, but I will do more on this subject!
I am planning some online training courses that will cover this in more depth, which is probably a better format for this kind of thing.
Excellent content. I wish more teams do this
Thanks, yes, me too.
Thank you! Great review!
Thanks
Great! I will try this.
Have fun!
great video and suggestions as always Dave ; one question - when you say decouple test as much as possible from system - so that the test should be able to validate what its supposed to even if the system undergoes big /major changes.. Thats sounds great but exact details/example would help. Lets say there is some 'approval' process in some workflow and we want to write a test for this. and say the last step of this process is user fills in couple of fields, checks few check boxes, adds comments and clicks approved button. now in this case are you saying even if the count of fields on screen change, even if the layout change, even if say we have a need to add additional approver etc etc ; the test should work ?
I will provide examples in future videos, so stay-tuned :)
I was going to ask this exact same question :)
I didn't do a good job of replying, so let me have another go...
I try to approach these kind of tests always from the users perspective. From their perspective the fields that they complete don't matter, their intent, presumably, is to say "I approve". The detail of what it takes to approve is what you, as the developer, care about, not what the user cares about.
So separate those two things.
In the Acceptance Test Case, create a Domain Specific Language (as I describe in the video) to capture the user's intent. In this language add, if it doesn't already exist, a step called something like "ApproveX".
This does several things. It captures the user's intent. If that approval is important then this will always be true, however "Approval" is achieved. It is so general, that you will often find that approval may be useful in other contexts, and finally, you have strengthened and extended the ubiquitous language!
Of course, you as the dev, still need the detail of the approval. So in a lower-layer of your test code write the group of interactions that make an "Approval". In these lower layers you get the info that you need and encode the interactions.
My preferred approach is a 4 layer strategy...
Test Case (Language of problem domain, "What") -> DSL Implementation (param parsing etc) -> Protocol Driver (Translate from DSL to System interactions, "How") -> System Under Test
I plan to do videos on this stuff in future, meantime here is a conference presentation on the same topic:
ruclips.net/video/s1Y454DTRtg/видео.html
See my other reply...
Loving these videos Dave, how about a collaboration with Chris Matts :)
Thanks, I'd be happy to collab with Chris, though now we have to think of something. Hmmm.
@@ContinuousDelivery I'll let him know, we work together ;)
Cool, thanks.
Great content!
Let's dig a little deeper into technicalities, so that I can ask a question:
The BDD needs to have underneath some support for the more concrete technologies used, some helpers, etc. E.g. "when operation A available", let's say an assertion that a link exists. In the BDD test, there's no mention of the link, just of the feature.
Cool so far.
The question is: would you tie those helpers to the technologies, e.g. to the link in this case, or would you introduce an additional "view model" and you'd make the system "render" those models instead of the whole css/HTML bloat, and assert against that view model?
I think that this may help describe how I divide up the implementation of Acceptance Testing ruclips.net/video/JDD5EEJgpHU/видео.html
In it I describe my preferred 4-Layer architecture, Test cases at the top, written in a DSL, which capture What the system should do without saying anything about how it should do it. Next layer down is the DSL, which is shared between many test cases. The the protocol driver layer, which I think is what you are asking about, and finally the System Under Tests (SUT).
The protocol drivers take biz-level concepts, captured in the DSL and translate them into something that drives the app. So a test case says "placeOrder" and the DSL sorts the paramaters, helps with abstraction and passes 'placeOrder' on to the protocol layer, which translates that idea into "complete this field with this value, and this other field with this other value, and press this button" or "Create a message with these values, and send it here".
This video also describes some aspects of this separation: ruclips.net/video/zYj70EsD7uI/видео.html
I think these explanations of continuous delivery processes require more practical demonstrations of how to write a system that does them correctly. This is all just theory based and at a certain point, I think this channel needs to step up and back up the theory with some examples, they don't need to be perfect, but at least prove you can do what you are telling others to do. For example how can I create a deployment pipeline step by step to develop a react application? Like what are the actual technologies to use for acceptance testing, building and deploying the software and how to use them?
Well it is certainly not "just theory" because all of this stuff is based on real world experience, often with VERY complex systems.
There are lots of videos on the channel of real examples of different aspects of CD. When it comes down to it, this is free advice, you don't have to take it 😉
Here's a real world example of a deployment pipeline that shows that this isn't just theory: ruclips.net/video/bHKHdp4H-8w/видео.html
...but you'll still need to learn to use your own tools to build one like this.
Here is how to start: ruclips.net/video/eozFlgu6ByY/видео.html
The irony is that a book that uses the term ubiquitous language doesn't seem to implement it for itself as most or it is rather unreadable
Ubiquitous != Readable, it can be highly arcane depending on the problem domain.