Fabio Pereira

Best parts from PAYOFF - Dan Ariely's new TED Book

Sun, 20 Nov 2016 00:00:00 +1100

I just finished Dan Ariely's new book PAYOFF and, as some of you might know, I love listening to book on Audible.

How to Customize Every Time Zone

Wed, 29 Jun 2016 00:00:00 +1000

I have had to work with people in 3 different countries, 5 cities and various timezones.

Young Leaders in Recife and US Assistant Secretary of State

Sun, 04 Aug 2013 06:36:30 +1000

On the 16th of July I was privileged to participate in a roundtable discussion as part of the group of Young Leaders in Recife with members of the consulate of the United States in Brazil and the US Assistant Secretary of State for Western Hemisphere Affairs, Roberta S. Jacobson, who came to visit Brazil. The objective of the round table was to give Roberta our view of the current scenario in the northeast of Brazil, since it was the first time she was visiting Recife.

Before the roundtable a member of the project Oi Kabum presented some posters that they had worked on to raise awareness racism as a huge issue we have to work on.
We all expressed our opinions and heard Roberta’s during the roundtable. The topics of the discussion were mainly about Brazil: education, including English as a second language, protests, corruption and the mindset shift that has happened recently in Brazil in regards of complacency with government issues. It was very interesting to hear everyone’s opinion about the topics.

Members of the Consulate:

Roberta S. Jacobson - US Assistant Secretary of State for Western Hemisphere Affairs
Todd Chapman - vice ambassador from US in Brazil
Heidi Arola - consul from US in Brazil
Brian Bedsworth - vice consul from US in Brazil

Young Leaders:

Guilherme Cavalcanti - CEO at CESAR-PAR
Renata Accioly – AMCHAM - Products and Services - Recife
Gilse Arruda – UFPE Student / Works at the consulate in Recife
Fabio Pereira – entrepreneur and IT Lead Consultant at ThoughtWorks Sydney/Recife

Follow Up on Retrospective Actions

Fri, 22 Feb 2013 10:56:58 +1100

One of the biggest complaints I see on retrospective is that action items are not followed up.

I'm quite happy to see that on my current project people take it very seriously. There's actually a wall with the retro items to be followed up (To Be Done TBD) and when they're done we move them to the \o/ happy/done column. During the following retro we go through them. Another important thing is to assign owners to these items! yay for the team!!!

Foto: Henrique Rezende

RSS Recife Summer School

Wed, 13 Feb 2013 18:57:42 +1100

Last week I gave a talk at Recife Summer School

I spoke about how to treat JavascrRipt as a 1st Class Language. More about it and the slides can be found here.

@gfcmotta registered the event.

Introducing Depth of Test (DOT)

Sun, 18 Mar 2012 17:57:22 +1100

For the last couple of years I have been particularly passionate and vocal on my projects and in the community about the importance of writing tests as close as possible to where the code is written. As a result I have been achieving easier and cheaper to maintain testing pyramids as opposed to expensive and brittle ice-cream cones. My passion stems from all the times that I saw, and wrote myself, test suites which attempted to achieve most of the high level scenario coverage through the user interface. I was one of the passionate advocates of this technique during a ThoughtWorks Technology Radar session where we collected new ideas. Now I am quite satisfied to see that the technique has recently been added to the adopt section of the latest radar.

Testing at the appropriate level

"The advent of BDD, testing frameworks like Cucumber, combined with browser automation tools like Selenium, has encouraged widespread use of acceptance testing at the browser level. This unfortunately encouraged doing the bulk of testing where the cost to run the tests is the greatest. Instead, we should test at the appropriate level, as close to the code as possible, so that tests can be run with maximum efficiency. Browser-level tests should be the icing on the cake, supported by acceptance and unit tests executed at appropriate layers"

thoughtworks.com/radar

Shallow Depth of Test

I believe that neologistic metaphors, like Ward Cunningham's Technical Debt, are extremely effective to explain concepts like this. I will explain a real world example and eventually I'll get to my neologism: Shallow Depth of Tests.

Let's say, hypothetically, as if I had never worked on one of these, that we have to implement a quote web application that has several business rule validations and if the details provided are valid, it gives the user a price. From the user's perspective, the app is pretty much like this:

Let's keep in mind that we want to avoid testing this system as a black box, so let's break it down and understand what's inside. The system's architecture is explained in more detailed in the image below:

Javascript layer communicating to server side using JSON services
Controller and mandatory validator
Domain model, business rules and pricing calculator
Data storage

The pricing calculator is a crucial component of this system. It has to be thoroughly tested in order to make sure that it provides the right price for several scenarios.If we decide to test pricing through the user interface, using a tool like WebDriver/Selenium, or any other tool that drives a browser the image below shows all the components that will be visited by these tests, I call these components on focus.

For pricing, there are several scenarios, maybe tens, sometimes hundreds of different combinations of factors that might affect the amount to be paid. This means that we will be visiting those components many times when all we are testing is the pricing calculator. In other words, everything will be on focus, when all we want to be focused is the pricing calculator component.

Here is when I start my neologistic metaphor… In optics, particularly in film and photography, there is the concept of depth of field:

"Depth of Field (DOF) is the distance between the nearest and farthest objects in a scene that appear acceptably sharp in an image."

wikipedia

Therefore, adapting this definition to software testing:

"Depth of Test (DOT) is the distance between the nearest and farthest software components that get visited during the execution of a test."

It is important to point out that the definition mentions a "software component", which is not necessarily one "class" (OOP), or one "function" (FP). Components are logical entities that performs a small feature of the system. It could be an entire pricing calculator, a business rule validator or a simple string concatenation function. Each system will have its own components with various sizes.

Having defined that, if we want to test the pricing calculator mentioned above, we should keep it on focus and test it at a different level, not through the user interface, in this case a browser. If we do that, we will end up having a Shallow Depth of Test.

What I have learned and observed is that the more shallow the depth of tests, the cheaper is it to maintain and also the faster it is to execute them.

Testing Pyramid - A Case Study

Mon, 05 Mar 2012 23:28:18 +1100

One common issue reported by many teams and that I have also experienced many times is the inverted testing pyramid.

A year ago I joined a project that was going in that direction. I could see us making the same mistakes again. If we had kept going we would have ended up with the slow and hard to maintain, melting ice-cream cone. However, this time we tried a different approach. Our test strategy was heavily based on the concept of Shallow Depth of Tests, which means testing the code as close as possible to where it is written using preferably either unit or integration tests. We only automated high level test journeys at the UI level.

Now, one year later, we have a stable and fast build, which gives us an extremely high level of confidence.

Here is our project's testing pyramid, of which we are very proud:

Some observations:

Only 12 tests through the UI take 13 minutes to run
1748 unit tests take only 1 minute
273 JavaScript unit tests take less than 1 second. Treating JS as a 1st class language helped us as well

Feel free to share your testing pyramid as well. And always keep an eye on it… It can make a big difference to your project.

Speaking at QCon Beijing

Sun, 05 Feb 2012 03:09:38 +1100

I'm very happy to be a guest speaker at QCon Beijing in April 2012.

I submitted the 2 abstracts below. We haven't agreed completely on the schedule, but it seems like one of them will be a half-day tutorial (Shallow Depth of Tests) and the other one a talk (Predictably and Irrationally Agile).

Shallow Depth of Tests - Scalable TDD/BDD

Test automation is prevalent in the software development community. Practices like TDD and BDD are widespread and applied almost unquestionably. However, several organisations have struggled in attempting to scale automated test suites, which very often become slow, brittle, non-deterministic, unreliable and difficult to maintain.
In this talk, I will discuss some common mistakes, Tautological TDD (TTDD), for example, and also present patterns that I have successfully applied, such as Shallow Depth of Tests and Testing Pyramid. These have enabled us to achieve maintainable and scalable tests that fulfill their purpose - to help software development teams deliver faster and more confidently the features required by business people.

Predictably and Irrationally Agile

People behavior is one of the centerpieces of Agile software development. Cognitive Psychology and Behavioral Economics have helped us achieve a better understanding of some human seemingly idiosyncratic behaviors, for example, the decoy effect on the decision-making process. Agile teams are constantly making decisions, for instance, while prioritising, estimating stories or choosing the size of an iteration.
This talk will compare and correlate Dan Ariely's controlled experiments described in his book "Predictably Irrational" to Agile. The anticipated result should be an increased awareness of the reasoning behind some Agile values, principles and practices which, as a consequence, should improve the way we apply them as agile adopters and practitioners.

JavaScript as a First Class Language

Thu, 08 Dec 2011 03:44:53 +1100

A couple of weeks ago I presented at the internal ThoughtWorks conference called XConf about how we have been treating JavaScript as a First Class Language recently on our current project. What it means to us is:

Modularise JS code (JAWR helps)
Unit test it. (we use Jasmine and JSTestDriver)
Static analysis, “checkstyle for JS”. (we use JSHint)
JS Dependency Injection to facilitate testing

Here are the slides with more info and some code samples.

JavaScript as a First Class Language

My Echidna photo was selected

Tue, 08 Nov 2011 02:40:12 +1100

I was quite happy that my photo was selected by schmap.com to represent Melbourne Zoo.

I’ve been working a lot on my photography skills… Who knows… One day I could be famous