Monday, October 8, 2012

Testing the developers, along with the development…

Interesting topic, right? What do you think ?
If you think this is interesting, then lets talk about this a bit more. 

Moving on...

Whenever we are testing a product or development, it is definitely from a development team. As we have been working with this team from long times, we must have some ideas and knowledge about the developers. So, can this awareness affect our testing effort or shall i say, can this awareness benefit us or not?  Lets share some experiences on it.

Knowing the developers or what I can say testing the developers can be advantageous or can be harmful. Lets talk about the benefit and negatives of this by examples.

Lets assume a 'Bug' to be a 'Criticism' (though, a bug is a blessing for me and for all the testers as well).  As a human being, we always do one common mistake. That is called 'Stereotyping'. So, whenever we are being given a new issue or a new feature from a specific developer (Say Developer X), unintentionally sometimes we take it as granted that Developer X tends to make some common mistakes like not thinking of the negative scenarios, spelling mistakes. As a result, we do strict our thinking ability and we loss our enthusiasm to explore for the unwanted things. This is a dangerous thing which affects directly on the curious mind and let it stop to work profoundly.

On the other hand, sometimes it benefits us while we are in a rush to test a some specific issues before release of the product. When you are in hurry what we usually do is finding out the minimal ways to complete the tasks in hand. So, we need to focus on the particular important things. So, if you do some tests focusing on the important parts and keeping in mind that Developer X has done it, then you can find out the most important features which will not be left out for testing before the release or when you are in a hurry.

 I know all the specialists of Testing whom i really follow, will not support this. Actually, i do not like it as well. But, sometimes it comes up through the unconscious mind and i have tried these approach unconsciously. Well, i had some success as well. But, in the long run, it actually limits the broader thinking approach.

So, testers!!! Be aware of this 'Stereotyping' !

Tuesday, September 4, 2012

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.

Wednesday, January 4, 2012

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:

Steps to follow:

Step 1: Adding Thread Group Control
  • Thread Group allows to run script with nth 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)

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.