Becoming an idea machine

This is not my idea, and I have to give full credits to James Altucher. Here you can find a better description to this approach, and I highly recommend his book Choose yourself that has helped me a lot. The two ideas from the book which affected me the most were: The daily practice which helps you maintaining a work/life balance and the Idea Machine methodology. I’m going to talk about how I approached the 10 ideas a day movement and how it changed me.

It’s stupid trying to explain the reasons and methodology better than himself, so I’ll you point you to his post again in case you don’t know what it is about. I don’t know how other practitioners approach it, but I usually spend my walk to work (it takes around 20 to 30 minutes) writing down 10 ideas about anything. Whatever yo want is a valid theme. It has ranged from work-related ideas (how to deal with X situation, how to improve Y product, what approaches can we take to solve Z), to personal subjects, game design challenges (how I’d change a game that I like), personal project ideas, general project ideas, stupid trivia, or even lists of ideas I can use for the challenge. The motto is that there is no invalid idea, and they don’t need to be plausible nor realistic.

That being said, doing it has helped me on numerous occasions. It helps me being ready to some unpredictable events because my wild imagination already hypothesized something similar, it brings new and fresh ideas to try and it trains me to give my best during brainstorming sessions (either formal or informal ones) which is one of my favorites ways to find solutions.

Thinking particularly about testing I find the training of thinking outside the box and defocus (as explained by James Bach’s Exploratory Testing dynamics) dealing with a wide spectrum of test scenarios before diving into the ones who doesn’t feel right. I don’t think testing is only about naming a bunch of scenarios that can fail (which I consider “wide testing”), but also focusing on a smaller set of features where most of the risks are concentrated (“deep testing”). Undoubtedly, training myself every single day to wreck my brain barriers and be more creative helps me A LOT during the wide testing part.

I have to admit that the most important reason, by far, why I started doing this and still keep on track is because I love this exercise. I’ve surprised myself so many times finding hilarious and weird lateral-thinking solutions to simple problems that now I have an addiction. I have really good memories doing this daily practice, especially when I involve someone in the process and we allow ourselves to get WAY out of the box. I remember a November’s night walking back to our Airbnb in Copenhagen when I started explaining the 10 idea-a-day magic to one of my closest friends, and we brainstormed way more than 10 ways inventions to keep our feet warm. I don’t think any one of them were actually viable but… I always enjoy realizing that someone can be as bonker as me.

James Altucher says that the majority of the ideas should be trashed, because if you really had a good idea it would come over and over again during the process, shaping it with more details. As I use Google Keep for it, I enjoy reading them again from time to time. And it allows me to do some cool things like sharing some examples with you right now!

Food is not the only way to get clients as a restaurant.. some ideas on that!

Living with a partner is not always as fun as it should… 10 crazy ideas to improve it!

Getting fired sucks, and if I know that person is an amazing professional, I have to help!

Have you ever tried this? Do you think you can come with 10 ideas about any subject right now? Seriously, try it! It’s so much fun!

May the force be with you,
Gino

How applying to another company made me a better tester

I always say that a good professional has to be always in the market. Has to understand how the industry is shifting, what other companies are looking for, the new roles that are emerging and think about your career. Obviously, during the process, you start questioning if your current role is the one you really like, and usually apply to a position that better fits your current needs and expertise. In this case, I applied for my dream position but got a negative response during one of the last steps. But we are not here to talk about my failure now, so let’s focus on why the experience made me a better tester for my employer at that moment instead.

So, at that point, I just stopped fearing at my workplace. I started being honest when I don’t share the decision, openly giving feedback no matter where it comes from. I started saying no when I get asked to do something that I don’t see value on, explaining to them why that other approach would be better. I spent loads of my spare time reading and learning, trying new experimental (new for me) approaches in any area I wasn’t comfortable with the results. I started giving me the luxury of going bold spending the time doing what I think would deliver better results (I.e. getting involved with the user testing, UX designs, etc.). It has been a time of high risk and high gain so far. I made the assumption that I’m here because of my skills and my knowledge, so I don’t have to convince anyone prior to taking an action as long as I think it’d improve our processes, product or moral.

One of the examples is saying no when I was asked to automate every piece of testing for our GUI. I’m a Software Developer in Test, I believe that automation (or how I prefer to call it, software tools for testing as described my James Bach here) allows to enhances quality in lots of ways, for example providing an exhaustive safety net to prevent regressions while building an extensively updated documentation; but, at that time and with that team, only focusing on automation wasn’t going to give us the value we needed. Instead, I focused my efforts on building a minimum GUI automated checking suite, while spending the rest of the time giving feedback on the product prior to the release through exploratory testing session, an informal way to centralise and share it (a Google Sheet instead of the usual Jira bug tracking), pairing with the developers doing a quick demo after the feature was done and involving everyone who volunteered (ranging from designers, stakeholders, operations..) to give feedback about the features, experience and suggestions (using myself as a hub to deal with duplicated feedback, fixes already on the pipeline and reducing noise). I would have never tried this if I wasn’t spent some time on the recruitment process learning about exploratory testing, if I still feared to say no or if I didn’t question my expertise considering areas outside automation.

Other areas where I feel it affected my job was dealing differently with each team, considering in each situation how should I approach the Quality. Previously, I tried to standardise how the company deals with Quality, but every small development team had different levels of involvement with Quality and my energies (as the only QA) were limited; so I found way more valuable to trust the approach of the ones who already see quality as part of their deliverable and dive deeper in the cases where changes were needed. In some cases, it only took the time of slightly changing the output for a cleaner reporting, reviewing their progress and offering consultancy and guidance; using the majority of my time addressing processes and assessing the Quality of the deliverables for the teams who needed more help.

This situation taught me that working in an open environment where you don’t fear about being questioned about your decisions (either if it’s because the company culture, or because you stop fearing to be fired) makes me a better professional, especially a better tester. For me, tester’s duties consist on questioning every process and methodology in order to change them to delivering higher quality products, hopefully leveraging the development process during the journey.

I was in a recruitment process because I felt that opportunity would be more enjoyable and enlightening. That mean I needed to either change how I was working to enjoy it more and learn as much as I could, or get sacked because stakeholders didn’t like the new approach. Either way sounded like a win for me.

May the force be with you,
Gino

Why I smiled when our servers melted

Yes, it’s true, I was cheering and dancing when our stress test melted our servers. I would be high-fiving the rest of the QA team if I wasn’t the only one. No, I’m not enjoying that we have to buy another server, nor that you have to spend some time now setting everything up again. I’m celebrating it because, today, I feel useful in the team.

That doesn’t mean that things have to break so I can feel part of the team, but there are some days when my job is under review because “I am not catching enough bugs”. There are some days when I have to spend time explaining why I’m reading the documentation and understanding the knowledge base instead of writing automated test of an unfinished product, occasionally spending way more time explaining myself than working on it. Some days I have to convince developers, one by one, that despite their beliefs I wasn’t hired to write and maintain their functional tests, even tough if I have command on Selenium and I helped them during that tedious week.

But, today, I feel that all the time invested learning how our users call our batch processor, reading how our stack handle and balance the load and how to performance test the application inside AWS so it doesn’t cost us a fortune was worth it. Today I know that we’ve found something that might happen when we go live and no one else was caring about. Today, I can prove how useful I am.

This is not about me enjoying when you feel ashamed, nor about pointing at you while talking with the stakeholders. This is about avoiding that our users break the application this way because we understand how to avoid it.

Today is a nice day.

And, ok, it’s also quite funny to see you al running around and asking me how did I manage to break it, as well as receiving compliments for the effort.

I’ve also ordered a fireproof vest on Amazon, just in case.

May the force be with you,
Gino

How killing raid bosses made me better colleague

OK, some of you won’t even know that a raid boss is, and those who know won’t probably see any relation; so let’s start from the beginning.

MMO is a genre inside video games, and it’s principal characteristic (I’m my opinion) is having a huge number of players working together for the same goal. The most famous example is probably World of Warcraft. One of the activities most of these games offer are Raids, which are challenges for a considerable number of players (10-25 usually) that need to be accomplished through coordination, proper leadership and fast reacting. And I’ve just spoiled you.

In order to succeed on them, I had to commit to a time schedule, build some relationship with my guild mates, learn some strategy or, in the funniest of the cases, worked it out with my friends failure after failure. There were some days when we spent hours retrying a hard challenge without beating it, even if we achieved small improvements (and learnt some mechanics). I really remember those experiences and feel so lucky. If you don’t know how it feels, or you just want to remember it, malukah’s beautiful post is for you.

And now, back to our business. OK, we know what a raid boss is, and how can it affect my career? I truly believe that every single of your experiences sculpts you, to a greater or lesser extent. I think those were the first times when I had to meet people’s expectations (and it was completely volunteer) while learning how to handle them. I had to commit my time, spent my energies keeping the moral up, convinced stakeholders to try another approach, decided when to take a break… Do these skills sound familiar to you? And, for me, the most important thing was that I was enjoying my team while learning because I was just trying my best to beat the challenge.

Years later, when I spent some time raiding again in another video game, I was the one explaining to the team the different approaches people are trying online so we can build our own with those premises. It was my duty due to my insane obsession with knowledge and efficiency that forced me to surf the net understanding the challenges. It also forced me to talk over a mic with Swedish, German and Polish people. Believe me, if make fun of me now because of my English, it was a huge step for me talking with those guys back then.

And this why I believe that every single of your experiences makes you the person (and professional) you are right now. For me, that was the time when I started building some of the skills I am proud about now.

Remember it when you start yelling at your child for wasting too much time playing video games. It’s not a completely waste of time!

May the force be with you.
Good luck & Have fun,
Gino

Meet Rapid Software Testing

Rapid Software Testing is a testing methodology defined by James Bach, Michael Bolton, and Paul Holland. This methodology focuses on the skillset and experience of the tester alongside with some rules and techniques to achieve a cost efficient quality assessment of a product. It is based on heuristics, fallible methods of solving a problem of making a decision. That’s the main reason why the methodology empowers the tester, which is the one deciding how and when to use the heuristics. It also focuses on the story of the testing journey, giving as much importance to explaining how the test was, what has been found and what is missing to verify than the test itself.

In this video, James Bach briefly explains its details:
http://www.youtube.com/watch?v=2t35cEF4e6M

Personally, I agree with most of the ideas from RST. I truly believe the future of the industry would be empowering testers as high skilled professionals, and relying on automation for the most repetitive, tedious and error prone tasks. Some ideas resonate with the Quality Assistance approach as well (although it relies on teaching the developers how to be a great tester, so it can get feedback sooner).

I also find Exploratory Testing as one of the most challenging intellectual activities I’ve ever practiced. It allows me to use my knowledge of the product, the technologies involved, how the team works and my guts to dive deep in a product and get a story about the current state of its Quality. Its heuristic techniques and tips have enhanced my exploratory testing exercises, as well as making me realize some potential scenarios while developing automated verifications.

There is a lot of documentation online about this methodology (way more than we can tackle in one blog post), so I’ll try to follow up the subject on following entries. It is going to be a subjective interpretation, what I’ve learned from it and how I apply it. Feel free to use the following resources to learn about it, although it heavily relies on practice so I encourage you to give it a go. Luckily, you don’t have to change neither the process or the technologies, so you won’t need any management approval to start applying this methodology!

I want to finish with some quotes from James Bach about Software testing, life, and everything else.

“In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards”

“That’s what training testers is all about. Not only have these ideas, but to explain and defend these ideas. “

“A lot of people think ‘Oh testing is all repetition’. It is kinda like sex, if it’s not fun, you’re not doing it right. You’re doing it wrong. If you approach testing not as the most challenging intellectual exercise you’ve ever done in your life, you don’t understand testing. Because that’s what it is.”

I hope you’ve found this as interesting as I do, and rest assured that I’ll dig deeper on the subject. That’s the best way to force myself to summarize the information I know, and it is an invaluable way to gather some precious documentation for the future.

May the force be with you,
Gino

Resources:

• http://www.developsense.com/courses.html
• http://www.satisfice.com/testmethod.shtml
• http://www.satisfice.com/rst.pdf
• Open Lecture by James Bach on Software Testing

Hi, I’m your tester

Hi,

I want to introduce myself before we start working together. I’m Gino, and I’m here to support you. I’m here to make you shine, developer. My job is to do whatever it takes to deliver the highest possible product that our users deserve. I don’t want you to think that I’ll try to break our product to shame you because my only goal is to understand how our solution performs and how can it get to a better shape before reaching our users.

That’s why I make the following commitments to you.

Sincerely,

Your Tester.

1. I provide a service. You are an important client of that service. I am not satisfied unless you are satisfied.
2. I am not the gatekeeper of quality. I don’t “own” quality. Shipping a good product is a goal shared by all of us.
3. I will test your code as soon as I can after you deliver it to me. I know that you need my test results quickly (especially for fixes and new features).
4. I will strive to test in a way that allows you to be fully productive. I will not be a bottleneck.
5. I’ll make every reasonable effort to test, even if I have only partial information about the product.
6. I will learn the product quickly, and make use of that knowledge to test more cleverly.
7. I will test important things first, and try to find important problems. (I will also report things you might consider unimportant, just in case they turn out to be important after all, but I will spend less time on those.)
8. I will strive to test in the interests of everyone whose opinions matter, including you, so that you can make better decisions about the product.
9. I will write clear, concise, thoughtful, and respectful problem reports. (I may make suggestions about design, but I will never presume to be the designer.)
10. I will let you know how I’m testing, and invite your comments. And I will confer with you about little things you can do to make the product much easier to test.
11. I invite your special requests, such as if you need me to spot check something for you, help you document something, or run a special kind of test.
12. I will not carelessly waste your time. Or if I do, I will learn from that mistake.

(These commitments are borrowed from James Bach, source: http://www.satisfice.com/blog/archives/652 )

Why Gino

Hi, friend!

First things first. It would be a nonsense naming this site ‘call me Gino’ without an explanation. I’ll keep it as short as possible, what coming from me doesn’t mean short at all. Here we go!

My real name is Luis Galotti Muñoz. Well, not my real name, but the one my ID shows. My parents wanted to name me Gino after my grandfather, but the judge complained saying that ‘Gino is not a name’. which is kinda true being honest. Gino is the diminutive of Luigi (Luigi – Luigino – Gino), so my father decided to name Luigi instead, but the judge kept denying him: ‘Luis is the Spanish translation of Luigi, so you have to name him Luis’. He freaked out but, after unsatisfactorily trying to make her seen sense, just gave up and named me Luis.

So, well, Luis is my ID name, but I don’t feel it like my real name. Anyone who knows enough of me to be considered part of my life is aware of the story and calls me Gino. So, if I’m going to share what is inside my head with you, it sounds fair to me making the proper presentations.

Nice to meet you, friend. And please, just call me Gino.