WTF?! Did Microsoft just change my Windows Admin UserID?

File this one under Microsoft Windows 8 (8.1 reaaly) horror stories.

I went to use Skype (purchased by MS) on Windows 8.1.  I had already gone thru the hassle of setting it up under Windows 8.0 – and no, as an existing Skype user you cannot simply bring up Skype, sign in and use it.  Microsoft forces you to use an email address and password to use Skype.  MS does not allow you to cancel out of this process, even though there is a cancel button.  I had to kill it using Task Manager.

So back to Skype & 8.1, when I went to use it, it now asked me to sign in – not to Skype, but to my local Windows admin account on my PC.  So I did.  Then it asked for the email address and I entered that.  Then they emailed a security number to that email addr and I needed to retreive it and paste it in to authenticate it was really me.  Did that.

Then a Skype wizard came up asking me if I wanted to store my Skype msgs and info in the cloud and “No” was “Not Recommended.”  Remember, I had already used Skype for years and also on Windows 8.0.  So I just accepted the Wizard’s defaults and tested Skype.  It appeared to work.

I wanted to test that the WiFi autoconnect worked from the location I was at, so I shutdown my computer and restarted it.  I logged in and my login failed.  Then I looked above the password textbox and noticed that the user name for my local Windows Admin account had been changed to my Skype email address!!!  I entered that password and bingo, I was logged into my laptop.

I can’t believe MS would change my local Windows Admin user account name, so I went in to User Accounts and sure enough – my old userID was nowhere to be found.  So now MSFT has my laptop’s Admin userID and password.  I’m feeling real comfortable about that!

Aboslutely, positively – Windows 8 will be the last Microsoft product I will ever buy.  I dumped Office in 2002, dumped IE in 2004, don’t use Xbox and would never buy a Windows-based smartphone.

Now looking at the Skype alternatives.  DUMP SKYPE NOW!

Posted in Microsoft, Software Stupidity, Windows 8.x | Tagged , , , , , , | Leave a comment

Signs a Company isn’t Commited to Quality

Over the past couple of years (maybe more), I’ve noticed that it has become fairly standard to job requirements to include some kind of phrase about “being able to influence others” or “persuade others” when it comes to software quality.

Here is an example from General Motor’s from Jun 4, 2013…

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.

Here’s another from PROLIM Global Corporation, whoever they are…

  • Excellent communication and persuasion skills to be a strong advocate for quality

Anyone who knows or has read anything about bringing quality to an organization, knows that the buy-off starts at the top – the CEO.  You won’t need to “persuade” your co-workers that they should take quality seriously, because management will get rid of those who don’t.

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

Who Wants to be a Billionaire? Windows OS Replacement Needed

The market is ripe for a viable Microsoft Windows OS replacement.  Many people are sick of being screwed by Redmond and TPOT is no exception.

I wonder if a shell could be developed and still give good performance?  I think this was done back in the Windows 3.0 ro 3.1 days.

Ubuntu or some other Linux flavor might do, if a decent UI/desktop exists (I haven’t kept up on Ubuntu).

Google certainly has the monetary and brain resources to develop an OS, but looking at some of their apps makes me wonder if they know much about users and UI’s – which is odd, since their uncluttered search engine page hits this spot on.

Apple can’t or won’t do it – to closely tied to hardware – technologically and financially.  But many users will defect from Microsoft to Apple.

Think of the market opportunities.  No corporation is the world will migrate to Windows 8.  The costs is astronomical – training (retraining, really); I’m not even considering the cost of buying touch screen hardware.

Of course, Microsoft will probably announce Windows 9, which will “unscrew” the screwed-up Windows 8.  Kinda reminds me of Kramer on Seinfeld – there’s a problem, Kramer jumps in and makes it much worse and then when things return back to the same problem, you feel so much better because the Kramer problem was solved, but you’re still left with your original problem.

Posted in Microsoft, Software Stupidity | Leave a comment

Microsoft – A Company Adrift

Windows 8 is just further proof that Microsoft hasn’t got a clue about their user base or perhaps it just shows their greed and hubris. A company that has virtually no market share in smartphones and tablets decides to screw their entire install base by forcing Windows 8 upon them.  Recent history shows that every other OS release is a good one.  Ditto for Office 2007 and “the ribbon.”

Back in the day, Microsoft wasn’t known for innovation, but making software easy-to-use.  MSFT didn’t create the word processor, but they beat WordPerfect by making Word easy and intuitive to use.  Ditto for VisiCalc and Lotus123 (I remember how easy it was to use Multiplan back in the 8-bit OS days).

Stupid strategy

No doubt, MSFT looked into the future and said “Let’s unify our OS user interface across all platforms.”  A much better strategy would have been to do this after they established significant market share in the smartphone and tablet markets.  Microsoft forced on steep learning curve on its users – again – and many users will take a look at alternatives they may have never considered before.

One has to wonder what, if anything, is going on in the executives’ heads at Microsoft?

Posted in Microsoft | Leave a comment

Windows 8.1 WTF?!?!?!

Disclaimer – I have not used Windows 8.1 for more than 2 minutes as of the time of this writing.

I decided to “upgrade” from Windows 8 to 8.1 to get back the familiar Start button and operations, so I don’t have to F— around with those stupid tiles – the new name for desktop icons.

The upgrade took 10 hours n my i7 quad core with 8G of RAM. So I decided to give 8.1 a quick test drive and guess what? When you click the Start button, it does the same thing as pressing the Windows key did in Windows 8 – it takes you to the stupid tiles screen.

I’m hoping they (Microsoft) got rid of the annoying behavior of bringing up the clock for some unknown reason and displaying the “charms” menu when you don’t want it and not being able to bring up the charms menu when you need it.

Update

It gets worse.  Now they pop up ‘helper squares’ (not sure what the official MS term is) that randomly appear in the upper right and left-hand corners of your screen.  So when you type in something you’re searching for, like Paint or Control Panel, the square blocks the first few results – usually the one you want.

After getting my new computer with Windows 8 installed, I went thru all the pains of re-establishing my cookies and credentials for banking and other websites, plug-ins, etc.  8.1 wiped all those out, so I had to do it all over again.

I noticed my computer was ahead 1 day.  How did that happen?  Changing the date is another adventure in Windows 8.  I went to install MS Security Essentials and it told me I don’t have to, because Windows Defender is better and already installed.  OK.  Then I bring up Windows Defender and it states the virus definitions are 127 days old!

I still don’t understand how and why the clock appears in the lower left-hand corner.  I just know it appears when I don’t want it to and won’t appear when I want it to.  Then it requires one click or keystroke to get rid of it.

The best thing about 8.1?  The very colorful default wallpaper.  They ditched the dull Seattle Space Needle rendition.

I am so glad Microsoft doesn’t make cars!

Posted in Microsoft, Software Stupidity | Leave a comment

Thank You Microsoft for Windows 8!

From the employees and shareholders of Apple.

Posted in Microsoft, Software Stupidity | Leave a comment

Clueless Companies – Symantec’s Stupidity

I went to run a full virus scan and noticed that the Norton Security Suite has a completely new look. One of the things that they did right in their past major change, was to have a checkbox option to shut the computer down after the scan completed. Another useful feature was the ability to skip Live Update, since it regularly updates in the background.

Well guess what? These boneheads have removed the shutdown option and the skip Live Update option. Truly clueless.

Hopefully, they’ve fixed the problem where the background scan starts up – even when you are perform a Norton virus scan!!! I kid you not.

And why did they change the UI – again? Keeping the UI the same used to be considered a selling feature because people didn’t need to re-learn the same software. That’s gone out the window these days.

Posted in Software Stupidity | Leave a comment

SCRUM User Story Quiz

As a ____ I want ____, so that _____.

This is an example of:
A. A SCRUM User Story
B. An untestable requirement
C. All of the Above

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

Job Postings: A New Trend – Copy & Paste

I’m now convinced that hiring managers, HR people and agencies are copying and pasting old or different job postings before the place them on Dice or Monster.

Ally Financial had a posting for ResCap, but it turned out that this job had nothing to do with ResCap (Residential Capital).

Here’s a posting from Dice today…

Manual QA Analyst

RESPONSIBILITIES:

• Develop test cases/test scripts by proactively reading requirements and respective documentation.

• Manage test execution and execute automated and manual scripts against new build.

• Effectively communicate with internal team members and discuss functional requirements.

• Conduct walk-through of test scripts/cases and test results to obtain sign-off from internal QA team, development, and management.

• Identify and create test data

• Identify and escalate issues and risks.

• Own defects from identification to closure. Identify, record, and track defects. Actively participating in defect resolution. Define and execute retest cases/scripts/data

Design and implement modular and reusable automated testing solutions that satisfy testing requirements.

• Develop and maintain test scripts that automate testing of enterprise applications through the entire product life cycle.

• Create and execute test scripts, cases, and scenarios that will validate system performance according to specifications.

• Produce reports and documentation for all automated testing efforts, results, activities, data, logging and tracking.

• Frequently communicate test progress, test results, and other relevant information to team members and management.

• Develop/enhance and document automated testing methodology.

• Knowledge of QA methodology and industry-standard testing and bug tracking tools.

• Responsible for development of test strategies and creation, maintenance of appropriate comprehensive test plans.

• Work closely with Developers to understand the product and track, report, and verify bugs.

• Ability to understand technical specifications and analyze log files.

• Comfortable communicating cross-functionally and across management levels in formal and informal settings.

• Show creativity and initiative to improve product test coverage and effectiveness.

• Testing web-based applications in a high-availability, high performance and large scale environment.

QUALIFICATIONS:

• Bachelor’s degree in a technical or business discipline, generally 3+ years related experience.

• Skills in research, analysis, solution validation, and implementation.

• Ability to quickly adapt to new environments.

• Demonstrated aptitude to learn complex technical aspects of a software application.

• Strong analytical, reasoning, and problem solving skills.

• Self-directed with a high degree of initiative, ability to perform with minimal oversight and the ability to understand complex applications.

• Ability to work cooperatively in a group environment to achieve common goals; ability to build and maintain effective working relationships;

• Excellent communication skills (written, reading comprehension, listening, verbal) required.

• Ability to clearly present technical information, verbally and in writing, to audiences of diverse technical backgrounds

• Excellent organizational skills.

• Experienced using Microsoft Products, especially Visio, Project, Word and Excel.

• Solid knowledge of IT concepts, strategies and methodologies.

• Understanding of business practices common across many businesses.

• Proficiency with SQL (Oracle or Microsoft) and working with databases

• Determine and prioritize multiple tasks, work on several projects simultaneously and meet assigned deadlines.

Megan Fales

J R D Systems Inc
TPOT says “There’s a lot of automated stuff (5 mentions) in there for a “Manual QA Analyst” (1 mention)- but wait!  Maybe the QA is manual and the testing is automated.  Or perhaps you are manually running automated test scripts.
Here’s one where I think they just didn’t know what to put in, so they searched on some testing items and copied & pasted them in the job listing (I have removed most the “content” to highlight the bizarre):

Technical Software Analyst – Quality Analyst

Responsibilities include, but are not limited to:

§  yada, yada, yada [TPOT here]

§  Write SQL to support test cases

Experience Requirements:

Current knowledge of QA standards and compliance requirements (ex.​ 508)

TPOT:  The above is for a specialized business insurance company.  In all my years of testing, I’ve never done 508 compliance testing (accessibility).  There’s no mention of testing UI’s, but they do talk about backend (SQL) testing, but then they jump into 508 compliance?  Hmmm.

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

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