Skip to content

P vs NP not well defined!

P vs NP depends on the assumption that the Turing machine truly represents the way humans solve problems.

What if this is not true?

What if there is construction in the Turing Machine that doesn’t account for the way humans solve problems.

The fact is P vs NP is not solved, and yet we keep solving hard problems.

My suggestion is to start over and analyse what is behind every row in the original paper of Alan Turing:



The missing testing principle

 software developer

What is so magical about the number SEVEN? Carlos Varela, the mystical trovador from Cuba, has an enumerative song about the subject … and it seems that everything circles around this symbol.

ISTQB, the International Software Testing Qualifications Board, has establishes seven principles (a heritage of over 40 years) that candidate certified testers, must be aware of and K2-downt (understand). Those principles are:

1. Testing shows presence of defects … but it doesn’t show absence of theme.
2. Exhaustive testing is impossible. Well, not everything can be tested.
3. Early testing. Be there from the very beginning in the development cycle … if possible
4. Defect clustering. Defects stick together like brothers in arms
5. Pesticide paradox. Same test performed many times over, will lead eventually to no defects found … this happens all the time.
6. Testing is context dependent. A car is a car, an aircraft is an aircraft and a submarine is a submarine … they have to be tested differently
7. Absence-of-errors fallacy. No matter how much testing is performed and how sophisticated it is, the user is the one deciding if the product is worthy.

Do these seven principles sound logical and practical? I have been studying testing and quality assurance for quite some time now, including some practical experience. Besides I have been developing for quite many years, and I have to admit that I agree. I have also read and watched tons of material about testing and yet, there is a missing element: the human aspect.

Developers are behind every line of code, documentation or specification being written. What is written comes from a mental model, which in turn is agreed upon by the team and stakeholders. In this context the general user is never present in early development for obvious strategic reasons. This situation brings about a plethora of material to be processed, where mistakes in translation and interpretation are increasingly common.
So, having said that I would append a 8th principle to this list:
8. Defects ALWAYS come from the developers.

El que pasa


Dedicado a todos los viajeros invisibles … 

El caminante se pone las botas y aprieta los cordones fuertemente, sentado en una cama sencilla y silenciosa. Son botas sucias pero no desgarradas; botas del tiempo, de algún antepasado que las convirtió en herencia.

 Su cuerpo es delgado y fibroso. Sus ojos son abiertos como libros de cuentos y su barba, larga y gris como en aventuras de hobbits y héroes.

 Es bien temprano en la mañana. Un café breve y caliente espera en la pequeña mesa, allá abajo, en el perfecto abandono del restaurante del diminuto motel.

 Todo está listo para continuar el eterno peregrinaje. La gran mochila de cuero, el diario con montones de sucesos y brillantes ideas, una boina carmelita con incontables sellos, y dos cantimploras … una para calmar su propia sed … la otra es para que siempre quede para otros.

 Dice un corto y dulce adiós a la joven de la cantina, y ella devuelve una sonrisa de esperanza.

El caminante sale a la carretera de polvo y tras una mirada al horizonte, emprende viaje … una vez más.

 Nadie sabe su nombre, de dónde viene, a dónde va, pero todos sienten la inmensa tranquilidad, que este hombre de paso, deja en sus corazones.

The walker


Dedicated to all invisible travelers …

The walker puts the boots on and tightens  them up. He is sitting in a simple, quiet bed. The boots are dirty ones, yet not torn; timeless boots, that some ancestor passed on.

His body is thin and tenacious. His eyes are open as storybooks and his beard, long and gray as in adventures about hobbits and heroes.

It is very early in the morning. A brief and hot coffee is waiting on the small table down there, at the perfect abandonment of the tiny motel restaurant.

Everything is ready to continue the eternal pilgrimage. The large backpack leather, the diary with incredible events and brilliant ideas, a brown hat with countless stamps, and two water canteens … one to calm his own thirst … the other just for the sake of others.

He whispers a short and sweet goodbye to the young lady behind the desk, and she gives him back a look of hope. The walker hits the dusty road and after a glance at the horizon, he sets off … once again.

No one knows his name, where he comes from, where is he heading, but everyone feels an immense peace, this passing-by man leaves in their hearts.

The talking ball … a challenge for testers …

GRINZ BALL Collie 450

Never take anything for granted … nothing is what seems to be … yet, this is my own opinion … so, don’t take it for granted.

I have got the following idea for a product, to test my own progress in the study of test engineering:

The talking ball is a ball that sends a signal to a transceiver every time it bounces. The transceiver, as a result, plays a given sound. The transceiver is an app that can be fed with new sounds.

The sounds are related to the bouncing angle and how hard the ball hits the surface.

In order to reset the ball, a signal is sent to it, by using the transceiver.

Mission. Design a test plan for the talking ball, that helps develop the product all the way out to distribution.

Have fun and enjoy the process …

Bug reports … beyond the bugs …


MARCELLUS: Something is rotten in the state of Denmark.

HORATIO: Heaven will direct it.

MARCELLUS: Nay, let’s follow him.

Hamlet, by William Shakespeare


The dialog about, the powerful exchange of opinions between Marcellus and Horatio at the end of the scene 4 in Hamlet, resumes what testers should be doing right after we encounter a nasty bug. Say it clear and loud “Something is rotten …”, and now, not just describe it, but follow it very tight, nobody else will do it for you … not even Heaven.

I have been watching some youtube videos about bug reports, with the spirit of trying to find information other than that recommended in the study materials; and It has come to my attention that the subject of bug reporting is underrated and  misunderstood. It seems like everyone follows blindly the golden words of the Great Master: RIMGEA.

For those who doesn’t know what RIMGEA stands for, it is just a mnemonic that assists a tester to assure the quality of a bug report, namely: Replicate it, Isolate it, Maximise it, Generalise it, Externalise it … And, say it clearly and dispassionately.

We have to remember that testing is a tough job, exciting and badly paid. You would never make it just as a test engineer, you would need to do some other things on the side, meaning that you need to have extra skills if you want to hold your position in an organisation.

And what makes testing tough is not just the persistency of the hunting for bugs and the constant suspicion that something will go wrong; but also how you canalise and express the findings. It is not enough knowing that hmmm … something is wrong … we also need  to see what it is and then clearly report it.

RIMGEA is quite a good resource … for the lazy, and just a start point for the tougher. A software development process, where testing is highly regarded, works like a closed-loop control system, where a feedback is used in order to adjust the reference value.  A feedback is to a control system what a bug report is to software development; moreover, a reference value is to a control system what requirement specification is to the whole process of development.

The problem with this analogy to control systems is that these never keep statistics about performance; this is the reason why they are enhanced with, for instance, machine learning capabilities. The same capability is missing from the RIMGEA schema: a routine to search and analyse the bug tracking system.

Nay, let’s follow him. Managers, testers and developers that keep an eye on what is going on in the bug tracking system, would make sure the following happens:

For testers

  • It is indeed a source for testing ideas. Bugs around given functionalities bring about new areas and ideas for testing
  • It gives bug localisation. A bug in an area can be the cause of bugs close to this area. Just look at the statistics, numbers don’t lie.
  • It spots potential spec misunderstandings. Repeated bugs on some functions could be the consequence of overlooking the requirement specification

For developers

  • A well organised report with severities, priorities and status associated, puts developers into perspective concerning the status of the whole project
  • It helps to organise the job for the next sprint or the next week.
  • It somehow tells them “It is gonna be alright” … yet, this is a feeling and can not be explained.

For managers

  • It gives an overview of the advancement of the development
  • It gives an indicator for the quality of the process. A recurring bug on certain functionality would raise a flag
  • It is a source of decision making. A bug tracking system is in fact a database with events organised in time, following some classification; and this could be subjected to complex event analysis for which a plethora of tools exists out there. Here you have business and operational intelligence at their bests.

… and for everyone is a non-disruptive protocol of communication, where boundaries are established and respected.

If we now add BI visualisation techniques, then we can exploit the preemptive mechanism of our brain to discover patterns in large data sets, like those coming from bug reports. And use the finding to convey peace of mind across the team.

So  “Nay, let’s follow him”. Lets follow the pattern, not just a bug …. because something might be rotten in the process.

About me as a test engineer


I am concerned, really concerned. My name is Samuel Ferrer and I have a long career as software developer. I have been working as programmer and architect for more than 20 years, on a wide variety of technologies, ranging from industrial systems att ABB, to common things as point of sale software.

Some agent told me once that my CV is scary, because I have done so many things. Actually he told me that I should not write that much in my CV, because it looks faked … but is not! Some other agent asked me why I wanted to move away from  development and, instead decided to focus on testing. Unfortunately those are people whose tasks are to find jobs for me, but don’t have a clue about what software testing is.

Regarding IEEE

“Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item”

 Software testing stopped being a separated process from development itself many years ago (1987 Tandem systems). Today testing is embedded into the fabric of software development, yet embracing a completely different skill set, although “a test developer must have the same technical expertise as would be required of an equivalent product developer” [Mary Alexander, Keith Stobie, 1988]. 
 A capable test developer is a developer with many years of experiencing both failure and success, and has the ability to learn fast and efficiently any product under any circumstance, under pressure. A test developer, at least, is responsible for the quality of the development process as well as the product developed. What consumers see on the market is not the end effect of a developer, but of an effective or very incompetent test engineer. 
When I engaged in the study of test engineering, I had my doubts about the role as a tester. I thought of it as a person looking eagerly for bugs and then making nasty remarks in the reports, keeping the development team on its guard. As a result bugs were carefully hidden and potential problems were never warned by the members of the team. This was the picture I had of a tester or QA personell as it is called … until now.
In fact, testing is an art (I would say a fine art) rather than a academically defined science, and a tester is a computer scientist with wide knowledge about many things (psychology among them), an open minded person who is considered enough to appreciate the dark reality of a software developer: nobody gives a damn about their late nights and bad dreams, but only about their unfortunate mistakes.
 So, next time CVs of old experienced developers end up in your inbox and you disregard them, think again; you might be overlooking an important quality in testers: experienced and adventured developer who never gives up.