Showing posts with label bdd. Show all posts
Showing posts with label bdd. Show all posts

Sunday, April 29, 2018

Testing Tour Stop #6: Pair Formulating Scenarios with Pranav

My testing tour continues! This time with a novelty: For the first time, I did not know my pairing partner before our session. Pranav KS saw the blog posts about my testing tour and decided to give it a try and schedule a session with me. How awesome is that?

Preparation Phase

As I haven't met Pranav before, neither in real life nor virtually, I decided to reach out via email and explain the session idea, its structure, the tools used, and the approach I'd like to use. The topics he wanted to learn more about was exploration and automation. As we didn't know each other, I suggested to explore an application together which I would select for our session, in case he wouldn't have any other suggestion himself.

A day before our session, Pranav reached out to me and asked if we could pair on automation as this was his current learning topic where he faced some challenges, especially regarding design. Since my first pairing session with Maaret I now always prepare the subject to pair on, or at least have fallback plans. But I learned it's even better if my pairing partners bring their own topics and applications to test. So far it seems doing so even increases the value of our sessions. Therefore I thought in Pranav's case: Sure! And responded by suggesting to work on exactly the challenges he faces and build on whatever he already had.

Meeting for the First Time

We kicked our session off with a short introduction round which built a first basis to start from. When I asked Pranav if he could introduce me to the automation topic to pair on, we both found we had misunderstood each other's previously written communication! I had assumed he worked on an automation project where he faced challenges and we would use this one to pair on. I guess he had assumed I would provide a practice project to pair on automation so we could learn together how to do it well, and he could then apply the lessons to his project afterwards.

So - despite of all preparation work done upfront, suddenly none of us was prepared anymore. We had to improvise! Challenge accepted. I found out that one of the challenges Pranav faced was how to decide which scenarios to automate. Also, he was using SerenityBDD with Cucumber, just as my team. This made me think of the various demo and practice repositories for SerenityBDD. We checked them out and found several were using a sample todo application to demonstrate how you could design your automation. We decided to go for it!

Identifying and Formulating Scenarios

To decide which scenarios to write, we first had to get to know the application's features. We agreed to create a mind map to document our findings in a light way. We mapped out the features we found when interacting with the application. Features like creating, editing, completing or deleting a todo. A counter showed how many active todos were left. Bulk edit options let us complete, re-activate, or clear all todos.

In the next step, we started to formulate Cucumber scenarios. We did not have any project set up yet, so we decided to simply use a text editor in the beginning. When writing the scenarios, it became obvious again that this task sounds easy, but indeed is not. I am missing practice on formulating good scenarios myself, but I read a lot about patterns and anti-patterns, and often was reminded of what I heard in the workshop "Writing Better BDD Scenarios" by Seb Rose and Gáspár Nagy at European Testing Conference 2018. Sharing this knowledge was great, and we improved our scenarios iteratively, step by step. We discussed how to best formulate intention without already stating any implementation details. We tried to find fitting scenario titles. We thought about where to parametrize and where not, as well as where to split up scenarios into separate ones to always only test for the outcome of one action. We pondered on how to best define the "given" state to start from, what the action in the "when" would be, and how exactly to formulate our expectations in the "then" part. The resulting scenarios were far from perfect in the end, but definitely a lot better.

We had the option to either formulate only a few scenarios and start automating those already as a minimal approach from start to finish, or to formulate all scenarios we deemed most important before starting to automate them. Well, we ended up with the latter option, formulating all scenarios first. However, in the end we both thought this was the less satisfying approach as we only managed to set up our project but could not start automating within the session timebox. Still, in the last minutes I learned how to setup a Maven project from an archteype in IntelliJ. It's some time ago that I used Maven, so a refresher was welcome.

Retro Time!

Our session timebox was quickly coming to an end. For this retrospective, I shared my screen and we created a mind map of our observations and thoughts together.

The first thing mentioned: our progress was a bit slow. We found that coming up with good scenarios and finding suitable formulations is hard and takes its time. Well, there was a reason Gáspár and Seb hosted a 90 minutes workshop just about this topic, or announced a whole book about it. Still, Pranav and I agreed we maybe should have taken the other route and only formulate one to three core scenarios and then start automating them to have at least one scenario automated in the end. Well, we addressed this option during the session and decided differently, which is okay. Next time I should advocate for the "minimum viable solution" option though. Also, as the whole session was a bit unprepared and rather improvised, we felt we lacked a bit of focus or end goal. Clarifying this in the beginning might have helped us with the session scope as well.

What was really good was to have an application where none of us needed to have special domain knowledge. Most people know the one or the other todo application and what they would expect from a user point of view. We did not struggle coming up with behaviors to check for.

Working with the tools we used left us with mixed feelings. Pranav didn't find the text editor convenient for writing scenarios. He would have preferred a different tool from which we could have exported properly formatted scenarios and imported them in our test project. Personally, I did not mind as this was a a quick and easy way to get started. We agreed, however, that working with the other tools was convenient for both of us. The mind map was easy to edit, the mob timer did its job, and especially the screen sharing with granted remote control worked very smoothly. I really enjoy Zoom for their great videoconferencing quality, and being able to share screen control makes this tool even more valuable. It's free, it's easy to use, and the result was a very smooth switching between our driver and navigator roles. The only thing we noticed: As we were using my Windows system to work on and Pranav used macOS, he had troubles using keyboard shortcuts before we figured out that he had to use Windows-style shortcuts, using the Control instead of the Command key. But all in all, this was a novelty on my testing tour so far! The first virtual pairing session where we could really do strong-style pairing without impeding technical obstacles. Awesome.

Speaking of our collaboration: Pranav told me it was his first time trying strong-style pairing. He paired before, but not in this way. I had sent him Llewellyn Falco's blog post explaining the strong-style approach upfront so he could familiarize with it beforehand. Although the concept was new to him, it went very well and we fluently switched between roles. This pairing style really forces you to express your thoughts and intentions clearly! Great for learning. We only caught ourselves finishing a sentence before handing over, or sometimes taking over mouse control as navigator to point to something, but that was it. Kudos to Pranav!

What's Next?

My last posts about my testing tour seem to have fallen on fertile ground. The idea of scheduling a pair testing session spread, and now I'm happy to announce that three more sessions had already been arranged. They will all take place within the next six weeks. And more are to come! This is especially awesome as I got the opportunity to talk about my testing tour and share my lessons on both CAST and SwanseaCon this year.

My original experiment was designed to have at least ten sessions with six different testers until end of October 2018. I'm already at six sessions with five different testers, with three more sessions to come. So I'm on a good way to fulfill my own requirements. Still, I'm eager to continue my testing tour until end of October and see how much more I could learn from all those other testers out there. Are you interested to join me on my tour? Just schedule a pair testing session with me! :-)

Monday, April 9, 2018

Testing Tour Stop #4: Pair Setting Up Automation with Dianë

Back on the road again! This time, my testing tour made something become reality what I was thinking about for two years already. You read correctly, I said two years. Two years ago my colleague Dianë Xhymshiti joined my company. Although we're working on two different product teams, both teams are literally sitting in the same office since two years. And we never paired before.

In the beginning I was too afraid to pair myself. I wasn't ready to fail safely. Now that the last year taught me so much that I decided to go on this testing tour, this was the perfect opportunity for me to finally make it happen. And I'm really glad about it! Here's what I learned pairing with Dianë.

The Idea

When first agreeing to pair, we considered to practice exploratory testing together, on any application. When making things concrete, however, we found that Dianë currently has a task on her list which she hardly finds time for but which would make her tester life easier. So we decided to give it a shot and pair on setting up automation through the UI for one of her team's applications. In addition, Dianë wanted to learn more about Cucumber, and I wanted to finally try out the Screenplay Pattern I learned about at last year's Agile Testing Days.

We both researched a bit about our topic before and started the session by sharing our ideas. I came from the perspective of what we are using in my product team which is SerenityBDD together with Cucumber. The latest version does support and even favor the Screenplay Pattern. However, we have quite an old version in place as well as a lot of legacy and anti-patterns in the code from our initial learning phase. I was eager to learn more about the newest version as input for completely revising our tests. Dianë's team instead is using Protractor for another application, and she thought about trying it out in combination with Cucumber and the Screenplay Pattern for this new use case. As our target system under test was Dianë's, we decided to go for her approach, follow a tutorial she found to get started and then continue from there. We also agreed on the following.
  • We used Dianë's laptop as it shows an English keyboard layout which is easier to use than my German one.
  • We connected an external screen and used the laptop screen as additional one.
  • We paired strong-style, switching navigator and driver roles every four minutes.
  • We tried out MobTime, a mob timer application I haven't used so far, running on my laptop standing at the side.

Achievements, Challenges and Other Lessons

When following the tutorial steps on how to setup Protractor in IntelliJ, we were delighted how smoothly and quickly it went. It only took us a few minutes to have a first example test running. We only stumbled once when IntelliJ complained about our spec file. Seems we missed to copy over the closing brackets from the tutorial example; easily fixed. Speaking of the tutorial itself and other resources we came across during our session, several issues quickly caught our eyes, like having step 9 before step 8, or checking for the "4rd" element. Documentation can be buggy, too, it also needs to be tested. Besides such more obvious things like ordering or grammar, it might not fulfill the need of the one who's reading it. If that's the case, sometimes you need to switch to another resource.

We came across two question marks right in the beginning.
  1. How to name the kind of tests we intended? They got sold to the team as "acceptance tests". The team also had another set of "end-to-end" tests defined already (by the way, I love Katrina Clokie's post about the different meanings of end-to-end). Dianë and I were both not quite convinced regarding this kind of naming. We were feeling confused about the many different terms many different teams use to refer to the same or often different kind of things. To not get stuck, we decided to go with the communicated name of "acceptance tests" for now and postpone the final decision.
  2. How to add the new dependencies to the existing project? The tutorial let us install everything for our local environment. But what about running the tests in our build pipeline on the server? Even though we frequently discussed automation setups and testing requirements with our developers, we normally only built upon what's already there and rarely set up things from scratch. We decided to postpone clarification of this part as well for now. Still, I could share what I learned from my developers, like the handy shortcut of copying over the needed Gradle dependency statement from the Maven Repository, for example for Selenium
After successfully having our first dummy example test running, we wanted to adapt it to be a real example for the actual system under test. Once again we noticed how often IDs are missing on elements to have them easily located; it seems people have to make an extra effort to consider testability when developing web pages. Well, we used this circumstance to refresh our locator knowledge and how to validate selectors using the Chrome DevTools.

All in all, the first steps were pretty straight forward; and then we stumbled heavily. We "just" wanted to verify that the expected page had been loaded. So we located an element and wanted to see if it's present. But no such methods were offered on the element! We checked the already existing Protractor tests in the other project and found that the expected methods were indeed offered on elements. What did we miss when setting up our automation basis then? The whole rest of our session we tried to find out where the mistake in our thinking was, trying out different things and searching for answers online. We generated further ideas what to try but could not find the solution yet. However, due to our Google research, I learned about how others search for answers. Dianë for her part suggested to search for a video and then quickly scanned through it to see if the content was helpful. I never realized before that YouTube offered shortcuts for that!
  • L: jump 10 seconds forward
  • K: pause/play video
  • J: jump 10 seconds backwards

In Retrospect

First of all, collaboration was nice and easy. Only very few times we ignored the timer and continued with our previous roles of driver/navigator. Rarely we mixed up the roles, like having the navigator type keys or the driver deciding what to do. All in all, everything went smoothly. Well, we know each other for two years already, so trust, communication or general understanding was not an issue at all.

Working on a foreign computer and setup is still hard. Even though I did it now several times due to frequent mob and pairing session, my finger muscle memory still wanted to go for a German keyboard layout and my eyes had to scan the English keyboard for the needed characters. On the level of "Where was the semicolon again?" I always need a short period of actively having my brain switch to the other keyboard layout. Same with picking up different scrolling directions. However, during this session the two screens confused me several times. We had them standing one behind each other instead of side by side, which triggered a severe "on which side of the screen can I move my mouse to the other one" kind of problem.

The mob timer program we used this time was surprisingly great. After the disappointment of last time, I didn't expect the next application I tried to work so well, but it did. It was yet another recommendation taken out of Maaret Pyhäjärvi's and Llewellyn Falco's awesome "Mob Programming Guidebook". I hesitated to try this one as I favored web applications and this one needs to be installed on the computer. But the setup is very easy, the UI simple and clear, when the timer runs it's only displayed really small on the bottom of the screen so it's not disturbing, and as soon as the timer is up it pops up to the foreground. This application had us to confirm starting the next round just like the last one did, but this time I did not feel annoyed by it, rather supported by the tool. Next time I would love to give MobTime another try, but running on the laptop we actually work on.

We started out very fast and straight-forward towards our goal, and then got sidetracked and confused in trying to find out what we were missing. Unfortunately this did not bring us closer to our original goal of trying Protractor with Cucumber and the Screenplay pattern. We couldn't even touch those topics. The session was still valuable for both of us and we had to create a basis anyway; but we definitely lost our focus. In hindsight, I think we should have shared our initial preparation for the session instead of doing it on our own. A different kind of start might have helped us to get farther towards our end goal. Another option would have been to begin our session with googling for the main intention we had. When I did so while writing this blog post, I came across a really promising framework which seems to fulfill all the initial intentions. Serenity/JS seems to combine everything we wanted to try: Protractor, SerenityBDD, Cucumber, the Screenplay Pattern. I also quickly found tutorials and getting started projects. Would love to try that next time! Really happy that Dianë and I already agreed to have another pairing session.

How to Become Part of My Testing Tour

The answer is pretty simple: just schedule a pairing session with me using Calendly! If the offered times really don't suit you, or in case you have any further questions upfront, feel free to send me a direct message on Twitter. Looking forward to pairing with you!

Tuesday, February 27, 2018

European Testing Conference 2018 - Coming Home

Last week I had the honor to join European Testing Conference as a speaker. It was my first time attending this conference, but it made me feel like I'm coming home. Here's why.

Arriving at Amsterdam

My travels went smoothly, but got even smoother after I arrived at Amsterdam airport.
It was an awesome experience to get greeted this way by Llewellyn FalcoSimon SchrijverMaaret Pyhäjärvi and her sister. I instantly felt welcome.

After a short rest at the hotel I enjoyed the second highlight of the day: meeting my learning partner Toyer Mamoojee again in real life! Although we talk every two weeks, we had so many things to tell each other in person. And we also had a final task to do: a last rehearsal of the talk we were going to give the next day. Our chance to practice it for the first time face to face! Well, all our virtual sessions before paid out. Once again we learned how well we got to know each other since we first met at Agile Testing Days 2016.

Time for the speakers' dinner! I learned to love this part of being a speaker at a conference. The evening when we all meet each other before the conference starts is an awesome opportunity to get to know some old and new friendly faces, exchange experiences, and calm each other's nerves.

Conference Day 1: Telling Our Story on Stage

Although our talk was scheduled for the first conference morning, the first day started surprisingly calm. I slept well, nervousness regarding my upcoming talk was not kicking in already. When asking Toyer about it, he confirmed it was the same for him. This might be due to the fact that either of us had already gathered some speaking experience, or that we knew we will have the other one right beside us on stage; or maybe a combination of both. After arriving at the venue we made sure our room was prepared and our technical setup working. Now we were ready for the conference to start!

Franziska Sauerwein kicked it off. Being a developer herself, she made it clear that this is a conference about testing, explicitly inviting testers and developers side by side (as well as anyone else interested in testing). I'm really intrigued by this idea! Collaboration for the win. Another great point made: European Testing Conference was started to change the world of conferences, for attendees and for speakers; and that proved just about right.
After the opening, we all enjoyed Gojko Adzic's great keynote "Painless Visual Testing". An exciting story of an experiment that could have failed or succeeded - and turned out to become an even greater success than dreamed of. Make sure to check out his open sourced tool Appraise! Right after the opening keynote Toyer and I headed towards our room - it was about showtime for our talk "Finding a Learning Partner in the Testing Community". At first only a few people trickled in, but then more and more found their way to our room. Half of them were awesome people we already met and admired, and half of them awesome people we still would love to get to know. And what can I say? We finally shared our story how we found each other as learning partners - on stage! It was simply amazing. According to the feedback we received afterwards we managed to inspire a lot of people, just as we intended. In case you missed our talk but would like to learn more, here are our slides, here's our InfoQ Q&A about the talk, and if you happen to organize a conference yourself we offer to share our story again on stage! ;-) Finally, some impressions on our talk. Right after our talk we rushed to the next great session: a speed meet! As Llewellyn put it, getting 200 geeks to talk is an achievement in itself ;) This format is an awesome icebreaker and fit really well to Toyer's and my talk before. We all were asked to create a personal mind map with three branches: about our person, about our work, and about what happened last year. This was a great conversation starter for the limited time we had to get to know the other person in front of us. My personal highlight: This way I could finally speak to Gojko himself, who had joined our talk before so that we instantly had a great topic to talk about! He also loved the fact that I studied sinology, as "inspiration can be found anywhere". I absolutely agree. Afterwards: lunch break! Time to finally get to know João Proença better. He is part of the other pact group together with Christian Baumann and Sonja Nešić which emerged at Agile Testing Days 2017, inspired by Toyer's and my learning partnership. What a great new connection! Throughout the conference we had really interesting conversations and I learned we have a lot to learn from each other. In the afternoon I joined Amber Race's workshop "Exploring Your APIs with Postman". She did a great job at making people aware of what to look out for when testing APIs as well as in demonstrating Postman, a really valuable REST client with many useful features (if you now read about this tool for the first time, make sure to check it out). It seems many people really were not aware of how easily they could get started with testing APIs. Although I already knew a lot of what Amber shared, I still could note a few points to implement at work. The only sad thing for me was that the hands-on time during the workshop was very limited. I would have wished for more time actually practicing exploring an API within our group.

Well, it also had it's good sides. From the past conferences I've spoken at I learned that at the day that I have my talk, I will have a down phase where I will be unable to concentrate anymore and get distracted by the feedback on the talk coming in on Twitter. This time, this phase started in the workshop and unfortunately continued during Emily Bache's talk about "Testing Microservices". From what I saw and heard it was a great talk, and I would have loved to learn more about Emily's experience; but I just could not pay the attention it deserved.

Next up: lean coffee! I love this agenda-less format where participants can bring their own topics and challenges into the discussion. We speakers were asked to facilitate, and I happily focused on just that. After yet another break with snacks and great conversations (I love how this conference provides multiple opportunities for people to get to know each other and exchange experience!), it was time for the last keynote for the day. Lanette Creamer did a fabulous job, telling us how to "Test Like a Cat"; a very enlightening presentation with many invaluable reminders for us testers. Just afterwards I learned it was her very first keynote! She really should get invited by more conferences. Was that the end of conference day one? Not yet, as it ended by something I've never seen at a conference so far. And as I've seen it now, I wonder how any modern conference can do without. They scheduled a retrospective so that organizers can get instant feedback from everyone and see where they can immediately adapt. And they did solve what they could! Unbelievably awesome! After shortly returning to the hotel, many people still made it to the restaurant where everybody could follow-up on the day together, enjoy nice food and a free drink.

Conference Day 2: Too Good To Call It a Night

The second day started with yet another powerful keynote, this time by Zeger Van Hese: "The Power of Doubt - Becoming a Software Skeptic". I've enjoyed this talk already online, streamed by another conference, but it was just as good seeing it again. If you have the chance, check it out yourself!
After the keynote, it was workshop time again! This morning I decided to join Seb Rose and Gáspár Nagy on "Writing Better BDD Scenarios", as this is a topic I read a lot about but really lack practice. I was delighted that this workshop was really hands-on, triggering lots of discussions around how to best formulate scenarios to benefit from easily understandable documentation as well as maintainable automation.

After yet another lunch with plenty of healthy but really tasty food, I enjoyed one of my personal highlights of the conference: Alex Schladebeck with "Exploratory Testing in Action". And when Alex says in action, she means in action. She lived up to what she promised and tested live on stage, simultaneously talking about her own testing and then debriefing it together with the audience. For all live testing she only prepared the system under test and two charters, without practicing anything upfront. And she absolutely rocked it! Awesome concept, message, and delivery. I'm in awe of the courage she showed, demonstrating the whole room what testing is and how to talk about it while being authentic, highly entertaining, and knowledgeable. I guess the only thing to top this would be to have the audience select the system under test and charters live. Alex, in case you read this: challenge accepted? ;-) Next up I joined Mirjana Kolarov sharing her experiences about "Monitoring in Production". As my team is on our way improving our monitoring I could really relate to the talk and also gain some great tips. The rest of the afternoon was preserved for a longer open space. Participants brought forward lots of awesome topics, so it was hard to choose which ones to attend. I first joined an experience exchange on mind maps where I learned how other testers use them in many different ways to help testing. Afterwards I could contribute to the question on how to identify a good tester in an interview; a discussion which draw so much interest that it inofficially continued for yet another slot. Astronomer Pamela Gay got the honor of the closing keynote for the conference: "Testing v. Crowdsourced Data, or How I learned to stop worrying and Love the F-Bomb". What a wonderful, inspiring keynote about difficulties at a level that probably not many others are facing. You know, rocks are hard - literally and figuratively. Identifying craters on the moon so that spacecrafts could land safely is a very tricky problem for both computers and human professionals; but (lots of) humans prove to be good in solving it after all. You never heard of Pamela? Now you have, and you should remember her. Wanna help her map the moon? At the very end of the conference, you might have guessed it, there was yet another retrospective! This time using the input of the audience to craft a mind map to help planning for next year. One of the positive things people mentioned: Throughout the conference we enjoyed the notes of brilliant new sketchnote artist Marianne Duijst! Check out her collection of sketchnotes done by her and others during the conference, they are absolutely worth it. So, was the conference now really over? Officially yes, but inofficially it was still continuing! Many of us could not let go yet and rejoined at a nearby restaurant. And even after a great dinner we could not yet let it go and gathered in the hotel lobby for a few more drinks with absolutely awesome people. Although completely tired, having those invaluable deep conversations even after the conference officially ended, made me feel at home even more.

Saying Goodbye for 2018

The next day I finally and really had to return home. Tired, happy, full of inspiration, new friendships made, existing ones strengthened, keeping the conference spirit in my heart.

Last but not least I'd like to thank the wonderful organizing team Maaret Pyhäjärvi, Franziska SauerweinLlewellyn Falco, Peter, Alina IonescuJulia DuránSimon Schrijver, as well as all volunteers helping European Testing Conference. You indeed do change the world of conferences - for both speakers and attendees. Many thanks for all your support and service, inspection and adaption, and most of all for providing the opportunity for everyone at the conference to learn from each other, together, with joy. THANK YOU.

I've never attended this conference before, but yet it felt like coming home. It had a kind of magic. The schedule was well balanced, the content awesome, the mixture of session types perfect, the speakers well taken care of. The people were amazingly inspiring and given the chance to have deep conversations with each other. I learned that European Testing Conference is all about the people. And these people are home.

Sunday, June 18, 2017

Our First Take On BDD

Most probably you came across behavior-driven development already. But what is behind this term? What is at its core? How does it benefit a team?

Years ago I read a lot of blog posts about BDD and was intrigued to experience it myself. When starting in my current team, I began to spread my thoughts about trying BDD to see if this approach would help us. It took quite a while, but finally the team agreed to give it a try.

So here we are. We started experimenting with BDD and had our first Three Amigo sessions to kick our stories off and create shared understanding before starting implementation. We had our product owner on board, the developer who pulled the story, and me as a tester. We talked about the scenarios we see and discussed concrete examples. We raised questions and discovered unknowns. We decided what's in scope and what might follow later or never. We captured our thoughts as conveniently as possible, be it using Gherkin's Given-When-Then syntax for scenarios or any suitable graphical visualization. We decided on which scenarios to automate, on which level to automate them (mocked, through API, or through UI), and which scenarios to leave for manual exploration only.

Right after our first Three Amigo session, the developer told me how much she loved it. Now that we clarified everything we could think of at that point, she felt confident to be able to focus on implementation, without having lots of question marks on product side. She even said she wanted to do this on all stories from now on. As for myself, I could not agree more. I felt that the biggest part of testing had already been done. As most of my questions were already clarified, I could focus on looking for further unknown risks when testing the actual product increment.

Our experiments triggered me to read about BDD again. I found several awesome blog posts, all emphasizing how important having those initial conversations are to create shared understanding by discussing examples and therefore to drive development. All of them stated that automation is nice to have, but that this is not the main point of BDD. Of course, when you automate the discussed core scenarios, you also have an executable specification, improved your regression safety net, and added living documentation. Still, Augusto “Gus” Evangelisti concludes for himself:
"BDD is about conversations and collaboration to generate software that matters"
 Liz Keogh even goes beyond software:
"I can’t even say that BDD’s about “writing software that matters” any more, because I’ve been using scenarios to explore life for a while now."
"BDD is the art of using examples in conversation to illustrate behaviour."
"If you’re not having conversations, you’re not doing BDD."
"BDD isn’t about the tools. It’s about the conversations you have, exploring examples (or scenarios) of an application’s behaviour, to see if everyone has the right understanding."
"Some people really focus on the tools and testing. Others focus on specification. Really, though, it’s exploration that we start with; those thought-experiments that are cheap to change, and not nearly as dangerous as the real thing. [...] It’s pretty easy to explore what they want using examples, then use the results of that conversation as specifications, then as tests."
Having conversations is more important than capturing conversations is more important than automating conversations
Having those quotes in mind, can we call our team's first steps with BDD actually BDD? I guess yes, but I think we have to gain more experience before I can truly answer this question for myself. However, I already know that having those conversations upfront to increase shared understanding, explore stories and clarify questions helped us a lot to deliver actual value to our users. It was worth investing the time and it will be worth asking again: "Can you give me an example?"