Top 5 programming languages

Following are the top 5 programming languages reported in use by respondents

C#: 72%
Java: 66%
Visual Basic: 62%
C++: 54%
JavaScript/ECMAScript: 50%

Read More...

Important Information

http://www.microsoft.com/technet/technetmag/default.aspx

http://www-128.ibm.com/developerworks/rational/library/1147.html

http://www.techinterviews.com/index.php

Testing Process: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnentdevgen/html/testproc.asp

Rules of Data Normalization

http://www.datamodel.org/NormalizationRules.html

Making the Right Choice
The features you need in a GUI test automation tool

GUI (graphical user interface) tools can boast a lot of capabilities. Approaching GUI test automation as a programming project, you'll need a tool appropriate to the size of your project. Here's a rundown of the key features you'll need in the GUI test automation product you buy.

• Factors to consider in choosing a GUI testing tool
• Treating GUI test automation as a programming project
• A list of essential features

Silk Automation tool

One of the best website to learn about the Silk automation tool is automation expertise - http://www.automationexpertise.com/tutorial.asp.

How to test like Leonardo da Vinci - Software Testing Resources

Leonardo da Vinci had an unrelenting quest for continuous learning. A daVincian tester should continuously learn from experts, peers and all other resources he/she can find.

To get started, here are a few good resources:

Books:

The Art of Software Testing by Glenford Myers (John Wiley & Sons, 1979)
One of the oldest books on software testing ruled the "Software Testing" books arena for years
The Craft of Software Testing by Brian Marick (Prentice Hall, 1995)
A decent introduction book. The author posts interactive updates on www.rstcorp.com/marick )
Testing Computer Software by Cem Kaner (The Coriolis Group, 1993)
One of the most prolific and popular books on software testing, which has been adopted as the standard book by many software companies.
Black Box Testing by Boris Beizer (John Wiley & Sons, 1993)
One of the most methodical and prescriptive books with great examples, including graph techniques to test programs.
The Complete Guide to Software Testing (John Wiley & Sons, 1993)
Talks about life-cycle of a program and testing.
How to Break Software: A Practical Guide to Testing by James Whittaker(Addison Welsley, 2002)
A comparatively short(200 + pages) with pragmatic approach to testing.


Online resources:

www.io.com/~wazmo/qa
www.mtsu.edu/~storm
www-cse.ucsd.edu/users/howden
http://blogs.msdn.com/chappell/archive/2004/03/26/97003.aspx
http://blogs.msdn.com/chappell/articles/106056.aspx
http://www.kaner.com/pdfs/testarch.pdf
http://blogs.msdn.com/ppelland/

Testing careers at Microsoft:

http://weblogs.asp.net/jobsblog/archive/2004/03/23/95037.aspx


Please share any more resources, that you may know.

More information on the way.............

SOFTWARE TESTING AND PIZZA BUSINESS

This article highlights the challenges that the test team lead faces
in keeping track of ever changing business requirements. It also
highlights the strategies that the Test team lead has to adopt in
order to overcome these challenges. To explain all this in plain
English Software testing is compared to the business of a Pizza shop.

...click here to read more

Repro this!

Pop quiz: A tester finds and logs a bug. Some days (weeks (months)) later a developer picks up the bug and runs through it. Lo and behold, the bug does not occur. What should the developer do with this bug?

Most common answer: Resolve the bug as "No Repro" and send it back to the tester. Bzzt! Wrong! An electric shock to that part of your body you care most about. The bug jolly well does repro or I wouldn't have logged it. Use the build I was using when I found the bug and I guarantee it will reproduce.

Less common answer: Resolve the bug as "Fixed" and send it back to the tester. The bug used to happen but now it doesn't, so I guess this answer is technically correct. You still get a cattle prod between your shoulders, though. The bug may in fact be fixed, but it's just as likely to still exist and merely be hiding behind some other bug.

Extremely rare answer: Install the build on which the bug was reported and verify it does indeed repro on that build. Next, binary search the daily builds (you do build your full product at least once each day, right?) until you find the build at which it stopped repro'ing. Binary search through the checkins for that build (a simple process if you run every checkin through a full build) until you find the checkin that "fixed" the bug. Figure out why that set of changes caused the bug to no longer repro. This is the first point at which you have enough information to validly resolve the bug as Fixed. Of course, it's just as likely that the bug is still lurking somewhere. If you find this to be the case, your tester will be more than happy to help you find it again.

Resolving a bug "No Repro" just because it doesn't repro on *your* machine is a sure way to make your tester grumpy.

.NET Remoting FAQ