Affirmative Developers and Bearish Testers

Developers tend to be optimistic folks, while testers tend to be more pessimistic.

* Developers are creators, with a natural optimism about making new things and solving difficult problems.
* Testers are fault finders, with a necessary skepticism and doubt.
* If developers are the yin, testers are the yang.

I believe this is a good thing, a sort of checks-and-balances tension that makes for better software.

But it does lead to some interesting contrasts...


Optimistic Developer: The glass is half full

Pessimistic Tester: The glass is twice as big as required


Optimistic Developer: This code hasn't yet been tested. It's not known if it has any bugs

Pessimistic Tester: This code hasn't yet been tested. It's not known if it actually works


Optimistic Developer: We are 90% done

Pessimistic Tester: We don't know when we'll be done, if ever


Optimistic Developer: We will refactor the code to make it better

Pessimistic Tester: They are throwing out the working code and replacing it with an unknown quantity


Optimistic Developer: I only changed one line of code

Pessimistic Tester: The entire system must be retested


Optimistic Developer: The code is the design

Pessimistic Tester: There is no design


Optimistic Developer: We'll fix those bugs later, when we have time

Pessimistic Tester: We never have enough time to fix the bugs


Optimistic Developer: This build is feature complete

Pessimistic Tester: The features exist; some are completely broken


Optimistic Developer: Anything is possible, given enough time

Pessimistic Tester: Everything has flaws, and given enough time I can prove it


Optimistic Developer: Of course it will work

Pessimistic Tester: It might work, but probably won't


Optimistic Developer: One last bug fix, and we can ship tomorrow

Pessimistic Tester: Fixing this one bug will likely lead to two more


Optimistic Developer: Stop finding bugs, or we'll never be done

Pessimistic Tester: Stop creating bugs, so I can find them all


Optimistic Developer: There's no need for more tests

Pessimistic Tester: Let's just run a few more tests to be sure


Optimistic Developer: There is no I in TEAM

Pessimistic Tester: We can't spell BUGS without U


Optimistic Developer: That's an "undocumented feature"

Pessimistic Tester: That's a bug


Optimistic Developer: I like to build things

Pessimistic Tester: I like to break things


Optimistic Developer: Sure, we can use the Beta version of this component in Production

Pessimistic Tester: We should wait until version 2.1


Optimistic Developer: Willing to bet that there are no more bugs

Pessimistic Tester: Willing to take that bet


Optimistic Developer: Let's slip these changes in now, because I'm starting my vacation tomorrow

Pessimistic Tester: Let's not


Optimistic Developer: That will never happen in Production

Pessimistic Tester: Never is a long time


Optimistic Developer: It works on my machine

Pessimistic Tester: Perhaps your machine is the only one where it works?


Optimistic Developer: I'm a Realist

Pessimistic Tester: I'm a Realist

Crowd vs Normal Testing

“There are a billion people in China. It’s not easy to be an individual in a crowd of more than a billion people. Think of it. More than a billion people.That means even if you’re a one-in-a-million type of guy, there are still a thousand guys exactly like you.” That means that when we have enough people, we have a thousand special people. These people can also look at a application from a different side and have an opinion about it. They can test the application! Wouldn’t this make an applications better??

Crowdtesting depends on a crowd that is composed out of a large group of diversified people. This might be the key aspect of crowdtesting; to create a crowd! A crowd should consist out of test experts, users, specialty testers, novices and everybody else that wants to test. A small group of 10 people with the same background gives crowdtesting no added value. But they should not only be of various test knowledge, but preferably also from different backgrounds and even different languages. The more different views there are on an application, the more different views that can help get a better product.

The most difficult task of crowdtesting is determining a good enough crowd.
But how can you determine what is the most beneficial structure of the crowd it when it is needed? That is the most difficult task of crowdtesting, determining a good enough crowd. The use of the crowd itself is decided by the client/customer that owns the work that needs to be tested. And beside these needed people there are people that can join voluntarily and most of these people will do this in addition to their daily work.

We can say Crowdtesting acts like complementary to ‘normal’ testing.
The crowd tests the software and can use the application further or even make others enthusiastic about it. But crowdtesting complements ‘normal’ or traditional testing. Normal test runs are still needed in previous test levels. Crowdtesting can use the creativity and diversity of various testers around the world and not just a small user group to accept the software.