Lynx under recovery

Hopefully you have noticed I have been away for a while now… that would mean you were following the posts and found them somehow interesting or helpful and I am grateful for that.

I have still many, many stories to tell and projects to explore with you…but sometimes a lynx gets too focused on hunting (projects at work, personal commitments, courses, last minute new year’s resolutions…) When this happens, little time is left to tell stories to other lynx, but, at the same time, many other potential stories are being born.

So the goal of this post is just to let you know that the test lynx is still out there and soon to publish some more stories.

However, there would be a slight change on the way the stories are told… as you know, I always hint about my next story on the previous one. This has been proven to be not quite sustainable… So, I will eventually tell the hinted story, but, I might tell an unrelated story next with the goal of speeding up the posting and not to block potential ‘out of the oven’ stories.

At the end of the day, even though I have a great passion on automation and testing, I can only stretch so much… I am only a lynx being.

Now that we know each other for some time, you might be interested in knowing more about my own story…but, that is, definitely, well…a different story.

 

 

 

 

Testing performance while testing UI: AKA = The “one time to rull them all” pattern

I know I have some pending stories for you, but I keep seeing something that I think is worthy to talk about. It is a very simple idea, but people usually don’t use it for some reason.

For the newbie lynx: Performance testing is a type of testing that we do in order to measure how well a website responds to the user input and load back an output. Sometime ago, users have to wait minutes for an image to load in their screens, there was no choice, nothing better available. Now a days, there is plenty of competition in services so one of the reasons someone can pick a service instead of another one is the speed of response. Everybody is busy after all, right? Better performance = better quality.

There are many tools available to measure performance and different parts of the application to measure it (server vs client). The developer tools in the different browsers provide ways of checking how long an object has taken to load.

Many companies have specific teams that are in charge of performance testing. I’m seeing this quite often, even if the developers are doing their own tests, someone else is in charge of the performance. However, it is usually forgotten that you can validate and debug some of the performance problems during your UI automation (or even in your unit tests).

I believe this to be a very good practice. As a testing principle, the earliest you catch the defect in the development process the cheaper it is to fix (in terms of resources and time used in regression). How can you do this?

Imagine you have the following code to test that an element exists in a website (this is only pseudo-code for the newbies to understand the concept):

wait(time)

element = findElement(X)

Now imagine that you are doing the same for another object:

wait(time2)

element2 = findeElement(Y)

Ok. If we keep doing this all over our code, we are going to end up with a lot of different times set up for each of the objects. On top of that, if there are problems with the connection or with the servers, we would have to modify one by one the waiting methods or set up really high times. Our code has suddenly become difficult to maintain and we have no idea of how well the application is generally performing.

How can we improve this in an easy way that could gives us an idea of the performance of the site? Very easy, we just use the same waiting time for all of the methods, which we set up in a constant. That way, if we have problems because of our test environments or anything on the likes, we can increase the waiting time for all the objects at once. We can also play around decreasing it so we get an idea of the minimum time a user is going to be waiting until all the objects are loaded in all the pages.

constant myTime = time

wait(myTime)

element=findElement(x)

….

wait(myTime)

element=findElement(Y)

We can also have a different one to load the pages or specific groups of elements (for example iframes), so we have different group of restrictions. Then it is just a matter of defining what is an acceptable time for a user to wait. This will ensure that at the firsts testing phases, all objects load faster than that time. After that, it would be good that you measure the performance of your server regularly and have some communication system if it goes bellow certain threshold. You can still have performance issues because of the server resources, threading issues or management of a high amount of users, but you will catch and easily identify some basic issues by just adding this constant across your code.

Disclaimer: I haven’t found this in any books or anywhere (yet, I am sure I am not the first one in thinking about this). The pattern name of the title is totally made up by me.

Note: usually performance tests run across systems/browsers/devices and so it is considered part of ‘system testing’. But that is…well… another story.

 

An unexpected story

This is not the story you were waiting for. I was supposed to continue talking about testing methods with basic examples. However, I need to tell a different story. I want to tell you the story of the “Test Bash”, my first test conference.

I heard that attending conferences could do good to you and your career. I thought if they exist, they would be specific and far away.

One day I read about the test bash. The content looked interesting and on my field, but I thought it was a lot of money to spend to attend, even thought it was happening in the uk and that is a short trip from Ireland, where I live.

I am contracting now, so everything needed to come from my own expenses. However, I was extremely lucky and they decided to do some discounts for people like me. I was still not sure whether to go, it was the last ticket that I purchased.

And there I was: suddenly on my way to Brighton, no idea where to go from the train station, and knowing nobody there… Finally, an adventure!

First of all, I started looking at all the meetups relating to test happening in Brighton in the time I was there. There was one just after I arrived. So I went to this pub, directly after checking in the hotel, introducing myself to total strangers, expecting to be in a corner trying to eardrop some interesting conversation … But to my surprise, I was immediately taken in and involved in many of those, just as the regulars.

The three questions:

There were three topics I brought up often in the conversations:

1) Do you know of others test conferences worth it to go?

2) What do you think of certifications?

3) Should a tester know programming?

The first one I asked because I started reading about other test conferences and they are usually even more costly than the test bash. I wanted to know other’s experiences to discard or consider further conferences.

What I learned? First of all, my lynx, I was attending to the probably better value/money balanced conferenced in Europe. EuroSTAR is the most known conference in Europe. Ireland have a small community of testers and last year the EuroSTAR was hosted in Ireland! (introduce feline facepaw here)

I also heard about other conferences worth the time and the effort: expoqa (Spain), let’s test (Stockholm), Copenhagen context, Pipeline conference…

The second question I was interested in, had to do with certifications. I do have a good working experience at this point, but some things you cannot get on some jobs and I like learning new things constantly. Unfortunately, most of the people who I spoke to agreed in that if you have good experience, test certifications are irrelevant. It is good to have the istqb if you are just starting in test but other than that I couldn’t find out a certification that everybody was happy about. Interesting. Also, for developers there are plenty of certifications and courses available but the options for testers are quite limited. Interesting again, I’m setting as goal right here and now to dig deeper into this.

The third question, I liked to bring it up because I come from a developer and engineering background and I should be able to go back to it. I wanted to know people’s opinion about testers that know programming or come from an engineer career. To my surprise (and a little of let down for a short while) most of the people I met told me, in different words, that I was overqualified. Even others that came from my same background seemed to have gave up all relationship with code. On the other hand, some people really got interested on this fact about me and most agreed that it could be of advantage to at least know programming. There is still hope.

A handful of people agreed with me in that we need more people with coding capabilities and background and they keep up to date with coding. It is not my intention to scare off anybody without a career in IT, but to bring the attention of people like me that worked hard to get one and doesn’t go into the  testing field because they think they might be overqualified. Not the case, you can choose to do whatever you want to do. Therefore, if your passion is testing, why not to work towards a career on it? Is it peer pressure? Is it about money?

I learned something from my experience: if you like what you are doing, you will be doing a brilliant work. If you are doing a brilliant work, you will be naturally well compensated economically and you will probably not even care about that!

The workshops:

In relation to the workshops and conferences: I wish I could have done them all, but I had to choose between them. They all looked very interesting. Some of them brought more value to me than others, but all of them brought even more interesting conversations.

I learned many things and got many concepts to think about. Some key concepts and tips below:

  • Talk always with all the parties in the development and understand their definition of quality and testing to alienate it with ours.
  • Quality is a team commitment.
  • Translate technical things for the none technical people.
  • Translate non-technical things to the technical people.
  • Setting expectations before a meeting keeps people focused.
  • Job titles are important. I’m going to call myself “Lynx trainer”!
  • There are many places to practice testing, paid projects and live bug bashes. I promise to go through them and talk about them in a separate post.
  • Ask questions.
  • Ask many questions.
  • Ask more questions.
  • Be impeccable with your words.
  • The shorter the releases, the more chances to success and easier rollbacks.
  • Companies change but if you are passionate about what you do, you will always find ways of keep doing it.

There were also many books and topics I should look deeper into. I have been working on all that but I didn’t want to slow down the release of this post even longer and forget about the experience and the feeling.

I could be talking about all of the workshops with detail, but there are many good experienced bloggers out there that are also faster than me and you could learn more about it through them. Besides, those are, well… other stories.

Hands on: Using Ranorex to automate scratch

Lynx are quite curious animals (they are felines after all) and this is as well a shared quality with testers. We want to understand how things work, we want to break stuff so we can recreate and improve it… we like “phoenixizing” programs.

The best way of finding out the quality of a program is to stand in the end user’s feet.

There are many type of testing, but my favourite one is the user interface testing (also known as functional testing). In this type of testing we use the application in several ways, with the most likely behaviour of the user and risky areas as priority, to find out defects on it. As you can imagine, manually testing the same buttons of an application could be quite time consuming and it will be difficult to regress (retest). That’s the reason we use automation for it (I’ll explain an example later on). Since I don’t know (or mind) if you have developing experience, I will divide this post in two parts: On the first part I will explain how to use scratch to develop a simple program that may be difficult to test manually. On the second part, I will explain how to use Ranorex to automate the previous program. Let’s get started!

PART 1: Scratch developing.

Scratch is a simple tool for start developing, in which you can develop interesting applications just it by dragging and dropping easy sentences. The first time I used it was in coder dojo about a year ago (maybe more?). Scratch website (http://scratch.mit.edu) has many examples and tutorials, but you should be able to reproduce this simple program by following these steps (picture in Spanish version):Scratch creation

  1. Go to the scratch website (http://scratch.mit.edu )
  2. Click on “create” on the top (or on the cat icon)
  3. You should register on the top right in order to upload your project for testing (optional)
  4. Click on events
  5. Drag “on click this element” to the coding area
  6. Click on movement
  7. Drag “bounce if hit corner” and “move 10” under the previous instruction ensuring that the instruction stick together
  8. Change the name and share it.

I saved the program above here: http://scratch.mit.edu/projects/48422496/

What does this program do? It moves a cat (called sprite) 10 pixels every time the user clicks on it. If it reaches a corner it supposes to bounce.

Can you think of anyways of testing it? It will require you to click on the cat until it reaches both corners if you want to be sure it behaves as you want to. Isn’t that a bit silly? Could we make it easier to test?

Part 2: Using Ranorex to automate the scratch program

There are many ways and tools for doing UI automation on a web application. An easy way of doing so is by using a recording tool.

I read about Ranorex in a testing magazine a while back. I found it quite interesting but never got the chance of working in a company that uses it so far. Therefore, I found this project perfect to give it a go, and I was not disappointed one bit. Their website: http://www.ranorex.com/

Automating Scratch programs have the added difficulty of using flash objects. This is not too bad if you are coding the automation or if you can add libraries to your application, but many recording tools will fail while trying to retrieve the objects.

For this example, and for teaching purposes, recording tool is indispensable.RecordSettingsInRanorex

  1. I downloaded the trial version from their website. They sent me an e-mail with instructions and followed up on it. I found that quite nice of them to do and they were very nice too. I found that it dowloads better from the .exe than from the .zipRecordSettingsInRanorex
  2. Open “Ranorex recorder”.
  3. Click the red record button, select “open a browser” and paste the url of the project. Select Internet explorer.
  4. The scratch project window will open and you will be able to start recording the clicks. Click once to activate the project and another time in the cat (sprite) RanorexRecording
  5. Stop the recording (The stop button is in the left hand side of the screen as shown in the picture)
  6. Copy the line that clicks the sprite and paste it as many times as you need with the buttons on the top or the well known shortcuts ctrl+c and then ctrl+p. In the picture the click is the third one.
  7. Click “Turbo mode” and play and enjoy how the cat moves by itself. Feel free of eating/drinking something while the computer does your job for you 😉Scratch recording

Thoughts on Ranorex:

Pros: Quite powerful and easy to install and start using. All comes with the package and didn’t need special configurations, libraries for the application… Great support!

Cons: Worked like a charm for internet explorer 11, but I could not make it record in Chrome and the clicking was misplaced in Firefox. I believe they are working on improving this.

I would really like to keep testing with it to have a better idea of all its capabilities. I need to keep looking for another automation tool that is open for the kids to use in coder dojo.

Conclusion

UI recording testing is a great way of quick testing the functionality of an application. There are ways of telling if the results are the expected for multiple automations without the need of looking at the output screen. However, that is… well, another story.

The story of the test lynx

I once assisted to a yearly meeting just after joining a company. As you could imagine, some bits were not very exciting for a person who just joined and did nothing to achieve any of the results that were shown. After about half an hour of those boring bits I started to feel quite sleeping (it was siesta time, in my defense). It took a couple of pictures of lions to wake up my brain at that point. Yes, you read it right, lions.

The last talk was a wonderful speech by Ian Thomas about lions and how they compare to business teams that managed to wake me up and I still remember after the years. I have no intention at all to duplicate or belittle his talk, very much inspired by it, I believe that testers could also be compared to another type of feline…

Lynx are animals that are known for their fantastic hearing and eyesight. I think these are two qualities that any tester should also be known for. I am sure we share many others.

On one hand, hearing should be an essential quality for a good tester (sometimes it is a difficult one to have). One could argue that more than hearing, what you need is listening. I could argue the same for the lynx as I am sure he needs to differentiate the noises and understand the meaning of whatever is heard. A tester should listen to anybody, developers, other testers, or even if you are building your own app, ask for feedback to the users and to your family and friends if needed. We should listen to ourselves too, as we also need to have a good insight.

A lynx is said to be able to spot a mouse 75 meters away… a good tester should spot a defect 75 meters away. This is better achieved when you have a good knowledge of the environment and of the type of prey you may find on it.

If you are brand new into developing and want to work on this quality, try with games such as word search or finding the difference. I know it sounds silly, but it is quite handy for things such as code reviews or some user acceptance testing. Here are some examples for you:

http://www.ecokids.ca/pub/eco_info/topics/landuse/bugHunt/app_BugGame.cfm

http://www.spotthedifference.com/

http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm

If you are intermediate and you know already how to write some code, a good idea is to write it without an environment and try to code it clean (directly in the notepad or vim). Then copy the results in the your environment and check with the compiler. Also, other tools such as stylecop, can help you find style defects and in long term improve your coding. As before, it will keep you alert for other issues.

If you are advanced in testing already, I suggest you try games like this:

https://xss-game.appspot.com/

(Some testers and developers will often forget about security and performance, especially when it is done by another team. I think a good tester should know at least a little about common issues and catch them quick, the same as the developers should also know about them to avoid defects. )

So, have you found the bug on this post already? That would mean you are in your way for becoming a great tester!

I can tell you more about types of testing and how to work on them. I am hoping to start coding some actual examples as well, as I would be too bored of just reading if I were you. However that’s, well, another story…

Baby lynx

A new lynx has born!

Hi,

I am a software engineer (in test). I have 5 years of working experience in the field, but I must say that I have been a tester since… well, always. In my opinion, this is something you are, not something you work on.

My goal for this blog is to share experiences, stories and learning. My dream is to be able to help anybody (interested), become a tester too. And if I can make it while writing interesting stories the better.

This blog is inspired in many others: some are from friends, but all of them are unknowingly mentors. Since I enjoy quite a lot the reading, I would like to share them with you:

(I know I have forgotten some of them and I am sure I will find more on my learning path, so I will make sure I update this list.)

And that’s all for my first post, short and concise, as tests should be. Maybe you were wondering about the lynx… you are showing tester’s qualities if you were. However that’s, well, another story…


Testing is like watching a movie after you read the book. (Noemi)