I think how to put a thought of me into discussion mode before I start to speak. I take several approaches and strategies on same i.e. to bring into discussion mode rather as a argument and debating tone. Yet there will be set back at certain times and I learn from it. I have not let it to demotivate it me, but I have taken it as an opportunity for communicating better. The intention is doing the job best and right for context and vision of the organization.
I once said, "I don't know and this is what I know" in a meeting to a team member. When I reflected on myself later that day, I could see that I had given up on holding it for long time. Which usually I don't do i.e. I don't give up. I get stuck to it and have patience with silence in doing the task, which looks odd most times to people around me. The point here was not doing it to perfect or excellent, but doing the work in the right way. Figuring out the right way is not easy when we have team with diverse skill sets and culture practice.
Most of the times I wrote feature file (outcome of the collaboration in BDD practice) that was written, though I know it should not be me writing it. I wanted to keep it at least on average though not at good, hence I rewrote on review. Different teams practicing it in different ways and none knows who is better and not better.
If there is a design approach for a product in programming, every programmer follows it in the team, say. But this does not go in testing and automation practice, most of the times. When I sit back and ask myself, "why it is this way?", I happen to see -- could be the team is not trusting on what I'm saying? Then whom do they trust? I don't have an answer for that as well. I asked myself, "why are they so confused when we have clear cut solution approach with clarity?" I learn this is where the skill and expertise gets distinct in the work.
During this time, I observed the work we were doing and I use to analyze by staring at it to know -- what are we doing and are we doing it right? That was one of key job I believe in my role. To mark where we were right and not right, I had to learn the subject which was new to me as well. I took time here thinking it will benefit the team and organization. I asked myself, is it worth doing it? Then who else had done it? I have no answer for that in me.
In this context for me the best thing to do was, to let the testers do it and if they see a failure or difficulty later, so they might reflect back. That was a hard call which I took. I failed! You see, that's how the failure tag is put on a senior or junior in team for doing and not doing a work, when nothing goes as expected. Anyways, I failed!
What did I learn from this, then? It is okay to fail and I have pride in it. What I got from this fail are incredible learning.
I'm glad when a friend Nikolay wrote about it here -- https://saucelabs.com/blog/is-bdd-automation-actually-killing-your-project
It is not just me who goes through it. There are other people too and I saw on reading the post of Nikolay. It is one of the good posts which I will refer to a tester who is practicing automation using Cucumber and the word BDD.
As well, I observed, at times even I give up and lose bit of my patience which I hardly remember doing in my career so far.
At the end, if the question is "Who is wrong here?", I don't see anyone. There comes the time -- where a person A feel other person B is wrong; then the person A feels I'm wrong and person B is right; then the time comes, where person A see that both Person A and person B both were right (or wrong).
It was the outcome which counted most that day and the decision that was made for the outcome, speaks out more unsaid. The team has to move on and continue doing what it is expected to do and in a right way for context.
