Many people (including testers i know) feel that software testing is a less brainy / easy to achieve task . They always rate software developer as the supreme. and see testing as peanuts .This is a highly wrong way of thinking . Software testing is a priced job . It requires special thinking abilities and out of the box approach . And definitely it is not an every man's job . It is really tough to become a good software tester .
If you are a software tester and are feeling bad about it , first find whether the job is too bad to get you exited .If it is , then quit it and find which gives you satisfaction . One should be proud of there job . And one can give good output and be happy only if he is satisfied well with his job .
Monday, June 13, 2011
Friday, June 10, 2011
Thursday, June 9, 2011
Problem with setting Testing Targets keeping testing case count in mind
In my 5 years of experience , i observed a very common problem when test plan is written and the application is tested with the plan . ie "Managers seeing only the Testcase count and setting the time frame for testing"
Testing Targets are normally set based on various factors . They differ based on the application under test . If it is client based urgent requirement , we will have some factors which mainly depend on the delivery date and quality . But for a product that can be released with some time delay , the factors vary . Being a product based company , we have the liberty to take more time . But the main problem i see in many managers here(even outside) is that they calculate everything based on the count of the cases . Planning based on count is good , but planning everything only on the basis of count is damn wrong . There are variety of factors that come in to picture here and some of the disadvantages are below
1. All the cases are not same . Some cases take more time to validate and some take less . So when setting a time frame , it is always better to have a bit extra time
2. Time for some extensive testing . Testing plans written exactly based on the test case count with tight schedule will not give the tester a free hand in testing . For example if a tester is asked to test an application having some 500 cases in 5 days . He will test only the testcases . He wont be thinking to crack the application . He will only try to finish of the cases and submit the reports . Although that would be suffice , it will no way enhance his skills or the product .It is always better to give some extra time and freedom to test .
3. A tight schedule might force the tester to skip the cases . If not credited or not planned well , the tester might end up being under pressure which will make him to skip some cases and hence resulting in breakages .
Tuesday, May 31, 2011
An easy way to reach the top?
Copied but a good one
Narayana Murthy (NRN), at old Infosys campus in 1990s. Since most of them know about the story of Infosys and NRN, let me narrate some interesting and rare facts which many might not know.
If Indian engineering students have taken job placements for granted, it is because of visionaries like Narayana Murthy. He is the Sultan of Indian IT but the journey was not as smooth as that of Tipu Sultan or other kings who were born in royal families.
Coming from a middle class family, like any other Indian, he had a dream of getting into IIT. He had managed to clear the IIT-JEE exams but his father could not afford IIT hostel and tution fees, due to which he made up his mind and joined a local engineering college (NIE, Mysore). He said to himself "All students from the IITs study well and do big things in life. But it is not the institution, ultimately it is you and you alone who can change your life by hard work" and he went on to prove his statement!! After engineering, he received Master's degree from IIT Kanpur.
Not many know that his first job was at IIM-A as systems engineer (also, he had 5 job offers including HMT, Air India, Telco after graduation but took up IIM-A which was the least paying).
He was initially a firm believer of communism but an interesting incident changed his life which led him to become a capitalist & an entrepreneur. During a foreign visit, for having talked against the Bulgarian govt with somebody in train, NRN was jailed for 4 days without food but later released because he was from India (which was a friendly country to them). This changed his life, he gave up the idea of communism and decided to create jobs in India. Thats how the story of his entrepreneurship started.
Infosys was his second attempt as an entrepreneur. The first one being Softronics, which was targetted to domestic market. Since India was not mature for IT yet, it turned out to be a big flop. So he started InfoSys (yes, the S was capital) and the rest is history.
Here is an interesting 3 min clip from a BBC documentary showing Infosys, Indian IT in general and the impact on India.
http://www.youtube.com/watch?v=I6-2hIImXok
The journey of Infosys was certainly not smooth and had seen lots of obstacles. Getting a computer took them 24 months, thanks to our govt red tape. Getting a loan was almost impossible. And at some point of time, the company was even at the verge of a sell-out. How they overcame all those troubles and became such a successful company is another story which I will be narrating using a different photo later :)
As usual, our next question. What is thought provoking in this story and what can we learn from it?
NRN has demonstrated that even if you are from a middle class family, inspite of studying in a local college, and being without any money to start a company & inspite of license raj of 1980s, you can go on to succeed in life and build a great empire by creating millions of jobs. He has shown that you need not have a surname called Tata/Birla to be successful. You dont have to be only from IIT to succeed. All it takes is hard work, determination & self confidence!! Hoping to see many more Narayana Murthys in future :)
Narayana Murthy (NRN), at old Infosys campus in 1990s. Since most of them know about the story of Infosys and NRN, let me narrate some interesting and rare facts which many might not know.
If Indian engineering students have taken job placements for granted, it is because of visionaries like Narayana Murthy. He is the Sultan of Indian IT but the journey was not as smooth as that of Tipu Sultan or other kings who were born in royal families.
Coming from a middle class family, like any other Indian, he had a dream of getting into IIT. He had managed to clear the IIT-JEE exams but his father could not afford IIT hostel and tution fees, due to which he made up his mind and joined a local engineering college (NIE, Mysore). He said to himself "All students from the IITs study well and do big things in life. But it is not the institution, ultimately it is you and you alone who can change your life by hard work" and he went on to prove his statement!! After engineering, he received Master's degree from IIT Kanpur.
Not many know that his first job was at IIM-A as systems engineer (also, he had 5 job offers including HMT, Air India, Telco after graduation but took up IIM-A which was the least paying).
He was initially a firm believer of communism but an interesting incident changed his life which led him to become a capitalist & an entrepreneur. During a foreign visit, for having talked against the Bulgarian govt with somebody in train, NRN was jailed for 4 days without food but later released because he was from India (which was a friendly country to them). This changed his life, he gave up the idea of communism and decided to create jobs in India. Thats how the story of his entrepreneurship started.
Infosys was his second attempt as an entrepreneur. The first one being Softronics, which was targetted to domestic market. Since India was not mature for IT yet, it turned out to be a big flop. So he started InfoSys (yes, the S was capital) and the rest is history.
Here is an interesting 3 min clip from a BBC documentary showing Infosys, Indian IT in general and the impact on India.
http://www.youtube.com/watch?v=I6-2hIImXok
The journey of Infosys was certainly not smooth and had seen lots of obstacles. Getting a computer took them 24 months, thanks to our govt red tape. Getting a loan was almost impossible. And at some point of time, the company was even at the verge of a sell-out. How they overcame all those troubles and became such a successful company is another story which I will be narrating using a different photo later :)
As usual, our next question. What is thought provoking in this story and what can we learn from it?
NRN has demonstrated that even if you are from a middle class family, inspite of studying in a local college, and being without any money to start a company & inspite of license raj of 1980s, you can go on to succeed in life and build a great empire by creating millions of jobs. He has shown that you need not have a surname called Tata/Birla to be successful. You dont have to be only from IIT to succeed. All it takes is hard work, determination & self confidence!! Hoping to see many more Narayana Murthys in future :)
Wednesday, May 25, 2011
how to start server with proxyInjectionMode option from the code
The below code can be used to start the server from the java code
RemoteControlConfiguration config = new RemoteControlConfiguration();
config.setProxyInjectionModeArg(true);
SeleniumServer server = new SeleniumServer(config);
Sunday, May 22, 2011
Check List Document for writing TestCases
Being an Form based Application(product i have has more than 500 forms minimum), i have prepared a Checklist for writing testcases . Hope it helps some one.
Checklist:
Usability
1. Check for presence of
Functionality
2. Functionality
Messages
3. Information / Errors / Warnings (thrown to user, by the system)
4. Confirmation messages
5. Warnings/Errors when something is done wrong
Configurations
6. Configurations based
The Configurations will change based on the Application , eg Testing an Mobile app conisists of testing in different hardware , Testing an Mail should be tested in various mail clients like OutLook , Gmail and with IMAP , POPS , etc
Impact
7. Impact testing
*Check for the impact areas due to the change
8. Breakdown (or) Crash ie application down / site down
*Test to check the behavior when an unexpected breakdown occurs (Eg. like server shutdown/crash)
9. Recovery
*Test to check the behavior on recovery (Eg. like restarting the server)
10. Inopportune scenarios
*Scenarios when a sudden valid thing happens at a particular time which is not expected to happen at that time (Eg. trying to delete a file while some one else is viewing it)
Database Testing
11. Database check
BackUp / Upgrades
12.Backup / Restore
*Take all database and configuration backup & move to some other system, restore the backed up data and checking for proper working
13. Check whether upgrades ( if present) are happening correctly or not
14. Check whether all the functionalities are working well after the upgrade
General
15. Multiple source to achieve things - Various places from where a particular operation can be done
16. Different options on doing a kind operation from different places
* Differences in doing a same operation from different areas (same functionality can by achieved by various methods
17. Tab feature , Enter key , Delete and various keyboard based shortcuts
18. Duplication - Adding multiple entries of same kind
19. Deleting and adding the same entry
*Delete a particular entry and adding the same entry again with the same name and configuration
Internalization
20. I18N
* Check if all the strings are i18ned
21. Check if the text boxes accept non-english characters
22. Check whether all the functionalities are working in non-english language
Logs
23. Code checks
24. Check whether Proper debugging is enabled to ease support
25. Logging - Check whether proper logging has been done for the feature
Various Logins
26. Type of user login - Check the functionality with free user / paid user / administrator previliges etc
27. Impact of a particular change in different places
28. License Check
*Check for license(if any) for any new feature implementation
Security
29.Security Testing
Performance Related
30.Performance testing
31.Scalability - Max no of nodes
32.Max no of users that can log in / or can access the site at a time
33.Stress test
Checklist:
Usability
1. Check for presence of
- Links
- Buttons
- Help Messages(Info messages if any needed)
- Color / Type of Text
- Size of the text(Maximum text that can be entered)
Functionality
2. Functionality
- Check for the working of all the links
- Check all features of the application (* Checking for what the software is intended for (Eg. If compose mail, whether the mail is sent correctly to the specified user(s))
Messages
3. Information / Errors / Warnings (thrown to user, by the system)
4. Confirmation messages
5. Warnings/Errors when something is done wrong
Configurations
6. Configurations based
- Browser based - Write check lists of what browsers and browser versions are supported
- OS based - Testcases should cover testing for all the OS supported
- Database Compatablity - Check what versions of databases are supported (Application i use support quite a few (Mysql , MSSQL 2000 , MSSQL 2003 , MSSQL 2007, Oracle )
The Configurations will change based on the Application , eg Testing an Mobile app conisists of testing in different hardware , Testing an Mail should be tested in various mail clients like OutLook , Gmail and with IMAP , POPS , etc
Impact
7. Impact testing
*Check for the impact areas due to the change
8. Breakdown (or) Crash ie application down / site down
*Test to check the behavior when an unexpected breakdown occurs (Eg. like server shutdown/crash)
9. Recovery
*Test to check the behavior on recovery (Eg. like restarting the server)
10. Inopportune scenarios
*Scenarios when a sudden valid thing happens at a particular time which is not expected to happen at that time (Eg. trying to delete a file while some one else is viewing it)
Database Testing
11. Database check
- Checking the relevant database tables for any operation
- Check for unwanted queries , tables
- Check for unique key, foreign key constrains , etc
BackUp / Upgrades
12.Backup / Restore
*Take all database and configuration backup & move to some other system, restore the backed up data and checking for proper working
13. Check whether upgrades ( if present) are happening correctly or not
14. Check whether all the functionalities are working well after the upgrade
General
15. Multiple source to achieve things - Various places from where a particular operation can be done
16. Different options on doing a kind operation from different places
* Differences in doing a same operation from different areas (same functionality can by achieved by various methods
17. Tab feature , Enter key , Delete and various keyboard based shortcuts
18. Duplication - Adding multiple entries of same kind
19. Deleting and adding the same entry
*Delete a particular entry and adding the same entry again with the same name and configuration
Internalization
20. I18N
* Check if all the strings are i18ned
21. Check if the text boxes accept non-english characters
22. Check whether all the functionalities are working in non-english language
Logs
23. Code checks
24. Check whether Proper debugging is enabled to ease support
25. Logging - Check whether proper logging has been done for the feature
Various Logins
26. Type of user login - Check the functionality with free user / paid user / administrator previliges etc
27. Impact of a particular change in different places
28. License Check
*Check for license(if any) for any new feature implementation
Security
29.Security Testing
- Password encryption
- Not to expose files
- Not to expose hidden functionalites (Typing the full url some times will bypass the checks )
- Check whether the passwords can be seen in Logs / database /URLS etc .. No password should be in readable format
Performance Related
30.Performance testing
31.Scalability - Max no of nodes
32.Max no of users that can log in / or can access the site at a time
33.Stress test
Subscribe to:
Posts (Atom)