Another interesting feature which i tested was Boundary value of Google's search box. I was reading this interesting post by Debasis and i found out the work done by him really impressive and thought of doing my own boundary value exploration for Google's search box...
Debasis has mentioned in his analysis that he found out the maximum no of characters which can be pasted in the box is 2048 and on further analysis he found that it is 1980 characters which when passed will result directly on a "Google 404 Bad request Page".
Here is what i have found:
I found that it is not the exact no 1980 which can cause the "Google 404 Bad request" page. I found it to be something else. I found that it is not the no. of characters which really matter for getting the bad request page, however it is the positioning and placements of few special characters like #,@, ( to name a few which were causing bad request page.
We need to definitely explore a bit in deep to find out what exactly causes bad request page because after my initial investigations i am now sure that it is something which needs time and deep investigation to be done to find out the exact reason.
I found out that i was able to reproduce the "Google 404 Bad request" page several times using different combinations and different placements of characters in the search string. The interesting part was that whenever i included a ( after several @ symbols in my search string, the result would automatically shift the line starting with ( on the next line. For more clarity check out the snapshot here.
I was surprised that why the search was displaying (, # and few other characters in next line of search results. I found out that increasing the no. of #'s in the search string was increasing the chances of minimising the 1980 barrier required to get a Bad request page. I pasted the string mentioned below which has 770 characters in it..
_________####_______________#############____________________+++++++++++++++++++++++++++++++++++@@@@@@@@######@@@+++++@@@@@@@@@@@@@@@@@(((((((((((((((((((++++++++))))))))))((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((@@@@@@@@@@@@@@@@@((((((((((((((((((((((((@@@@@@@@@@@@@@@@@@@@@@@))))))))))))))))))))))##################################################################********************************(((((((((((((((((((((((((((((((^^^^^^^^^^^^^^^^^^^^^^^((((((((((((((((((((((((((((((((((((((((=====================================================================================================================================((((((((((((((((((((()))))))))))))))))))))))))))))))))))))))))))))))0#################################################(######
Paste the above string exactly in the Google search box and you will find that when we press Search Button we get the bad request error. Now if i reduce the above string to 769 characters i was not getting bad request error.
The interesting part was that sometimes this bad request error comes also when i have 765 characters and sometimes it does not comes.
Strange but true.. I see definitely here a relation between how we place characters and which characters are at what position has definitely to do something with bad request page.
I am sure that we can even further reduce the no of characters to get bad request page.
Output:
We need to explore more on what exactly causes Bad Request Page..
Happy Googling..
Madhukar.
Saturday, June 2, 2007
Thursday, May 31, 2007
Immediate boss is the reason people stay and thrive in an organization. And he ’s the reason why people leave.
Sometimes back i was going through this amazing article written by Azim Premji which truly reflects state of the IT Companies in today's world....I am amazed to see the trueness which this article reflects...You might probably feel that you also have encountered this situation sometimes in your life...
What do you say...
Azim Premji, Wipro
Every company faces the problem of people leaving the company for better pay or profile. Early this year, Arun, a senior software designer, got an offer from a prestigious international firm to work in its India operations developing specialized software. He was thrilled by the offer. He had heard a lot about the CEO. The salary was great. The company had all the right systems in place employee-friendly human resources (HR) policies, a spanking new office,and the very best technology,even a canteen that served superb food. Twice Arun was sent abroad for training. "My learning curve is the sharpest it's ever been," he said soon after he joined.
Last week, less than eight months after he joined, Arun walked out of the job. Why did this talented employee leave ? Arun quit for the same reason that drives many good people away.
The answer lies in one of the largest studies undertaken by the Gallup Organization. The study surveyed over a million employees and 80,000 managers and was published in a book called "First Break All The Rules". It came up with this surprising finding:
If you're losing good people, look to their immediate boss. Immediate boss is the reason people stay and thrive in an organization. And he's the reason why people leave. When people leave they take knowledge, experience and contacts with them, straight to the competition. "People leave managers not companies," write the authors Marcus Buckingham and Curt Coffman. Mostly manager drives people away?
HR experts say that of all the abuses, employees find humiliation the most intolerable. The first time, an employee may not leave, but a thought has been planted. The second time, that thought gets strengthened. The third time, he looks for another job.
When people cannot retort openly in anger, they do so by passive aggression. By digging their heels in and slowing down. By doing only what they are told to do and no more. By omitting to give the boss crucial information. Dev says: "If you work for a jerk, you basically want to get him into trouble. You don't have your heart and soul in the job."
Different managers can stress out employees in different ways - by being too controlling, too suspicious, too pushy, too critical, but they forget that workers are not fixed assets they are free agents. When this goes on too long, an employee will quit - often over a trivial issue.
And finally the Golden Words...
Talented men leave. Dead wood doesn't...
What do you say...
Azim Premji, Wipro
Every company faces the problem of people leaving the company for better pay or profile. Early this year, Arun, a senior software designer, got an offer from a prestigious international firm to work in its India operations developing specialized software. He was thrilled by the offer. He had heard a lot about the CEO. The salary was great. The company had all the right systems in place employee-friendly human resources (HR) policies, a spanking new office,and the very best technology,even a canteen that served superb food. Twice Arun was sent abroad for training. "My learning curve is the sharpest it's ever been," he said soon after he joined.
Last week, less than eight months after he joined, Arun walked out of the job. Why did this talented employee leave ? Arun quit for the same reason that drives many good people away.
The answer lies in one of the largest studies undertaken by the Gallup Organization. The study surveyed over a million employees and 80,000 managers and was published in a book called "First Break All The Rules". It came up with this surprising finding:
If you're losing good people, look to their immediate boss. Immediate boss is the reason people stay and thrive in an organization. And he's the reason why people leave. When people leave they take knowledge, experience and contacts with them, straight to the competition. "People leave managers not companies," write the authors Marcus Buckingham and Curt Coffman. Mostly manager drives people away?
HR experts say that of all the abuses, employees find humiliation the most intolerable. The first time, an employee may not leave, but a thought has been planted. The second time, that thought gets strengthened. The third time, he looks for another job.
When people cannot retort openly in anger, they do so by passive aggression. By digging their heels in and slowing down. By doing only what they are told to do and no more. By omitting to give the boss crucial information. Dev says: "If you work for a jerk, you basically want to get him into trouble. You don't have your heart and soul in the job."
Different managers can stress out employees in different ways - by being too controlling, too suspicious, too pushy, too critical, but they forget that workers are not fixed assets they are free agents. When this goes on too long, an employee will quit - often over a trivial issue.
And finally the Golden Words...
Talented men leave. Dead wood doesn't...
Wednesday, May 30, 2007
Add Value to your Automation....
Simplify Automation Creation and Maintenance....
I am sure anyone involved in automation testing would have encountered the situation below:
Your team is working hard on an application, lots of automation scripts are created, the test suite is running all fine when suddenly one day you wake up to find that all scripts have failed..
Nothing changed in your code..right? Then what caused this catastrophic failure..
Everyone is behind you asking for the reasons why it failed and you yourself do not know what happened...Strange isn't it...? How can a person who has written the scripts be unaware about why they failed in the night..
I will tell you why....
1. The scripts were procedural test scripts which were just recorded and replayed with some checks in place, some loops, some if else statements and so on...
2. These kind of scripts are difficult to maintain when the application changes, and in development the application changes quite frequently from build to build. Some new objects get added to the application, some old objects are not present, some objects have their properties changed and so on....
3. Testers generally have an attitude that automation tools are just about record and replay and nothing more, they are unaware about the capabilities which they can bring into it.
How do you overcome all these issues then?
You can simplify maintenance by avoiding to fall in the pitfalls of poor record and replay scripting..which will not lead you to automation success.
Automation becomes of little value when it does not provides useful information which can be reviewed by testers and most importantly my managers (after all managers are interested in the number game, in the % age of bugs covered by automation etc)...
Never rely on the tools built in reporting features. Create a library of functions which can be then reused by each test. Using the library the output can be given in so many formats. Find a few examples here.
1. HTML Files: People love coloured HTML pages, plus on top of it if you can add a little bit of Java Script to it then it can be more presentable.
2. Excel Sheets: Excel sheets can be processed easily by machines and people can do lots of manipulations with the data just by using few mouse clicks.
3. Database: Results can also be posted directly to a database and which can then be used to comapre with a pre existing standard template.
4. XML File: Another very popular medium of output.
Reported results should contain enough information which can answer the following:
What happened to the application when error occured.
Exactly at which point did the error occured.
Which script and which line of code caused the error.
What action does the Framework took when error occured.
How many errors were application specific and how many errors were due to errors in scripts itself.
How many test cases ran totally?
How many passed and how many failed?
One more feature can be built into the framework..Snapshot of the application can be taken and stored whenever an error occurs so that it becomes more easy to debug the errors.
Snapshots also provide a real proof of where the error occured. Snapshots can also be customised with the Log File ouput, for example the time stamp in the log file for a particulat step can be appended to the Snapshot file name so that it becomes easier to find the actual state of the application at the point when error occured.
Most Importantly remember:
An automation effort which runs for several hours is of little importance if it takes another several hours to figure out what went wrong and to interpret the results..
And yes i will be posting many new ideas for automation..so keep reading...
Happy automation..
Madhukar..
I am sure anyone involved in automation testing would have encountered the situation below:
Your team is working hard on an application, lots of automation scripts are created, the test suite is running all fine when suddenly one day you wake up to find that all scripts have failed..
Nothing changed in your code..right? Then what caused this catastrophic failure..
Everyone is behind you asking for the reasons why it failed and you yourself do not know what happened...Strange isn't it...? How can a person who has written the scripts be unaware about why they failed in the night..
I will tell you why....
1. The scripts were procedural test scripts which were just recorded and replayed with some checks in place, some loops, some if else statements and so on...
2. These kind of scripts are difficult to maintain when the application changes, and in development the application changes quite frequently from build to build. Some new objects get added to the application, some old objects are not present, some objects have their properties changed and so on....
3. Testers generally have an attitude that automation tools are just about record and replay and nothing more, they are unaware about the capabilities which they can bring into it.
How do you overcome all these issues then?
You can simplify maintenance by avoiding to fall in the pitfalls of poor record and replay scripting..which will not lead you to automation success.
Automation becomes of little value when it does not provides useful information which can be reviewed by testers and most importantly my managers (after all managers are interested in the number game, in the % age of bugs covered by automation etc)...
Never rely on the tools built in reporting features. Create a library of functions which can be then reused by each test. Using the library the output can be given in so many formats. Find a few examples here.
1. HTML Files: People love coloured HTML pages, plus on top of it if you can add a little bit of Java Script to it then it can be more presentable.
2. Excel Sheets: Excel sheets can be processed easily by machines and people can do lots of manipulations with the data just by using few mouse clicks.
3. Database: Results can also be posted directly to a database and which can then be used to comapre with a pre existing standard template.
4. XML File: Another very popular medium of output.
Reported results should contain enough information which can answer the following:
What happened to the application when error occured.
Exactly at which point did the error occured.
Which script and which line of code caused the error.
What action does the Framework took when error occured.
How many errors were application specific and how many errors were due to errors in scripts itself.
How many test cases ran totally?
How many passed and how many failed?
One more feature can be built into the framework..Snapshot of the application can be taken and stored whenever an error occurs so that it becomes more easy to debug the errors.
Snapshots also provide a real proof of where the error occured. Snapshots can also be customised with the Log File ouput, for example the time stamp in the log file for a particulat step can be appended to the Snapshot file name so that it becomes easier to find the actual state of the application at the point when error occured.
Most Importantly remember:
An automation effort which runs for several hours is of little importance if it takes another several hours to figure out what went wrong and to interpret the results..
And yes i will be posting many new ideas for automation..so keep reading...
Happy automation..
Madhukar..
Tuesday, May 29, 2007
Tools for a Tester....
I was reading some interesting artciles on the net and came across pretty good tools which a Software Tester should have handy for getting help in his/her testing....
The very basic utility that each tester should be aware of is Process Monitor which is a File and Process Monitoring Utility in real time..Its nothing new..its a combination of earlier known Filemon and Regmon...Now its the power of 2 in 1..
Have a look and enjoy the super power you are charged with...
Wanna have more...I would say that a Tester should always keep his guns loaded with destructive weapons which he needs most of the times..for example while testing an application he would always need the below mentioned:
1. Random Test Data to test applications reaction for different values.
2. Destructive data which is the data not acceptable to the application..always keep a notepad ready which has lots of combinations of special characters, ASCII characters, strings with different lengths, very long strings etc..
Have a look at various tools available which generate random test data for your convenience which might help a lot..One such example of a test data generator is here . Check it out it can be a handy tool to generate data in different formats like HTML, XML, Excel, CSV etc....
Also read the article by James Bach about more of weapons here.
Happy Testing....
Madhukar..
The very basic utility that each tester should be aware of is Process Monitor which is a File and Process Monitoring Utility in real time..Its nothing new..its a combination of earlier known Filemon and Regmon...Now its the power of 2 in 1..
Have a look and enjoy the super power you are charged with...
Wanna have more...I would say that a Tester should always keep his guns loaded with destructive weapons which he needs most of the times..for example while testing an application he would always need the below mentioned:
1. Random Test Data to test applications reaction for different values.
2. Destructive data which is the data not acceptable to the application..always keep a notepad ready which has lots of combinations of special characters, ASCII characters, strings with different lengths, very long strings etc..
Have a look at various tools available which generate random test data for your convenience which might help a lot..One such example of a test data generator is here . Check it out it can be a handy tool to generate data in different formats like HTML, XML, Excel, CSV etc....
Also read the article by James Bach about more of weapons here.
Happy Testing....
Madhukar..
Tuesday, May 15, 2007
Test Automation Realities
Ever Wondered why software Test Automation Fails
This is my First ever Blog on the internet and this happened just because of the person who i respect a lot and have learnt a lot of things from him. His name is Shrini, and he hired me at Aditi Technologies from where i started this career of Software Testing 4 years ago. Shrini as i know is a great follower of in depth learning about Software Testing and i have learnt a lot from him.
The views presented in the article below are completely mine and their might be people who do not fully agree to them. I am open for any comments for my views so that we can together make Software Testing better.
I know we all who are involved in this Software Testing world would have encountered sometimes in our Life a little bit of Test Automation using Testing tools. I would like to ask a question, what are the responsibilities of a Software Test Automation engineer?
The answer which i generally get is he/she should be able to automate the application after all that's what pretty simply is the definition about.
I have came across lots of people who will just be doing record and play back using the Test tools and do you feel they deserve to be called automation engineers? A straight answer is NO...
Well Test automation is not about recording and replaying the actions to see if something has broken. It is much more than that in fact and required lots of experience and skills to become a effective Automation engineer. The most important of which is to learn first what automation testing is all about and then rest all will fall in right place.
Do you find new bugs using Automation?
Their might be different views for this, but the truth is that Automation can never find new bugs.
It is always the same functionality and same scripts which you will be running usually called regression testing where you might say that this particular functionality which was working earlier is not working now but you cannot say that a new bug has been introduced because you simply don't have an automation script for that.
How Automation should be done then?
This is my First ever Blog on the internet and this happened just because of the person who i respect a lot and have learnt a lot of things from him. His name is Shrini, and he hired me at Aditi Technologies from where i started this career of Software Testing 4 years ago. Shrini as i know is a great follower of in depth learning about Software Testing and i have learnt a lot from him.
The views presented in the article below are completely mine and their might be people who do not fully agree to them. I am open for any comments for my views so that we can together make Software Testing better.
I know we all who are involved in this Software Testing world would have encountered sometimes in our Life a little bit of Test Automation using Testing tools. I would like to ask a question, what are the responsibilities of a Software Test Automation engineer?
The answer which i generally get is he/she should be able to automate the application after all that's what pretty simply is the definition about.
I have came across lots of people who will just be doing record and play back using the Test tools and do you feel they deserve to be called automation engineers? A straight answer is NO...
Well Test automation is not about recording and replaying the actions to see if something has broken. It is much more than that in fact and required lots of experience and skills to become a effective Automation engineer. The most important of which is to learn first what automation testing is all about and then rest all will fall in right place.
Do you find new bugs using Automation?
Their might be different views for this, but the truth is that Automation can never find new bugs.
It is always the same functionality and same scripts which you will be running usually called regression testing where you might say that this particular functionality which was working earlier is not working now but you cannot say that a new bug has been introduced because you simply don't have an automation script for that.
How Automation should be done then?
Software Test automation for most of the testers today is just a phrase. They don't really understand the meaning of it and just start jumping into it. To take an example in India we have these training institutes which i call money making shops which can be found at every nook and corner of the streets. But the reality comes when you actually join them. You find that there are no computers, no teaching faculty which is good enough. These shops do so many promises to you that we get lured by them, and yo here comes the easiest prey for them (The Fresher). A fresher who has just passed out from college who does not know ABC of Software Testing jumping into Software Automation...can you believe this? The shops charge heavy amount of money and provide with Placement guarantees at the end of the course...Heights..isnn't it....? If getting a Job was so easy then why do we in India have so many unemployed people still....A thing to ponder upon....
This happens because he has heard that get some knowledge about Software testing, learn 1 or 2 automation test tools which will add a Buzzword to your resume and then their are these so called recruiters who will do a CTRL F on the resumes to just find words like "Automation" and some famous automation tools and wow you have got an interview call. Now if you are smart enough then you can fake out the Interviewer and you are in....Look pretty simple...And the fact is that yes we have so many automation engineers today in so many comapnies but i would say that a person does not becomes an Automation Engineer just merely by working on a Tool and doing some scripting in that.
I still feel bad that people don't really understand the real meaning of Automation Testing. For most of them its just record and replay to test the application. If you want to be a good automation engineer then i would say do the following:
1. Spend some time to actually learn Software test automation and how is it different from normal testing.
2. Have your concepts and logic very clear so that given a programming language you can easily convert your logic and apply them in that language.
3. Learn a scripting language like Vb Script, Java Script as most of the Test Automation tools revolve around scripting.
4. Read good books on Software Test Automation, read articles by great personalities in Software Testing.
Only when you feel that you have done all what is mentioned above you should think of working on a Test Automation tool. To emphasise once again i would say that Automation tool is just a medium to achieve your goal. Their are thousands of people who call themselves automation test engineers and Good Test Automation Engineers are very few. To find them is also very difficult.
Don't be lost in this huge crowd of automation engineers, stand apart so that the world knows you. Browse the net and read interesting articles on Software Automation. Their is so much to learn and so less time. Don't waste time and prove your worth to this world. You are capable of doing it, it just needs a change in your attitude, your thinking and you can be a better Tester.
To be a Good tester you should have an attitude and most important you should be a better thinker.....Testing cannot be taught, it just comes out as a result from better thinking...
Madhukar....
Subscribe to:
Posts (Atom)
