The IE7 team is asking developers to test their sites. I’m assuming that this means that all the new rendering enhancements and features are in place, even though I can’t find any reference to list of those types of changes. Testers, get your browser compatibility testing shoes on! Give your site a whirl in IE 7! How does it look? I’m afraid to look…Let the defect input begin.
You can get technology IE7 technology overview here.
For those of you have been involved with or are a part of the Waterfall software cycle you’ll appreciate this Web site. I couldn’t help but laugh at some of the following tutorials (since it hit so close to home in the past):
Converting bugs to enhancements
How to produce an impressively thick test plan, suitable for clubbing errant programmers over the head
Top 10 Reasons to reject a build before you even test it
Strategies for lengthening the test cycle
Techniques to force programmers to follow standards
Recently the IA Web Service Namespace URI changed which broke all my existing tests in SOATest. While talking with support person at SOATest, I found out that there is no quick and easy way to update the namespace URI in each test case when your test cases are in the view “Form XML” (“Refresh the WSDL” doesn’t work). However, he did tell me that if your test cases are using the “Form Input” view, “Refresh the WSDL” will update the namespace URI. Moral of the story: When you’re done creating your test case, make sure and leave it in the “Form Input” view so that namespace changes are updated when you refresh your WSDL!
When I reviewed my issue a bit more, I discovered another possible solution. To avoid the issue when using the “Form XML” view, parameterize the namespace in each test case and utilize a namespace/value you set at a global level.
In the above example, in the form “AccountHistory”, I’m adding a dynamically checkbox element and setting it to “on”.
This was helpful in my particular situation because based on the user you log on with, the number of accounts you can select from is dynamic. If I want more than one selected, I can’t hardcode any of that from user to user, so, I’ve got to do it this way. And, it also allows me to perhaps randomly turn them on and off as needed.
Lee Copeland recently delivered a dinner speech at the EuroSTAR testing conference where he compared the life of kindergartener to a tester. It’s a pretty good analogy. You can find the full speech out on Stickyminds.com. In a nutshell, Lee suggests that testers should live by these rules:
Don’t hit people.
Put things back where you found them.
Clean up your own mess.
Don’t take things that aren’t yours.
Say you’re sorry when you hurt someone.
Wash your hands before you eat.
Warm cookies and cold milk are good for you.
Live a balanced life.
Learn some, think some, draw some, paint, sing, dance, play, and work every day.
Take a nap every afternoon.
When you go out in the world, watch for traffic, hold hands, and stick together.
It appears that FireFox 1.6 will have an additional attribute added to the Anchor tag called “Ping”. This feature will let the browser send a notification ping to the URL specified for the Ping attribute. The intent of the attribute is to improve page load performance and provide sites a mechanism for link tracking.
I don’t know about you, but when I put my evil QA hat on I’m thinking that this could be a nice little feature that could gain me more pings/hits to my site. If I set the ping attribute to qainsight.net for every link I put on my page, I could get an extra hit for link clicked; more hits equals more Google Adsense revenue… Okay, the hat is off now, the evil Brent is gone (I won’t be doing that).
I haven’t installed FireFox 1.6 to test this but I’m imagining my evil code would look something like this:
<a href=”http://weblogs.mozillazine.org/darin/archives/009594.html” ping=”http://qainsight.net”>Link to Fried Fish</a>
I then saved the script off to my project\Scripts directory as UserID.js. (by creating the file externally, I have the power to reuse the script from many locations from within my test). Now that I had something to generate the IDs all I had to do was set the rest up in SOATest. In order for the user ID to be generated every time I executed my Test Suite, I needed to create a Set-up test. This was done by:
In the left frame, right mouse clicking the associated Test Suite directory
Selecting Add Test > Setup Test > Test Method
Selecting the new created Setup Method; the Tool page will appear in the right frame:
Browse to the previously saved UserID.js file
In the left Tests frame, right mouse click the Setup Method
Select Add Return Value Output > New Output > XML Databank
With the above mentioned, executing the Set-up Test will now call the function from the .js file, return it to the SOAPUtil, and then will populate the XML Databank.
Now, from the test case in which I intend to use my random user ID I can select that Username attribute/node (in the right frame), select the value to be “Parameterized” from the dropdown, and then select the name of the Set-up Test I previously created (Set-up 1: z0 in my case).
Many of us have seen the FireFox plugin that allows you to view your FireFox page in Internet Explorer (IE View Lite). Now you can do the opposite with FireFoxView written by Alex Sirota. This FireFox plugin installs context menus for Internet Explorer and allows you to quickly jump from IE to FireFox (Yes, you install the FireFox plugin to get the functionality in IE). This can be done in Internet Explorer by a right mouse click on any page and choosing the context menu item “View This Page in FireFox” or by right mouse clicking a link and choosing the context menu item “Open Link Target In FireFox”. Needless to say, this quick link can be very convenient when testing browser comparability. For example, if you find an issue in IE you can quickly jump to that page in FireFox to see if it exists there too!
Beware, as noted by Alex: “FirefoxView isn’t compatible with Norton Antivirus 2004 and older with script blocking enabled. Important: The extension uses a simple ActiveX command to launch Firefox. The full source code is open as part of the extension. Apparently, Norton Antivirus (versions prior to NAV 2005) sometimes detects this as a malicious script. I can assure you there is nothing malicious in FirefoxView. Please check your Norton Antivirus script blocking settings if you want to use FirefoxView.”
Sometimes when doing performance or scalability testing your application may need pre-enrolled users. Enrolling a specific amount of users can be a bit tricky with Segue SilkPerformer when you want to run multiple virtual users to get the job done quickly. Running one virtual user usually solves the typical problems but 1 virtual user when I needed 1 million enrollments was unacceptable time-wise. I recently worked through a problem where virtual users weren’t stopping when they reached the end of the file so they would cause errors to occur in the application because they were being re-enrolled. Here is the solution Mark and I came up with:
First off, I needed to list the 1 million signon IDs for Performer to enroll so that I could signon with the same IDs later. I list these in a data file. To ensure each is enrolled, Performer’s virtual users need to read the user names from the file sequentially to make sure they ALL get enrolled (IAUser1 – IAUser1,000,000). In order to tell the virtual users that they had reached the end of the file I placed an obvious string (“END”) at the end of the data file so that the first virtual user that came across it would halt. This looked like:
IAUser999996 IAUser999997 IAUser999998 IAUser999999 IAUser1000000 END
After I setup the data file, I then placed the following code in Init transaction (or the first transaction called by all virtual users):
//Load and pull user name from the data file FileCSVLoadGlobal(nAcctFile, “MillionIAUsers.rnd”); sUser := FileGetCol(nAcctFile, 1, STRING_COMPLETE);
//Define a global variable that all virtual users have access to GlobalVarGet(“Enrolled1”, nIsEnrolled1);
//If the user ID is “END” set the nIsEnrolled1 flag to 1 and halt if (sUser = “END”) or (nIsEnrolled1 = 1) then GlobalVarSet(“Enrolled1”,1,1000); halt; end;
What happens here is the first virtual user that encounters the “END” flag sets the global var nIsEnrolled1 to 1 and halts. When the next virtual users come in behind the “END” user they will have sUser set to an already enrolled user name from the beginning of the data file (for example: IAUser1). We can halt all the remaining virtual users by checking for the global var (nIsEnrolled) that the user who encountered the “END” set (since nIsEnrolled1 is set to 1 any virtual user that followed will then be halted via the if statement).
This method worked perfectly for me. The best solution? Maybe not. I’d like to hear some other solutions. Do you have one?
I can’t help but laugh to myself every time I see a new Internet Explorer 7 feature that FireFox already has. The last blog entry from the IE Team talks about their new IE 7 feature “Delete Browsing History” and how it’s “coming to a computer near you very shortly”. Actually, it’s already on my computer in a handsome little browser called FireFox. Check out the similarity/copy. It pretty sickening how Microsoft doesn’t listen to it’s user’s requests but instead the competition. I guess the bright side for Microsoft is that they got free usability testing by FireFox. The downside is that if they keep doing this they’re going to lose more market share.
What’s in Internet Explorer 8 Microsoft? What’s that? The same things that are in FireFox 2.0? Heh. Imagine that.