Is Microsoft Lowering the Software Quality Bar for the Industry?

From a paper I wrote in 2006 originally titled “Is Microsoft Ruining Software Quality?”

I have worked as a professional software testing and QA consultant since 1994 and have tested software, as a developer and user, much longer. I scan job postings when looking for my next assignment and to keep a tab on the industry. I noticed that when searching jobs in the Seattle area, a new category of software testing jobs was popping up frequently. This job is called Software Development Engineer in Test or SDET and Microsoft was initially responsible for all these SDET postings.

Microsoft used to have bragging rights when it came to the ratio of testers to developers. For some areas, it was rumored to be 2:1 – unheard of in the non-critical commercial software industry. Perhaps Microsoft is leading the way once again with the hiring of SDET’s. But I also noticed that Microsoft didn’t appear to be hiring any professional software testers.

In 2006, I had a chance to talk with a Microsoft HR person, responsible for interviewing testers. She told me that Microsoft now only hires people with development skills in a current language (C, C++, C# or java) for employee positions. They only hire for SDET positions – all software testing jobs were temporary contract positions filled by agencies. She went on to tell me that SDET’s actually do more programming than developers, so their job was even tougher than the developers’ job. Jokingly, I asked “So SDET’s must earn a lot more than developers, right?” She didn’t answer and changed the subject.

So what does an SDET do? Since SDET’s are developers, they write code – specifically test tools and they also presumably perform testing whenever they haven’t hired temporary testing contractors.

What could be wrong with this? As a test professional, I can see the value of having a developer write custom tools to aid in testing, but by not hiring testers as full time employees and hiring masses of SDET’s is fraught with problems and reveals a lot about Microsoft.

The first problem is that it is a well-known fact that development skills and testing skills are almost mutually exclusive. It is very rare to find a good developer that tests well. It’s hard enough to get devs to even minimally unit test their code, let alone going beyond that. If there really are as many great developer/testers as Microsoft has hired, why not fire all your developers and hire only SDET’s?

Most testers, on the other hand, don’t have development skills, aren’t good developers or do not want to become developers. An obvious questions that always seems to escape the mind of hiring managers and HR people is this: Why would someone accept a testing job if they have good, current development skills, since there are typically 15 dev job openings for every 1 test opening. Test jobs are the first to be cut when times get tough and dev jobs typically pay more than test jobs. Developers also get more respect.

It’s also not productive. Division of labor into specialties is much more effective in both the quantity and quality of work. When people work in the areas that they are good at and enjoy, it is much more effective. Having developers check their own work is like proofreading your own writing – a lot of mistakes are not caught.

The second problem might best by illustrated by a story. Imagine you have won the lottery and you are having your dream house built. You decide to go to the work site to check up on the progress of construction. When you arrive, you find craftsmen, not building your house, but creating a bunch of custom tools. Do you feel good about this? Why do they need to make special tools? Does this mean repairs will be difficult? Oh, and for the actual construction of the house, they will hire day laborers.

In Tools We Trust

When test automation first appeared on the scene, tool vendors were criticized for over promising results. Marketeers made it sound like anyone could use these tools to write tests, run tests and customers would automagically get higher quality software. In 1999, James Bach wrote a paper titled “Test Automation Snake Oil,” which became famous for exposing this kind misrepresentation. But 7 years after Bach’s published paper, it appears that Microsoft has re-bought the test automation myth.

To be sure, test automation can be good, effective and dramatically increase productivity and software quality – but it doesn’t happen automatically. Automation is good for simple tasks, checking detailed calculations, performing tedious tasks and highly repetitive tasks like smoke tests and regression testing. As a tester, I like test automation for a couple of reasons: By freeing up routine testing tasks, it allows me to perform more in-depth exploratory testing.  And writing automated test scripts is also a refreshing break from testing.

By over relying on test automation, many types of errors will be missed, especially errors that users are likely to experience. Much of the test automation is geared towards API-based testing and DB testing which means the GUI is bypassed during testing. Another sign that testing is misunderstood, comes from the failure to recognize that different types of testing reveal different types of errors and that you cannot simply replace one type of testing with another.

But Microsoft does contract out for temporary, manual testing, so perhaps that fills these gaps. That’s possible, but there are more problems lurking here too. These are temporary, and usually short-term contracts, so no product experience built up and carried forward to the next release. Also, many employment agencies pay low wages for these positions. This has a direct consequence on the type of candidate that will accept these offers.

And what message does this send out about how software quality is valued? They company is not willing to hire FTE’s to test. Temps are here today; gone tomorrow – they don’t get to know that application under test intimately. And working as a temp, how well would their suggestions and criticisms be received, and that’s assuming they are asked?

Extreme Makeover – Microsoft Edition

A conversation with a Microsoft employee revealed some key information. He said that Microsoft used to be made up of 20% developers and 80% non-devs. For some reason, Microsoft decided that almost every employee should be a developer (receptionists, janitors and food service, like testers, are temps hired through agencies). Today, Microsoft is 90% developers. To paraphrase Dan Aykroyd from his Saturday Night Live Scottish skit days, “If you aren’t a developer, you’re crap!” If you view Microsoft through this lens, it all becomes clear.

Microsoft is a very dev-centric company. This would be logical, since they are a software development company, but development is much more than programming. So I should say Microsoft is a very programmer-centric company. Development would encompass other areas such as marketing, requirements gathering, design, test, project management in addition to programming.

Why are SDET’s performing testing? Because they want to? No. Is it because they really want to be developers, but for some reason they were not hired as devs? None of the SDET’s that I’ve talked to want to remain in testing. Unlike development, testing has an infinite workload – you can always perform more testing, in addition to documenting test cases, generating and maintaining test data, analyzing requirements, etc.  This has profound implications when it comes to attitudes towards testing and the number of bugs found. With this lack of enthusiasm for testing, it is unlikely that they will do anything beyond the minimum needed. If they want to progress at Microsoft, their time would be better spent learning more programming skills. Microsoft has created a culture that only values developers.

By requiring their “testers” to be developers, we can glean several things from this. First, they probably aren’t very good developers, because if they were, they would be working as developers. They may be developer wannabes that couldn’t make, so they’ve taken a testing job, biding their time until a development job slot opens up. Or they might be testers that do not want a long-term career in testing, so they have learned programming as a way out of testing. Neither case sounds good. All have consequences on software quality.

The fundamental problem that haunts testing, is that companies fail to recognize testing as a skill in and of itself. It is well-known that dev and testing skills require very different skill sets and mindsets. These are not usually found in the same person. Developers focus on creating while testers focus on breaking programs. Apparently, Microsoft either doesn’t know this or think it is common for people to have these two skills or is able to skim the cream of the crop and hire these rare individuals. But then what do they do when a Google comes along and is able to steal talent from them?

Microsoft does have some “staff” test functions for test automation and performance testing for groups that can’t justify hiring these specialists. But here too lies another disconnect: Usually, when writing automated test scripts, you need detailed application knowledge, unless your tests are very simple. Also, many bugs are usually found during the creation of automated test scripts, but these specialists are remote and in my case, did not entered a single bug in the defect tracking system. Maybe it’s because test automation was done so late in the lifecycle, all of the bugs were fixed. Maybe their scripts didn’t exercise the application very well, so no bugs were found. Maybe the automation specialists didn’t know the application’s business rules. Maybe they felt that it wasn’t their job to report bugs, since their task was to automate. I never met or saw people from either staff test group.

Groping in the Dark

Maybe Microsoft is doing the right thing, or something that feels right. Maybe they became so frustrated at trying to hire testers, that they’ve just given up. Maybe there are so few testers that are exceptional, that it’s not worth the effort to recruit them. Maybe previous testers were so poor that they can get the same poor results cheaper by hiring contractors. Attaching programming requirements for full-time employees in testing is much easier and more familiar to Microsoft. Even if a test contractor proves himself valuable, rules are rules and the software giant fails to capitalize on this.

Hiring good testers is not easy. Even experienced testers may not be good due to the common industry practice of moving “duds” into testing, which makes the “testing is for losers” mindset a self-fulfilling prophecy. Then there are different types of testing: GUI, functionality, database, performance, etc. And there are approaches to testing: glass box black box, etc. And each tester needs to be good. Testing tends to be repetitive, but the good tester will always be thinking of news ways to test the same functionality. Thinking is not repetitive. Testing tends to be a high burnout job. Environments can be stressful, especially towards the end of the project, but also usually lacking in resources and being held to a higher standard than analysts and developers are held to in the area of documentation, which doesn’t make sense since requirements and functional specifications are foundational documents for testing.

Another problem that plagues the software testing world is lack of testing curriculum offered in colleges and universities. Anybody can be a “tester.” This means that testers have wildly varying backgrounds and you never know who will be a great tester and who will be a lousy tester. Testers often fall in line with the low self-esteem image that others paint them with. One common response is an emphasis on backend testing and API testing. While these have valid places, testing the application through the GUI, using it as the users would use it, is not in vogue. Besides, it looks so much cooler to be working in an IDE (integrated development environment). Your respect will go up when others see you single-stepping away. Using the actual application puts you on par with the lowly user.

Testing suffers from being defined and run by non-testers. People with little or no test experience (or worse, people who believe they have test experience) always seem to wind up driving the test process. It looks like the same thing has happened at Microsoft.

One might think that people with computer backgrounds would be good testers, but this is not always true. The desire to think, have a strong curiosity and self-motivation are much more important.

Where Have All The Evangelists Gone?

Microsoft created a job position called “Evangelist.” The purpose of the evangelist is to spread the good word of whatever technology or process Microsoft wants others (inside and outside Microsoft) to use.

Does Microsoft have a Test Evangelist? I can’t find one, which I consider a good thing given Microsoft’s current state of testing practices. I doubt any serious, professional tester would ascribe to the testing philosophy Microsoft has adopted. This leaves me wondering who at Microsoft made this decision to contract out all testing and only hire programmers as SDET’s? I also wonder how this conclusion was reached.

The Proof is in the Products

With the heavy emphasis on automation and the use of temporary contractors, what would I expect to experience as a user of Microsoft’s products?

Fewer memory leaks, fewer load/stress bugs, fewer bugs in simple user scenarios (positive test case scenarios) and fewer regression errors (features that a patch breaks or features that do not work on a new version).

On the downside of over reliance on test automation, I would expect to see more errors in negative scenarios, more complex (real-world) user scenarios, error recovery failures (bugs in recovering), GUI bugs and usability issues.

In short, test automation often translates into testers using the program less and certainly not in ways end users would use it (API testing)

The Sincerest form of Flattery

The sad thing is that other software companies look at Microsoft and want to emulate them. After all, Microsoft is the largest software company in the world. These MS-wannabes run the same “Software Developer in Test” job listings.

Ironically, even some of MS’s biggest competitors like Google are following in Microsoft’s footsteps. Fortunately, searching isn’t a critical function, many alternatives to Google exist and you can change search engines instantly. It’s not as easy to change your operating system.

Microsoft is still a world leader in software. If other companies emulate their approach to software testing, this will lead to a collective worsening of software quality in the industry, just when the need for higher quality software is increasing, as computers are placed in the heart of more and more everyday systems.

Posted in Microsoft | Tagged , , , , | Leave a comment

Unit Tests – Please tell the Hiring Manager what these are

Another pet peeve of mine is unit testing.  Oh there’s nothing wrong with it; I recommend it highly, but clueless managers and HR people see the word “test” and think “Ah,ha – This is something testers do.”

Wrong.  Unit tests by definition are developer run tests.  Period.  If a tester is supposed to perform unit testing, tell me how that fits in to the SDLC.  This is made even funnier if you consider TDD (Test-Driven Development).

So here’s an odd thing: I came across a job listing from a testing company that is looking to hire and train the right people for testing.  Sounds good to me.  But then they state “dedication to unit testing code before or during application or service development.”  OK, now it sounds like they’re screwed up.

Later they add “ability to…run and report Developer’s unit testing.”  Well, OK – the developer writes the tests and you run them.  Sounds bizarre to me, but perhaps these are not automated unit tests, but I think we’ll see Bigfoot before we see developers documenting their unit tests.

To recap:  This company specializing in software testing should know that unit tests are not the responsibility or domain of testers, but they don’t.  Then they back-off, saying testers should execute dev-written unit tests, but then they come back around saying they will train the right people to write unit tests.

Now it wouldn’t be a bad idea to teach testers how to read unit test code – again, assuming unit tests are actual code, not English test cases.  In this case, testers could review developers’ unit tests to get an idea of the breadth and depth of the unit testing being performed.  That would be good, but in my experience, unit testing was only given lip service and any unit testing that was claimed to be performed, wasn’t in code (like JUnit or NUnit) – so who knows if any unit testing was really done.

That is the nice thing about have automated unit tests – there are artifacts to examine.

Posted in Job Postings, Software Testing & QA | Leave a comment

What’s the “U” in UAT stand for?

I always thought UAT was User Acceptance Tests, but apparently this has changed over the past couple of decades.

The idea behind UAT is that actual, real-life users of the application would test it after it came out of development and “QA.”  Real users know what they want from the system and how they’ll use it.  Ideally, they would write scenarios early on and be ready to test them when the software was delivered, usually in a staging environment.  Smart testers would review the UAT team’s test cases, to make sure they – the testers – hadn’t missed anything.  Testers might offer to help the users write test cases – showing them a particular format, making sure the steps and expected results are clearly documented, etc.

But in the past few years, testers are now expected to write UAT test cases and execute them.  This defeats the purpose of UAT.  This is not UAT, it’s TAT – Tester Acceptance Tests.  This is like sending someone to take a test drive in a new car you want to buy, instead of taking the test drive yourself.  A lot of risk opens up.  I would definitely recommend this Yugo.

I have no problem with testers helping the UAT team write the test cases, showing good formats and collaborating with them to make sure nothing is missed (this assumes the testers know more than the users which is rarely the case).  But when UAT is solely the domain of testers, we’ve got a problem.

Posted in Software Testing & QA | Leave a comment

More Pathetic Job Postings

Develop and maintain test strategy and test plans for data warehouse and web applications developed using Cognos suite of tools, SQL Server, Oracle, Web Servers, VB, Windows, etc; review, approve testing “Project Plans”; interface with business analysts, SMEs, development partners and clients as required; manage daily testing activities; coordinate, report testing status, estimates with management; perform QA reviews to ensure quality of deliverables; provide QA best practices/standards for team to follow. Require: MS in CS/CE. FT, Comp salary, travel involved.

Mail resumes to:
HR, Spansoft, Inc.
29451 Greenfield Rd.
Ste # 213
Southfield, MI 48076

TPOT says “So they want someone with a Master’s degree in CS or CE!?!? And this “tech company” wants you to mail – yes, snail mail – your resume.”

Job Title                                            Location                Salary              Last Updated

Quality Assurance Team Lead Ann Arbor           $12.25/hr      11/04/2011

TPOT says If they’re paying the Lead that much, I’d hate to see what they are paying testers.  Junior testers probably have to pay the company to work there.”

Software Test & Quality Assurance Engineer

Research, design, develop, and support software applications and systems for clients, focusing on testing, defect management, and quality assurance: gather and analyze clients business process to ascertain its needs and requirements in software applications…

TPOT says “Is that all – I only have to research, design, develop and support applications and systems?  Oh, ya – test it too.”

Quality Assurance Technician

 TPOT says “Technician?  Believe it or not, this was for a software QA job. Let’s see, where is my software QA toolbox?  Can you hand me the .NET wrench?

General Motor’s Needs to Recall these Job Postings

Former HP CIO has moved to GM…don’t know if he’s responsible (thru his leadership style) for these bizarre requirements:

For software test jobs, they contain…

  • Software automation experience with documented return on investment

TPOT says “At least they’re only asking for documented ROI, not a real ROI.”

Quality Assurance Business Analyst and Operations Lead-INF0004877

  • The QA Lead maintains the ability to influence projects without having to lean on authority to successfully deliver a quality product that may cross several functional teams.

TPOT says “Three jobs wrapped in one (because QA just isn’t that demanding) and, oh by the way, be able to influence people but don’t ask us for help – we can’t do this, but maybe you can.”  GM is clearly showing they don’t value quality.  Perhaps that’s why I’ve never purchased a GM vehicle.”

A posting from Modis

As a Quality Tester you will be a member of a team that has vast responsibilities. You will work directly with application Business Analyst, business customers, and project team members to identify appropriate test case coverage and related test data requirements…The whole time you will be responsible for documenting test cases and application functionality.

Skills Preferred

• Agile

TPOT thinks “Another clueless agency representing a clueless client.  Why would a “Quality Tester” (testing quality in to a product?) be responsible for documenting application functionality?  I want to work as the BA in this company!  And they want Agile, but Agile de-emphasizes documentation (actually, usually eliminates it, but that’s another story, so why are they insisting on documented test cases (almost always a poor investment)?

Here’s one that’s hard to believe…

Job Description
Quality Assurance Associate/Office Assistant

TPOT thinks “Just answer the phones, receive deliveries while you test, because you really don’t need to think or concentrate while testing.”

After this company lists all the requirements like “Supreme attention to detail” and requiring that the applicant MUST HAVE EXPERIENCE in testing and defect tracking tools, they are willing to pay a whopping $13/hr!  Oh yeah, this is a 20-30 hr/wk job too.


Work to an aggressive QA schedule including weekly live site changes, large scheduled projects and unscheduled high priority projects requiring QA.

TPOT thinks “Aggressive QA schedule – we won’t provide you with the artifact, time and resources you need so plan on putting in a lot of hours.  “…and unscheduled high priority projects requiring QA”  Remember that aggressive QA schedule we forced on the QA team?  Well, that caused a lot of production bugs and now we must have you QA the fixes that we didn’t schedule for, so plan on working even longer hours.  And don’t ask us to improve our process!”

Test Manager

from CareerBuilder

Employee Type : Contractor

Industry : Banking – Financial Services

Manages Others : Not Specified

Job Type : QA – Quality Control

Experience : At least 10 year(s)

Relocation Covered : No

Post Date : 12/16/2012

Contact Information

Ref ID : 12-06108

TPOT thinks “A contractTest Manager for 2 months – now that’s dedication and commitment to quality!  Well, at least 2 months on quality.”


Posted in Job Postings, Software Testing & QA | Leave a comment

Actual Job Listings from Dice

Here’s an old collection – Oh, yes, I’ll be adding newer ones – for your entertainment.  These are real posting found on DICE.  Nothing has been altered.  Some are funny; others pathetic.

Position Title: Testers

Skills required: Very stron in Web Application Testing
Location: Long Beach
State: CA Pay Rate: Keep it low
Area: 562 Length: 6 Months extendable

TPOT says “At least they’re honest about the pay rate 🙂  Stron testers shouldn’t get paid too much.”

Position Title: Senior Tester

Skills required: Windows Environment, manual software testing,
Location: Orange County
State: CA Pay Rate: DOE
Area: 714 Length: 6-7 weeks

TPOT says ” 6-7 weeks is more than enough time to test any app.”

Position Title: Contract Business Systems Analyst

Skills required: Business Systems Analysis, Word, Excel, Test Script
Location: Burbank
State: CA Pay Rate: Market
Area: 818 Length: 1 1/2 – Ongoing Months

 TPOT says “Testing is just another tasks that can be heaped on to a “real” job.”

Senior/Lead QA specialist needed for a 2-3 month project. Database testing of a SQL Server Database.
Lots of testing of VB screens. Plug in database information and test. Most data is in flat files.  Load into database and verify the results. Some stored procedures. They do not have a testing tool available at this time so all testing will be done by hand. Experience with BRIO and accounting applications is a plus. 1st month will be spent creating the test plan and the 2nd/3rd will be doing the actual testing.

TPOT says “Waterfall – just define all testing up-front, then just run the tests.”


Position ID: 0708

DICE ID: donnmoor

Job Description:

Upcoming positions need to provide Quality assurance
testing for our pharmaceutical client in New Jersey.
Client is requiring that all candidates must have
pharmaceutical/biotech industry

send resumes and we will call all candidates that
fulfill the requirements.

TPOT says “When you put in unrealistic requirements, you get unrealistic responses.”

Position Title: QA Tester

Skills required: Mercury Interactive and Rational Test Manager
Location: IRVING
State: TX Pay Rate: ALAP
Area: 972 Length: 6months

 TPOT thinks “ALAP – As Low As Possible.”

Title: Associate Quality Assurance Developer

Skills: Human Resources or Payroll background; SQA Robot

Date Posted: 06/18/01

Location: Pleasanton, CA

Area code: 925

Tax Term: Contract (W2)

Pay: $20/hr

Length: 1 month



Position ID: MSF010604A

DICE ID: trinite

Job Description:

We are looking for a Software Quality Assurance Developer to conduct acceptance testing, and do test

automation for Payroll and an Customer Satisfaction team.


1. Knowledge of office productivity tools including MS Word and MS Excel, email.

2. Knowledge of Automation development tool such as SQA Robot, or development language such as Visual Basic

3. Human Resources and/or payroll background

Highly Desired:

Experience Testing software

If you are interested in hearing more about this opportunity, please call Angela Tuscano at


or email your resume to put the DICE ID in

the subject line).

Thank you and we look forward to hearing from you.


Contact for more information:

Trinite Inc

Trinite Inc

2700 Augustine Drive, #261

Santa Clara, CA 95054

Tel: 408-969-9710

Fax: 408-492-1699

TPOT says “Where do I begin with this gem?  Let’s take it from the top..

The title “Associate Quality Assurance Developer” – what is this?  They forgot to add Business Analyst and Project Manager to the title.  Then there’s the whopping $20/hr for a 1 month contract.  Good thing Pleasanton, CA has a low cost-of-living.  Conduct UAT and do test automation on payroll and maybe another app – in 1 month…for $20/hr.  I would make a list of everyone that applied for this job and blacklist them.  Oh ya, you should have an HR and/or payroll background, in addition to your SQA Robot and VB background.

Posted in Job Postings, Software Testing & QA | Leave a comment

TPOT’s First Law of Software Testing

The most important aspect of software testing is testing software.

Sounds funny? Just look at most (pathetic) job postings – most emphasize writing test plans and master test plans, detail test plans and test cases in addition to having development skills, DBA skills, project management skills and more! More in future rants.

Test case and test plan documentation requires balance. It is very easy to go overboard and document to the Nth detail – and many companies (especially consultancies) love this. Their dream is a 1,500 page test plan because it’s very visible. But it doesn’t say this has been tested! If you had limited time and money, which would you rather have – a document full of test cases that have never been run or someone running actual tests?

Test documentation does prove valuable for showing what was tested and what wasn’t and to keep you on-course (or let others know what was tested).

The other balance is the detail level of test cases. Sometimes test cases become a user manual assuming the user knows nothing of the AUT (appl under test). And many other times, you are bludgeoned to death by zero-value boilerplate.

As testers, we must do a lot of things that support our testing effort, but let’s try to minimize the overhead and eliminate the ridiculous.

Posted in Software Testing & QA | Tagged , , , , , | 1 Comment

Is SCRUM Making You Sick?

One popular SCRUM theater antic is to have all the developers and testers sit together at one table while they perform their work.

My experience shows this is very distracting. If one “team member” gets a phone call, everyone gets interrupted. If someone comes in to talk to one person, everyone gets interrupted. And if you work with immature people, who text and IM jokes and other things around and then try to suppress their giggling, everyone gets interrupted – and yes, this is a true experience.

Then there’s the cold and flu and who knows what else. By sitting next to your sick co-worker, I’ve seen SCRUM teams wiped out and sprints miss their deliverables because of this. Now to throw gasoline on this fire, your employer probably has PTO – Paid Time Off. What does this mean? It means there are no sick days. So if you stay home sick, you are using your vacation time up. This virtually guarantees that sick employees will come to work no matter what. Most managers (SCRUM masters would cower) are too wimpy to tell sick employees to stay home and/or go to a doctor.

Posted in SCRUM, Software Testing & QA | Tagged , , , | Leave a comment

New Annoyance Award goes to Adobe

Got Adobe?

If so, you’ve undoubtedly noticed that after installing a new update, it asks you how you want to be notified of new updates.

I can’t tell you how much I hate Adobe’s new way to annoy users by ignoring their preferences, resetting the default preference to Adobe’s preference and forcing you to re-select your ‘new update’ installation preference.

Posted in Software Stupidity, Software Testing & QA | Leave a comment

What does SCRUM short for?

Myth: SCRUM is not an acronym.

Reality: SCRUM is short for SCRewed Up Methodology

Posted in SCRUM | Tagged , , | Leave a comment

Welcome to T.P.O.T.

Welcome to The Pissed-Off Tester – T.P.O.T.


Economics is known as “the dismal science.” I claim that Software Testing & QA is “the dismal career.” Why am I pissed off? Let me count the ways.


Because testing is not taught as a formal curriculum, this means that every tester has come through some sort of nook and cranny. It’s nice that this opportunity is open to all people, but this double-edged sword also causes a wide-variety of skills and backgrounds. This leads to a wide range of expectations and pay. I’ve seen a testing job for a payroll application advertised for $10/hr on Dice. I guess the payroll system isn’t too important. Some testers come from a development background while others were secretaries. With such a wide range of skills (or lack thereof), we must wonder who is hiring these people and why. Clearly, they do not have a good idea of what is needed from a tester. Perhaps they’re just looking for a scapegoat if things go wrong.


None of the Project Managers, Directors and CIO’s that I’ve worked for have a background or experience in software testing. By looking at current job postings, it’s clear that they still don’t have a clue. I will cover this nonsense in a separate rant.


No doubt software testing & QA has made major leaps and bounds in the past two decades, but is it keeping up with technology? Probably not. Consider the spectacular increases in the computational power of hardware – yet most applications run slower today then they did 20 years ago. Sure we’ve added graphics, audio, video, Internet-enabled, etc., but software demands are outpacing hardware increases. Compounding this is that more and more devices rely on software; I have to wait for my toaster to perform Power On Self-Tests.


And at this time when software is responsible for controlling more and more critical systems – like engine control systems, medical devices and electric power generation and distribution systems – we enter the age of agile.

Agile methodologies have brought more focus to software development and corrected a lot of problems with waterfall, but what is really scary is the lack of analysis that most agile shops perform. At least there’s no paper trail (documentation) leading to the guilty party/parties :). More on this is a separate rant.


Software testing still suffers from the “red-headed step-child” syndrome – the bastard child of software development. Perhaps even more now than in the past, because if they were doing software testing back in 1970, then they probably took quality pretty seriously. Today, having a “tester” or better yet, a “QA Analyst” is a checklist item. It would look too embarrassing not to have one of these token workers on your team.


Software quality has advanced, but mainly on the development tools side – IDE’s, automated unit testing tools, source control, code profilers, etc. There have been advances in testing tools – the capture/playback and behind the UI, but I don’t think the mindset has changed. Testing is still an afterthought or lip service – even with full-time testers on the team. If testing is the culmination of the project – verifying that everything is working as planned – you would think that this would be the centerpiece of software development.


I recently watched a video where testers were saying “We need to get programmers involved more in testing. We should offer them discounts to our testing conference.” I have no problem with that, but I was wondering if developers ever thinking the same – we really need to get testers involved with us; we need an outreach effort to get testers to attend our conferences. Don’t think so. Most “QA people” are happy to get out of QA and “move up” into programming or DBA work or anything but testing.

At any rate, I will post my rants and raves on this blog. And (will try to) keep them much shorter.

Posted in Uncategorized | Tagged , , , | 1 Comment