Last week, I went with my little cousins to see a performance of “The Little Prince”, by Antoine de Saint-Exupéry. Obviously, this play has nothing to do with testing, but the tester in me could resonate a lot with the play.

At the beginning of the play (and the book), when the little prince meets the pilot, the former asks the latter to draw him a sheep. The pilot is not a very good drawer, so he tries to do his best:


But the little prince says it looks very sick and asks the pilot to make another:


But this one has horns and looks like a ram, so the pilot tries it again:


And this one is rejected too, because it is too old. So the tired pilot draws a box with the sheep inside (at least that’s what he says):



And that is exactly the way the little prince wanted it.

At this point maybe you have thought the same thing I thought the moment I saw it: sometimes the client is not very sure of what he wants or, if he is, he doesn’t know how to express it or he is very cryptic about it (just like the little prince). This way it is very difficult to develop and test the right application. I am sure I am not the only one who has faced a situation where it’s not possible to finish testing an application because  a client is never happy with what  they  get or what they get is not even close to their expectation.

Therefore, it is important to perform a requirement analysis, that encompasses the tasks that determines the needs of the stakeholders for the new application. The testing team has to participate in this analysis, to help the client to define exactly what he or she wants and make sure that the developed product is the product the client asked for. To achieve this, some of the tasks of the testing team are:

  • Preparation and attendance to requirement gathering meetings, in the first phases of the project
  • Acquire the functional knowledge about the user needs in relation to the new application
  • Revise the document that contains the requirement, in order to indicate if it describes what the client wants
  • Register the requirements, which have to be validated by the client
  • Define the Acceptance Test Plan, which contains the tests to be executed to check that the built application meets the requirements established by the stakeholders.

To sum up, testing doesn’t start when the application is already built and ready to be tested. It starts at the beginning of the project, with the requirements definition; so that we are  sure about  what the client needs and also about developing the right application . This way we can draw the right picture of the sheep for the little prince from the start.

Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

Posted in: A testers viewpoint, Behaviour Driven Development, Business Intelligence, communication, Developers, Human Interaction Testing, integration tests, IT strategy, Managed Testing, Opinion, Software Development, Software testing, Technical Testing, Test Driven Development, Testing and innovation, Working in software testing      
Comments: 0
Tags: , , , , , , ,


Tester – The Private Detective Of Software Development

In my earlier� post, I have talked about the characteristics a good tester should have, such as being analytical and curious, being a good communicator, having the ability to put himself in the users’ shoes. But lately, I am starting to think that the most important characteristic that defines a tester is being inquisitive: investigate and ask perseveringly until he/ she gets the information he/ she needs to test the application and to know if it has the expected quality. Something like a cop or a private detective who searches for clues and interrogates the witnesses to find out who committed the crime, how and why.

More than once we have to test applications without having enough functional or technical documentation that explains us how they must work. How can we say if the application works as expected if we don’t know what we have to expect? How do we know what is the expected result when we sum 1 + 1 if no one has told us it must be 2? That’s the moment when we have to turn on our detective skills and start interrogating the witnesses, that is, the business analyst, the functional analyst and, sometimes, even the developer. Ask, ask and ask again until you find the solution or find achievements of the culprit:

– What formula is applied to calculate the cost of the product?
– What must be the answer of the application if a series of steps are followed?
– If an error happens, how does the application respond?
– What fields are mandatory to create a new register?
– What filters have to be established to do a search in a certain screen?
– What security profiles must the user have to accomplish a certain action?

However, in most cases, this is not enough. As Grissom said in CSI: “People lie, but evidence doesn’t. That’s why we have to look for fingerprints or DNA samples to find the killer. And which clues can help us to resolve the crime?” For example, we can search for old documents that make reference to the application under test, make queries in the database or access applications that interact with the one we are testing, among other options.

In short, to become better testers and to manage that the application under test has the greatest quality possible, we have to grab our magnifying glass, start thinking as a detective would do in the middle of a police investigation and to do everything we can to prevent that the crime remains unsolved.

Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

Posted in: Behaviour Driven Development, Business Intelligence, Developers, Digital strategy, functional testing      
Comments: 0
Tags: , , ,


people the key to success

As a tester, I have been involved in several software projects. Most of them have been successful, but I have also lived the other side of the story. Speaking from my own experience, I can say that there are different factors that can determine the success or the failure of a project:

  • Tools
  • Processes
  • Techniques and methodologies
  • Available technologies
  • Planning

Nevertheless, no matter how important those factors might be, the key that determines the success of a project is the team of people responsible for its fulfillment. In the end, software is made by people, not by machines. This seems pretty obvious, but we usually forget it and we keep on giving more importance to tools, processes and techniques. And what’s the point of having the most expensive and complete tool of the market and applying the newest technique if our team consists of unprepared people, who neither have team spirit nor motivation? How are we going to build high quality software if we don’t have a good team of developers and testers responsible for its design and its maintenance? Without this good team, our project has every chance of failing.

Unfortunately, at least in Spain, this is usual in a lot of companies. For them, professionals are just an accessory that contributes developing programs and they count on teams that don’t have the appropriate training, profile and qualifications required to fulfill their tasks, driven by the motto of minimizing the expense. That is, they look for the highest profitability, ignoring and despising quality. What turns out to be curious is that, when they fail, they don’t realize that the root of the problem is that they don’t have the right team and they keep on tripping over and over again on the same stone instead of changing the strategy.

So, if we want to have success in our projects, we must count on a team of professionals who have the required knowledge and who have the necessary experience. Besides, every person involved in the project must be completely committed with the group, must be clear about his role and his tasks and must work together to reach the common goal and, therefore, success.

Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

Posted in: architecture, Developers, DevOps, Digital, Digital strategy, High Tech, Human Interaction Testing, Infrastructure, Innovation, IT strategy, project management, Quality Assurance, Requirements, Research, Software Development, Test environment, Test Tools, Testing and innovation, Transformation, User Experience, User Interface      
Comments: 2
Tags: , , , , , , , ,


iStock_000074617193_Woman using phoneA few days ago I forgot my smartphone at home. When I realised it, I panicked. How I was going to survive through the day without my phone? How I was going to check Twitter and Facebook or play Candy Crush? What if I received a life-changing call and I could not answer it? What if my mother called me and thought that something bad had happened to me because ti went unanswered? What if all my contacts sent me messages through WhatsApp? At first, I was continually looking at the place where I usually have it in my desk, but as the day was passing, I completely forgot about it and I could survive the day without it.

This situation made me think how people are completely dependent on cell phones in particular and on technology in general. It is true that technology makes our lives easier, but it is also true that it makes us isolated from the rest of the world. Why are we going to meet our friends if we can talk to them using an application? Why are we going to buy clothes on a shop when we can do it in an online shop? Why are we going to the cinema hall when we can watch films through Internet movie platforms?

And the list is much, much longer. I’m sure you have seen lots of people in front of a beautiful landscape taking thousands of photographs instead of just enjoying it. Parents recording videos of their kids doing something for the first time, instead of just witnessing that awesome moment. A group of friends having dinner around a table using their phone, instead of talking to each other, people walking along the street typing as if life depends on it, not paying attention to what happens around them (with the risk it implies).

What concerns me more is how this technology abuse is going to affect our children. It is not unusual to see toddlers playing games or watching videos with their parent’s phones or tablets, using them better than an adult. And when teenagers have to prepare an essay for high school, they just go to Wikipedia and copy/paste it, without even reading what it says. Or what is even worst, teenagers pay more attention to social networks than to real people and they publish all their life there, making it available to anyone, who can use it against them.

With all this, I am not saying that technology is something bad (I have a job thanks to it J). What I am trying to convey is that sometimes we forget that technology is something that has to help us and not something we depend upon or something we get addicted to. That is what we need to keep in mind and that is what we have to teach our children.

So, now I encourage you to think how dependent you are on technology and to try to spend some time without using your phone, your tablet or your computer, just enjoying a real conversation, reading a hardcover book or going for a walk. I know it is difficult, but I can guarantee you it is really worth it.


Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

Posted in: Human Behaviour, Innovation, IT strategy, Research, Social Aspects, Social media, Technology Outlook, user stories      
Comments: 0
Tags: , , , , , , , ,


4961686-Vector-Comic-Character-Girl-Stock-Vector-sad-cartoon-girlWhat I learnt from Katie…

I read this book a couple of months ago about a poor girl, Katie, who always had had bad luck with guys: one boyfriend borrowed all her money and disappeared to Mexico, another one two-timed her and her last couple used her to paint his apartment. She was so devastated that she thought she would never find anyone nice and decided to give up. But her best friend tried to stop her and gave her this advice: go to have lunch to a different place, somewhere completely different and maybe you’ll meet someone there, someone who could become the one. And so she did. She did something different and met someone completely opposite to the losers she dated before. This way she could finally be happy.

Being honest, this book is not a masterpiece, but it made me remember one of the seven testing principles according to ISTQB: the pesticide paradox. This principle states that if the same tests are repeated over and over again, they will no longer find any new defects. That is, if we always use the same test cases, the software will become immune to them, all the bugs that those tests would find will be exposed and we won’t be able to uncover new bugs.

If you want a different result, dare to be different…

If we expect to have a different result and maintain the effectiveness and efficacy of our test cases, they need to be regularly revised and updated, and

we have to write new and different tests in order to exercise different parts of the application to find more defects. And sometimes it is also important to identify those test cases that have failed to detect any defect and remove them from our test plan, so that it doesn’t grow to infinity and beyond and we don’t waste time running those ineffective test cases.

Just as developers make the code better when correcting bugs, testers have to make the test cases better. This way, we could find those resistant bugs against which our initial test cases are ineffective and those subtler bugs that have been introduced to the system as a result of the correction of the former ones.

Additionally, it is important not to rely solely on structured and formal test techniques, but to perform exploratory testing, error guessing or another informal approach to increase the chances of capturing new bugs. The most variety of test techniques and methods the better.

To wrap things up, we as testers, should remember that if we do the usual thing, we get the usual result. So, we have to act like Katie and do something different to have a different result. If we do this, we can rely more on our test results and assure that we have find the greatest possible number of defects (since it is very difficult to find all of them).

Image 1


To read the original post and add comments, please visit the SogetiLabs blog: The Pesticide Paradox in Testing: If you want a different result, do something different!

Related Posts:

  1. Modelization of Automated Regression Testing, the ART of testing
  2. Shakedown Testing! … What’s that?!
  3. What the *BLEEP* do we know about Software Testing?
  4. Everybody tests with Agile

Paloma Rodriguez has been Test Engineer for Sogeti Group since 2011. In this role, she manages testing projects and participates in various publications and training activities.

Posted in: A testers viewpoint, Behaviour Driven Development, Developers, Digital strategy, Exploratory Testing, functional testing, Internet of Things, IT strategy, Managed Testing, Technical Testing, test data management, Test Driven Development, Test environment, Test Methodologies, Test Plans, Testing and innovation      
Comments: 0
Tags: , , , , , ,