For getting a testing project/job/contract we have not to forget that, to get it, the most important thing is not the testing skill.

Most of the time people interviewing you are not testers or not testers with the same ideas like you about testing.

The things that will matter  more can be:

• Reputation, this will help you getting the project without being asked too many questions related to your skills
• Ability to talk and convince, especially enthusiasm or maybe seriousness that can click your probable client’s interest.
• Being cheap, this is to consider, even if is not pleasant.  This is the main criteria this days for a lot of companies.
• Some hiring people have some … weirdness… a rule that they use in their own life. They like people that: have family, play golf, go hunting, are over-organized or whatever… This is just how they take the decisions.
• General set of skills, most companies use check-box lists and then select based on  that…
• Being non-aggressive, not causing problems and conflicts at work

And there is a huge list of items that come before the actual testing skills, and this should not be frustrating as it its an unwritten rule in every area.

Participating in EWT again made me re-think  of impossible problems. I don’t think a tester should spend too much time figuring out what a functionality should be or trying to guess the expected behavior. A tester should though recognize an impossible problem or to clarify the requirements.

First of all we need to determine the oracle, the set of references that tell us that something is a bug or not. And for this we need to clarify the requirements for things that are documented and for things that are not documented.

Popularity: 2% [?]

What is actually metrics? Is basically a form of control and monitoring. You need some results to trick the employees somehow, give the sensation of some sort of advancement.  As I stated before I don’t believe too much in this.

In a lot of companies the main objective for a tester is to become “leeead” (long “e”), because the work seems super relative to everyone. Of course this sole motivation makes an annoying environment eventually  and the lack of interest will eventually kick in.

Sometimes fake objectives are drawn to look nice, which of course are never followed.

Since automation looks cool in name the tendency is to fill 100 % with tasks related to this. Its more easier of course to measure it. No one cares if the tests are made shallow covering a small basic scenario only. Till of course major failures, complains from customers etc…

But I have to add this document as a start point to use metrics http://www.kaner.com/pdfs/metrics2004.pdf

Popularity: 3% [?]

Since this is a hot subject on the software-testing mailing list I though I put some lines about it.
First of all I myself have little clue on how a good metric for testing should be. I know this causes a lot of problems in testing.
I am not saying not using a metric at all should be the solution because its impossible in an organization. There is the need for a formal one at least.
But let’s not focus extremely too much on it because let’s face it:

• Promotions are established well in advanced without any relation to real productivity, possible even before hiring
• Raises are given to all the employees usually and is percentage of salary most of the time
• Firing people is mostly done in cases of financial troubles

And there are many other situations when using metrics for employee evaluation that are completely un- useful.

Usually the general view is the one deciding and for the most part is the best. Enforcing metrics will increase the chances for sabotage among employees or give false results.

I don’t have a valuable solution for this but it would help differentiating testing metrics to development metrics. Because:

• Testing is considered a simpler activity for a specific functionality than developing it, but testing has to deal not only with a task-done type of thing, but larger areas, interactions, thing that shouldn’t be there. Is basically an infinite process
• Testing is more closer to marketing and arts or puzzle solving than computer science
• Testing is little bit trying to break the toy than building it up-so again common metric is not relevant

Things that a tester  does in addition to testing can be measured: installing an environment, reporting, presence at work. But is not relevant to the main job itself.

Also what should not be done (!!!) is rewarding testers by completely absurd criterias like:

• Times per week going to gym
• Playing guitar lessons
• Speaking loud and much
• Sabotaging skills
• Blaming skills to pay
• More bills
• etc

Although those above have some relevance it should not be considered a major factor because this means that testing in that organization is not taken seriously and doesn’t have a real chance to improve.

Metrics are indeed hard but if you use a group of sub-metrics and a good impartial general view you can tell what tester is more productive than the rest after some period.

It’s more like evaluating a person who is a better friend: is it the one who goes with you the most of the time to beer?  Could be – but is hardly a good criteria; it could be a  sub-metric though that can influence it.

Popularity: 4% [?]

If you like this trick you can use it in your own page by placing the following code in your body section:

This is very known simple javascript usage. But it depends on imagination if you can create something nice.

Similarly we have the view testing. Its not “click click” only, because you can reduce by this principle every activity to a “manual” operation.

Note: If you accessed directly http://www.testalways.com you will not see the first part of this post so try to click on the title of the post, see if anything changes.

Popularity: 8% [?]

Popularity: 7% [?]

Few days ago I twitted about uTest that the platform may not be so reliable if you think to have a steady income from it. The people there are claiming that are top incomes of 4000-5000 dolars /month for the top earners. I have to admit that I stated only my opinion because I care a little for reliable info when comes to things like that.

I was surprise to be contacted from the people there after my tweet and asked, advised and encouraged to continue with uTest, or to participate in bug battle. Well to be honest I don’t have so much time but I want to send a sample bug for the competition. Is not a major issue but I used the excuse to play with perlclip.

The uTest promo looks like this:

What's the best way for new uTesters to stand out from the crowd and get invited to paid testing projects? By participating in the uTest Bug Battle!

Our quarterly Bug Battle competition is open to all members of the uTest global community. We're already five days into the current contest – which is comparing the top 4 job sites – but there are still five days left. So why should you join in the fun?

   1. Money: There's nearly $4,000 up for grabs in this Bug Battle. Rewards are spread out across multiple categories, including best bug, best mobile bug, best usability feedback, top tester, top new tester and more. See a list of winners from our 2nd quarter Bug Battle.
   2. Power: Many of the top testers in our community got "discovered" by participating in Bug Battle competitions. After strutting their stuff and catching our attention, these testers are now regularly invited to high-paying projects for Google, Microsoft, AOL and others.
   3. Respect: The results of our Bug Battles have been covered by TechCrunch, Mashable, Wired, FastCompany, USA Today and thousands of other tech blogs. Winners get listed in our blog, in the tester forums and in our Bug Battle Report, which is downloaded by thousands of readers.

I made a video for my observation (It’s not a bug per-se)

This should be taken as a fun example to play when starting testing something and there is a lack of ideas.

Popularity: 6% [?]

010010010010000001100100011010010110010001101110001001110111010000100

00001101000011000010110010000100000011000010110111001111001001000000

110100101100100011001010110000100100000011001100110111101110010001000

0001110100011010000110010100100000011011010110111101101101011001010110

1110011101000010000001100110011011110111001000100000011000010110111001

1011110111010001101000011001010111001000100000011000100110110001101111

0110011100100000011100000110111101110011011101000010110000100000011000

1001110101011101000010000001110011011000010111011100100000001000000110

11110110111001100101001000000110001001101001011011100110000101110010011

11001001000000110010101101110011000110111001001111001011100000111010001

1010010110111101101110001000000110111101101110001000000110000100100000

0111011101100101011000100010000001110000011000010110011101100101001000

0001100001011011100110010000100000011001000110010101100011011010010110

0100011001010110010000100000011101000110111100100000011100000110111101

1100110111010000100000011011000110100101101011011001010010000001110100

011010000110100101110011001011100000110100001010000011010000101001010

0000110110001100101011000010111001101100101001000000110001101101111011

01101011011010110010101101110011101000010000001110111011010010111010001

101000001000000111010001101000011001010010000001110011011011110110110

0011101010111010001101001011011110110111000101110

Popularity: 17% [?]

I couldn’t take out of my mind the Abe Heward’s blog post where he describes his final interview with a CEO. The culminate point  in it was this question:

“So, tell me: How are you going to guarantee the accuracy and integrity of the data?”

Its not important if the question makes sense or not, although we see the point of it. Its the perspective and the implications that it has.

I got my jobs and clients before with just a formal talk and I thank them for that. I also hope I was worth it. Sometimes was a cheap logical test or something similar.

When you have an interview for a testing related job and sense or receive a lame impression, usually after a very boring, typical, non-relevant question, you get unmotivated and wish to get over with.

If you get along with this and respond automatically with typical answers, with unproven statements, with general and boring arguments, at the end of the interview you feel dirty.

So it goes something like this:

1)You receive many stupid interview questions that you have to answer

2)You develop stupid answers, boring, unproved,general and non-specific

3)You develop an automatism with this answers

And the result:

1)You get bored and transmit the same sensation to your interviewer who maybe wanted initially to learn from you too

2)You get altered in your ability to convince a person

3)You will not be able to answer a more interesting and more practical question.

The hiring person can have different roles so take that in consideration:

1)CEO or owner will want always that his products are reliable, secure, usable, with good performance and are fulfilling the customer expectations and even exceeds it. He will take note of the technical persons that interviewed you before, but usually he wants someone that guarantees him everything is OK. Simple to say hard to do though, even for people with lot of experience.

2)A CEO or owner of an outsourcing company really doesn’t care so much what you do as long as he can take the money from his client and pay you less and this process is long enough. He will try to convince his client that you are the best and convince you that you are the worst.

His criteria will be usually bad.

3) Simple manager who will ask you questions unrelated or poorly related to your job. In this case its just like a roulette. Other skills may be important for this situations.

Some interviewers will be very sure that they know what has to be known and if you take another path it will be hard to be on the same page with them; especially if they do some checkbox checks.

Experience helps to visualize a similar problem in the past  and might help answering a related question.

The hardest is to respond to typical ones without getting bored.

Some will accept usual responses and some will accept innovative answers.

Practice  helps and maybe you should use some interviews you don’t care too much for this purpose.

Here are some other tricky and unusual questions to get a view http://blog.seattleinterviewcoach.com/2009/02/140-google-interview-questions.html.

Popularity: 10% [?]

Write down digits 1 to 9, in order. Add between them math operators (you decide which and where) to get an expression equal with  1234, 2345, 3456, 4567, 5678, 6789, 7890. (for each number is a separate  expression)

You can use ANY math operators.

Example: 1^2+3*4+56+7*8-9=1+12+56+56-9=116 In this case using digits 1 to 9 the result is 116.

The solutions for this exercise, even partial ones can be posted in the comments.

Popularity: 15% [?]

Testers tend to think very quickly that if they use some tool or some script then quickly  are doing test automation.  The term “test automation” is actually a fuzzy one but it appears to be defined like this “Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions” (Wikipedia).

I will not go in this post why there is the approach to split testers in only two categories defined as manual testers and automation engineers, which are both wrong  and this type of simplifications give testing a bad name.

If I use a tool, a scripting language to automate the install process or the configure process its not test automation! Its just a process to help me reduce the time spend and I could do zero tests in meantime. I wouldn’t consider that test automation, but I would include it though in my testing process.

Any tool or script that helps me do my job as a tester is welcomed and it should be mainly the tester’s decision for the usage of it. Its should not be called automated or non automated.

Part of the productivity of a tester is his freedom, motivation, respect. That’s why in teams with large number of “testers” motivation is low, respect is low, freedom is low and eventually results are limited. The “wise” managers of this large teams adopt different techniques and have the sensation that are superior and their testers aren’t capable to understand. If they would had been in the lower level of the team model they themselves have created and had to accept the same rules, they will be the same! The advantage and experience will fade under the lack of motivation, low income helping with that. They try to grow competition within teams and give small bonuses that work for a while but eventually go to cause frustration or just not carrying.

Its not good to split activities of a tester in simple views unless of course you are not well intended. Great things are though created from simple items put together in an inspired way, similar to great testing.

Popularity: 11% [?]