Tag Archives: testing

Object oriented documentation

Hello reader, welcome back, it’s been a while.

Today I have been thinking about the documentation topic. For me, it is a very hot topic.  In the deepest shity moments everyone is saying how good it would have been to have some documentation. Everything lasts until the problem at hand is “hot-fixed” (as this would ever exist).  As soon as the problem is patched and the project is printing money again the voices change to “buhaha, let’s reduce the development time, cut the costs, fuck the documentation”.

I do wonder, still, after a couple of years, how come, exactly the ones that have no skill nor knowledge in approaching the crysis reach this conclusion. You, the hopeless ones should be advocating for proper documentation because it is your CMA ticket in case of emergencies. It is the only proper piece of information you can rely on and share with a team member later in the night from whom you are expecting the problem to be solved.

There is also the management aspect. The business wants things that will be invented tomorrow done yesterday.

Maybe is the development team’s fault. We taught them to be this way. All they have to do is ask and stamp, we will fix it.

Maybe is the product owner’s fault.  With all this agile shenanigan we are not able to tie our shoes properly anymore.

Maybe, maybe, maybe… maybe is nobody’s fault. I’d go for this route. We are all equally guilty for not paying attention to everyone’s need in order to perform better. We all look at that stupid burn down chart and cherish like some teenagers when we go below the line.

I see a solution though. Many years ago, programming has evolved from procedural to object oriented in order to do more in the same amount of time.

I would say that this is a good solution for the documentation. All we need is a platform which allows us to include pieces of documentation from one page to another.

This is necessary because each piece of documentation for each feature is written only once and maintained only once.  I use the excerpt macro a lot at work and it is just the tool needed for the job.

Imagine that you write the documentation for the login feature with all the required tests. The same button is used on the pages 1,3,4,10. All you need to do is use excerpt and done. All the tests and relevant information follow the reader everywhere.

I don’t think I can explain you long enough why this macro or something similar is a must.

Now that we have the tool and the plan, next time I will propose the kind of information that should be written in the first steps of the documentation process. Don’t forget, everyone wants it fast. In order to deliver this we must be able to stop and start in the spare time without having to read again where we have left our train of thoughts.

A while ago I have read that developing happens when the developer writes something new. When the old piece of code has to be read and interpreted it is called maintenance. The world does not have time for that.

I hope this will help you make an idea how the documentation should be written.  In order to get a bigger picture on how this help you can read My friend is not insane.

More to this topic soon.

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,

Personal opinion – how to interview


A kick in the but, a step forward, new opportunity,  good luck, bad luck, call it as you like. In the end it is just an interview. It is only a defined period of time in which you have the opportunity to make a summary out of what you have learned. “No pressure ™”.

Now, what if you would be on the other side. One of the ones that listen and chose.

Exactly like in the dude from first paragraph, the dude from the second one has to use the skill set. Maybe on a deep thought it looks like the second would be in a more powerful position. My opinion is that they are both equal. I also think this is a correct mindset.

How to make that step? From person one to person two. What qualifies someone to be person two?

At this moment, with my QA profile, I only know three things. Listen, ask “how” and at the end ask “why”. Those three actions served me well for the last period.

Having the masterplan let’s proceed to picking up a methodology.

First we need to understand the acceptance criteria for this task. What it is required of us, what are the input parameters and what it is the desired outcome. This should allow us to crate a feature related scenario. So far so great. Next step.

Second we should identify our input. In a more programmatic approach we would call those optional parameters. If they are provided, use them for relevant outcome, if not they are supported by the feature anyway.  Here, the scope changes. The recruiter is the feature within a feature. This calls for abstraction.

Third comes the prioritization. Those inputs should be assigned some values in order to determine the best mathematical outcome.

The end.

In theory QA should be able to use their expertise in order to hire people.

Have fun,


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.