(Guest Blog Series) This is why vulnerability helps you improve as a professional

“Vulnerability is the birthplace of innovation, creativity and change” — Brené Brown

Each person has a different perception of what vulnerability means. Most of us associate it with weakness. This is mostly due to our upbringing, social background (race, education, lifestyle, gender, creed etc) or due to not knowing too much about this subject in general.

While indeed vulnerability involves a lot of exposure and risk, it is in no way the same thing as weakness. Now, we will explore what vulnerability means and showcase why being vulnerable can be beneficial for your career and personal growth.

The textbook definition of the term is: ‘vulnerability is the quality of being easily hurt or attacked’. The term is derived from the latin work ‘vulnus’ which means ‘wound’. This literal definition can be extended to the emotional area as well and imply a certain openness — if you are vulnerable, you might suffer.

But what if you can cultivate this emotion? What if this kind of exposure or being vulnerable is an untapped source of growth and learning?

Where would the world be if innovators shut down all vulnerability?

Thomas Edison

If Thomas Edison got discouraged after his many failed attempts to build the lightbulb (and many other patents) and after people telling him it’s pointless, we would have probably gotten this invention at a later time.

If Henry Ford quit after his first 2 car companies failed and he lost credibility from his investors and the public, the automobile industry would not be the same today.

If Elon Musk was afraid of public view and being exposed, he would not openly reveal his projects, only his successes. For example, he publicly announced when his Model X Tesla would start being manufactured. That term was delayed for 18 months. This is just one of the hits the magnate has taken, a full list is presented here. How much do all these failures affect him? Well, he’s worth 20 billion USD so I’d say they haven’t killed him yet.

But what does this have to do with vulnerability?

I’m sure that they did not necessarily think about vulnerability when they decided to keep going despite all the things they’ve been through, but this emotion is the core to understand why they did it.

The researcher Brené Brown says that tapping into the emotion of vulnerability opens up some new experiences which otherwise are not lived at their fullest. These experiences are love, trust, joy, and creativity. Vulnerability also means being engaged, being all in, and this is exactly what the people mentioned above were/are. They showed dedication and a strong belief in their work even when the circumstances were not encouraging.

When Musk was asked during an interview how he felt about his role models not supporting his ideas, he gave an emotional and genuine answer. This is what vulnerability is all about:

Despite the fact that people he admires most, don’t share the same vision, Musk is nowhere near giving up. His natural response is that he wishes to show them what he is doing and what he’s hoping to achieve and hopefully bring them to his side. That’s how strong his resolve is.

Examples of vulnerability which encourage growth

1. Creating and showcasing your creations: An example could be when you create a presentation or workshop about something you are passionate about (or anything for that matter) then deliver it without any guarantee of acceptance or appreciation or even that anyone would show up to see it.

2. Asking questions: Being afraid or ashamed to ask questions revolves around the sphere of vulnerability. If you do ask, you might be perceived as stupid or it means admitting that you don’t know anything about the subject at hand. If you don’t you’ll probably play along, act like everything is crystal clear and in fact leave with bigger gaps than the ones you started with. But, under no circumstance is asking a question a bad thing or something we should avoid.

3. Showing genuine appreciation: Vulnerability is to tell your colleague how much you appreciate his work and that he did a good job because you really feel that way and you mean it.

4. Giving/Receiving feedback: Vulnerability to put yourself out there and openly give someone feedback even if it’s not necessarily something good. Then being open to receiving the same kind of feedback.

5. Saying no: Many people have a problem with saying no at work or their personal lives. This is because we fear that by doing so, people will stop liking us and we lose part of our utility. Instead, saying yes all the time to all insignificant requests can disrupt our flow and render us less useful or productive at work. When the request is not necessarily beneficial for your growth, some alternatives to saying no could be openly explaining why you are not going to do it or offering them another solution.

6. Asking for help: By doing this, you openly admit that you were not able to solve an issue by yourself. Certain thoughts can arise that we might seem weak or that we are not as resourceful as we have people believe. The truth is that, by asking for help, besides getting a new perspective from others, you also save up time to invest in other activities. And people are generally really eager to help when they can. When you seek or offer help, a deeper level of appreciation and trust is created.

7. Accountability for your work: This means that you are responsible for all the work you do, successes and failures alike. It’s being able to take a compliment when it’s due but also owning up to your mistakes and being able to say ‘it is my fault‘ or ‘I’m partly to blame for this so let’s see what we can do so that it doesn’t happen again or how can we improve our process’.

8. Nurturing connection: Vulnerability encourages connection. The connection is starting to be more and more valued in the age of technology where we tend to only focus on our 9 to 5 where we do our part then go home. By allowing yourself to be vulnerable you open up to a greater level of connection which ultimately results in gaining trust.

9. Being adaptable: Adaptability to change is all about vulnerability. It implies that you let go of some beliefs and truths which you already know and adopt new truths. It’s taking into account that confirmation bias is real and it can affect every aspect of learning something new, especially in a field where we already have some kind of expertise. Adaptability also implies having the courage to take up learning a new thing, even if it’s hard and you might fail at first, but believing you will get it done.

10. Showing authenticity: This means being able to express who you really are, not who you think you should be depending on a certain situation. Authenticity generally leads to people’s appreciation, and with that, to gain their trust.

The bottom line is…

Whatever your conception was regarding vulnerability, it should not be seen as a weak spot.
Shutting this emotion down will not make you a better or a stronger version of yourself. It will only lead to a more limited and close-minded you.
So start with baby steps and gradually do some of the stuff I’ve mentioned above or something you’ve been putting off until now and see where it takes you professionally and personally.

Please let me know if you liked this article and more importantly what you didn’t like about it, and if it helped you in any way shape a new/ different perspective on the subject of vulnerability.

Thanks for reading!

On the 2018 Romanian Testing Conference

So, last week I had the pleasure of attending the 2018 edition of the Romanian Testing Conference. It was my second visit to Cluj: after having delivered a workshop at the conference last year I was invited to do another workshop for this year’s edition. I told Andrei, one of the organizers, that I would gladly accept if he:

  1. could schedule my workshop for the Thursday (Wednesday and Thursday were pre-conference workshops days, the conference itself was on the Friday), and
  2. would make it at least as good an event -and if possible, better- than last year.

Challenge mutually accepted!

During the time when the CFP was open, I sneakily submitted a proposal for a talk as well, and was quite surprised to see it accepted too. Yay! More work!

I left for Romania on Wednesday and arrived around 7 PM at the hotel Grand Italia, which again was both the place where the speakers had their rooms as well as the venue for the conference itself. I cannot stress how awesome it is to be able to pop in and out of your room before, during and after workshops and talks without having to go to another place. Need a rest? Go to your room. Forgot something? You’ll have retrieved it in minutes. Want to check if there’s anyone up for a chat and/or a drink? Just ride the elevator down.

Again, the organization went to great lengths to make us speakers and workshops hosts as comfortable as they could. Always someone around if you have questions, picking you up from and bringing you back to the airport in dedicated RTC cars (even at stupid o’clock), it is a wonderfully organized event.

Thursday – workshop day
Like last year, I hosted a workshop around API testing and automation. Where I only used REST Assured last year, I decided to give the participants a broader overview of tools by including some exercises with SoapUI, as well as a demo of Parasoft SOAtest, a commercially licensed API testing tool. Also, compared to last year, I threw in more background on the ‘why?’ and the ‘what?’ of API testing.

Me delivering my workshop

I had 30 participants (like all other workshops and the conference itself, it was sold out) and after a bumpy start, including a couple of power outages, we were off. Like with all workshops, it took me a little time to gauge the level of experience in the room and to adjust my pace accordingly, but I think I got it right pretty quickly. With several rounds of instructions > exercise > feedback, time was flying by! Breaks were plenty and before I knew it, the working part of the day was over.

We were invited to a wonderful speakers dinner in the hotel restaurant, which provided plenty of time and opportunity to catch up with those other speakers I met before, as well as to meet those that I hadn’t had the privilege to meet yet. After a day of teaching and all the impressions from dinner, I decided to be sensible and make it an early night. Mission failed, because once in my room it still took me hours to fall asleep. My brain just couldn’t shut off..

Friday – conference day
Friday morning came quickly and that meant conference day time! The programme was strong with this one.. So many good talks on the schedule. Yet, like with many conferences, I spent most of the day in the hallway track, preparing for my talk (I wasn’t on until 4 PM) as well as having a chat with speakers and attendees. For me, that’s often at least as valuable as the talks themselves.

Still, I saw three talks: first Angie Jones’ keynote (I met her a month earlier in Utrecht but had never seen her speak before), then Viktor Slavchev’s talk and finally Maria Kedemo’s keynote. All three were very good talks and I learned a lot from them, both in terms of the message they conveyed as well as their presentation style.

This day flew by too and before I knew it, it was time for my own talk. Now, I’m a decent workshop host (or so I’d like to think…) but I am not an experienced speaker, so doing a talk takes a lot out of me, both in terms of the time it takes to prepare as well as the energy I spend during the talk itself. Still, I was pretty pleased with how I did, and the feedback afterwards reflected that. Maybe I just need to do this more often…

Me during my talk

After the closing talk, which I skipped in favor of going outside, enjoying the beautiful weather and winding down, the conference was already over. To round it all off, we went out for a bite with some of the speakers before we attended the conference closing party. The organization had one final surprise in tow for me there when they gave me an award for the best workshop of the conference. Seeing the list of amazing workshops that they had on offer this year, I certainly did not expect that!

Since my flight back home left at an ungodly hour the next morning, I decided not to make it too long an evening (not everybody followed my example judging from my Twitter timeline the next morning..). Travels home were uneventful (which I consider a good thing) and suddenly, it was all over again.

My thoughts on this wonderful conference, the organization and the volunteers can be summarized by this tweet, I think:

Andrei Contan@andreicontan

Book the dates 8-10 May, 2019 for @RomaniaTesting by @ard_kramer

Bas Dijkstra@_basdijkstra

I encourage *anyone* in the software testing field to go to @RomaniaTesting at least once. You *will* be having an awesome time.

See Bas Dijkstra’s other Tweets

So, did the organization deliver? Well, I did get to do my workshop on the Thursday, and I had an amazing time again, so yes, I’d say mission accomplished.

Who knows, we’ll be seeing each other there next year?

14 Most Common Mistakes A Tester Makes

Did you do any mistake recently?

I did.

But we’re all humans, right? And we’re all likely to make mistakes. Usually people associate making mistakes with punishment which in most of the cases is the immediate action after a mistake is made. And seeing the good part in it is almost impossible, at least while you’re struggling to repair what you did wrong.

Making mistakes can have a positive impact on your professional growth, the only condition is to learn a lesson from the mistakes you’re doing. And during the learning process is almost impossible to avoid making mistakes.

Making mistakes is a lot better than not doing anything. — Billie Joe Armstrong

There is no activity domain in which you’re more likely exposed in making mistakes than in others. Below is a list of mistakes a software tester is exposed to during his/her work lifetime and from which can learn several lessons.

1. Incorrectly evaluate the risks

The job of a tester rely much on identifying and risk mitigation. A good risk analysis can help in identifying what can go wrong with the product you’re testing before it goes to production.

Identifying the areas of concern can massively reduce the costs and time spent afterwards in fixing problems found in later stages of development.

Photo by Caroline Hernandez on Unsplash

2. Miscommunicate the impact

Miscommunication is always a mistake, even we’re talking about miscommunicate the impact of a bug, the presence of it or any situation that might jeopardise the quality of the product we are testing.

3. Ignore a bug when you see it

Ignoring things like miscommunicate them should never happen. As testers we must address any situation we’re facing — even if we don’t have solutions for these situations or maybe don’t have the bigger picture, it’s better to make them known than to act like the elephant is not in the room.

4. Using the same test data — pesticide paradox

Executing our testing scenarios using the same test date might lead us to the pesticide paradox. Repeating over and over the same test cases with the same test data will no longer find new bugs.

5. Not keeping test cases up to date

If you want your test cases to be useful, keep them up to date. Outdated test cases don’t bring any value into your testing.

6. Criticising developers

A constructive way of giving feedback and a positive communication can make the difference in a tester-developer relation. Try to spot also the good work a developer is doing, not only the bugs or problems found in his/her code. Add positivity into your testing!

7. Making assumptions

As a tester you should never make assumptions! The best way is to ask all the questions you need an answer for, helping you to understand the requirements, what need to be tested, what was implemented or how the application under test is expected to behave.

8. Incorrectly evaluate and measure the effort

Project Manager: “How much would it take you to test this?”

Tester: “Hm, a couple of hours, maybe?!”

Be sure you make a step back and you see the bigger picture before you give estimates.

9. Frequently changing the focus

Emails, meetings, regression testing, test case creation, test case execution, a phone ringing, a person asking something, a patch in production that needs to be tested, another hot fix. I think you all recognise the scenario.

This can have a negative impact on your productivity and quality of your work. I would suggest you to try to find what works best for you and organise your working day accordingly.

10. Copying the acceptance criteria into the test cases

We are sometimes tempted to make this mistake while writing our test cases when we don’t see much value in writing and executing them. Let’s try not just state the obvious from acceptance criteria in our test cases, but also focus on negative testing, edge cases or other scenarios that might make our testing more complete.

11. Incorrectly evaluate the impact of a new functionality/fix

This is translated by one word: regression. It is crucial to understand what other areas are affected by a newly developed functionality or by a code fix.

12. Being scared of using tools

This might happen when you, as tester don’t feel very comfortable with your technical skills. It’s totally fine not to be a super hero in using tools, but I encourage you to be open to any solution that might ease your daily work.

Even you don’t feel comfortable in using tools, you might get help from other testers, developers or maybe online support.

Photo by Todd Quackenbush on Unsplash

13. Not thinking as the end user

It is better to take the user’s hat and imagine how s/he will use the application you’re testing. It is said that the end user is the best tester which finds more and critical bugs. And we don’t want that, right?

14. Not asking developer’s help

Sometimes we are afraid of being judged or afraid of looking stupid which leads us in trying to find solutions to our problems by our own. It is not a bad thing to be a problem solver. This is not the best practice though when you invest time in doing it instead of asking a developer what you’re trying to figure out.

I encourage you to have a good relation with the developers you’re working and maintain a positive communication. There should be no me vs. you, tester vs. developer kind of situations.


Conclusion

If you found yourself in most of the above situations, I can feel your pain, I went though all of them too through my career. Definitely is desirable to avoid all these mistakes when possible, but when they happen, don’t punish yourself too much. Is good to make mistakes and learn good things from them. Turn your mistakes in valuable life lessons!