I took 57 minutest of TV time the other night (skipped Survivor XVII; Jewish midgets vs. Satanic albinos) and instead turned to Google Video to watch How to become a software testing expert by James Bach. I’d never seen James Bach speak before until that night, and I have to say that I really like his style. If you are Software Testing QA Engineer and have a spare 57 minutes I recomend watching this presentation. I did, and I have to say “I’m a software testing expert” and I didn’t even realize it! It’s very empowering…
You can download the presentation slides off of Jame’s site.
Today marks the day where QAInsight.net is gonna stir the QA pot, put some fuel on the fire, and add a pinch of spice (ground Cayenne). It’s getting hot in here, so take off all your clothes, I am getting so hot… uhum well…anyway. To pour some vivation into this parched QA terrain called QAInsight.net I’m going to kick-off a new series dubbed “Stupid Testing Tricks”. Each post in the series will be well… a stupid testing trick that is short, uncanny, and helpful. So let’s get the stupid stuff started:
Stupid Testing Trick #1: Quickly access your hosts file
When testing in a browser, there is often a need to edit your hosts file, but traversing the relevant, overpopulated Windows directories to “C:\WINDOWS\system32\drivers\etc\hosts” is a royal pain. Ease the pain by creating a browser Favorite/Bookmark that points to your hosts file.
From the browser’s Address bar navigate to “C:\WINDOWS\system32\drivers\etc\” (or wherever your hosts file is located)
Create a Favorite/Bookmark to this location
Right click the Favorite/Bookmark and click “properties”
Change the “Target” field to C:\WINDOWS\system32\drivers\etc\hosts (or wherever your hosts file is located)
When you need to edit the hosts file you just click the bookmark and select an application to open it (you will need to do this since the file can’t be permanently assigned to an application due to its lack of an extension).
Have a Stupid Testing Trick? Email me using the “E-Mail” link on the right.
Exploratory Testing Dynamics defined! Do you remember when you thought exploratory testing was just simple software exploration that usually resulted in some pretty cool and unique defects? A chance to test without hindrance of documentation? Get over it; everything must have a rhyme and a reason my QA friend.
I’ve recently had a chance to write some Ajax in a side project that I’ve been working on and through use of it I started thinking about how one could easily use it to do evil things. Doing evil things reminds me of security testing, and I haven’t had an opportunity to test an application that uses Ajax but am pretty interested in finding some good exploits when I do get the chance. Before you get all “You had the chance to test it Brent, didn’t you test YOUR Ajax code Brent? You’re in Software QA and you don’t test your own code?”. Let me tell you that I did think about it being exploited, and if it did it wouldn’t really matter in my situation.
But while thinking about it, I did find the following article on Ajax Security Basics that would help a tester start thinking about how to attack the technology. After working with it, and reading the article, when I think about how dangerous this could be to an application I rank it up there with the danger of using <frames>. Are any of you testing Ajax applications? Do you have any advice or test cases you’d be willing to share?
What seemed to be out of the blue, NUnit started failing on me yesterday when I attempted to load my project. The cryptic error was:
System.IO.FileNotFoundException : File or assembly name nunit.core, or one of its dependencies, was not found.
Exception details are found at the bottom of the post. The problem? The web.config that went along with my assembly wasn’t valid because I was missing a trailing quote:
<
add key=”blah” value=”missingquote />
Ooops. Thanks for the uninformative error message NUnit. That’s a half hour of my life I’ll never get back….
On this blog you hear a lot of SWEA this, SWEA that… SWEA solves all my web page automation tasks, SWEA saves my ass, SWEA is cheap, without SWEA I couldn’t test 90% of a new build of our UI in 10 minutes, SWEA takes 4 letters out of SWEAt, no SWEAt with SWEA, I get left with T, Time. Time to focus on complex functional tests, installers, performance, (insert more buzz-word test types here).
So about now you’re thinking, SWEA Sure Would Enhance the Automation in my workplace. Yeah! YEAH! Now you’re catching on…
So, not long ago AdventNet posted a nice little automation tool comparison chart, but they forgot to add SWEA. Wonder why? Probably because SWEA is $59.00 which blows all other tools out of the water in the price department. Not only that, SWEA holds its own in features too. That’s pretty freakin’ sweet since SWEA was create by one man, a Mr. Alex Furman man. One might think, “Hmm, I’m not sure if I should bank my automation investment on a tool created and supported by one dude”. Let me tell you, and you must listen my automation tool shopping friend: Alex Furman is the man! I work with quite a few tools, I’ve worked with some of the tools that you’ll see in the comparison chart (the one I’m leading up to) plus some others, and I have never received the support I’ve received from Alex. Alex gets shat done, he works hard, he is proud of, and smart about his product. For example, one day I’m like all IMing Alex: “Hey, it’d be nice if I could attach the SWEA designer to any already open Internet Explorer window”, Alex is all “Sweet idea, my heroic QA engineer Brent Strange, I’ll put that feature in tonight, it’ll be a lot more fun than that near-impossible AJAX support I’ve been working on”. Heh. Seriously the guy responds and makes it happen for me (thanks Alex). The tool has made my QA life easier.
Oh yeah, the purpose of this post…If you put it in the comparison list provided by AdventNet it really hangs with the big dogs (view a larger comparison of tools here):
