When a friend leaves us behind

My intention with this blog is to keep it strictly for testing related topics, but today I want to make a pause on that to pay tribute to a friend of mine, I'm not the best writter around, but this post is truly heartfelt.

On October, 2008 I was a recent graduate looking for a job, didn't have any previous experience except for my "experiments" with Java, C++, C# during college, and like most I wasn't really considering a career in software testing, my interest was in SW development.

One day I saw a job ad from a company looking for trainees for multiple testing projects, got interviewed at some point of mid-October by the company's manager who was re-routing candidates to the test leads, I got my next interview with a person that would end up being key in my career, her name was Renata Espinoza.

I passed my interview with her and was selected with other 5 people for a training to get into the 2 positions she had open in her team, my best friend who I met at that training and is still my best friend today and I were the chosen ones. On October 29th, 2008, I started writing my testing story.

Renata probably wasn't a Rockstar/Ninja/Hardcore/Super Saiyan God level tester, but she had great softskills and was a great coach, to be honest I didn't like at all to stay on testing as a career path at that time, I desperately wanted to transition into a development role, but as the days passed and I started learning more about testing and its importance thanks to her, I stayed in testing, and plan to stay in the testing world for many years to come.

My first project there was under scrum with a very demanding client, being just out of school I didn't know a damn thing about any agile methodology, but thanks to her I found my way through, my client sent me a message thanking me for all that I had done and telling me she was impressed with the job I did being only a trainee, I thanked her and immediately reached to Renata to thank her for all that she taught me during that project, I had multiple opportunities to do different things, including my 1st test automation project during the short time she was my boss at that company.

On August, 2009 I left that company, with less than 1 year of experience I was hired as a Semi-Sr test engineer at some other place where I had better salary & benefits, since my then-girlfriend(now the most supportive wife ever) and I were planning to get married I couldn't let that opportunity pass. On my last day I thanked her a lot for all that she did for me and told her that if I had gotten ranked as Semi-Sr was thanks to what I learned from her, I remember she told me that all that I needed was a push, she gave me her blessing, wished me luck and hugged me, I never had the chance to work with her again, but the lessons I learned with her still serve me on my day-to-day.

Yesterday, Renata, that great 1st boss I had passed away after battling with cancer for sometime, leaving behind a mourning family and a lot of alumnis like me that got an opportunity thanks to her and will miss her everyday from now on.

Goodbye my friend, and may you rest in peace for eternity.

A creative way to present a test strategy to your team

Last week I was checking what was going on the testers.io slack team, and I noticed some comments from Mark Winteringham about test strategies, I among other people commented on the same topic, then Mark mentioned one time he crafted a test strategy in the form of a ludo board.

I became intrigued with that approach and asked Mark for some more details of it, he commented briefly about the general idea, I still couldn't picture it entirely, so last Sunday after my 2 childs went to sleep I started creating one, the idea of this approach is to serve as a general guideline on the responsibilities of each "specialist" within a cross-functional team working under scrum on regards of software quality.

First let's take a look at a blank ludo board:

As you can see the board has 4 squares where the tokens are placed and the goal is to bring them all to the center.

In my case I labeled the center as quality strategy, And assigned each square to an "specialist" area, in the case of my team, there's one BAs, another one for Developers, Another for testers, and last but not least, one for the Scrum Master and product Owner, so I got something like this:

Click to enlarge

Since not all team members have had experience with scrum, I started by filling out the responsibilities that each role has had in my previous experiences at other companies. The next step was to socialize this with my team, so I had separate quick conversations with some Devs, my BAs, Scrum Master and fellow test engineering colleagues, we came to agreements on responsibilities, always emphasizing cross-functional team collaboration, how I as a tester could help my Devs, BAs, SM, PO, and vice versa.

This approach was greatly received in my team, so right now we're in the process of getting some printed copies so we can hang them in the walls in our office space.

Hope this is useful for you, and in case you follow this approach, I invite you to blog about your experience.

Also, last but not least, huge thanks again to Mark Winteringham for sharing this on slack.

Walking new paths

Last August I was in my previous job's bench, I had just finished my assignment in an e-commerce project for an apparel company. 

It seemed to be just like any other bench time I had, not much to do, working on some improvements to internal company documentation, trying to learn about new frameworks, but suddenly on Aug 12th I opened my twitter feed, and saw some testing folks tweeting about this session. 

I had already heard about James Bach, but hadn't really read about his testing philosophy, knew he is a respected member of the testing community, so I started following the thread, that's how I first learned about Context-Driven testing.

I kept following the conference and became fascinated with it, so I started reading and reading and then it was like a sudden realization moment, I wanted to be part of it, I wanted to start trying to do things in a different way I had been doing before.

Later that month, everything lined up perfectly so I could join my current company, they needed a Test engineer that could come aboard and set up the company's test practice.

This blog is going to serve as a log for my memories of this new stage of my career where I'm trying to test differently and better than ever before along with my memories in my attempt to become a speaker for testing conferences and sharing my knowledge and the Context-Driven testing approach with the testing community and last but not least, try to become a blogger.

Hope You'll like the content of this blog. 

More entries coming soon.