Connect to a remote Xvfb server using VNC and a SSH tunnel

Xvfb is an in-memory display server commonly used to execute programs that require a UI in a server which does not have a screen output. Using Xvfb is very convenient when your automated tests are executed in a remote server and orchestrated by a Continuous Integration system.

While having a VNC server running in production instances is not always a great idea due to the potential security flaws, opening port 5900 on this server to allow external connections sounds even worse. This post will guide you through the steps required to access a remote VNC server via an SSH tunnel, without opening any additional ports.

Assuming that Xvfb is already running in your server and the display has been exported to :99, the next step is to install x11vnc:

sudo yum install -y x11vnc

IMPORTANT: Connections to remote x11vnc servers are not password protected by default which leaves your server accessible to potential attackers. Make sure x11vcn is always started with the argument ‘-rfbauth ‘.

We will now establish the tunnel to access the x11vnc server through SSH. This needs to be done in your workstation:

ssh -i [SSH key] -l [username] -L 5900:localhost:5900 [server hostname] ‘x11vnc -display :99 -localhost -rfbauth [VNC server password file]’

You are now ready to access your remote server screen by using a VNC client in your workstation and connecting to localhost:5900

Test your testing skills with the Atlassian QA Challenge

Today I found the Atlassian QA Challenge in this post during my morning feeds review, and I was quite delighted about the challenge itself! The company behind JIRA and Confluence proposes a set of exercises to train your abilities around security testing.

On the first exercise you will have to break in through a login form and get yourself authenticated on the system. After completing the first exercise you will be eager to test your abilities on the the other challenges!

 

atlassian qa challenge

Bug Driven Development

When a project backlog is turned into a repository where the majority of items are bugs, I like to think that we are then working under the premises of a Bug Driven Development process. Once this starts to happen you basically have 3 choices:

  • Review your user stories, trace them back to the original business requirements and ensure you have enough information to develop the work products.
  • Think about what caused the mess and try to fix it.
  • Start using Bug Driven Development.

Ideally we would go for the first option in order to have a clear view on the scope for the current Sprint. This could work when a) time permits, b) the team realizes about the problem and c) your options to further enhance the requirements definition through additional elicitation and analysis are good.

The second option proves to be the most reasonable idea when it comes to retrospectives. But it might cause a significant deviation (in money, time or quality) after having spent a whole Sprint building tentative components that are potentially useless, or would need an important rework.

And the only option left is Bug Driven Development (bDD); not to be confused with Behaviour Driven Development. I’m not trying to convince anyone that using bDD is a good idea, since reaching this status means that not only several aspects of the analysis have gone wrong, but also that you are increasingly doing it wrong. You would use bDD to enrich your user stories from bugs encountered in the system being tested.

And this exposes a high risk: testers covering the gaps from proper requirements analysis. But it also proves the importance of having testers in your Agile teams. When I’m asked how does Agile approach change the traditional role of testers, my answer is: it does not! While Agile emphasizes the importance of involving testers in the definition of the user stories and acceptance criteria, it has always been a good practice to have the requirements reviewed by testers (and the rest of the team) to make sure these were accurate, testable, measurable and anything that define them as SMART. Same happens in other parts of the testing process. Test automation? Reporting? Exploratory testing? I feel most of these topics became popular during the last few years but things are not done differently in general.

So what about using Bug Driven Development? Let’s think about this scenario: third Sprint, the Product Owner has not been deeply involved in the process and non-business users are appointed to attend the demos and sign-off the incremental part that has been built, user stories are too high level, the business analyst was only involved during the initial Sprint and the rest of the team does not have a profound domain knowledge. It sounds bad, right? But I told you: if you are using Bug Driven Development, this is the result of many things done wrongly in the first place.

Let’s use the example of the diagram below and put in a timeline:

bug driven development

  1. We have a business requirement which comes from the Project Charter or the Business Requirements Document, which defines the construction of a new interface to manually upload reconciliation files through sFTP. This is just a small part of the final solution and is targeted to be built as an increment on the current Sprint.
  2. As part of the initial analysis, the BR is broken down into 2 different User Stories: one of them relates to the user authentication and the other one to the upload process.
  3. While conducting the initial test design, the tester founds a lack of detail on the expected file extension which ends up in the addition of another user story defining the scenarios where it could contain zipped files of plain CSVs.
  4. After running one of the test cases for the first time, the tester founds a defect and while this is investigated the team founds that a user could switch from the base directory and browse sensitive data. This raises a concern and ends up with the addition of another user story to define the directories restrictions.
  5. The tester keeps exploring the system under test and founds something else as User Story N.

Some of these “discoveries” could have ended up as an enriched acceptance criteria, but the risk here is that an insufficiently defined requirement ends up with a significant amount of expectations in detriment of a very basic definition of its value or adherence to the business from a user point of view.

Obviously the sooner the user stories are enriched and completed, the less we will be using Bug Driven Development and the happier our lives will be 🙂

World Quality Report 2013-2014

Some months ago I was offered the opportunity to participate in the Quality survey promoted by Cap Gemini, Sogeti and HP, and I found very interesting some of the contents in which it deepened. Few days ago I reviewed the results from the previous survey (2013-2014) and the they show a positive scenario for the world of testing. Below you can find the key findings as well as an interesting infographic.

  • QA functions are becoming structurally more mature – the number of organizations with a fully functional TCOE increased from 6% in 2012 to 19% in 2013
  • Organizations continue to increase the proportion of their IT budgets for Testing – from 18% in 2012 to 23% in 2013
  • QA teams are still engaged too late in the application development lifecycle, which contributes to the increase of testing’s share within IT budgets to manage operational and quality inefficiencies
  • Rise of Mobile Testing as a key discipline: 55% organizations now carry it out compared to 31% last year
  • Organizations face challenges in managing test environments and creating test data – 16% of testing projects are executed with data created ‘as we go’, up from 5% in 2012

wold quality report 2013-2014
The full report can be found here [link]

Agile Testing and the challenges for testers

Next February 27th  expo:QA  organizes a new casual afterwork among friends and professionals in Software Testing and QA, in the context of “Agile Testing and challenges for testers”.

Here you can find more details:

We invite you to a talk and snack with our guest Graham Moran, dedicated to the world of software quality and testing for 15 years.

Graham has worked for IBM and AIG between Ireland and Spain. He has a passion for software testing and in particular the training of the same. In recent years he has been working with agile methodologies and is certified as a teacher of ‘ Certified Agile Tester’.

Should testers have a different attitude to work in an agile environment?

This talk describes what the ‘Agile Testing’ is and explores not only the daily challenges that testers face, but the changes in attitude that they adopt.

Graham will conduct a funny Quizz, with some more surprises …

  • Date: 27/02/2014
  • Hour: 19:00 to 21:00.
  • Price: free
  • More information and registration here.

(Español) Análisis y gestión de requisitos

Acabo de ver en el Blog del Centro de Innovación en Productividad de Microsoft este vídeo muy gracioso y real sobre análisis y gestión de requisitos.

Una situación bastante cómica pero a la vez muy real. No siempre es trivial alinear las expectativas sobre como debe comportarse un sistema.

Its defect speaking

Pere Felices just sent me a very funny text about a (software) defect’s life, which I’m sharing here so you can also enjoy it:

I am defect. For some people I am a mild inconvenience and for some I am their worst nightmare, probably a life threatening nightmare. For many years, people like you have treated me as a hunting target and treated me as a non-living entity – without any emotion, say or dreams. Till now, I kept my silence but now I had it enough. TestingGeek has allowed me to tell my story to the world, to tell you truth about me and my feelings.

You call me so many names (And all of them are bad BTW), but do you know anything at all about me? Do you know where I lived before you forced me to live in your code – to be found, discussed, killed, ignored and humiliated?  People tell me so many things, but do you realize reasons for my existent? I know I am not desired, I know I am not welcomed and to be honest, I do not want to come anywhere near your (sometime dirty) code, requirements etc. But you force me to live in your requirements, code, network and so many unimaginable places because of your misunderstandings, lack of knowledge or plain sloppiness some time.

You do not realize, but I pay a great price for your sloppiness and your lack of understanding. I take blame for lost life, money and happiness for many users. Plane is crashed because there was a defect; transaction was not complete because there was a bug and so on. Why don’t you pause, think and say plane was crashed because someone did not do their job properly. I am there not because I love staying in your code, but because someone took short cut, invited me there to be found by someone else. I was invited, ignored and now I am blamed. Where is justice? Unfortunately defects cannot trial humans in their court, but I hope our fate will change.

My life is extremely comfortable till you guys put me in the code. After that, it’s all misery and my life becomes extremely miserable. From that moment onwards, I live my life in anticipation of to be found, broken in pieces, discussed and humiliation. I do not like being here and so always gives you hint of my presence. Sometime, I have power to give strong hints and it becomes impossible for you to ignore me. But sometime, you just do not recognize my hints, you over look what I say in log files, you don’t notice when I create slight flicker or make your system slow. You attribute things like these to something else and leave me there to rot, to get worsen. That doesn’t leave me any option but to gather strength and try harder. Most of the time I succeed and you notice me. Unfortunately I cannot understand your situation so some time by the time you notice me, I might have crashed a plane or ruined millions. So please, practice, observe and understand my hints. I will be very happy if you find me and kill me in such a way that I do not have to come again, but alas it doesn’t happen.

Most of the time, instead of killing me you just change my dress and location. Sometime, you even break me in to pieces and scatter me in your code base. Unfortunately, we do not follow the law of physics so some time when you break me in pieces, every piece could be bigger than the original itself. Even in pieces we communicate with each other, we affect each other and because of this you get confused. Rather than finding all the pieces, you take one piece and kill it or unfortunately break it in even more pieces…and cycle continues.

Buried in your millions of line of code, I wait patiently for my angles called testers who have skills and mandate to discover me. Given the right environment these angles could find most of us. But look, what have you done to my angles? You have converted them from angel to robot so rather than finding me, they are following some steps. If I am lucky, they will find me otherwise my angles will pass by me and ignore me, because someone has given them steps to follow rather than mandate to find me. Will I not feel angry about it? How would you feel if you struggle to survive in a sea and rescue boat follow the route given to them and ignores your plea? Well, that’s how I feel.

Sometime my angels create robot themselves and call it test automation. This can be extremely useful, but only if mandate for them is to find me rather than creating more robots. Unfortunately, for many people mandate is limited to the creation of these robots and they are worse for me. Well, it’s like missing rescue boat in periodic manner, after every check-in, after every few hours or on nightly basis.

I am not selfish and understand that sometime you just can’t kill me, but believe me I will be very happy if you can find me, discuss me meaningfully and take conscious decision to keep me in the code. Because, if you do that I’ll understand that I’ll never ever kill someone because of my presence, I’ll know that I will not ruin your millions. So as long as you have assessed risk associated with me staying in your code, I can live there happily. I just do not want to live there with feeling that I am not wanted here and I can possibly hurt someone.

Please, I do not want to stay in your code or system. I am extremely happy outside, don’t invite me inside. I know some of us are a bit naughty and will come without invitation. For those naughty defects, give our angels mandate to find them in best possible way rather than following steps or creating just robots. I am good at heart and do not want to hurt anyone, so please find me and get me out of your code base.

Remember, I am a defect buried in your code and waiting for you. Please be aware of my presence and keep your eyes open for me.

Waiting to be found – A defect.

Fuente: Testinggeek.com

ISTQB Advanced (Test Manager) – Mind Map

ISTQB Mind Map

Few weeks ago I was preparing the exam for the ISTQB Advanced Level (Test Manager) certification. This is an oficial certification that proves the candidate skills on several disciplines:

  • Software Testing Basics.
  • Testing Process.
  • Test Management.
  • Reviews.
  • Defect and Incident Management.
  • Standards and Test Improvement Process.
  • Test Tools and Automation.
  • Team Composition.

To prepare myself for the certification I prepared a mind map that includes all the basic concepts from the syllabous. You can download it here:

ISTQB Advanced Level – Test Manager (FreeMind format)

ISTQB Advanced Level – Test Manager (Xmind format)

Let me know if you are interested in a different format.