I happen to stumble on this link on Mike Kelly's blog where he describes a method of using JUnit and XMLUnit to test webservices. Worth idea to copy ....
http://www.testingreflections.com/node/view/2966
This post is interstingly on "Automation". Read on ...
Shrini
Sunday, November 27, 2005
why skilled testers do not like scripted tests that much ...
Jonathan Kohl, has posted an interesting article on "Scripted procedural test scripts". In the post, Jonathan takes us through a story line that points to developers. How about giving a “step by step”, clear and detailed set of instructions to developers and something that is written long ago before the development begins. Will it work? The development manager who heard this, said – “I would fire a developer who would need that amount of hand-holding”. Developer would decide what his best and do that based on good judgment and skill.
Yes exactly - why can not we apply that to testing? As a skilled tester would you like to be constrained by procedural tests? Would you like the hand holding? Notice the keywords that Jonathan mentions in the post - Tester's skill, Heuristics, Seeking for the information when it is not readily available, judgment, Mission of testing. They are very powerful.
He finally calls out for Skilled testers – Are you identifying yourself with Skilled testers community? Are you somebody who thinks that testing is about "Critical thinking" and interested in improving and nourishing that skill? If yes, read books, articles and blogs from James Bach, Cem Kaner and Michael Bolton. Here the websites for your reference...
James Bach - http://www.satisfice.com/
Cem Kaner - http://www.kaner.com/ and http://www.testingeducation.com/
Michael Bolton http://www.developsense.com/ And don't forget to check out articles by Michael on stickyminds.com. They are like big bang on "Rapid Testing" and Critical thinking....
Shrini
Yes exactly - why can not we apply that to testing? As a skilled tester would you like to be constrained by procedural tests? Would you like the hand holding? Notice the keywords that Jonathan mentions in the post - Tester's skill, Heuristics, Seeking for the information when it is not readily available, judgment, Mission of testing. They are very powerful.
He finally calls out for Skilled testers – Are you identifying yourself with Skilled testers community? Are you somebody who thinks that testing is about "Critical thinking" and interested in improving and nourishing that skill? If yes, read books, articles and blogs from James Bach, Cem Kaner and Michael Bolton. Here the websites for your reference...
James Bach - http://www.satisfice.com/
Cem Kaner - http://www.kaner.com/ and http://www.testingeducation.com/
Michael Bolton http://www.developsense.com/ And don't forget to check out articles by Michael on stickyminds.com. They are like big bang on "Rapid Testing" and Critical thinking....
Shrini
Testing is not a mechanical Activity ....
I was reading this article posted on Cem Kaner’s site on - I wish to stress the following statement made in the article -
"Testing is a cognitive Activity - not a mechanical one"
Here is meaning of the term Cognition from Web
Cognition: 1. The mental process of knowing, including aspects such as awareness, perception, reasoning, and judgment. 2. That which comes to be known, as through perception, reasoning, or intuition; knowledge.
Note the keywords: Perception, Intuition, Reasoning, Knowledge, Awareness, judgment – all these represent “testing”. A true testing reflect this basic qualities related to HUMAN INTELLIGENCE.
In todays world of software with focus on "processes", "standards" - we all try to reduce the practice to the testing to a mechanical activity- be it test planning, test case design and especially execution - automation. Given a chance, the whole Non testing world (some even in testing group) would replace all smart and thinking testers with "nicely programmed Robots" - Righting test plans, test cases, executing them, logging bugs, making reports, attending meetings too ?? They follow processes, Do things 100% predictably all the time and don’t crib about "burn out" - All at the push of a button.
Such is the craze and lack of understanding about testing in the current Industry.
Remember "Real Testing" is about cognitive thinking and it is very "HUMAN" - don’t try to mechanize it. Today’s software systems have become so complex that It looses its effectiveness. Next time when some one says "standardization" or creating some types of robots - point them to this article.
Be tester, a thinker and be a human (No pun intended for Non testers - they are human too)
Shrini
"Testing is a cognitive Activity - not a mechanical one"
Here is meaning of the term Cognition from Web
Cognition: 1. The mental process of knowing, including aspects such as awareness, perception, reasoning, and judgment. 2. That which comes to be known, as through perception, reasoning, or intuition; knowledge.
Note the keywords: Perception, Intuition, Reasoning, Knowledge, Awareness, judgment – all these represent “testing”. A true testing reflect this basic qualities related to HUMAN INTELLIGENCE.
In todays world of software with focus on "processes", "standards" - we all try to reduce the practice to the testing to a mechanical activity- be it test planning, test case design and especially execution - automation. Given a chance, the whole Non testing world (some even in testing group) would replace all smart and thinking testers with "nicely programmed Robots" - Righting test plans, test cases, executing them, logging bugs, making reports, attending meetings too ?? They follow processes, Do things 100% predictably all the time and don’t crib about "burn out" - All at the push of a button.
Such is the craze and lack of understanding about testing in the current Industry.
Remember "Real Testing" is about cognitive thinking and it is very "HUMAN" - don’t try to mechanize it. Today’s software systems have become so complex that It looses its effectiveness. Next time when some one says "standardization" or creating some types of robots - point them to this article.
Be tester, a thinker and be a human (No pun intended for Non testers - they are human too)
Shrini
Friday, November 25, 2005
LUC - what is Least-privileged User Account?
Today's Tip is related to "Access control and security":
Most of us who test applications on windows platform use an account that has administrative privileges on the machine from where they are running the tests. This means that the application that runs has access to "everything on the computer". Try running the application that you are testing - by logging in to windows as non admin account. You might see serious issues - application may not launch, it may give weird messages and host of other issues that you would never notice if you are not working with an account that has admin privileges on the machine.
Why it is important to Test (Sometimes in a test cycle) by logging as non-admin account?
As golden rule of access control and security - a program should mandate an account privilege that is just sufficient to execute the required functionalities nothing more. Developers while developing typically work on admin account , develop code that assumes admin level of access and put that code on a production box. But the moment some body with non admin account uses the application - some part of the application may break. A Tester should explore the ways in which the application is using the access model and investigate where things look suspicious.
What's the problem with a developer having administrator privileges on her local machine?
The problem is that developing software in that kind of environment makes possible Least-Privileged User account (LUA) bugs that can arise in the earliest stages of a project and grow and compound from there.
Following as an excerpt is from the book Computer Security: Art and Science, written by Matt Bishop, ISBN 0-201-44099-7, copyright 2003.
Definition 13-1. The Principle of Least Privilege states that a subject should be given only those privileges needed for it to complete its task.If a subject does not need an access right, the subject should not have that right. Further, the function of the subject (as opposed to its identity) should control the assignment of rights. If a specific action requires that a subject's access rights be augmented, those extra rights should be relinquished immediately upon completion of the action.
This is the analogue of the "need to know" rule: if the subject does not need access to an object to perform its task, it should not have the right to access that object. More precisely, if a subject needs to append to an object, but not to alter the information already contained in the object, it should be given append rights and not write rights.In practice, most systems do not have the needed granularity of privileges and permissions to apply this principle precisely. The designers of security mechanisms then apply this principle as best they can. In such systems, the consequences of security problems are often more severe than the consequences on systems which adhere to this principle.This principle requires that processes should be confined to as small a protection domain as possible.
Read this article on Least Privilege Access http://www.windowsecurity.com/articles/Implementing-Principle-Least-Privilege.html and this https://buildsecurityin.us-cert.gov/portal/article/knowledge/principles/least-privilege.xml
Try your LUC (luck?) next time by logginng in with the user not having the admin persimission on and see if you can notice something suspecious. Don't forget to send me a mail about the bug that you caught ...
Shrini
Most of us who test applications on windows platform use an account that has administrative privileges on the machine from where they are running the tests. This means that the application that runs has access to "everything on the computer". Try running the application that you are testing - by logging in to windows as non admin account. You might see serious issues - application may not launch, it may give weird messages and host of other issues that you would never notice if you are not working with an account that has admin privileges on the machine.
Why it is important to Test (Sometimes in a test cycle) by logging as non-admin account?
As golden rule of access control and security - a program should mandate an account privilege that is just sufficient to execute the required functionalities nothing more. Developers while developing typically work on admin account , develop code that assumes admin level of access and put that code on a production box. But the moment some body with non admin account uses the application - some part of the application may break. A Tester should explore the ways in which the application is using the access model and investigate where things look suspicious.
What's the problem with a developer having administrator privileges on her local machine?
The problem is that developing software in that kind of environment makes possible Least-Privileged User account (LUA) bugs that can arise in the earliest stages of a project and grow and compound from there.
Following as an excerpt is from the book Computer Security: Art and Science, written by Matt Bishop, ISBN 0-201-44099-7, copyright 2003.
Definition 13-1. The Principle of Least Privilege states that a subject should be given only those privileges needed for it to complete its task.If a subject does not need an access right, the subject should not have that right. Further, the function of the subject (as opposed to its identity) should control the assignment of rights. If a specific action requires that a subject's access rights be augmented, those extra rights should be relinquished immediately upon completion of the action.
This is the analogue of the "need to know" rule: if the subject does not need access to an object to perform its task, it should not have the right to access that object. More precisely, if a subject needs to append to an object, but not to alter the information already contained in the object, it should be given append rights and not write rights.In practice, most systems do not have the needed granularity of privileges and permissions to apply this principle precisely. The designers of security mechanisms then apply this principle as best they can. In such systems, the consequences of security problems are often more severe than the consequences on systems which adhere to this principle.This principle requires that processes should be confined to as small a protection domain as possible.
Read this article on Least Privilege Access http://www.windowsecurity.com/articles/Implementing-Principle-Least-Privilege.html and this https://buildsecurityin.us-cert.gov/portal/article/knowledge/principles/least-privilege.xml
Try your LUC (luck?) next time by logginng in with the user not having the admin persimission on and see if you can notice something suspecious. Don't forget to send me a mail about the bug that you caught ...
Shrini
Friday, November 18, 2005
Sanitising your Resume...
I was going thru a set of resumes for test engineer position. Following are few things that I really find un-appealing and takes off my interest. I suggest to my fellow test professionals (others in general) - watch out for these (irritants) and if you are convinced that what I am saying makes sense - Clear your resume TODAY....
1. Open your resume in Word and search (Ctrl F) for words like "Involved", "Participated" etc. and delete the sentences containing them. The recruiter is not interested in what all are you were involved or participated - but he/she would like see "what you achieved" by doing that. Here is a way to rate your resume - Give one negative mark every time you encounter such word in your resume. How much did your resume score? Now do you understand why you are not getting enough interview calls?
2. I will not press very hard for this one - but if you do it is better. Get rid of words like "was Responsible for" or any variant of "Responsibility". What attracts recruiter is action word - "Achieved zero Downtime for systems I was responsible for" v/s "I was responsible for maintaining systems and ensure that downtime was low”. Notice the power of action. You will be delivering the same message but in a power packed way. That catches eyes of who "matter" in getting you a new "dream "Job. It is very important that you load your resume with these power packed action words, lots of them - especially in first 1-2 pages.
3. This one is the most "useless" part of resume if it is present. Writing paragraphs about the application that you tested with the names, versions, modules, detailed functionalities. Looks like a copy paste from functional specifications or SRS (System Requirement Specification) of the software product that tested. Watch out, some times this might land you in legal issues with your employer dragging you to court for leaking strategic product information to public - via your resume. This is big TURN OFF for the reader - especially a recruiter who would process and see thousands of resumes in a day.
Don’t forget the thumb rule – 1 page of resume for every 2 years of experience. So a person with 8-10 years of experience should not have a resume that exceeds 5 pages. Less and crisp is better and easier to read.
Enough? Open your resume and sanitize it TODAY.
May God bless you with job offers and interview calls pouring all the way !!!
Update: 21 Nov 2007 -- I referred this post to someone and at the same time happened to read another related but useful post on the same topic ...
http://steve-yegge.blogspot.com/2007/09/ten-tips-for-slightly-less-awful-resume.html
Shrini
1. Open your resume in Word and search (Ctrl F) for words like "Involved", "Participated" etc. and delete the sentences containing them. The recruiter is not interested in what all are you were involved or participated - but he/she would like see "what you achieved" by doing that. Here is a way to rate your resume - Give one negative mark every time you encounter such word in your resume. How much did your resume score? Now do you understand why you are not getting enough interview calls?
2. I will not press very hard for this one - but if you do it is better. Get rid of words like "was Responsible for" or any variant of "Responsibility". What attracts recruiter is action word - "Achieved zero Downtime for systems I was responsible for" v/s "I was responsible for maintaining systems and ensure that downtime was low”. Notice the power of action. You will be delivering the same message but in a power packed way. That catches eyes of who "matter" in getting you a new "dream "Job. It is very important that you load your resume with these power packed action words, lots of them - especially in first 1-2 pages.
3. This one is the most "useless" part of resume if it is present. Writing paragraphs about the application that you tested with the names, versions, modules, detailed functionalities. Looks like a copy paste from functional specifications or SRS (System Requirement Specification) of the software product that tested. Watch out, some times this might land you in legal issues with your employer dragging you to court for leaking strategic product information to public - via your resume. This is big TURN OFF for the reader - especially a recruiter who would process and see thousands of resumes in a day.
Don’t forget the thumb rule – 1 page of resume for every 2 years of experience. So a person with 8-10 years of experience should not have a resume that exceeds 5 pages. Less and crisp is better and easier to read.
Enough? Open your resume and sanitize it TODAY.
May God bless you with job offers and interview calls pouring all the way !!!
Update: 21 Nov 2007 -- I referred this post to someone and at the same time happened to read another related but useful post on the same topic ...
http://steve-yegge.blogspot.com/2007/09/ten-tips-for-slightly-less-awful-resume.html
Shrini
Subscribe to:
Posts (Atom)