Altom

Exploratory testing - a rookie's thoughts (part 3)

2011-12-03T12:21:00.000+02:00

Q: What other testing activities have you done besides pair testing?

A: Well, we also did something I named parallel testing, which involves less teamwork but can be just as engaging as pair testing. I’ll try to explain what this means using a similar analogy I used for pair testing. I compared pair testing to a car ride, where one tester is the driver, while the other is a passenger in the same car. Parallel testing is similar, with both testers being drivers (both with their own keyboard/computer), in slightly different cars (this can vary between using different browsers/OSs/computer configurations), driving parallel to each other (testing the same piece of software/section of application), with a communication link between them (both testers are within earshot of each other - in same office or room).

One aspect of this method is that each person tests the same section or even features that overlap with one other. This makes it possible to test things in more detail, knowing that there is another person that is doing tests on the same piece of software.

Instant feedback is another aspect to consider. A different tester is basically testing the same part of an application you are, so when you would normally ask someone to help test something the entire introduction to what you are doing can be skipped. Of course there are some cases where you just end up diverting their attention to something less significant you want them to try out and they might miss something important...

Googling parallel testing turned up finds pointing to a different procedure than what I was referring to, (testing an old version of software in parallel with a new version, checking for inconsistencies between the two), so the name might not be the most appropriate, but it will have to work until someone suggests a better one. :)

A mindmap of my Eurostar 2011 experience

2011-11-29T21:49:00.002+02:00

Having just returned from my first Eurostar conference, I've made a mindmap of all the sessions and tutorials that I attended and tried to include all the notes I had (if any) on each of them:

(opening the image in a new tab will allow zoom-in)

The mindmap is also shared online here: http://www.xmind.net/share/rucindrea/eurostar-2011/

I also want to thank all the people that I met in Manchester this year and that made this first Eurostar experience a very special one.

-Ru

Exploratory testing - a rookie's thoughts (part 2)

2011-11-13T12:09:00.003+02:00

Q: How about reporting issues? How did you go about logging bugs while pair testing?

A: Logging the bugs we found took longer than expected. This means, that we found something, determined that it was a bug, investigated its cause, then spent too much time logging the said bug (even if we agreed on the cause and the effect of the bug, as well as on the steps to reproduce it); I guess you could say we didn’t agree on what information to include in the report, what order was the most appropriate, and what was relevant as far as that particular bug was concerned.

I don’t have a concrete example for this, but I seem to recall logging a tricky bug that overlapped with another one and my testing partner suggested adding information from one bug in the other’s report, while it was clear - to me at least - that the piece of information they wanted to add was not relevant to the bug report at hand. I realize this is quite biased, seeing that this is only my side of the story I suppose….

Bug reporting may have been slow because when I write things down, I constantly revise it until it starts to resemble a coherent thought (this fails at times though... miserably even). Or it may have been because my level of English was different than that of my testing partner. It was probably a little bit of both. :)

Or maybe this is a personal thing, I don’t know; I tend to be a perfectionist when it comes to putting my words on digital paper and I consider committing anything to words to be mainly a solitary activity, after all it’s your ideas on digital paper. Besides, two people can have very different ways of writing the same thing down, even if the main idea is identical. So you would have a train of thought and your partner would have a different one, and oftentimes they would rather collide instead of combining into a cohesive bug report.

All in all, my conclusion is that having someone next to you can help a lot during testing, while it could be a hindrance when logging bugs.

Exploratory testing - a rookie's thoughts (part 1)

2011-11-13T11:52:00.006+02:00

Here are some of my thoughts in the form of questions and answers, which mostly come from feedback I gave Alex and Oana on exploratory testing when I first started out as a tester, and although much has changed since, I still have a lot to learn in order to become better at my craft… Enjoy! :D

Q: So… pair testing; comparing the experience to testing alone, what are the things you did differently when testing with someone else?

A: Pair testing? Err… don’t you mean peer testing? Hm…

*thought about this for a while, then googled a bunch of stuff regarding peer/pair testing*

Okay, let me try to explain why naming it peer testing makes sense to me: if someone is your peer that means the person is of the same level as you (viewed as your equal, if you will). So if two peers sit down together to test a piece of software, there is no hierarchical difference between them, one tester does not simply oversee the other tester’s progress, both testers are interchangeable. I’m not saying pair testing implies inequality between the two participants, but it does not exclude that possibility either (one could be a developer or a business analyst - according to the Wikipedia page on Pair testing, anyway). I also did a Google search on peer testing, turns out it’s also used in the way I’ve used it, but pair testing is more widespread, so I guess for the sake of familiarity, I’ll change the name.

Regardless of how you call it, one thing is certain: there are far more questions raised by two people looking at the same piece of software than going at it alone. Instead of sitting in front of a monitor and wondering what this feature does, you engage in conversation. The testing partners enter a kind of dialogue in which the third participant is the application itself.

Another thing is you bounce ideas off each other about how a user might act in a certain situation or what might be considered a bug in what situation. There are also occasions where you just look at each other perplexed and wonder what had just happened and how you could make the application do that again.

The way I see it, the person sitting at the keyboard focuses on the task (or scenario) while their partner takes notes and can look at the overall changes happening in the application. It’s kind of like driving a car really, the driver, as in the person at the keyboard, focuses on the road ahead, and is basically in control of what the application is doing, and sure there are times when the person next to them tells them what to do or where to go, but backseat driving is never popular. :P

Meanwhile the passenger can look around freely, without any focus in particular. They can look at different things that happen throughout the application, not just what the “driver” is looking at. This is where most of my ideas for possible tests came from. When you are focusing on one thing happening (or waiting for some particular thing to happen), you can’t see all the possibilities for bugs just waiting to happen. Of course some of the ideas are a little far-fetched, and wouldn’t necessarily discover bugs in most situations.

Letsdoitromania - a great testing exercise

2011-09-26T15:07:00.000+03:00

This weekend Altom participated for the second time in LetsDoItRomania! The program is part of http://www.letsdoitworld.org/, started by the Estonians in 2008, that has the target to clean the country by involving a big number of people. This year we didn't have the time to get involved in the organization of the event, but we managed to gather a team of 5 people: Ionela, Levi, Ramona, Oana and myself :D.

We got the garbage bags and the plastic gloves from the organizers, we bought two pairs of industrial work gloves and we borrowed a fork and shovel (lessons learned from last year), we chose two garbage sites near Valisoara, a remote village near Transilvania Highway, and on Saturday morning, 24th of September, we left Cluj to clean them :D.

This whole experience reminded me a lot of the software projects I'm involved in as a tester. I think this was a great example of how someone can learn about software testing by doing something not related to work, and I will try to explain why.

Delayed start

On Friday we had decided to meet the next day at 9:00 AM and leave for the selected sites, but on Saturday morning when we looked for the sites details (pictures, GPS coordinates, description) the application was not showing any of the needed information. We found out that the organizers had set up a local call center, we called them (we had to wait until we were able to get someone on the other line) and someone was able to give us the GPS coordinates for the selected locations.

All this hassle delayed our departure with around 20 minutes. One thing we could have done to minimize the risk of this happening was to look for the information on Friday evening, but we were too optimistic and left this important task for the last moment :).

Has that never happened to you when starting a new testing project: realizing that you didn't have important information, and in order to get it you had to call someone on the client side/development team which delayed the start of your work?

Our village doesn't have garbage

Once we found the information we needed, we entered the GPS coordinates and we left for the 1st location. We arrived in the village, and even if we had the coordinates, we stopped to talk to an old man and get some inside information :).

I first asked him if he knew about areas used by the village people to dump the garbage, and his answer was that the village was clean, as they had a garbage collection system and that took care of the problem. I continued by asking: "well, but before this system was put in place, where did you use to dump the garbage?", and his answer was: "well, but that was a long time ago...".

This short discussion reminded me of lots of developer's / engineering manager's answers I got while testing: "our code doesn't have bugs, as we use this system/process (please read garbage collector, unit tests, code review) that makes sure everything is taken care of."

I told the old man that it had been reported that there were areas in the village where garbage was dumped, and his first reaction was: "Who said that? Was it someone from the village?". I said "No, not someone from the village", then he replied "Well, if they're not from the village, then they don't know"

Working as a consultant I often noticed this attitude: "if you're not from the organization, how dare you say we have a problem?"

Changes you don't know about

We left the old man, and continued our way to the first garbage site. We stopped where pointed by the GPS coordinates, but unfortunately there was no dump yard there. Instead, we found some men who were trying to build something. I got off the car and went to talk to them. One guy came towards me and told me that he had bought the area one year ago, and that he had cleaned most of the garbage.

It happened to me while testing to find out that parts of the application or functionalities had been removed, but the documentation had not been updated in the meanwhile. This was the case with this location too: the garbage site had been reported last year, but no one cared /had the time to check and update the details of the site.

We phoned the call center again, and asked them to assign us another site somewhere in the neighborhood. Once we got the new details, we headed to the new site which was at the other end of the village.

Understanding the impact

The site was on the water stream, which is quite a common location. For some reason people think that it's OK to throw their garbage in the stream / river, as the water takes it away, but they don't think that the people up the stream can, and will, do the same thing or that their garbage will harm the people down the stream.

The way we perceive the impact of our actions always amazes me. As the villagers don't understand that the animals (domestic or wild) will drink from that water and that they will later eat the meat or they'll drink the milk and get sick.

It often happens that we don't understand or minimize the risks introduced by the changes done in the software application we develop.

Estimating the amount of garbage

The procedure when mapping the garbage sites is the following: someone identifies the location, gets the GPS coordinates, takes some pictures and enters some details describing the type of garbage that is found there and estimating the amount of garbage bags needed to clean up the location. This was the third time I took part in a cleaning action (last year I participated both in the pilot event and in the national event), and every time the estimates were way off. For this year's location, the estimates were 25 garbage bags. We collected 44, and we could have had more if we had continued until sunset.

Another thing I noticed was that the garbage bags were not identical: some had more garbage than others, they contained different things (plastic bottles, clothes, rubber, glass bottles...), some were heavier that others.

This reminded me of a project I worked on that used some algorithm to estimate the number of bugs that should be found in the application, and afterwards reviewed testing based on bug numbers...

Coverage

After approximately four hours of intense fight with the garbage and nettles, we decided to stop. We had to call the organizers and tell them the exact location where we had left the garbage bags so pickup trucks could come to take them.

One of the questions they asked me was the coverage percentage for that site. I told them that the estimates were 25 bags and we collected 44, so what kind of percentage did they want?

One thing I want to specify about garbage dumps is that they pile up between plants and the earth brought by the water. It's like thinking of different layers of an application. So if one continues to dig, there's a big chance that s/he'll find more garbage. This is why I thought that providing a percentage was kind of useless. In order to know the percentage, we needed to know the total amount of the garbage that was located on the site, something we couldn't know for sure.

The girl on the phone insisted I give her a number, and I said 70%. While I'm writing this I question my answer and wonder if that was the right thing to do... If a client asks me for something, and I explain them that this number is useless but they still ask for it, is it OK to give them my best guestimate? I've offered them my advice, but they are the ones paying, after all... For an interesting view of this issue please see the first 5 minutes of this TEDTalk - the Japanese tea story: http://goo.gl/I64c.

One of the things that I like most about being a tester is that I often find similarities between my work and day-to-day events, which makes learning more interesting and fun :).

2011: A CAST Odyssey

2011-08-19T16:56:00.002+03:00

Last week I had the chance to be in Seattle for CAST2011 and I think it was definitely worth the effort to apply for a US visa, travel for 30 hours to get there, and another 30 to get back.

The conference was fully organized by volunteers, people that gave up their free time to make sure that the others enjoyed the conference.

Two days before the starting of the event everything was on time. Please read: "everything that the organizers had thought of", as people still complained about different things :-). My favorite was "the absence of proteins for breakfast", which I found extremely funny, as no-one seemed to be close to starvation, au contraire :-D. The organization committee, and especially Jon Bach, did their best to solve the "bugs raised", and they even provided eggs for breakfast starting with the second day :-D.

This was a real face-to-face get-together. I like the internet, but I like more getting to know people in flesh and blood. (I was finally able to meet the man behind the email address or Twitter nickname I'd been following.) Besides, I think the internet can sometimes be very misleading. To give you one example, this spring when I took Bug Advocacy, I had Doug Hoffman as lead instructor. My image of Doug after the course was of a harsh and frightening man. After the first few hours I spent with him before the conference, I discovered a totally different person: caring and open to listening and helping others.

The conference was about human interaction and sharing experiences. Being built as a large peer conference, interesting discussions developed not only during breaks or on the hallways, but also during sessions and keynotes due to the open-season. I loved the idea of a facilitator taking care of who was to speak next and keeping discussions on the right track, and also the use of the colored k-cards both from a listener / member of the audience point of view and also from a speaker point of view.

The selected topics made me want to clone myself several times, and send each copy to a different session. Unfortunately that was not possible, so I had to make some tough choices. I liked Paul Holland's session on "How to organize a peer conference". What a good way to learn how to do that: experience CAST as a participant, and have someone like Paul, who has been involved in so many events of the kind, to come and talk about how it is to be on the other side, to be in the shoes of the organizer.

The keynotes were very interesting, and very well delivered. Even if Michael's computer didn't work, he was able to deliver a great speech, and also to beat the previous record of Red Cards shown during a talk :-). I definitely recommend watching the recordings on the AST website once they are uploaded.

Maaret Pyhäjärvi asked me to join her team for the testing contest. At first I thought I'd be too tired to take part in the contest, but then I agreed. Because we felt that the application was too buggy, and being exhausted after the first day of the conference, we lost our motivation after less than 3 hours. My takeaway from this exercise was Maaret's report - she did a great job in presenting our testing story just by using a mind map. Unfortunately the bugs we found were not as interesting as the ones found by the other teams and we didn't interact enough with the developer, so we didn't win the contest, but her report was mentioned by James Bach at the awards handout.

For me CAST2011 was a conference made by people for people, with the purpose of building a testing community, and no commercial flavor.

I loved being there, and I plan to attend next year as well!

AST BBST Foundations a.k.a my testing bass line

2011-03-31T19:59:00.001+03:00

I have just finished the BBST Foundation course from AST and it has been such a powerful motivational booster that I have to tell the whole world (read “testing community”) about it.

I have been a tester for almost ten years now and I’ve always considered myself one of the few that are still very much enthusiastic about testing. But this course has been like a wake-up call. It felt like an “intervention” coming from well-intentioned friends, meant to remind me that sometimes you’re so focused on what you’re doing that you forget how to do it well. It basically blew my mind.

Let me try to explain.

There are very few things that have been constantly present in my life in the last decade. One of them is testing, the other one is music. I’ve changed countries, cities, jobs, partners, diets, friends – but testing and music have always been there. I’ve been playing guitar for quite a few years, and while I’m not at all good at it, I love playing because it gives me a different way to enjoy music. A few months ago, a friend suggested I should try playing a few bass lines and taught me some basic things. At first, I thought: “Ok, let’s give it a try” and learned a couple of songs. And then, one day, I realized that everything had changed. Music had changed for me. I could no longer listen to a song without noticing the bass line. I could no longer understand what it had been like before, when I wasn’t paying attention to it. All the old songs I used to love were all of a sudden completely different, and there were so many new songs to like. My music world had been turned upside-down by something as basic as the bass line.

The BBST course did the same thing to my testing world and the knowledge I gained from it will be my “testing bass line” from now on.

The main objective of the course is to help testers understand key testing challenges. It covers testing objectives and the testing mission, oracles, test coverage and measurement, and at the same time it teaches students about the importance of clear communication.

If you’ve been a tester for some time, you might think this is nothing new. That was my first thought as well – there wasn’t anything on the course objectives that I hadn’t heard of before. But then, going back to my music parallel, it’s not like I hadn’t heard millions of bass lines before either. The trick is to actually understand them and pay attention to them – that’s when everything changes.

I started the course with the typical enthusiasm I have every time I start something new. I expected it to fade a few days afterwards, like it always does. But two weeks into the course, I was still hooked, even though it was so much work. There were quizzes, group assignments, videos, readings, slides, discussion forums, debates… all of them just perfect to feed my tester nerdiness.

I don’t want to go into too many details about the assignments because, since I plan to recommend this to every tester I know, I don’t want to spoil the surprise. But here are a few points:

What I absolutely loved about BBST:

There are no “Best Practices”

This is made clear from the very first lecture. Nothing that you learn during the course feels like it’s being imposed on you. You learn about practices that have proven to work within a certain context. You can agree or disagree, or come up with an approach that works better in your situation.
Group assignments

There are various group assignments during the course, where you need to work with your colleagues to come up with a group solution/strategy for a certain problem. You get to work with people from all over the world that have different schedules and are in different time zones. It feels real. It feels like the real work you do every day, where you have teams all over the globe and you have to deal with it.
Working on the exam questions before the exam

For the final exam, you have to answer a set of questions that are chosen from a pool of questions that are available to you from the beginning of the course. You not only get (and are supposed) to prepare your answers in advance, you also get to discuss them with the other students – which helps you learn so much more. You get to see different points of view, discuss your own and challenge the others’ and understand what you might have missed or misunderstood. On some level, the whole course feels like one big group assignment and I’m happy I got the chance to be in the same class with such interesting and smart students.
Feeling significant

I realize this might sound very silly, but just being part of this made me feel important. You not only have access to excellent material, you also get first hand feedback from people like Cem Kaner, Becky Fiedler and Doug Hoffman. There’s something about that that made me feel amazingly good. I’m sure you’d understand :)

What I wish I could have done differently:

I wish I had better English skills. For a non-native speaker who hasn’t lived in an English speaking country for more than a year, I think I’m doing pretty well, but sometimes I do feel self-conscious about my ability to express myself in a professional way. I was in the same class with people like Catherine Powell, to give just one example, and while it was a pleasure to read her witty and very well structured answers, it made me wish I could write at least half as well as she does. But the best thing I can do is practice, so please bear with me :)

I wish I had more time. I did spend more time on this that I had initially planned, but I still wish I could have been more involved. A month after the course has ended, I still go back to the e-learning platform every now and then, when I have a spare moment, to go through what I haven’t had time to read during the 4 weeks.

What I will do next (and this is a promise!):

The Bug Advocacy course - I just need to catch my breath first
Skype coaching with James Bach - as soon as I work up the courage :)
The BBST Instructors Course – as soon as I figure out how it works
Write a blog post about all of the above

But first I want to spread the word. This was an amazing experience and I'm confident any tester would love it. We will promote it within our team of testers at Altom and I encourage other software testing companies to do the same.

'No talk on Tuesday' experiment

2011-02-27T22:18:00.000+02:00

I think that when you work as a software tester, it's important to have your mind trained to spot things and follow the logic of an application, so the capacity to focus is a key element. We are a team of software testers working in an open space office, but on different projects. One day, I realized that we started to talk or chat if we had something in mind, without checking first if the others were busy or not. Whenever I wanted to know what the progress was with some tests, I just raised my voice and asked my colleagues how we stand. Whenever I remembered something interesting I started telling the story. They were questions, news, concerns or whatever had happened to me during the previous day:
"- Did you reply to the client's latest email?"
"- I've just read that passive smoking causes hearing loss"
or
"- Do you know Radio Lab? They make great radio shows with scientific topics."
"- Can you please add in the report what we have and what we haven't covered during tests?"
"- Have you heard about Wikileaks and Assange? Did you check a cable from their website?" (no link here, for safety reasons ;))

I think communication was great in our team, everybody asked questions face-to-face, discussed issues from the project they were working on and talked about many different aspects, test related or not.

But one day I asked myself if all these interruptions were good or not. Should we promote 'silence'? Would I work better if I were more focused on a specific task? And would the others work better if I left them alone?

The very next evening I noticed a TEDx talk that caught my eye: Why work doesn't happen at work....

I first thought it was about something else... I'm interested in making the office a place where you feel very good and where you can work in a relaxed and familiar environment.

So I clicked on the video: http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html
(WATCH THE VIDEO BEFORE READING FORWARD, it's only 15 minutes!)

My first reaction was to say that the guy is an old fashioned, pre-google era guy working in an HR department. The next day I went to work and decided to start an experiment: No talk on that Tuesday (instead of Thursday) - to see if there's any applicability value for us in his theory.

The agreement was that nobody talks to any of the colleagues directly. The 'rules' were that

We use chat and email if you want to talk to people instead of the face-to-face conversation. This way, we have the option to choose whether we want to be interrupted or not.
Any person that failed to do this and spoke loudly interrupting the colleagues outside the 1 hour lunch break had to put 5 RON (~1.15 EUR) in the 'office piggy bank' that we use to buy fruits for all of us.

I was the winner, as I broke the rule unintentionally twice! So it cost me 10 RON.

At the end of the day, I asked everybody what they thought about the experiment, if they were able to focus and how they found it. They all had some common answers (experiment's initial feedback):

Not being interrupted can help them concentrate better, but after a while they felt sleepy. The communication efficiency was pretty much affected during this extreme experiment. They all found the rule too restrictive and that it was tiring to talk complex work aspects over IM...and also less effective.

Me personally? I loved it!! I started to notice how efficient I was on a task if I didn't defocus that often.

So I decided to find a set of recommendations as an optimized version of the initial experiment to help us all work better. Some people can focus back to their task very quickly after being interrupted, some need more time. So, can we create a set of rules that work for all of us?

The first version was something like this:

1. All the to-do items are to be discussed loudly in the morning for about 15 minutes through either scheduled meetings or ad-hoc ones, without any decibels restrictions.
2. Later on, if you have a more complex aspect that you want to talk about with your colleagues about, ask them first on chat or email if they have time (and when). If they agree to talk to you, keep your voice low or go into a meeting room.
3. Any phone calls and meetings are taken outside the office or in a meeting room.
3. Talk as much as you want during the 1 hour lunch break :)
4. Loud talking session in the afternoon: 15 min. That's when people start to feel a little bit sleepy.
5. You can interrupt people at the end of the program, at least to say goodbye :D

Then I checked again after 2 more months to see the results and here's what I found out:

some people were not happy with the fact that the upper list had the name 'rules', even though they were actually recommendations, as they had never been enforced (but this is another topic that I may address in another post)
the same people that were not happy with the rules preferred the headphones instead of having the rules in place (I wonder why..)
some considered that these rules affected their efficiency in communicating with the rest of the team
some considered the experiment and the rules beneficial (just a minority).

The purpose of the experiment and the follow up is to see if there's any value in Jason's theory on increased efficiency when people are not interrupted.

If I am to draw a conclusion from it at this point, this would be: the real value of the theory and the experiment is to make people aware of how important it is for them and for others to be able to focus. I think that the way each team juggles with focusing and defocusing operations should be up to them and not enforced by rules or recommendations. This requires 'team agreement' and not just using headphones to isolate oneself.

This experiment is worth doing to check what is the need of focus and how important is to avoid interruptions. If there are any others out there who have tried the same experiment with their teams, I would love to hear their results.

Meeting James Bach

2010-10-27T14:26:00.017+03:00

You heard about him, read about him, read his work… and you think you know what to expect. But nothing really prepares you for it. He’s intimidating and overconfident and at the same time passionate and charming. He’s everything you would like to be one day and he makes you believe you actually have a chance at it. All you have to do is think for yourself and question everything.

James Bach came to Romania for the first time for a workshop we organized in Cluj Napoca, on October 25^th, 2010. We had planned the event for 20-30 people, but we had so many requests that we had to extend the number to 50 and, still, all the seats were booked one month before the event.

I don’t know how many of the people that signed up for the event knew about the Context-Driven School, about exploratory testing and James Bach’s role in defining it, or about how opposed he is to ISTQB and everything related to it. But I am very sure that most (if not all) of the participants that didn't know these things looked them up afterwards – which is more than we can hope for.

I did know about his work, his beliefs and his methods. Still, the workshop was fascinating. Two days later, I still find myself thinking about it and analyzing everything that I’ve learned.

At the end of the workshop that day, while discussing it with my colleagues, Oana and Alex, I went on and on about how he didn’t have this or that right, or how he contradicted himself on this or that. I argued that while he pointed out that the ISTQB syllabus incorrectly defines exploratory testing as a testing technique, when it is really a testing approach that can be applied to any technique, he himself mistakenly called it a technique later on during the talk. He also presented a “boundary analysis” example which was meant to prove that the ISTQB definition for boundary analysis is incorrect because it says it only involves testing the values around the boundary. In his example, where a program had a 32k bytes boundary value, the program crashed when a value larger than 64k bytes was used – thus proving that it’s not only the values around the boundary that need to be tested, but also any other values that are ‘related” to the boundary in various ways. I was skeptic and argued to my colleagues and even to him, during the workshop, that the 64k bytes value was no longer part of the analysis for the 32k boundary value and that the crash could have been maybe found anyway by stressing the program with any other large(-r than 64k) value.

Later on I realized I would have argued anything. I was just trying to find reasons to prove that he’s not ‘the god’ we all think he is. But this is exactly what he wanted us to do: question him, question everything, think for ourselves. So I did think for myself and realized that his 32k bytes boundary value example was the perfect way to explain how exploratory testing can be successfully applied to any testing technique. It was an approach that he (and everyone else in that room) applied to the boundary analysis technique. I also realized I couldn't care less about semantics, as long as applying what he taught me helped me find a bug I wouldn’t have found otherwise.

So here I am, two days later, still thinking about it and finding out that my attempts at proving that he was wrong only led me to understand how right he was. I had been brainwashed, by ISTQB and years of working in environments that always told me what the right way was to do things. I need to deprogram myself, and if I might have known this for a long time, somewhere in the back of my mind, I never really thought I could or had to do it. But this is what this workshop taught me, above anything else: if you’re passionate enough, you can do anything. And when you see someone as passionate as James Bach, if you get a chance to hear him talk and think and question, you get all the motivation you need. Trust me.

As a side comment: While we were having lunch that day, James mentioned that he has a script that will alert him every time a new blog post or article related to exploratory testing or any other subject of interest to him is published on the internet. So this is also a test - I'm still trying to prove that sometimes he's just bragging ;)

--Ru

Selenium, XPath and Internet Explorer - Painfully Slow?

2010-10-01T11:48:00.001+03:00

I've been using RobotFramework with its Selenium Library for web automation for quite a while now and have always had the problem of getting any scripts that use XPath run on Internet Explorer.

For some web applications, if they're not too complex and don't use a lot of Ajax, you might be able to run scripts that use XPath on Internet Explorer and actually have them finish in this lifetime. But most of the time, they won't.

So I googled it. I found out that a lot of other people have googled it and a lot of them have complained on different forums. I've also found out that Selenium uses "AJAXSLT" as its default XPath library, which has a lot of performance issues on IE, and that the trick is to change this to the much faster javascript-xpath library.

However, none of the sites I read told me how to do that. I've never used Selenium RC directly, I've always used the Selenium Library for/from within RobotFramework, so maybe this is a trivial change in Selenium. But for those of you, like me, who are stuck with a "selenium-server.jar" file, here's what I had to do:

1. Locate "selenium-server.jar" (For RobotFramework users, this will be located in your Python directory, under \Lib\site-packages\SeleniumLibrary\lib\)

2. Make a copy of it (just in case).

3. Rename it to "selenium-server.zip" and unpack it.

4. Browse the unpacked selenium-server folder and go to \core\scripts\.

5. Edit "selenium-browserbot.js".

6. Inside the file, search for "ajaxslt". Depending on the version that you have installed, you should find one of the following lines:

this.xpathLibrary = this.defaultXpathLibrary = 'ajaxslt' // change to "javascript-xpath" for the newer, faster engine

this.xpathEvaluator = new XPathEvaluator('ajaxslt'); // change to "javascript-xpath" for the newer, faster engine

7. Change this line to:

this.xpathLibrary = this.defaultXpathLibrary = 'javascript-xpath' // change to "ajaxslt" for the slower, older engine

this.xpathEvaluator = new XPathEvaluator('javascript-xpath'); // change to "ajaxslt" for the slower, older engine

8. Save the file.

9. Archive the folder again into "selenium-server.zip"

10. Rename it back to "selenium-server.jar"

This worked just fine for me and I now get almost the same run times on Internet Explorer and Firefox. Hope it helps!

James Bach on Testing - 1 day workshop in Cluj-Napoca - Romania.

2010-09-03T10:01:00.003+03:00

I am happy to announce that James Bach will be hosting a workshop on testing on October 25th in Cluj Napoca. Here you can find more information and register for this event.

We also encourrage anyone who isn't from Cluj-Napoca/Romania to contact us if they want to take part in the workshop - I am confident we can help them find reasonable options for accommodation.

Alex

Buying train tickets in Romania - a tester's story.

2010-08-10T16:10:00.006+03:00

This year (or maybe at the end of last year) the Romanian national railroad company (CFR) introduced a new payment method: by bank card. I know we're in 2010 and that this system has been in place for several years in many parts of the world, but in Romania it hadn't been before. The thing I like most about this is that the option is only available in one ticket office from Bucharest Central Station - Gara de Nord - the one for international tickets, and nowhere else in Romania, as far as I know.

For the first seven months of this year I traveled almost weekly with the train, an 95% of the time I paid the ticket with a bank card. During this time, I observed the following process for POS ticket payment:

you specify from the beginning that you want to pay by card (this is really important, because the ticket officer will automatically assume that you pay by cash, and this is irreversible!)
the ticketing officer calculates the total amount to be paid
she writes the amount on a small piece of paper and hands it to you
you go to the international tickets office with the pice of paper and make the payment
you return to the ticket office with the receipt
the ticket officer enters again the ticket details, issues the ticket and hands it to you. At this point you are the happy owner of a train ticket :-)

Only a couple of times the ticket officer issued the ticket in step 2, and then asked me to go and pay for it.

I want to talk a little about the steps described above. Let's imagine the following scenario: you want to buy a ticket and let's assume that it's the last one available for your route and class. You take the piece of paper with the amount to be paid and go to the POS ticket office. In the meanwhile another customer goes to any of the 20 something ticket offices, asks about the same route and class ticket and wants to pay by cash. The ticket officer sees the same last ticket, and, as it wasn't reserved in the system for you, she will issue the ticket. Now, what happens when you return with the POS receipt? You paid for a ticket that is not available anymore, and the CFR won't upgrade you to the upper class either :). So basically you paid for a ticket but you don't get one. I wouldn't call this the best customer experience.

One time I asked the ticket officer "Why are you doing it like this? What don't you issue the ticket before sending me to pay it?" "We want to make sure you can pay for the ticket, and the POS is not always working.", she replied. "But if I pay by cash, you won't ask me to show you the money before issuing the ticket, would you?". At this point, a man from the queue yelled "Hey, we're queueing here, not philosophizing!" and the ticket officer said nothing.

I must have bought at least 20 tickets during the 7 months, and the POS always worked. I know it's a small sample and I can't generalize and say that the POS always works, it's software after all :). I did see once someone that didn't have enough cash on her, so after the ticket was issued she had to go and withdraw money from and ATM machine.

I don't remember if I used to notice things like this before being really interested in improving my skills as a software tester. Reading blogs and books by Jerry Weinberg / Cem Kaner / James Bach and others, following the software-testing user group, made me more aware of this type of reasoning.

And one more thing ... I definitely don't want to be like the man that was queueing that day.

Testing a sumoBot

2010-07-12T16:26:00.022+03:00

Robot-sumo, or pepe-sumo is a sport in which two robots attempt to push each other out of a circle/ring (in a similar fashion to the sport of sumo).
The robots used in this competition are called sumoBots.

The challenges for the sumoBot are:

to find the opponent (accomplished with IR [infrared], Ultrasound, Presence sensors)
to push it out of the flat arena
to avoid leaving the arena (usually by means of a sensor that detects the edge, e.g BW [Black & White] sensors)

Standard class sumoBots:

may average up to 3 kg
must fit inside a 20 cm by 20 cm box
can have any height

To make this easier, we'll take as reference point V.A.S.I.L.E.

V.A.S.I.L.E [Very Advanced Intelligent Sumo Lifeless Entity]
...is a sumoBot sponsored by Altom, which participated to the National Robo Challenge competition at Bucharest, the 15th of May, 2010.

The team had about a week until the competition to design, get the necessary components and build the sumoBot. Getting the components was the biggest issue. First of all, we couldn’t have the motors we needed (suitable for sumo robot competitions) in efficient time, because they were not on stock. Some of the motors that we did find didn't meet the requirements (they were too big, i.e more than 20 cm by 20 cm) and ordering them from online sites would have taken too long. Finally, we found some pretty good motors from an old printer, which also provided us the wheels.
But another problem was encountered: the need of gear-box. We only knew one person who could provide us the gear-box, but we were told it would take a week to finish it. Luckily, the other components were sent fast, but the whole motors and gear-box process took about three weeks to arrive.

So, we had only six days left until the competition to build the sumoBot.

The team was initially formed by three members: Andrei Cociuba, Adina Moldovan and Lucian Nertan. The team members' experience with this kind of competitions was low-medium, as only Adina had previously built a sumoBot for a Mini-Sumo Competition, at the end of a BEST course in Ankara, “Robotic Days”, March 2010. However, Andrei was very experienced in advanced circuitry and all the members of the team had good programming skills, excelling with Lucian. A day before the competition, Dan Salagean, mid-level software tester, gave us a hand in software debugging and bug fixing.

As we had little time to finish the sumoBot, we tried to work quickly and efficiently. Even if V.A.S.I.L.E was not developed using a certain model, during the development process we used elements of trial and error and scrum methods.
V.A.S.I.L.E grew up based on daily scrum meetings, when we quickly discussed an overall about our project:

what we've done until yesterday
what we’re doing today and who’s doing what
issues preventing to accomplish our goals; solutions

The development process was partitioned into five phases:
1. Planning, when we analyzed the competition requirements and specifications, sketched the sumoBot design and got the components.
2. After planning, the compatibility testing was done. The motors, gear boxes, wheels and battery were mounted on the chassis. The target was to determine V.A.S.I.L.E to move, without additional circuitry.
3. BW sensor circuits and trigger circuits for the BW sensors were done and tested.
4. All sensors were mounted on V.A.S.I.L.E and tested using software test programs. Also, additional components were mounted on the robot, i.e little protection wheels for BW circuits, wheels protection, attack and defense blades.
5. Writing and testing the software. The software was based mostly on trial and error methods, e.g: Motor directions were set by writing ad hoc software with motor directives. The software was uploaded on V.A.S.I.L.E’s microprocessor. V.A.S.I.L.E was put in the sumo ring and observed. After identifying the motor directions (forward, backward, left, right), the software was improved and corresponding procedures were created (GoForward(int), GoBackward(int), GoLeft(int), GoRight(int)).

Issues encountered, related to the five iterations:

The trigger circuit: We applied three different methods to build it (one of them based on operational amplifiers, the other one resistance-based and the last one using a NAND circuit. Unfortunately, neither of them worked as indented. The trigger circuit was supposed to launch an interruption when any of the BW sensors would detect the white border).
Solution: Technical debt, i.e none of the trigger circuits wasn't used anymore, the BW sensors being wired directly to the mainboard. This debt affected us later, creating problems with the delay (see Issue because of inefficient testing)
Burnt motor drivers. During one of our hardware tests, while supplying the motors circuit, the motor driver got burnt.
Solution: We bought one for the circuit and another one for future burn-downs, but our work was slowed down two days because of this. During those two days, we tried to work on other independent components of the sumoBot, e.g, Analytic sensors.
V.A.S.I.L.E was overweight (more than 3 Kilos).
Solution1: Liposuction process, i.e holes in the chassis to lose weight. The method proved to be inefficient because there was too much weight to be dropped down.
Solution2: We bought a new battery, which weighted 0.5 Kilos less than the current one.
Find opponent strategy changed. The first configuration with 1 * US plus 1 * Presence sensors in front and 1 * IR back, changed to 2 * IR plus 1 * Presence sensors in front and 1 * US back. We changed the sensor configuration in order to detect the opponent movement direction easier. With two analog sensors in front and some computations, we wanted to search for the opponent only once during a round and then with the sensors aid to detect its moving direction. V.A.S.I.L.E would only have left to move synchronously with the opponent.
Solution: Designed and constructed new blades with shells for the sensors. This lasted about 4 hours. We also rewrote the software program in order to match the new logic.

V.A.S.I.L.E’s strong points are:
Weight. The boundary of weight is 3 Kilos and V.A.S.I.L.E weights 2.99 Kilos. This is a great advantage to use all the necessary resources to improve wheel adherence.
Motors. Even if we couldn’t test the motors power, we did some load tests and V.A.S.I.L.E could push 5 kilos without any difficulties.

One day left until the competition…
We had one day left to write the final software and test it. We also had to consider to successfully pass the preliminary task: to push a box out of the ring. During our scrum meeting that day, we decided there wasn’t enough time to write advanced defense procedures, so we focused on finding the opponent and attacking it. With the two advantages listed above (weight and motors), V.A.S.I.L.E should handle the situation.

Testing V.A.S.I.L.E

[Image] V.A.S.I.L.E and its sensors' display

We had to cover two aspects: the hardware and the integrated/embedded software.
We started with tests for the hardware:

Functional testing

BW sensor read: After soldering the circuits for BW sensors, we tested them with corresponding equipment consisting of power supply and oscilloscope

Detecting opponent sensor read: IR, Ultrasound, Presence sensors. We tried to identify sensor’s behavior taking into account the possible noise (object presence near the ring – the US is detecting objects on 6 meter distance) and calibrate the sensors according the output values.

Integration testing

We have tested V.A.S.I.L.E under normal conditions:
On a regular collision with the opponent
* the components don’t fall off the chassis:
· motors and gear-box (they were mounted under the chassis)
· battery (was not glued on the chassis)
· mainboard (was very sensitive on wire connections. At this part we also found a bug: V.A.S.I.L.E had problems with directions as the motor driver was not fixed very well on its socket and the pin connection was sometimes lost)
· BW sensors
* motors don’t burn
* BW sensors don’t scratch the floor (as they were mounted very close to the floor. To prevent this, we used some little wheels near the BW sensors, to have a smooth movement)

When being pushed out of the ring
* the sumoBot can be easily be stopped if executing procedures
* the components don’t fall off the chassis
* the mainboard circuits don’t break
* the BW circuits don’t break

Load testing

How many Kilos the sumoBot can push [around 5 Kilos]

Then, we continued with tests for the software:

Direction directives: Go Forward, Go Back, Go Right, Go Left
Turn directives: Turn 90 degrees, Turn 180 degrees. Turn 180 degrees procedure was very useful when the US sensor mounted at V.A.S.I.L.E’s back would detect the opponent
Avoid leaving the ring:

When opponent is not detected yet
· BW sensor read procedures combined with motor directives procedures, in order to stay in the ring. We implemented a ring coverage

When opponent is detected
· Give priority to BW sensor read before executing other procedures

Find opponent: developed a procedure to cover the whole ring in only a few moves
Attack opponent: the attack is done by simply going forward toward the opponent to get it out of the ring.

We also thought of other strategies like
· first going back and then go forward to gain speed or
· attack from one of the right or left sides of the other sumoBot, in order to be more difficult to get attacked
but unfortunately, we didn’t have enough time to test these ideas and ideas which are not tested are worth very little.

Hardware-Software dependency
The hardware-software dependency was one of V.A.S.I.L.E’s weak points. The issue was that we relied on how charged the battery was to execute the direction and turn procedures correctly. For example, if the US sensor detected the opponent, the following code would be executed:

/*
Variables and parameters:
us –> the ultrasound sensor which is mounted at the back of the sumoBot
long, short -> delay Constants

Procedures:
GoLeft(int delayConstant)
GoForward(int delayConstant)
These direction procedures go left / forward for a certain amount of ms (milliseconds), specified by the delayConstant

The logic:
When the us (ultrasound) sensor detects the opponent, turns 180 degrees and then attacks it(by going forward)
*/

if (us<30){
GoLeft(long); //turn 180 degrees
GoForward(short); //attack
return;
}

The 180 degree turning is done by going left a certain amount of time, specified by the parameter long. The issue here was that the variable long depends on how charged the battery was. If the battery is charged 100% it takes a certain amount of time to turn 180 degrees and if the battery is charged only 50%, the time to turn 180 degrees increases.

Issue because of inefficient testing
Another delay issue was that when the delay function was called, the software froze. We discovered this problem only during the competition, when V.A.S.I.L.E got out of the ring by itself, and the local press commented: “V.A.S.I.L.E was shy”.
This can be exemplified in the following code sample:

/*
Going left is mechanically done by turning the left wheel backwards and the right wheel forward.
*/

void GoLeft(int delayConst=0)
{
MotorLeftBack(); //left motor spins back
MotorRightForward(); //right motor spins forward
delay(delayConst); //going left for a certain amount of time, expressed in ms
}

If the delayConstant is 1000 ms (1 second), then during that second the sensors are not read. This means that if in less than one second V.A.S.I.L.E gets at the white border, it cannot detect it. Taking into account the delay constant can also take higher values and that the sumoBot is almost in continuous movement , the chance to miss the white border is very high.

The competition
A month before the national competition, another local competition had been organized in Bucharest. This local event helped the teams which won a lot, as it gave them time to improve and test their sumoBots. Consequently, the competition level was very high and the robots were very good. Having the honor to compete with such sumoBots taught us a lot of things and gave us a lot of hints to improve our own sumoBot.

From design point of view, V.A.S.I.L.E should have had an angle blade in front. The angle blade is the most common "weapon" used in a sumobot competition, usually tilted about 45 degrees towards the back of the sumoBot. The angle blade is far better than the normal blade V.A.S.I.L.E had, because it goes with the idea of going under the opponent in order to determine it to lose adherence. This way, it is much easier to push the opponent out of the ring.

Another design aspect which could have been improved is the height of V.A.S.I.L.E. Even if the specifications of robot-sumo regarding height is unlimited, the principle of sumoBots is ”the lower, the better”.

Regarding hardware, some time should be spared for failover. There always should be a PLAN B if the components burn or crash, the battery discharges, the sumoBot doesn’t fit the requirements, something happens during a fight etc.

We have also noticed that it is allowed to have more microprocessors with different software that can be switched during the competition. This idea goes with applying different strategies considering equivalence classes of sumoBots’ characteristics.

Another lesson learned is to try to eliminate the hardware-software dependency which was previously discussed.

...see you soon
From this experience we have learned a lot of things to improve our working technique on sumoBots.

V.A.S.I.L.E will be soon improved and will compete in Cluj-Napoca in December at "BattleLab ROBOTICA" competition. It will be a first-time for Cluj-Napoca in this field and we hope it’s going to be a success.

The competition will be organized by the Technical University Electrical Engineering Faculty, having as main coordinator PhD. Eng. Septimiu Crisan. This event is an extraordinary chance to prove what we've learned from this experience and also for other students to gather their skills and build strong sumoBots to challenge V.A.S.I.L.E II.

External links:
Robo Challenge Competition
Robot-Sumo [Wikipedia]

Setting up your environment for Flash/Flex Automation

2009-03-11T21:16:00.014+02:00

Before going into details about some of the tools mentioned in the previous post, we thought it would be a good idea to start with what you need to do to get your environment ready for Flex/Flash automation. There's a lot of information out there but there isn't a place that walks you through the entire process - so we decided to write everything down and try to make it easier for other users.

Here is what you need to get started:

1. A Web Server

You will need to install and configure a web server or make sure you have access to one where you can upload your .html and .swf files. This is the server that you will direct your test scripts to as well.

We won't go into details here – the most obvious choice, if you don't already have access to one, is to install Apache.

However, if you prefer to run all your tests locally, you will need to change your Flash Player settings to allow local Flash content to connect to the internet. Here's how you do that:
This link will bring up your Flash Player Settings Manager.. Go to the “Global Security Settings”, go to “Edit Locations” and add the local .swf file that you want to test.

2. Flash Builder or another IDE of your choice

There are several ways (depending on the tools you plan to use as well) to setup your automation environment. All of them, though, require compilation of a Flex project, so you will need an environment that allows you to do that. At first, you can download the Flash Builder and use the 60 day trial. Note that if you plan to use Adobe's Automation Framework you will only be allowed to use 30 actions/test script, unless you have a FlexBuilder Pro Licence. The Framework for Flex 2 used to be available within the LiveCycle Data Services package, for which, as far as we know, you can get a free Licence by registering on the site if you only need it for development purposes. But since Flex 3, the Framework is no longer provided in LCDS.

Depending on the preferred approach and the chosen automation tools, there are several ways to start your flex/flash automation.

Let's say you want to test a Test.swf application.

Option 1 – Using Adobe's Automation Framework and an Automation tool of your choice

To automatically test your Test.swf application, you need to either have the source code for it and recompile it (probably the best approach) or load your automation libraries at run time.

Here are the instructions for both cases:

Option 1a – Recompiling Test.swf with automation support

Once you have the source code for your Test.swf, you need to recompile the Flex Project after including your automation libraries by using the include-libraries compiler option (in Flash Builder, you just have to go to Project > Properties > Flex Compiler and add them to the “Additional Compiler arguments” field).

You will have to include:

automation.swc
automation_agent.swc
automation_charts.swc (only if your application uses charts)
automation_dmv.swc (for charts or the AdvancedDataGrid classes)

and any other libraries required by your test automation tool. For example, if you want to use FunFX, you will also have to add the following libraries:

funfx-0.2.2.swc (the current FunFX automation agent)

automation_rb.swc

Option 1b – Loading your automation libraries at run time

If you don't have the source code, you will have to load your automation libraries at run time before you can test the .swf file that was compiled without automated testing support.

To do this, you need to create an new Flex project and use the SWFLoader to load your Test.swf and also add all the required libraries:

1. Create a new Flex project (let's call it Wrapper) and have the following MXML file:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
<mx:SWFLoader source="Test.swf" width="100%" height="100%"
</mx:Application>

2. Include all the libraries mentioned at Option 1a as compiler arguments.

3. Compile the project. The Wrapper.html file will then load your Test.swf application and will also load the automation libraries at run time.

4. Direct all your test scripts to Wrapper.html to access the objects in Test.swf.

Note: In the above option the name of the test application is hard-coded inside the wrapper, but there is also the option to pass the name of the application as a parameter.

For example, we have a FunFXLoader (compiled with all the required automation libraries) that we use anytime we want to test a Flex application using FunFX.

The .mxml looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
creationComplete="initVars()">
<mx:Script>
<![CDATA[
private function initVars():void{
FunFX.source=Application.application.parameters.testswf;
}
]]>
</mx:Script>
<mx:SWFLoader id="FunFX" width="100%" height="100%">
</mx:Application>

while here you can see what the index.template.html file contains.

Now, to load your Test.swf, you will have to access the following page:

http://mytestsite/FunFXLoader.html?testswf=”Test.swf”

Of course, this can be used with any .swf file as long as you copy it on your web server (relative paths can be used to specify the file location).

Option 2 – Using an ActionScript “Framework”

If you want to use an already developed ActionScript Framework - I guess if you develop one of your own you know how to use it :) - for example SeleniumFlex.as, you must refer the ActionScript file in your main MXML file, like this:

1	<mx:Script source="YourFramework.as"/>

Option 3 – Using other Automation methods/tools like Test Complete

Automation tools that don't use Adobe's Automated Testing API, like Test Complete, have other methods of exposing Flash Objects.

With TestComplete, for example, to access internal objects of Flex applications, you have to compile your Flex application with the Generate accessible SWF file option enabled and make TestComplete recognize Flash elements as MSAA objects. However, this approach only lets you test Flash elements residing on web pages that are shown in Microsoft Internet Explorer or the Microsoft WebBrowser control.

Flex/Flash Test Automation Tools

2009-03-01T21:49:00.023+02:00

For a while now, I've been involved in testing a complex media web application developed in Flex, and I got to the point where some help from a tool would have been much appreciated :). I have to admit that this was my first RIA project, so I decided to dig a little bit into it, especially regarding the options one would have in automating some of the functional tests.

Scope
I don't want to argue about the ROI of an automated GUI test suite, or about the fact that maybe it would be much more useful to automate some other types of testing like unit and performance (there are specific tools for each of these).

All the info from this post can be found on the internet, but it takes a lot of time and trouble to gather and analyze it. This post will provide a list of tools I found that support Flex Automation, hoping it will help you if you're thinking about functional testing automation for Flex based applications.

The Flash in the blackbox
The main issue with RIA Flex applications is that the Flash player is basically a runtime, which makes its objects invisible to its container (e.g. browser's html or javascript code), unless explicitly exposed from within.
I was able to identify three ways to add automation support for Flex applications:

using the Flex Automation Framework (+ExternalInterface). Adobe has developed this framework to provide a way for developing ActionScript automation-agents that facilitate the communication between the automation tools and the Flex objects. This is possible using the ExternalInterface API. I couldn't find a way of using the Automation Framework without the ExternalInterface, although it is not specified as the only option for establishing the communication. Even though the Flex SDK is open-source, the Automation Framework is not: the trial version can be used for scripts with up to 30 actions. One would have to pay 499€ (VAT not included) for the FlexBuilder Pro license in order to create larger scripts.
by developing your own framework in ActionScript and make it visible through the ExternalInterface - more info about the API can be found here.
IAccessible interface and MSAA. Not all the objects support the IAccessible interface by default; here you can find more info on how it can be added.

The Tools
Below you can find a table with the tools that could be useful. I say this because I found some tools that claim to support Flex Automation, but they are just basic macros (mouse click at a certain coordinates on the screen), i.e. iMacros from iOpus.

We plan to take a closer look at some of these tools, especially at the open-source ones but also at the ones that have a decent price. I am pretty sure that companies like IBM, Borland or HP have their own research and analysis on flex automation already available. Plus, we are not a big corporation, so we don't plan to acquire any of them in the near future :).

Here you can find some useful info on how to setup your environment and get started with automating your applications.

Stay tuned, we'll post some new info soon.

ISTQB Certification Survey Results

2009-02-21T20:15:00.017+02:00

We had a total of 81 responses to our ISTQB certification survey. The analysis below will first look at the responses provided by the 57 testers that are certified and will then show the same graphs with the answers provided by the 24 testers that are not yet certified.