feeds2read
Latest Flows from this sub-category:
放心情 ^_^

Новости от компании Инком

JournalRhythm

Hourly hot News

Market Research Blog

MCCL News and Information RSS feed

الكرويتات

Newsfeeder

Sohli.com - Articles

Мобильный Стиль Жизни

random selection from this sub-category:
IPS Noticias - Comunicación y Medios



Actualités du Dictionnaire des e-technologies

DDL Testing Services Newsroom

Intel Press Room

MSDN Just Published

Wired News: Top Stories

Бизнес новости, финансы, кредиты, недвижимость, ипотека

MS Watch

Tech Talk for Families (mp3): Technology, Toy, and Video Game News for YOUR Family

Rss Directory > Computer > News > QA Insight: Brent Strange's Software QA blog


Brent Strange's thoughts on Software Quality Assurance and technology
Copyright: Brent Strange
  Thu, 04 Sep 2008 13:24:38 +0200

image

 

Don't quit your day job...

  Thu, 04 Sep 2008 05:47:20 +0200

In the slim and clean Google Chrome (beta) interface JavaScript issues are not easily detectable unless your page or site is visually broken. Much like FireFox and Safari, a tester must open the "JavaScript console" and keep it in visible view while they test in order to catch JavaScript errors. Chrome's Javascript console is a lot like Safari's, but is a tad worse (see the gotchas at the bottom of this post).

My fellow testers, here is how to get to that JavaScript console and monitor for JavaScript errors while you test:
 

Click the page icon to the right of the URL bar. Select "Developer" and then "JavaScript console" from the menu:

image

In the top of the JavaScript console window click the "Resources" button:

image

Start testing. When an error occurs you'll see a red icon with a number in it next to the page that the error occurs:

image

You'll also see a log of the error in the bottom of the JavaScript console window, if you click the provided link it will take you to the line of code where the error occurs:

image

Also, if you click the page in the "Resources" section the offending line of JavaScript and the error will be displayed:

image

As of now, I see two gotchas in Google Chrome Beta when attempting to detect/find JavaScript errors:

  1. The "JavaScript Console" reports more than JavaScript issues which makes sorting/distinguishing JavaScript errors from other reported HTML style of formatting errors tough. A cheesy visual helper is to also open up the "Debug JavaScript" window (found in the same Page > Developer menu to the right of the URL bar) and watch for new line items to show up in the log. Those line entries are associated with JavaScript errors, unless..
  2. You changes sites/domain, in this case the previously opened JavaScript windows won't display data for the new site. You have to close those instances and re-open them to monitor the new site.  You know that the monitoring has stopped when you see in the "Debug JavaScript" window the following log entry: "lost connection to tab"

image Just when you thought you had a handle on your browser compatibility testing, Google gives us Chrome.  What does that mean for you, the infamous browser compatibility tester? Just another browser to test? Yes and no...

Have you seen my previous screencast on Browser Compatibility Testing Risk Analysis? If not, its a worthy watch if you want to get a feel for how the browser generally works and how to trim that browser test list based on a little bit of data and risk analysis. Once that's under your belt, continue on my friend...

Let's dive into the details of Chrome to get a quick grasp on where some new browser compatibility defects for your site may be lurking:

The Layout Engine
What does Google Chrome use for a layout engine? WebKit. The same layout engine that Safari uses. Will it render exactly like Safari? Well, it depends on which version of WebKit that  your installations of Chrome and Safari use. You can determine this quickly by looking at the user-agent string. A quick way to do this is to go to BrowserHawk.com, click "more" in the top right menu, scroll to the bottom of the new page and look for the text "User agent". Here is the Google Chrome user-agent:

Mozilla/5.0+(Windows;+U;+Windows+NT+6.0;+en-US)+AppleWebKit/525.13+(KHTML,+like+Gecko)+Chrome/0.2.149.27+Safari/525.13

As you can see we have a WebKit version of 525.13. Chances are that the latest version of Safari runs WebKit 525 also (again do this by looking at the user-agent of the latest version of Safari). Ignoring the minor version number and focusing on the major version number, if they are the same we can feel comfortable that Chrome and Safari will display layout the same...Meaning they will align objects on the page the same. If you've already tested Safari, chances are you aren't going to find any unique layout defects in Chrome.

The JavaScript Engine
This is where things start to get different. In Google Chrome we have a brand new engine and way of doing JavaScript. Google calls their new engine V8. Safari's engine is JavaScriptCore. Night and day...expect to see differences and potential issues here. When testing make sure to look for JavaScript errors and possible issues with sites that us AJAX (in my next post I'll talk about how to view JavaScript errors in Chrome) .

The Shell
What stands out the most to me in Chrome's "shell" is the fact that tabs, plug-ins, and JavaScript run under there own process. On the surface this looks like an ideal way to manage security and to keep memory in-check, but I would keep an eye on functionality of pop-ups and session management between windows (as in, losing reference where there needs to be reference). Also, notice the clean-cut/different "shell" that Chrome has... This "shell" could also yield potential defects related to printing, or any other page related features that you may find in the various menu bars/icons or "Options" menu.


In summary, if you are asked to test both Safari and Chrome the layout is going to be the same (if the WebKit versions are the same). However JavaScript and the Shell could yield some unique defects.

  Mon, 01 Sep 2008 12:49:03 +0200

image Web-site layout, one of the many things that can keep a tester busy. Uhm...overwhelmed? So many browsers so little time... Wouldn't it be nice if you, the mighty tester, could just review a butt-load of screen-shots of your Web application in multiple browsers on multiple platforms to make sure there are no layout issues?  Wouldn't that be quick and efficient?

I've got 2 semi-solutions for you (keep in mind I've done little with both, so forgive an misinformation):

Litmus
"We've felt the pain of getting website designs to work correctly across different browsers. Not to mention designing email newsletters that work on all email clients. Litmus makes compatibility testing easier. Litmus is lightning-fast, reliable and affordable. It's relied upon by thousands of smart freelancers and switched-on agencies; as well as big companies like Yahoo!, Facebook and eBay."

The FREE part of Litmus: Screen-shots of your site in IE 7 and FireFox 2.

The $ part of Litmus: Pay $24 a month to get 23 browsers and 14 email clients.

BrowserShots
"Browsershots makes screenshots of your web design in different browsers. It is a free open-source online service created by Johann C. Rocholl. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to the central server here."

The FREE part of BrowserShots: 70 browsers on various platforms! Submissions get dumped to a queue for processing.

The $ part of BrowserShots: Pay $15 a month to get priority processing.


Both of these appear to be good services that can provide quick insight to layout problems in your site. However, as far as I can tell the two big limitations are:

  • You are limited to pages that you can navigate to via URL, which rips the grandiose dream of having a screen-shot for every page in your website (pages that require form post or special conditions to get to are not going to happen). However, Litmus does provide a step in the right direction with it's functionality for authentication.
  • Your site must be exposed to the Web, doing little for internal Dev and QA project cycles.


I have a dream...

  • I want to screen-shot any page in my website (requires a decent engine that will allow me to get to the various pages in my site).
  • I want to screen-shot my site that is not yet published for the world (requires the service to exist within my local network).
  • Once I've approved an ideal layout screen-shot I want the software to determine and tell me if the other screenshots are worth looking at (by doing a statistical image comparison with a predefined pass/fail threshold).
  • I want to provide basic wire-frame definitions and have software determine if my screen-shots are within reason (by analyzing elements in the DOM and browser dimensions)
  • Get rid of screen-shots and do DOM to DOM element width and height comparisons between browsers (Come on, it's a dream, standards compliance for all browsers (another dream) might make it possible?)

Honestly, I think the dream is doable... So many dreams/ideas, so little time.

  Thu, 14 Aug 2008 11:50:25 +0200

A couple years ago my grandpa Alfred Olsen passed away and I wrote the following eulogy entitled "Follow the Leader" that was read at his funeral. He was a truly remarkable man, I miss him a lot, and the man he was, is what I strive to be. I was perusing the hard drive this evening looking for something QA related and rediscovered this. I thought I'd share since some of these lessons are applicable in the business world too:

 
Follow the Leader

Written by Brent Strange in memory of Grandpa Olsen

It’s funny, I always have fleeting thoughts of how I appreciate the little things about a person or the different things I love about them but I’m always hard pressed to put it into words or too chicken to tell that person about those things. “I Love You” says a lot, but doesn’t say much for why. Putting the “Why” behind “I Love You” is something I’ve thought about for a long time with my Grandpa Olsen but I never did sit down to tell him. Now it’s too late to tell him in person, so here I am settling down and am writing it out. I hope and pray that he is listening now…

My Grandpa is the most respectable person I’ve ever met. Let’s cut to the chase: Grandpa was honorable, funny, kind, loving, giving, non-judgmental, and a man of God. He is everything I want to and struggle to be. Over the years Grandpa has been a silent leader for me. Follow the leader!

Follow the leader: give somebody some “bugs”!
My first memories of Grandpa date back to when I was less than two years old. Back then Grandpa preached at the Assembly of God in Naselle where he and Grandma lived in the connecting house. I remember in the evenings we would sit in his vinyl, burnt-orange chair together. Grandpa would bounce me on his knee helping me pretend I was a cowboy riding his horse. The orange chair was where I first remember getting “bugs”. Yeah bugs…Grandpa’s way of tickling was giving you little tickling pinches under your legs and arms saying “You got bugs, BUGS, BUGS!” each bug bite made you squirm and laugh trying to wriggle out of his reach to get rid of those darn bugs. When the horse rides and bug bites died down I would sit on his lap, leaning against him listening to him talk to others in the room. His voice was comforting to me.

Follow the leader: sit on the edge!
Grandpa and I did a lot of fishing. My first remembered fishing trip was frightening! Grandpa took me to the dock at the Chinook cannery where we sat on the edge to fish for Perch. I remember sitting on that edge, feet hanging over, and looking down at the water below scared to death since it was so far down (seemed to be about 20 feet down to this day, probably was 10…). Grandpa didn’t seem too concerned and my fear soon went away after we caught the first Perch.

Follow the leader: cast through the brush, the fish are just past it!
Summer visits to Grandpa and Grandma always meant a trip Martin Wirkkalla’s place to fish in his private lakes. I remember walking behind Grandpa as he led me through the trees and brush to find those hidden lakes. Fishing would usually start out with me casting into the weeds and trees but after a couple hours of untangling weeds from lures, and carefully finessing lures from tree branches Grandpa and I came back with a few nice trout. Those times were always special to me because we were fishing in lakes that nobody else could, and we ALWAYS caught fish!

Follow the leader: take time out of your busy day for your loved ones!
The last time I fished with Grandpa was on his 62nd birthday. I remember the day pretty well. Grandpa was pretty busy for some reason but we headed to the Naselle River off of South Valley Road to get a few quick casts in. What I remember most about that day was walking down to the river with him and asking him how old he was. He told me he was 62 and I remember thinking that 62 was REALLY OLD and that he would die soon. My eyes welled up with tears with the thought. I managed to get the tears dried up before they fell so he didn’t see. I spent the rest of that fishing trip appreciating EVERY little thing about him (by the way, this was the ONLY trip together that we didn’t catch anything).

Follow the leader: make people laugh!
Grandpa was a prankster. If you didn’t know this, you didn’t know Grandpa! Every time I visited he had a new trick up his sleeve. Even in his 80’s! The last prank he played on me was his exploding pen cap. I think over the course of 2 years I actually fell for that prank twice.

Follow the leader: confirm those answers?
When Grandpa would ask a question and someone would reply he would always follow up a reply with a “Huh?” I thought that was pretty funny because I knew he heard the reply but he still always said “Huh?”. I remember listening to Grandma replying to Grandpa, Grandpa then saying “Huh?” and then Grandma replying louder, firmer and a bit annoyed. I always smiled to myself when I heard that word “Huh?”, it was a funny habit of his.

Follow the leader: Give!
Grandpa was so giving. With every visit I ended up with some sort of odd, hand-me-down gift that meant a lot. Grandpa had a way of showing you all his cool things throughout the house and shop and waiting for your eyes to sparkle about one of those things. That THING usually was gifted to you by the end of your visit. Over the years I obtained some pretty special gifts: stuffed baby alligator, pocket electronic golf game, Skil-Saw, fishing lures, wood pens.

Thank you for your love and leadership Grandpa. I respect and honor your life and am committed to providing the leadership to my family and friends as you have done for yours.

clip_image002 clip_image002[4]
  Mon, 21 Jul 2008 13:36:10 +0200

For those of you in need of doing SQL load testing from Visual Studio 2005 or 2008 there is a new open source project at CodePlex called SQL Load Test. How does SQL Load Test work?

"This tool takes a SQL Profiler trace file and generates a unit test that replays the same sequence of database calls found in the trace file. The unit test is designed to be used in a Visual Studio Load Test. The code generated is easily modifiable so that data variation can be introduced for the purpose of doing performance testing."

Get more info and download SQL Load Test here.

I've been using to last.fm recently and last night had good luck tapping into some great 80's songs by creating a station by using artist: "Kiss". Oddly enough over the course of two hours I didn't hear any Kiss songs but I did venture into a few solo albums from various members of the group. As I was coding away on a personal project, and slightly paying attention to the music, I was brought to full attention when I heard a pretty, Disney, girly, kids' song. What the... When I brought the last.fm window up I was greeted with the meta of the song "A Dream Is a Wish Your Hear Makes" from the "Ultimate Disney Princess"...here's the kicker/defect:

Sang by Cinderella...the late 80's early 90's glam metal band. Hehe, too funny.

image

  Sun, 06 Jul 2008 06:04:02 +0200

Things have been a bit quite here at QAInsight for the last few months wouldn't you agree? As always the days and nights are never quite long enough to get all those things I want done.

I have one excuse though.

Actually I have more than one but I'm only going to share one with you:

I've been working undercover with the FBI and Viacom to help parse Google/YouTube logs to obtain logons which relate to IPs, which point to people who are uploading copyrighted content. A mass effort to prepare for the largest bust in digital history.

No... Just kidding.

Really, I'm kidding don't start with that death threat stuff. I've already had three this week.

Apparently the insightful QA advice found on said Software QA blog has increased defect finding and input by QA Engineers across the globe  and developers are angry. Go figure, they want to eliminate me because apparently I'm the ring-leader that has slowed down their development process and release to production.

It's just a blog. I set forth ideas, I didn't do the defect finding. Please spare my life. Please? I have kids.

In fear of my life I'm going to lie low a while.

In the meantime, take some more QA advice from me and go check out Go Daddy's new QA blog BugCrushers.com. They have a QA army of 50 talented individuals. I expect to see some good stuff come from these peeps.

Oh... By the way, if you're a developer and you see posts on BugCrushers.com where the author is "Brent Strange"...

IT'S NOT ME. It's another Brent Strange. Ironically this one does QA too. Go figure.

The alpha version of IETester was recently released and "IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE8 beta 1, IE7 IE 6 and IE5.5 on Vista and XP" on the same machine.

To good to be true? No, not if you take that sentence literally. These kinds of tools can indeed help you test for "rendering/layout" and "JavaScript" issues, but tend to quickly fall apart when it comes to integration with the OS shell (plug-ins, caching, cookies, modal dialogues, printing etc). IETester is much like MultipleIEs, these types of tools can help when you're in a bind and want to validate something simple that is script or layout related. But to use these tools to conduct all your browser testing versus your dedicated IE systems or VMs will likely bite you in the long run when the issues go beyond layout or JavaScript. IMHO these tools are best left in the hands of the developers to quickly validate layout issues and then QA can follow up with the real thing. It's a good tool to have around but don't bank on it! :)

Download IETester here.

Get a better feel for for how the browser works with my recent screencast: Browser Compatibility Testing Risk Analysis

  Wed, 28 May 2008 07:41:16 +0200

I just listened to a podcast where Željko Filipin talks with Bret Pettichord about Watir. This is an easy to listen to and informative podcast about Watir. I really admire and appreciate Bret's openness about Watir as he talks about both the good and the bad. If you have 23 minutes give it a listen.

  Wed, 28 May 2008 07:11:43 +0200
PexLogo Pex (from the Microsoft Research Lab) has finally been released the public. Pex 0.5 can be downloaded here.

What is Pex?

"Pex (Program EXploration) is a white-box test generation tool. Given a hand-written parameterized unit test, Pex analyzes the code to determine relevant test inputs fully automatically. The result is a traditional unit test suite with high code coverage. In addition, Pex suggests to the programmer how to fix bugs."

I haven't had a chance to dive in but I'm pretty excited to see how this can speed up production of writing white box tests and/or increase the code coverage on QA's side.

At the end of the day it'd be nice to see this in the developers' hands and not mine. Baby steps though...

Read more about Pex here.

Get an ear full of Pex with a great Hanselminutes Podcast entitled "Pex with Jonathan 'Peli' de Halleux and Nikolai Tillmann".

brentUnit

I hate it.

Unit test this. Unit test that.

Let's put "unit" in our testing framework so we can test "units" cuz that's all ANYBODY is EVER going to test.

Testing outside of the "unit" is forsaken. Thou shalt never test more than a unit. Test more than a unit and ye shall be pelted with stones and crucified.

Let's see... What do we have here for unit test frameworks:

brentUnit (even Brent Strange can have a unit testing framework)
JUnit (notice the word unit)
nUnit (look at me, I test units)
mbUnit (I'm a follower, I can't think outside of the box. Uhm...let's test units.)
csUnit (CHEESE & RICE, this is INSANE)
...

OH HELL...Just go here for the gi-hugey list:

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

You back? See what I mean? There's like one-cajillion testing frameworks that are for "Unit Testing".

Unit, unit, unit. It's freakin' beyond dumb.

Tell me...What happens once this developer phase of "Oh, I gotta go write some unit tests, with my unit test framework so my code is better" evolves to tests beyond "unit"? You know, like writing some tests that are "integration" or "functional? It'll happen people.

IT'S HAPPENING PEOPLE.

I, and others have been using "unit testing" frameworks as an automation test harness for years now. All kinds of tests.. Tests that aren't "unit".

Yeah, insane. Unheard of I know. What? You going to crucify me now?

Drop the unit. Get over it. These are "Testing frameworks".


P.S.
Microsoft, nice namespace: Microsoft.VisualStudio.TestTools.UnitTesting

P.P.S
Don't give me any crap about how "unit testing frameworks" are for developers. Good one rocket scientist...Let's create separate frameworks to basically do the same thing. One for Dev, one for QA. Brilliant...


Disclaimer|Rss Directory|Try a Feed|Suggest a Feed|F-A-Q|Partners
Links: Référencement internet | Annuaire Webmaster  | ubuntu/debian tips
Comparateur de Prix | Logos, Sonneries, Jeux Java | Sonneries pour portables | Ringtones and logos for mobile phone | Accéssoires pour téléphone portable | Sonneries Et Logos
© copyright feeds2read.net 2005-2008