Selective Retention while Testing

We have so many organs in our body and if we are lucky enough then we have these receptive organs with full of functionality. So, in every moment we are having lots of inputs through these. But, as we have the most obscure yet most creative thing in out head that is 'Brain', we do always try to conserve those inputs which seem important to us and leave the others. Trust me, we are continuously doing it in every moment either consciously or unconsciously. So, this is what the topic is all about. This is called Selective Retention.

Formal definition of Selective Retention from Wikipedia:

"Selective retention, in relating to the mind, is the process when people more accurately remember messages that are closer to their interests, values and beliefs, than those that are in contrast with their values and beliefs, selecting what to keep in the memory, narrowing the informational flow."

According to an article from Illinois State University, Selective Retention is the personal filtering of what we see and hear so as to suit our own needs. ISU also says, Much of this process is psychological and often unconscious.

Well, now some questions may come to your mind like "What is the uses of it while testing?",  "Testing should cover every inputs in all dimensions, so are you kidding about testing?". For those who do not agree with me, please be with me for the rest of the post. I will try to explain my thoughts regarding this. If you will not agree after completing the post, then i will definitely say that i am a failure to justify my reasoning. But, i wont say that 'Selective Retention is not important'.

Now, come to the core area of our expertise that is testing. While testing, actually the term should be 'Exploratory Testing', you are the king of the domain. You can traverse anywhere you want and you can do and see anything you want to. So, one thing about Exploratory Testing is that you have no boundary condition. So, should we explore all the things? 
Theoretically, we should. But, we are not living in the world without limitations. Time and cost are the main limitations we are living with. So, we need to traverse and explore the domain with  a mindset that the important things should be completed effectively. Those who believe in Exploratory Testing will definitely agree with me in this point. So, here while testing we do always accept the information what is needed and try to retain them in our mindset. These practices become a habit while you are growing up as a tester. So, when you have grown up enough, there are always some selective retention in your way of testing unconsciously. It is not bad and it should happen because you are the king of your product and you need to act fast and spontaneously. So, if this is not unconscious, it can never be such fast as it should be.

This is all about the Selective Retention while Testing. So, are you guys are with me? I will appreciate your opinions, thoughts and whatever you want to say about it. 

Thank You !!!

Acknowledgement: 1.  http://en.wikipedia.org/wiki/Selective_retention
                              2.  http://www.citeman.com/696-selective-attention-distortion-and-retention.html

Load Testing of Database Query with Jmeter

Most of people who are involved in the testing activities have some ideas about Jmeter. JMeter is a popular open source tool for load testing, with many useful modeling features such as thread group, timer, and HTTP sampler elements. Interesting thing is that along with the usual load testing of a web application or a web server, Jmeter has the feature to test the load of the database. In this post i have tried to give a step-by-step procedure to test a simple database queries with Jmeter. I have a plan to make several blog posts to cover the important load testing scenarios of database. Here, i have done the load test for Microsoft SQL Server 2008. I have used the jTDS Driver (from net.sourceforge.jtds.jdbc.Driver class) to integrate the Jmeter with SQL server. You can test for the other databases (Oracle, MsSql, PGSQL ) also.

Required Software:

•  Jmeter:  http://jmeter.apache.org
•  Microsoft SQL Server (jTDS Driver): http://sourceforge.net/projects/jtds/files/

Steps to follow:

Step 1: Adding Thread Group Control

• Thread Group allows to run script with n^th no. of users with defined ramp-up period and also the scheduling of execution.
•  Right click on the Test Plan and add the Thread Group control.

                                                   Figure 1: Adding Thread Group Control

         

                                              Figure 2: Adding Thread Group Control

Step 2: Adding JDBC Connection Configuration control

•   Used to configure the database i.e. Oracle, MS SQL Server etc.
• Add JDBC Connection Configuration control to the Test Plan.

Database Connection Configuration

•         Database URL:  jdbc:jtds:sqlserver:// [server name or ip] / [db name]

•         JDBC Driver Class: net.sourceforge.jtds.jdbc.Driver

•         Username: Username of the database (e.g. Username: scott)

•         Password: Password of the user (e.g. Password: tiger)

Important:

Add the following Jars in JMeter Installation directory (i.e. D:\jakarta-jmeter-2.3.1\lib)

·         jtds-1.2.5.jar

          

                                         Figure 3: Adding JDBC Connection Configuration control

Step 3:  Adding JDBC Request Control

•   JDBC Request control allows to run a SQL query, procedure etc.
• Add the JDBC Request control below the Thread Group.

                                    Figure 4: Adding JDBC Request Control


In my db, there is a single table ("Student") which contains only two columns(id, name) and this table has only 2 rows. You can test for the 'Insert', 'Update' and 'Delete' commands also. For that, change the 'Query type' to 'Update Statement' from the drop-down box.

Step 4:  Adding Listeners: View Result Tree control

• View Result Tree control is used to view the result of the query executed.
•  Add View Result Tree control to the Test Plan.

                                  Figure 5: Adding Listeners: View Result Tree control

Step 5: Verify Result from the Listeners 


 Check the load testing results from the Listeners. 

                                        Figure 6: Adding Listeners: View Result Tree control

                                    Figure 7: Verify Result: View Result Tree control






In the next few blog posts, i will try to extend this load test with the stored procedures and reading data from configuration files etc.

Be 'Stupid' to be a 'Smart Tester'...!!!

"If we did'nt have stupid thoughts
we'd have no interesting thoughts at all"

Interesting, Interesting and say it loud that it is interesting. Lets first share a "Stupid" video with you all:

     

So, have you enjoyed the video? I think you must have enjoyed. If you haven't, then you are not that 'STUPID'....:P

So, what makes me share this post with you.I must have something in my mind surely about 'Testing' or shall i say 'Stupid Testing'...:)

When i saw this video yesterday on the Diesel website, i was truly amazed. Then, i thought about it for a moment and realized that 'Stupidity' is a part of my regular activity too. And, that is none other than 'Testing'. Its must be a part of all the other Testers' activity also.

Everyday for testing different modules, we have to do basically all the 'Stupid' things along with the 'Smart' things. It may be a 'Stupid' inputs in the text-fields or it may be a 'Stupid' flow of activities to find a bug that cannot be found if we do only the 'Smart' ('Valid'/'Regular') way of doing that.

Truly, when a developers commit a code, he/she must have had some positive tests('Smart') before passes it to the QA team. So, as a tester if we only do the 'Smart' positive tests, then no bug will be found literally. So, along with the 'Smart' positive tests, we have to incorporate some 'Stupid' negative tests to find out the loopholes of that committed code.

Honestly, as a tester we have to take the risk of finding out the critical bugs by various 'Stupid' things continuously. So, i'm not afraid of being a 'Stupid' tester. Because, more or less you must be a 'Stupid' tester to be a successful 'Smart' tester.

Last part of the lyrics that i've enjoyed from this video is given below:

Its not smart to take risks...
Its stupid.

To be stupid
is to be brave

The stupid isnt afraid to fail.
The stupid know there are worse things than failure...
like not even trying.

Smart had one good idea,
and that idea was stupid.

You cant outsmart stupid.
So dont even try.

Remember
only stupid can be truly
brilliant

So,
BE STUPID...:)


Courtesy: www.diesel.com

Thinking From the Users' Perspective...

The title itself suggests the detail of this post. So, you may think that what’s the big deal reading this post, it is a common topic. Yes, it’s a common topic. But, I bet you may start thinking like an end-user, not a tester after reading this post. Let gets to the detail of this.

While testing the products what we actually do (or trying to do) is to act like an end-user of the product. But, despite our hundreds of testing criteria, sometimes we fail to act like end-users. Few days back, while testing a new feature of our product, I have found a ‘System Crash’ in our system which has been already in the system from the beginning. But, we could not find it earlier as we did not think like the end users before finding it in this specific instance.

The ‘System Crash’ happens for a specific input in all our ‘Text-box’ fields. Actually, I was testing a ‘Contact Form’ for the users where from they can ‘Report a Bug’ or can provide ‘Ideas to improve our product’. While testing this I was wondering what kinds of inputs user can input in that field. Suddenly, I got an idea of a specific input. Usually, for any website when the database connection does not work properly, an error page appears with lots of code instances provided that in the ‘Web.config’ files ‘Custom Error’ field is set to allow the users to view the errors. Though, in our product this feature does not allow the users to view the errors occurred, I intentionally insert such a group of error lines in the input field. The system crashes after inserting these error lines. After that, I narrowed down the error lines and found a specific text which actually caused the crash. So, I thought it is for that text fields only and I reported it. After a while, one of my team-mates asked me for this error text. And we started testing with this input to the all text fields our product. Finally, we came up with the decision that for all the text-fields this specific input causes the ‘System Crash’.

So, thinking from the users’ perspective is really important for testing any products and we have to ensure this in every instances of our testing career.

One more thing, it feels really good when I get any ‘System Crash’. I feel like a Tester (This dialogue is from ‘Raymonds’ clothing: "I feel like a man"..:P) when I get such type of ‘Blockers’, although all the bugs whether it is minor or major should be treated in a proper way. Nevertheless, finding any type of bugs give me an immense pleasure and satisfaction.

How important is to check the input data type while testing...

Input type testing or input domain testing is the word which we usually use for testing the mismatches of inserted input value to our program.So, how important this type of testing in our test life-cycle. Some testers may find it important, on the other hand some may not put special importance on this. Because the second group may think that developers by default check this input testing while coding. But, do the developers always check this things?? I think they do not. So, are you still thinking about the importance of input testing??
I bet you will give more importance on this testing after reading the story below:

Explosion of the Ariane 5

On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after lift-off. The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million. A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,768, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.
The following paragraphs are extracted from  report about the explosion::
On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded.
The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system.
The internal SRI* software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. 


So, what are you thinking now after reading the story. Is input type testing is worthy or not. Are you not convinced yet. If you are not, then i think you probably will never be.


Courtesy: www.ima.umn.edu/~arnold/455.f96/disasters.html

So, This is called testing...?

When a baby is born,everyone surrounding him/her tries to help him to learn what he/she must learn to carry on his/her activities.Sometimes he/she stumbles or sometimes falls down from the bed. I am thinking myself as a baby in this QA field as i've started my career as QA engineer few days back.So,please help me to understand what QA is and help me to carry on my QA activities.

Testing!!!!

When i first heard about testing, i was wondering what it would be and how this would be done.I made some general explanation in my mind.I thought it is a diagnostic approach to find bugs in a software project. I thought there would be some specifications and i've to go through those to cross-check the projects.But,as days are continuing i am realizing that i was somewhat wrong and there is something which is beyond this diagnostic approach.I am learning that it is not cross-checking rather it is questioning. It is questioning about the products,it is questioning about the users and most important thing is it is questioning about yourself as a tester.Because as far as i know if there is a question,then there will be an answer, otherwise what is the necessity of an answer. And in our case,the product is the answer. So,the best quality of it will be ensured if there are lot of questions about it.So, i've been continuously training my mind for questioning to become a good tester and consequently to become a good SQA engineer.I'm not sure is this a right approach or not but i guess if i ask about a problem from different point of views then definitely i'll reach quite close to a solution.

So,this is the definition of testing to me.I am requesting all of you to suggest me if i am wrong in my approach on testing.All yours advices will be taken cordially and i'm waiting for your comments.