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
Wednesday, April 28, 2010
Saturday, January 9, 2010
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.
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.
Wednesday, December 24, 2008
WiFi Hack ...
One day while going around the terrace I discovered that the laptop was catching somebody’s wireless connection. Alas to my surprise! I found that wireless connection so dependable and now I use it 24×7 , free The WiFi AP admin, whom I don’t know now uses WEP, a weak encryption technique, which i could bypass without much trouble.
After arpanet, the internet evolved, wires everywhere, Now its gone wireless.
Wireless/Bluetooth are fairly new technologies and the encryption algorithms behind are fairly easy to crack (WPA2 is latest though)this internet connection I found floating all around the air near me.On the terrace , and the fourth storey room.
The High Speed internet was around me, but I couldn’t get onto it/surf it.REASON: The connection was ENCRYPTED.
The laptop’s WIFI LAN card catches the singal, so the Access Point is around,We have a transmitting point.
Normally the router here on in to be referred to as the AP.My machine, Laptop and similar machines are the clients,,We’ve data flowing(incoming and out) between the Access Pt. and Router (packets).
So why can’t we just jump on the connection, just as we do with cable TV, or electricity.Well the network and its packets is encrypted.To get on the network we need to get authorized by AP, using a passkey.
Normally in ASCII but some AP’s accept Hex keys.
[So how do we crack/discover this key]Its simple, little fragments of this key are inside each packet.So we need to sit in the network range.And get us a copy of these packets. (i.e. Random data)
For that:set the wireless card into monitor mode. (Requires special drivers)And running a packet sniffer (Wireshark)
Once enough packets are gatherd, we can send them all off in one big go to the decryptor.The decryptor will juice out the useful info from it
several types of encryption standards exist for WiFi.WEP, WPA, WPA2 or WPA-PSK.As with every encryption these can be broken by one of three methods.Brute force (theoretically should work everytime but time consuming) , Dictionary(luck matters) or Rainbow Tables.
Each encryption standard has different qualities, you may say “Strengths”WEP today is by far the weakest one, but 128 bit key should help.WPA is also lame, until better length key is used.WPA2 , you may say is one generation ahead.
Measures against getting wardriven. :Use WPA,
WPA-PSK can be broken only by trying BF combination. Just ensure your passkey is something that’s NOT on the dictionary and its 512 bit.something like gr3yh4t1nd14i55om3th1ng_1′4m . . .I would love to see a dictionary with that on it.
Thats itThats the simple laymen style boiled down theory behind war-driving.
After arpanet, the internet evolved, wires everywhere, Now its gone wireless.
Wireless/Bluetooth are fairly new technologies and the encryption algorithms behind are fairly easy to crack (WPA2 is latest though)this internet connection I found floating all around the air near me.On the terrace , and the fourth storey room.
The High Speed internet was around me, but I couldn’t get onto it/surf it.REASON: The connection was ENCRYPTED.
The laptop’s WIFI LAN card catches the singal, so the Access Point is around,We have a transmitting point.
Normally the router here on in to be referred to as the AP.My machine, Laptop and similar machines are the clients,,We’ve data flowing(incoming and out) between the Access Pt. and Router (packets).
So why can’t we just jump on the connection, just as we do with cable TV, or electricity.Well the network and its packets is encrypted.To get on the network we need to get authorized by AP, using a passkey.
Normally in ASCII but some AP’s accept Hex keys.
[So how do we crack/discover this key]Its simple, little fragments of this key are inside each packet.So we need to sit in the network range.And get us a copy of these packets. (i.e. Random data)
For that:set the wireless card into monitor mode. (Requires special drivers)And running a packet sniffer (Wireshark)
Once enough packets are gatherd, we can send them all off in one big go to the decryptor.The decryptor will juice out the useful info from it
several types of encryption standards exist for WiFi.WEP, WPA, WPA2 or WPA-PSK.As with every encryption these can be broken by one of three methods.Brute force (theoretically should work everytime but time consuming) , Dictionary(luck matters) or Rainbow Tables.
Each encryption standard has different qualities, you may say “Strengths”WEP today is by far the weakest one, but 128 bit key should help.WPA is also lame, until better length key is used.WPA2 , you may say is one generation ahead.
Measures against getting wardriven. :Use WPA,
WPA-PSK can be broken only by trying BF combination. Just ensure your passkey is something that’s NOT on the dictionary and its 512 bit.something like gr3yh4t1nd14i55om3th1ng_1′4m . . .I would love to see a dictionary with that on it.
Thats itThats the simple laymen style boiled down theory behind war-driving.
Subscribe to:
Comments (Atom)