Dear reader,
This is to list the sources we have today (27th April, 2009) that could help in using www.TestersDesk.com.
The basic purpose of TestersDesk.com can be read in a minute or two, from this link.
You could read the Frequently Asked Questions here. If you have questions that are not covered in it, do write to me at my email (ap at testersdesk dot com).
As many of you know, the key features of TestersDesk.com is its Pairwise TestCase Generator that is rich in using the test coverage techniques to produce a minimal set of test combinations. Please do read about it here.
Must read - There are at least 20 different ways how the Online Toolkit can benefit Software Test Design and Test Data Generation activities (whether you are doing manual testing or using test automation tools) - They are documented here.
There are a few videos at this page. Some done by me and some by Pradeep Soundararajan (an independent test consultant and also a trainer who is known to many through his blog) here. Do watch them in a sequence when time permits.
And please stay tuned, there is more to come, help-wise or tool-wise.
Of course it is good that many users are straight on to the regular usage of the tools, and the above links are for the rest of us.
Cheers
Ashwin
Monday, April 27, 2009
Sunday, April 19, 2009
Bug reporting skills, Good testers and "I entered something and it crashed" syndrome
I have roamed around India speaking to testers from different cities. I notice common patterns and region specific patterns about how testers think and or communicate.
I know there would be a never ending argument of what are the attributes of good testers because everyone seem to have a different opinion. However, I think there exists a set of attributes that any school of thought would agree upon.
Let me discuss one such and you might have guessed it from the title. I have never seen a good tester say, "I entered something and something and it crashed". But why do they not say?
I have heard the above sentence from a lot of testers and most of them have been clueless about software testing. I shall explain to you my reasoning of the same.
Assume you are the cockroach catcher and that's what you do for a living. I hire you to catch a cockroach that I saw in my home and you are going to ask me, "Where did you see the cockroach?" and if I dont have an answer for that how helpful am I being to myself in getting the cockroach out of my home?
If I am staying in a 2 acre bungalow, your job is all the more complicated. Instead, I say, "I last spotted a couple in the kitchen and the bathroom", I am helping myself and you.
Look into your organization's bug tracking system and you'd find testers reporting problem like, "I entered some input and application crashed". Now, that's like reporting, there is a cockroach in this country find it.
Unless you are specific as a tester, how do you suppose a developer to fix the problem. Testers are finding a bug to get it resolved or help the management take a better decision. Reporting it in such a way that it is of no help to anyone is an extreme bad job.
Why would a developer ever want to respect such a tester? Why would the developer community want to respect such community of testers?
So, if you have been doing it and want to be better, here is a way:
You may want to look into what the Quantified String Generator can do to solve this problem of yours or any other toolkit at Common Test Data Generator in Testers Desk
Here is an output:
Now, whether the developer or specification talks about Boundary or not, you might be able to find it out using this Quantified String Generator. For instance, let me assume you copy paste the above on to your input field and it accepts 983 characters and it then appears to crash as you hit the submit button.
Now, investigating this bug is an interesting challenge: Typical bad testers would directly report the problem however here is a pattern that I observe in most of the good testers I have met - They would want to know from which number does this crash occur.
Is it 983 characters or is it a number below that?
So, we go for a smaller sample than 983 characters: And here is a sample output from Quantified String Generator:
Tip: Did you notice the beauty that you dont need to count the characters and it counts itself?
That's 300 characters.
Now, in case we see that it does not crash for 300 characters, we have learned that it is somewhere between 300 and 983. And as we zero down, we might find that great number from which the application starts crashing.
Imagine you reporting a problem like, "I used the Quantified String Generator and discovered that 432 characters ( and thereafter ) appears to crash the application" and ask a striking question to the developers, "Why would it crash at 432?", "What is so magical about 432?"
Note: If you'd want to see that in demonstration, you may consider watching this video.
That's when the developer would start respecting a tester for his skills of bug reporting, bug investigation and communication.
I leave the choice to you. You need to do lots of things and change the way you do things to become a good testers and you just need to do whatever you are doing right now to be a bad tester.
I know there would be a never ending argument of what are the attributes of good testers because everyone seem to have a different opinion. However, I think there exists a set of attributes that any school of thought would agree upon.
Let me discuss one such and you might have guessed it from the title. I have never seen a good tester say, "I entered something and something and it crashed". But why do they not say?
I have heard the above sentence from a lot of testers and most of them have been clueless about software testing. I shall explain to you my reasoning of the same.
Assume you are the cockroach catcher and that's what you do for a living. I hire you to catch a cockroach that I saw in my home and you are going to ask me, "Where did you see the cockroach?" and if I dont have an answer for that how helpful am I being to myself in getting the cockroach out of my home?
If I am staying in a 2 acre bungalow, your job is all the more complicated. Instead, I say, "I last spotted a couple in the kitchen and the bathroom", I am helping myself and you.
Look into your organization's bug tracking system and you'd find testers reporting problem like, "I entered some input and application crashed". Now, that's like reporting, there is a cockroach in this country find it.
Unless you are specific as a tester, how do you suppose a developer to fix the problem. Testers are finding a bug to get it resolved or help the management take a better decision. Reporting it in such a way that it is of no help to anyone is an extreme bad job.
Why would a developer ever want to respect such a tester? Why would the developer community want to respect such community of testers?
So, if you have been doing it and want to be better, here is a way:
You may want to look into what the Quantified String Generator can do to solve this problem of yours or any other toolkit at Common Test Data Generator in Testers Desk
Here is an output:
2^4^6^8^11^14^17^20^23^26^29^32^35^38^41^44^47^50^53^56^59^62^65^68^71^74^77^80^83^86^89^92^95^98^102^106^110^114^118^122^126^130^134^138^142^146^150^154^158^162^166^170^174^178^182^186^190^194^198^202^206^210^214^218^222^226^230^234^238^242^246^250^254^258^262^266^270^274^278^282^286^290^294^298^302^306^310^314^318^322^326^330^334^338^342^346^350^354^358^362^366^370^374^378^382^386^390^394^398^402^406^410^414^418^422^426^430^434^438^442^446^450^454^458^462^466^470^474^478^482^486^490^494^498^502^506^510^514^518^522^526^530^534^538^542^546^550^554^558^562^566^570^574^578^582^586^590^594^598^602^606^610^614^618^622^626^630^634^638^642^646^650^654^658^662^666^670^674^678^682^686^690^694^698^702^706^710^714^718^722^726^730^734^738^742^746^750^754^758^762^766^770^774^778^782^786^790^794^798^802^806^810^814^818^822^826^830^834^838^842^846^850^854^858^862^866^870^874^878^882^886^890^894^898^902^906^910^914^918^922^926^930^934^938^942^946^950^954^958^962^966^970^974^978^982^9
Now, whether the developer or specification talks about Boundary or not, you might be able to find it out using this Quantified String Generator. For instance, let me assume you copy paste the above on to your input field and it accepts 983 characters and it then appears to crash as you hit the submit button.
Now, investigating this bug is an interesting challenge: Typical bad testers would directly report the problem however here is a pattern that I observe in most of the good testers I have met - They would want to know from which number does this crash occur.
Is it 983 characters or is it a number below that?
So, we go for a smaller sample than 983 characters: And here is a sample output from Quantified String Generator:
2^4^6^8^11^14^17^20^23^26^29^32^35^38^41^44^47^50^53^56^59^62^65^68^71^74^77^80^83^86^89^92^95^98^102^106^110^114^118^122^126^130^134^138^142^146^150^154^158^162^166^170^174^178^182^186^190^194^198^202^206^210^214^218^222^226^230^234^238^242^246^250^254^258^262^266^270^274^278^282^286^290^294^298^30
Tip: Did you notice the beauty that you dont need to count the characters and it counts itself?
That's 300 characters.
Now, in case we see that it does not crash for 300 characters, we have learned that it is somewhere between 300 and 983. And as we zero down, we might find that great number from which the application starts crashing.
Imagine you reporting a problem like, "I used the Quantified String Generator and discovered that 432 characters ( and thereafter ) appears to crash the application" and ask a striking question to the developers, "Why would it crash at 432?", "What is so magical about 432?"
Note: If you'd want to see that in demonstration, you may consider watching this video.
That's when the developer would start respecting a tester for his skills of bug reporting, bug investigation and communication.
I leave the choice to you. You need to do lots of things and change the way you do things to become a good testers and you just need to do whatever you are doing right now to be a bad tester.
Exploratory Testing can be justified when you explore what not to do by hand
I was reading this post titled "Convince my boss to let me do exploratory testing", while most of what is said in it makes direct sense, I want to add a small point through this post.
Let us say, a tester has to test a text field with the below cases:
1. It has to be tested with multiple languages like English, Hebrew, Arabic, Kannada and Devanagiri.
2. It has an upper limit for its length, say 40 characters, and the tester wants to prepare strings with 40 characters and 41 characters (and also need to know, if a string gets truncated, where it got truncated).
Naturally the tester may ask for a lot of time to prepare the inputs that drive these tests.
It could be a tester who does everything manually, or a tech-savvy tester who want to develop scripts to accomplish the same, it takes time; and I consider that as "non testing time".
So, there is a desperate need for a tool that can aid the tester to do that.
Today, http://www.testersdesk.com/ has a toolkit named "Common Test Data Generators" which help them on that aspect. It is free for the entire testing community.
As you can see, we named it as "common" test data generators instead of hyping the simple things it does.
No, this post is not about TestersDesk.com, because it does a lot more than what is written here.
Exploratory Testing can be justified when you explore what not to do; i.e., the right ways of saving (or escaping from) some time needed in scripted testing.
And of course, the mixing proportions of testing time have to rightly balance scripted and exploratory testing, and there is no "this" or "that" type of testing, by itself, that can reveal all the defects.
Enjoying and respecting the fact that we are human beings,
Ashwin.
Monday, April 13, 2009
Exploring TestersDesk.com - Pradeep Soundararajan
In this video, Pradeep Soundararajan shows a few ways how the free Online Community Edition of TestersDesk.com could be useful in Software Functionality Testing activities.
Monday, April 6, 2009
From the testers, For the testers, By the testers
Can you imagine a carpenter building a tool for a mason? No, you cant because the carpenter might have no clue about the problem that a mason faces. So, if someone has to build a tool for a mason it has to be another mason who has faced the pain points of being a mason.
How different is software testing?
Ah! So, you need someone who understands your pain points as a tester to be able to build a product that can be of help to you in solving those problems.
Welcome to Testers Desk!
Testers Desk is a plethora of tools for a tester who can use the tools to various contexts and to solve various kinds of problems. I believe that how we use a tool depends on how creative we are. Haven't you used the back of a spoon to unscrew when a screw driver was not available? I did and I have seen many other people using many different tools to solve many different problems.
However, you might observe that a screw driver is specifically built to solve the purpose of putting the screw or taking it out from its slot. Similarly, the purpose of Testers Desk is to help testers to solve the basic problems of test designing and generating test data for testing.
Hey, but what about the title?
Yeah, this product was conceptualized by Ashwin Palaparthi, a tester and an ex Vice President of Applabs and then he hired a set of testers to develop it. It is inspiring to note that Ashwin collaborated with mathematicians to arrive at this scientific product.
Based on my face to face interactions with him, I think he has been breathing Testers Desk over the last two years and he'd continue to breath that way. I also think he is a crazy about serving the community with this product because he has pumped all his savings on it. Why isn't Ashwin thinking like those tool vendors who make huge profits with shoddy tools? That's about serving the community, right?
Now here is a test for you: Testing a typical registration page is what many testers of web application do and yet miss out potential problems. Click on this link and use Testers Desk as your test design bed and find bugs.
You may post them as comments and or as a blog post in your own blog by linking to this post. You have the freedom.
How many tests can you come out with using TestersDesk for the registration page?
Take a look at some sample tests I came out with using Testers Desk for that registration page:
E-mail ids:
Name:
ALEJANDRO, JESS
ALIBERTI, MALCOM
ALTERMATT, THU
ANGELOTTI, STAR
ARMSTONG, GRAIG
BADGER, CHARLINE
BEACHAM, KACI
BEDDOE, CELSA
BESEAU, JOSPEH
BILLINGSLY, REID
BOBSIN, RUSTY
BONAR, JAMAAL
BONSON, REUBEN
BUFFUM, MING
CAMPAGNINI, ALBERTO
CASKA, KARENA
CIGANEK, AI
COBBIN, NGUYET
COCKER, MELVA
COLASUONNO, SALVATORE
COLLINI, ANDREA
DALZEN, CHARLENA
DELEPPO, LARAE
DELORIA, GLENN
DIPIRRO, EMILIO
DOLIVEIRA, WILLIAM
ERSERY, BRIAN
ESCHENBURG, MALIKA
EYSTER, ODELL
FEAGINS, EUGENE
FLANNIGAN, VINCE
FLEAK, CONSUELA
GALLAHER, CHARLES
GAMM, MAKEDA
GATLING, ALICIA
GEISEN, ROSAMARIA
HARDISON, HOMER
HARWELL, CHANTAY
HIGBY, WALKER
HOFFPAUIR, LAWERENCE
HOGAN, AMEE
HUELSE, ELDEN
HUMMONS, ELVINA
Mobile Phone Numbers:
+118845112345
+712845112345
+711845112345
+216845112345
+118845112345
+015845112345
+614845112345
+815845112345
+514845112345
+213845112345
+213845112345
+518845112345
+013845112345
+512845112345
+518845112345
+610845112345
+719845112345
+512845112345
+218845112345
+910845112345
+017845112345
+011845112345
+611845112345
+617845112345
+718845112345
+617845112345
+315845112345
+112845112345
+218845112345
+016845112345
+319845112345
+415845112345
+313845112345
Alpha Numeric Values for other fields:
A3A5A7A9A12A15A18A2
1A24A27A30A33A36A39
A42A45A48A51A54A57A
60A63A66A69A72A75A7
A81A84A87A90A93A96A
Experience & Percentage fields:
Experience,Percentage
-1,49
-1,50
-1,51
-1,75
-1,99
-1,100
-1,101
0,49
0,50
0,51
0,75
0,99
0,100
0,101
1,49
1,50
1,51
1,75
1,99
1,100
1,101
35,49
35,50
35,51
35,75
35,99
35,100
35,101
69,49
69,50
69,51
69,75
69,99
69,100
69,101
70,49
70,50
70,51
70,75
70,99
70,100
70,101
71,49
71,50
71,51
71,75
71,99
71,100
71,101
How much time do you think I took to do all this? Less than 7 minutes. Hey, wait you want me to be more specific, that is about 6 minutes 14 seconds ( if my stop watch doesnt have bugs).
So, show your manager you are smart before someone else in your team does that. Let us know about your story and the tests you choose to run for various kinds of products and you stand a chance to win a cool goodies from Testers Desk.
Happy Testing!
How different is software testing?
Ah! So, you need someone who understands your pain points as a tester to be able to build a product that can be of help to you in solving those problems.
Welcome to Testers Desk!
Testers Desk is a plethora of tools for a tester who can use the tools to various contexts and to solve various kinds of problems. I believe that how we use a tool depends on how creative we are. Haven't you used the back of a spoon to unscrew when a screw driver was not available? I did and I have seen many other people using many different tools to solve many different problems.
However, you might observe that a screw driver is specifically built to solve the purpose of putting the screw or taking it out from its slot. Similarly, the purpose of Testers Desk is to help testers to solve the basic problems of test designing and generating test data for testing.
Hey, but what about the title?
Yeah, this product was conceptualized by Ashwin Palaparthi, a tester and an ex Vice President of Applabs and then he hired a set of testers to develop it. It is inspiring to note that Ashwin collaborated with mathematicians to arrive at this scientific product.
Based on my face to face interactions with him, I think he has been breathing Testers Desk over the last two years and he'd continue to breath that way. I also think he is a crazy about serving the community with this product because he has pumped all his savings on it. Why isn't Ashwin thinking like those tool vendors who make huge profits with shoddy tools? That's about serving the community, right?
Now here is a test for you: Testing a typical registration page is what many testers of web application do and yet miss out potential problems. Click on this link and use Testers Desk as your test design bed and find bugs.
You may post them as comments and or as a blog post in your own blog by linking to this post. You have the freedom.
How many tests can you come out with using TestersDesk for the registration page?
Take a look at some sample tests I came out with using Testers Desk for that registration page:
E-mail ids:
| FY@xX.com.tw |
| Oc@n9.com |
| Zc@NR.net |
| JI@TE.org |
| hU@ZQ.biz |
| 1A@RY.us |
| 5f@PH.cn |
| Wr@sj.com.cn |
| Gf@Nf.net.cn |
| 61@NA.org.cn |
| kU@5h.info |
| l3@I0.co.uk |
| GA@H9.org.uk |
| zO@Az.tv |
| Mc@V5.ws |
| eU@C6.ca |
| wG@t3.eu |
| KP@OS.cc |
| TJ@Qs.jp |
Name:
ALEJANDRO, JESS
ALIBERTI, MALCOM
ALTERMATT, THU
ANGELOTTI, STAR
ARMSTONG, GRAIG
BADGER, CHARLINE
BEACHAM, KACI
BEDDOE, CELSA
BESEAU, JOSPEH
BILLINGSLY, REID
BOBSIN, RUSTY
BONAR, JAMAAL
BONSON, REUBEN
BUFFUM, MING
CAMPAGNINI, ALBERTO
CASKA, KARENA
CIGANEK, AI
COBBIN, NGUYET
COCKER, MELVA
COLASUONNO, SALVATORE
COLLINI, ANDREA
DALZEN, CHARLENA
DELEPPO, LARAE
DELORIA, GLENN
DIPIRRO, EMILIO
DOLIVEIRA, WILLIAM
ERSERY, BRIAN
ESCHENBURG, MALIKA
EYSTER, ODELL
FEAGINS, EUGENE
FLANNIGAN, VINCE
FLEAK, CONSUELA
GALLAHER, CHARLES
GAMM, MAKEDA
GATLING, ALICIA
GEISEN, ROSAMARIA
HARDISON, HOMER
HARWELL, CHANTAY
HIGBY, WALKER
HOFFPAUIR, LAWERENCE
HOGAN, AMEE
HUELSE, ELDEN
HUMMONS, ELVINA
Mobile Phone Numbers:
+118845112345
+712845112345
+711845112345
+216845112345
+118845112345
+015845112345
+614845112345
+815845112345
+514845112345
+213845112345
+213845112345
+518845112345
+013845112345
+512845112345
+518845112345
+610845112345
+719845112345
+512845112345
+218845112345
+910845112345
+017845112345
+011845112345
+611845112345
+617845112345
+718845112345
+617845112345
+315845112345
+112845112345
+218845112345
+016845112345
+319845112345
+415845112345
+313845112345
Alpha Numeric Values for other fields:
A3A5A7A9A12A15A18A2
1A24A27A30A33A36A39
A42A45A48A51A54A57A
60A63A66A69A72A75A7
A81A84A87A90A93A96A
Experience & Percentage fields:
Experience,Percentage
-1,49
-1,50
-1,51
-1,75
-1,99
-1,100
-1,101
0,49
0,50
0,51
0,75
0,99
0,100
0,101
1,49
1,50
1,51
1,75
1,99
1,100
1,101
35,49
35,50
35,51
35,75
35,99
35,100
35,101
69,49
69,50
69,51
69,75
69,99
69,100
69,101
70,49
70,50
70,51
70,75
70,99
70,100
70,101
71,49
71,50
71,51
71,75
71,99
71,100
71,101
How much time do you think I took to do all this? Less than 7 minutes. Hey, wait you want me to be more specific, that is about 6 minutes 14 seconds ( if my stop watch doesnt have bugs).
So, show your manager you are smart before someone else in your team does that. Let us know about your story and the tests you choose to run for various kinds of products and you stand a chance to win a cool goodies from Testers Desk.
Happy Testing!
Subscribe to:
Posts (Atom)
Posts
