Tag Archives: framework

Learning Agile – Post #1


Starting from today I am planing to learn Agile while questioning its utility against my last 3 years of experience.

What Agile looks like for most of us?

agile[ ATTRIBUTE: Please check: http://www.flickr.com/photos/78832226@N00/2119855534 to find out how to attribute this image ]

This image is a good description i’d say. I can’t really point why but usually it has something to do with stickers and a whiteboard. I would guess that this is the non IT version and that IT does not have to follow it. It does not make sense to track a piece of work in 2 places.

A story starts with a quick background to set up the scene

“In February 2001 seventeen software developers met at a ski resort in Snowbird, Utah to do some skiing while spending time reflecting on what defined the core principles of agile software development methods.”

2001. Now we are in 2014. Maybe we can improve a bit. The customers have improved a lot. The technology has changed drastically. Here is a random post with multiple images I have found over the internet.

In the same phrase, right after, we are presented the owners of the idea. The software developers. Now, I did a bit of development and I must admit that while doing it I am not quite focused on either customer or business satisfaction. I want the things done is such a way that I can be proud of them while respecting a deadline.

So far, my conclusion is that there might be room for improvement.

Let’s go to the core concepts

This should help me scratch the surface a bit.

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”


“Individuals and interactions over processes and tools”

I do not agree entirely, here is why:

1 developer (Dev) costs ~50-250 Euros per hour. 1 product owner (PO) 100-150 Euros per hour. I think this is the minimum “team” necessary for the team word to exist and for agile to happen. Anything less than this and it is called singularity.

A developer starts working (actually writing new code) in at least 30 minutes based on complexity. He needs to find the focus, understand the previous code, create a local branch, read a row of specification.

If during the peak of his working speed the PO talks to him he needs to stop and the conversation is longer than ~2 minute or if it requires focus, the dev will forget what he was doing. This means that we throw away at last ~15 minutes to get back in the zone. If the PO comes with a requirement change we throw away most of the work previously done. On top of that we re-introduce the initial >30 minutes overhead.

Mathematical conclusion:

  1. Interruption with design change – 150-400 Euros per hour based on how much work was done or can be reused
  2. Interruption without design change – 12.5-62.5 Euros per hour

A designer on the other hand, code (software architect) or visual (user experience designer or user interface designer), is a person made to have it’s cost shared with the whole team. On top of that can deliver the answer to the PO faster because the creation time it is much much smaller. Also, while the design is happening dev actually continues with his peak and pushes towards delivering a bit of functionality.

Now comes the more interesting part:

The quote from History: The Agile Manifesto by Jim Highsmith states:

“The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.”

My question would be. Why not delivering a proper sentence to begin with? Something like “Individuals and interactions in an optimized methodology”.

Because it wouldn’t sell just as well. In order to embrace something the business people have to see a big gain. The IT society is teaching us that in order to make money we must sell, because yes, money must come to us… LOL. We, as technical people, we suck at selling most of the time. The easiest way is to present something with less substance in order to look simpler.

How much process is enough?

Let’s say that the best practices do not exist because in order for them to be best they must apply to a scope. The scope can’t be the same in a 100 employees company, in a 5 employees startup and in a 15 employees scale up business.

My definitions of how much would be:

For documentation – “Enough to train any missing resource in the shortest acceptable time frame”.
It is normal for the people to come and go. The business must be ready to absorb the impact if the most senior resource leaves. The irreplaceable tend to become expensive after a while in multiple metrics (money, emotions, boredom etc).

For specifications – “Enough to avoid lost of focus or interruption”.
This goes hand in hand with the estimation presented above. It is more a matter of discipline. Look at the race between the turtle and the rabbit.

For deliverable – “The smallest piece of functionality that can be delivered to the customer which covers the smallest expectation of the stake holder”.
A developer has to develop. A PO has to figure this out with the stake holder. The QA has to look at the feature from the eyes of the customer.

In each of the three, every team member can improve enough the quality of the product without long working hours or stress.

How do we earn more money?

By have enough amount of resources with the enough seniority level. An individual chooses a position because he wants to. Not because he lost on a roll of dice. Let’s look again on how much we can save by not wasting.

Here is an example:

I am doing a work. My work has some results. When results are visible to :

  1. the team -> my hourly rate/team members that need it.
  2. a team member -> my hourly rage/1.
  3. the final customer -> this is investment, not expense

My conclusion related to “Individuals and interactions over processes and tools” in Agile

The conclusion of the first phrase would be that in order to increase the revenue we must make sure that:

  1. what we discuss is available in the same place to everyone that might need that piece of information when they need it.

The result is:

  1. we don’t interrupt ourselves
  2. we can set a goal instead of a deadline


Next topic “Working software over comprehensive documentation” tomorrow.

Have fun.

Why having versioned documentation


very often we have our project’s piece of code under a versioning system. This has proven to be of real help. It helps the developer to observe the changes, remember the reason behind them and code just for the differences.

The documentation should obey the same rules.

“My taller friend” pointed out that the documentation is split, by functionality, in at least two categories. One would be to describe the characteristics of an entity or process. The second to describe a list of checks to be made in order to validate an entity.

By combining those two we look at the ideal documentation as follows. A dynamical part, with unchecked checks that is included automatically after each clone of the previous version. A static part that is being altered from one version to another.


Real life simplified example:

We have a a folder that can contain an infinite depth of folders and an infinite number of files.

We work hard enough to create a good enough script that validates that each folder has the require image and name based on the documentation provided by the stakeholder.

We copy our folder onto a new location and add a few folders and files.
Now we have two ways of writing some documentation in order to help the automation:

We work hard enough, again, to parametrize the initial script based on the re-written documentation.
We copy the first script and just alter the changes.


The versioned documentation allows the team to adapt faster without over-thinking the technical solution.

I would like to read your opinions,

To Scrum or not to SCRUM – this is the question


one of the most used words today is “scrum”. All caps or not, it does not really matter. The baseline is that it is not an acronym.

Now, after working in this framework for a while, with various better or worse implementations I came to the conclusion that up to a point it is better to have the QA in charge of the “Scrum master” role. Here’s why:

  • In the early stages of the process, QA usually writes the acceptance criteria which get signed by the client
  • During the development QA must ease the communication between the developers and the product owner

Why the first?

Because they are the ones that later on in the process must verify that the deliverable covers all the expectations. Else the clients would get an image as a website while the team will strongly state that it looks exactly the same. This doesn’t mean that it functions, or if it does that it functions well.

Why the second? Why can’t a developer handle the task?

The QA person is the one handling the status of the tickets once they are considered complete and in testing. The developer must dig for this information while the QA can’t avoid it. So, the dev can but it is extra work.

Why not have the Product Owner in charge of it?

1) If the client is “many” and “decision-challenged”. The product owner brings way more to the project by just listening to the client and filtering the information for the team. This filters most of the noise. To his extent comes the QA that delivers his the required client-facing information.

2) If the client is “one” and “decision-challenged”. the product owner should filter the incoming information and extract the client-facing information by its own. In this case I do not consider that the QA should handle the “Scrum master” role. However in a team of 2 complementary senior QA resources, the more soft-skills oriented one can cover this role as well. He/she already have visibility regarding the team’s workload and there shouldn’t be 6 hours of decisions every day.

3) If the client is “one” and the decisions don’t change. This is quite ideal. Once the acceptance criteria are agreed upon there is no need of a product owner all-together. The team should be productivity driven with the final goal always visible.

Personal opinion:

Since the scrum is founded on the premises of a holistic approach (treat the team as a whole, not as individuals) and the client is the input and output, the QA should be the filling and the Product Owner should be the shield around it.

Please disagree and let’s have a chat.


Behat – External selectors file – Definition of useless or genius


Before we start, thank you Mario for listening to my idea and coming up with a better one :).

Last night I have finished implementing a feature into Behat on which I have mixed feelings about. It allows the team to store the selectors in an external file. Now, this sounded great at first and I did not vouch against. Mostly I was curios how it can be done.

I am saying it is a bad idea because sending parameters to the FeatureContext constructor can be done through several different ways:

  • – an array of parameters via the behat.yml that can be extended through import to include a different file
  • – a multi-dimensional array via the Scenario Outline and the Examples table
  • – a normal file include in FeatureContext

However, none of those actually inserts the values into the scenarios at runtime, replacing the keywords. This is when I get to say that it is genius.

But again, this should not be used in the first place. The whole purpose of BDD (in this context) is to be a tool that provides documentation for the stakeholders replacing a tests managements tool. Else we should not have used Gerkin to begin with. But what if the the target is the QA person, if so it makes sense. However, we are testing a framework built on top of Magento that we implement for the clients. Now it gets back to be a bad idea. The clients will not understand jack from our tests. On the other hand, since we share some of the code base but we implement custom functionalities on top of it, we want to maintain or selectors and values in a decoupled spot and not work on the code all the time. But the .feature files are quite decoupled as they are. Uhmm… reasons reasons.

I will let you reader to meditate upon using it or not and if you do use the code, please drop a comment why. Thank you in advance unknown friend.

We will start with a top down overview of the implementation. The xxxx.feature file looks like this:

  Scenario Outline: Invalid user login
    Given I am on homepage
    And I follow "Log In"
    And I fill in "email" with "<__email__>"
    And I fill in "pass" with "<__password__>"
    And I press "<__button__>"
    Then I should see "<__messageBody__>"

    |  |
    |  |

The current implementation needs to have the empty table at the end in order for Behat to generate an array at runtime. Probably this can be fixed in the code. The <> are regular placeholders. They are substitute with the values from the Examples table at runtime. The “__” (double underscore) are used in order to ensure some kind of differentiation between our keys and the table already existing.

In FeatureContext.php I have created this method that will be loaded on the @BeforeFeature hook:

     * @BeforeFeature

    public static function prepare(\Behat\Behat\Event\FeatureEvent $event)
      $feature = $event->getFeature();
      $exampleLoader = new ExamplesLoader();

The class for this is a file called ExamplesLoader.php, located in the Bootstrap folder. This does not have to be loaded or anything because Behat automatically loads all the classes from that folder. Since the logic is in here I will post it based on functionality.

This will iterate through our scenarios and for each scenario will get the examples. In will return an array with the number of elements equal to the number of rows in the Examples table. In the current implementation it works with two.

foreach ($feature->getScenarios() as $scenario) {
            $examples = $scenario->getExamples();
// all the other pieces of code will go in here. Leave it blank.

This piece will glue together the current working directory ( getcwd() and the name of the file where the selectors/locators exist ). They will be glued by the DIRECTORY_SEPARATOR so it works on every operating system. Please note that the working directory is where behat.yml is located, not where the current file exists. This string will exist in the “$filePath” variable.
The “$holder” will contain a bi-dimensional read from the “tsv” file just read. If you want to read a file with a different separator please read the PHP documentation for fgetcsv(). The second argument is the separator. Also, if the examples table is longer an iteration inside the $holder[$row] is required because we want to have data for all the rows, not just two.

$filePath = join(DIRECTORY_SEPARATOR, array(getcwd(), 'locatorsFile.tsv'));
$holder = array();
if (($handle = fopen($filePath, "r")) !== FALSE) {
    while (($data = fgetcsv($handle, 1000, "\t")) !== FALSE) {
        //if you are thinking that it would be better to iterate over many elements,
        //don't later you will use only key:value

The $rows is a variable created by Behat which stores all the values of the Examples table. Each element of this array is an array of what is inside between 2x| (pipe) on that specific row in examples. Basically here is where we want to add our keys and values. Because after we are inserting them, the framework will handle all the logic that there is to come. The setRows($rows) is a method that locks in place this table for tests creation.

// Add our global examples
foreach($holder as $value){
    $rows[0][] = $value[0];
    $rows[1][] = $value[1];
//and we send the data to the examples table

Now our table will include all the data from locatorsFile.tsv. Here’s how that file looks like on the inside:

__button__  Send
__messageBody__ Invalid login or password.
__email__   asdkjasdj@askdjaskjd.com
__password__    asdadasd

Have a nice day,
Bye bye!

Testing framework – EP 2 – What types of automation are there


now that we have identified the fact that automation is required let’s have a look at the approaches already available.

  1. Code driven testing
  2. Graphical interface testing (GUI)

The code driven testing involves testing the classes, modules and/or libraries.
The graphical interface testing involves the emulation of keyboard and mouse actions. The output is visible on the screen.

How to chose between one and the other?

This question arises because the GUI projects are composed of code but not all the applications have a GUI.

If the project’s code exposure through visual feedback for both the configuration data (Admin) , manipulation feedback (Frontend) and it’s scope is to facilitate the actions of the visitors, the GUI only approach is enough.

If the configuration data is updated through a file (.tsv/.csv etc), some code driven testing is necessary for the input scenarios.

If all the project is an API, for instance, or its scope is to connect two systems, code driven testing is sufficient.

Based on this article we know for sure which way we should head with our automation process.

Testing framework – EP 1 – Why have automation


the purpose of this series is to come up with a definition of what a “testing framework” is based on today’s needs and standards. The project in scope is a big custom Magento implementation.

The release methodology is Agile, the project is split in two teams. One team handles the issues and the client’s needs. The other the new functionalities. The release cycle lasts about 2 weeks. Rarely more, rarely less. If special events occur there are hotfixes in between. Generally they are avoided by both the team and the client.

The QA (Quality Assurance)’s role is to inspect the requirements and provide feedback, write acceptance criteria, write test cases, conduct UAT (User Acceptance Testing), performance testing, report issues and maintain a healthy build. All this, if possible, should be done by yesterday’s evening.

So far so good, pretty much a standard situation in most of the teams that feel the need for automation.

The challenge is to deliver the same amount of work as before in a shorter period of time in order to accommodate the new features if possible without cutting corners.

  • One solution would be to get more QA resources, but this does not fix or improve the process, this just enables a wider bandwidth at the expense of money.
  • Another solution would be to increase a bit the release time or lower the number of tickets. This has some monetary impact on the client and unless the quality is a problem it is very less likely to be accepted.
  • A third option is to implement an automation framework which absorbs some of the tasks allowing the tester and the team to focus on delivering.



The automation framework is the extra kick needed by the team, as soon as possible, in order to deliver better quality in the same amount of time for a long period of time with marginal cost increase while providing adequate documentation.