I found a great article over at the Google Testing Blog entitled Automating tests vs. test-automation. The article does a great job of summing up some things about automation that I had to learn myself over the years. The last set of bullets is oh-so-true, and if you are starting down the automation project path be sure to heed the advice:
To summarize, I figured out that a successful automation project needs:
to take the internal details and exposed interface of the system under test into account,
to have many fast tests for each interface (including the UI),
to verify the functionality at the lowest possible level,
to have a set of end-to-end tests,
to start at the same time as development,
to overcome traditional boundaries between development and testing (spatial, organizational and process boundaries), and
to use the same tools as the development team.
It’s refreshing to hear this come from somebody else; especially a team at Google. It helps me justify in my paranoid mind that my thoughts about how automation should work are sane and that GoDaddy’s latest automation initiative is going to work.
The ACE TEAM over at Microsoft has released a tool that does static analysis for cross site scripting (XSS). Confused about what a static analysis tool is? The ACE TEAM explains it well:
There are two types of web application vulnerability scanners: dynamic and static. Dynamic analysis tools are also called penetration testing tools. You point such a tool at a live application; the tool begins crawling the web pages in the application and throws test strings at each of them. The effectiveness of a penetration testing tool is therefore dependent on its ability to go through all the use cases in the application. Most tools in the market, if not all, are not very good at it. Static analysis tools on the other hand scan the application source code or binaries to detect programming errors. Consequently, they offer 100% coverage and are able to identify many more vulnerabilities than penetration testing tools. XSSDetect is a static analysis tool.
Get all the specific details on how XSSDectect works here. XSSDetect is now in Beta and is a free download here. Question is, who is going to run the tool in your company? QA or Dev? We all know who should be running it first. Don’t we? DON’T WE? Okay then, download it, play with it, get to know it, present it to the Dev team (making you look REALLY smart and up to par on the latest technology), and then talk them into running it against their code before release for testing.
Life is good when your app isn’t vulnerable to XSS. Life is better when the developer finds the XSS vulnerability before you do.
Tuesday evening I had the opportunity to attend my first Phoenix Software Quality Association meeting (PSQA) where another Rock-Star GoDaddy employee Lauren Snyder presented an “Introduction To Watir”. It was really great to see her enthusiasm for automation and on top of that she is a great presenter. The presentation provides a HEAP of information about Watir and would be valuable to anyone diving into Watir.
Heh, get it? DIVING INTO WATIR.
Awe, never mind.
Lauren gave me permission to post the presentation here for your consumption:
Company: ISI Job Title: Developer in Test/Test Engineer
Description “We are looking to add a Developer in Test/Test Engineer to our team here at ISI. We are a product development shop in the POS for Quick Lube and Car Wash industry. We are continuously getting better at producing our products in a Lean/Agile fashion.
We are looking for a test infected developer to help us jump start our test automation effort. You will work primarily with our testers to design our test automation strategy and then execute on it. We have multiple technologies including DataFlex, PowerBuilder, PocketBuilder, C, Java, PostgreSQL, Sybase, Linux, Windows, WinCE”…
I’m going to try to do something a little different here on QAInsight.net. I get a few requests to take a look at jobs “if I’m interested, or know of somebody that is”. Why not post them here? I’ll put them in a separate RSS category, so you can avoid them if you want or subscribe to them if you want. The new category will be Testing Jobs.
This isn’t an invitation to send all your QA jobs to me recruiters. My intent here is to help those that I’m working with or I’ve worked with in the past. Hopefully I can also help those who may be looking!
It’s a small QA world and it’s funny how we follow each other around from job to job or eventually cross each other’s paths. In my small QA world many have contributed to me and my career (willingly or not). It doesn’t hurt to return the favor.
This whole Blu-Ray versus HD DVD issue is pathetic and vaguely familiar. Can you say BetaMax versus VHS? Why do they do this to us? I have a beautiful TV capable of 1080P and really want to get started on a 1080 movie collection but don’t want to make the wrong choice and end up with a library of unwatchable movies. Yes unwatchable, as I conform to the industry and buy products that use the industry chosen format (video camera, video converters, portable player, etc) those movies in the other format will quickly gather dust.
Sure, for home I can buy the LG BG100 that is capable of both formats and cover my format player bases. But I still have my problem…I really want to start buying high definition movies. I suppose by buying a HD DVD Player and getting these movies I am “voting” for HD DVD and this is my contribution to helping the industry decide on the chosen format. It just disgusts me that my vote could turn into a player that everybody will laugh at me for owning 2 years from now. But the bright side is that I’ll have a beautiful collection of HD DVD drink coasters.
I’ve been following the Microsoft hacking blog%41%43%45%20%54%65%61%6d (can you decipher that?) for a while now, but its content isn’t necessarily what you may be thinking… posts on how to hack Microsoft products? Nope, instead the content of the blog is written by hackers that now work at Microsoft. You know, the white hat kind. If you can’t beat ’em, hire ’em? There aren’t a lot of posts, but when there do post they tend to be interesting.
The latest post First Line of Defense for Web Applications – Part 1 had a lot in common with a recent project I’d been working on, and the image they created to illustrate their point is a beautiful summary for their post and also for what I was working on. What the image portrays is a very common problem, a problem that a lot of testers don’t know how to test for, or help enforce with good requirements:
This series should be good and I look forward to the next post. So should you.
While I’m at it, make sure and check out a little less of a white hat perspective at http://ha.ckers.org/. There is a ton of valuable stuff here, stuff that has worked its way into my test cases.
Back in October of 2006 I wrote an article for Better Software Magazine entitled The $60 Web-Testing Toolbox. Wrong or right, I’m posting it here (3.9 MB) since I have a heck of a time tracking down where I put the digital copy whenever the subject comes up. The $60 toolbox is not myideal toolbox, but it proves the point that you can get a great set of tools on a low budget. I’ve got about half an article written about my ideal Web testing toolbox (see my placeholder on the right entitled “Brent’s Test Toolbox). Hopefully someday soon day that “Coming soon!” link will become active.