Nice little poem from Anne Marie Charett

http://mavericktester.com/archive/please-dont-hire-me/


 If you want perfect software
If you want me to break your code 
If you want to measure me by the number of test scripts
I write If you want me to tell you its ready to ship 
If you want 100% of your product tested 
If your looking for a tester to only “check” if things look ok 
If you want your testers to mindlessly follow test scripts 
If you want training on a test process If you feel you can’t test without requirements

But if you’re looking for a tester who prides herself on the work she delivers, offers as much value to her clients as she can, and has a reputation for excellent testing, then yes, please hire me!

A fable about quality - I know it when I see it (John Guaspari)

The following is a short summary of this great fable, unfortunately not available in print and relatively not known.

The book was written by John Guaspari and published in 1985.

I had to order it through a private bookstore that had it ordered for me.

The book can be ordered from Amazon using this link. The price is only $9.95.

I hope that the summary does not have too many quality defects (punctuation errors) :)

Alex



Punctuation Inc. was a very successful corporation. They had a broad line of products like commas, apostrophes, periods, dashes, brackets, etc. All their clients were thrilled by the changes that the Punctuation Inc. products brought to their documents.

Punctuation Inc. had not only lots of great products but also a lot of competitors on the market. Their competition was just imitating their products without being able to match the innovation, design and genius of the Punctuation Inc. products.

In time, more and more competitors appeared on the market. Some of them were specialized like Excite Inc. (specialized in exclamation points) or Interrogation Inc. (specialized in question marks). These companies and their products would be popular for a while but disappear eventually leaving Punctuation Inc. to be still the place to go to for punctuation products.

One day, THE BOSS of Punctuation Inc. noticed in the quarterly reports another rival company. The rival's name was Process Inc. and they had the second place on the market for 4 quarters now. THE BOSS and  his staff thought initially that Process Inc. is just another of their rivals that do not create quality products and disappear after some time from the market.

This did not happen however as Process Inc. continued to be the second on the market for a few more quarters.

THE BOSS started to get worried. He did some market research by checking if clients buy in stores Punctuation Inc. or Process Inc. products. He found out that the clients prefer the Process Inc. products 
because they are simpler, working better and having better quality than the Punctuation Inc. products. When asked how they define quality, all clients could say was "I KNOW IT WHEN I SEE IT".

How could THE BOSS understand this definition of quality and put it in practice? He and his staff have always done high quality work and always cared a lot about the quality of their products.

After lots of thinking, THE BOSS had finally an idea.

He organized a meeting with all his staff. He told everybody that he knows what they have to do  for getting better quality of the products. That was to try harder and do better.

These suggestions did not have unfortunately the effect that THE BOSS expected will happen on his staff. They did not quite understand how to do better and were puzzled on "try harder". Didn't they do their best in the past?

The result of the meeting was that the morale of Punctuation Inc.'s employees went down and so did the market share of the company very soon.

THE BOSS understood that something else is needed. The quality problem was of course related to the defects found in the Punctuation Inc. products. Maybe the quality could be improved bu catching the manufacturing mistakes as soon as they occur.

In order to do this, lots of product inspections would be needed and lots of new workers to be hired (inspectors). The plan was to have 1 inspector for every worker from the manufacturing department.
THE BOSS's 2 vice-presidents were named as managers of the inspection department and manufacturing & design department.

The quality of the products will be overpowered with more inspections!

So this is what they did.

The results of the new change were still negative. The market share went down further, same the company profits and the morale.

The managers of the manufacturing and inspections department were blaming each other for the low quality. One of these managers was blaming the other for not doing enough checking, the other manager was defending his department's errors by explaining that this is why they have inspectors, so they can catch the errors.

Nobody was assuming any responsibility for quality.

THE BOSS was more puzzled than ever on the quality dilemma. After much thinking, he arrived to some conclusions.

The first one was that quality was a matter of survival.

The second conclusion was that Try Harder, Do Better was not the answer and the same for more inspections. The only thing that more inspections did was to increase the number of defects.

The last conclusion was that the only thing left to change was the system.

More time passed.

One day, THE BOSS realized that what is needed is a new mind-set.
The new mindset would replace the inspection with prevention.

The new mindset change happened by keeping all existing employees, both the manufacturing workers and the inspectors. All  inspectors were converted in preventors. Who is in a better position to figure out 
how to prevent defects than people who are highly skilled at spotting defects, than the people who know the process that caused the defects?

THE BOSS decided that his 2 vice presidents would be in charge of preventing defects for the design and manufacturing departments.

Punctuation Inc. started to improve the quality of the products using the new mindset, the morale started to go up, the productivity was up and the market share stopped falling.

Everybody was very happy for a while expecting that all quality problems are gone ...

Until one day when a client came to the Punctuation Inc. office with product complains. On his tax return, a + changed into a - as the vertical line fell down and in one of his letter, the ! changed into | as the . fell down too.

THE BOSS asked his vice presidents to explain these product defects, The VPs blamed each other as follows: the VP of design prevention said that all issues are related to manufacturing and the VP of manufacturing prevention said that all issues are related to design :)

These 2 VPs and their departments did not work together at all.

THE BOSS was more puzzled than ever. They did implement so many changes that were supposed to help but none of them really helped.

How was it possible that there were still quality problems after so many initiatives?

The Punctuation Inc. customers kept telling them about product quality issues and every time this happened, the Punctuation Inc. people went back to check their requirements, tight tolerances and records that  proved that they were doing everything right about quality. How could the clients still say that the quality was not good?

THE BOSS finally realized that even if Punctuation Inc. has product requirements, tight tolerances and quality records, the clients are not interested in any of these.

The clients are only interested that the products do what they expect them to do, nothing else.

Punctuation Inc. got it backwards thinking that they are the experts who can rely on their intuition for the quality of their products.

The clients are the only ones entitled to rely on their intuition when it comes to knowing what quality is.

The clients pay Punctuation Inc. to be precise and rigorous about the client's definition of quality, to determine what the client's requirements are and then to do what it takes to meet these requirements.

This is the end of the story.

THE BOSS finally understood what the clients mean when saying that quality is "I know it when I see it".

He got awarded as the Quality Man Of The Year :)

Tips and Tricks for testing credit cards validation

1. The following test credit cards validate properly but are not actually in use (http://support.microsoft.com/kb/258255):

AMERICAN EXPRESS: 3111-1111-1111-1117
VISA - 4111-1111-1111-1111
MASTERCARD - 5111-1111-1111-1118
DISCOVER - 6111-1111-1111-1116

2. How to test over limit on a credit card?

Use a prepaid VISA gift card. Pick one for 25$, go over the limit, see what happens when the card is declined. This is great as there is no revealing of personal card information in the wild

Source: http://www.testthisblog.com

A Tester Is For Life - ebook with testers' thoughts

Excellent ebook with testers' opinions, this is the link.

Some of my favorite paragraphs are below.

It is essential to notice that everybody suggests more reading, more reading and more reading. It is not possible to evolve as a tester without lots of reading books, blogs, magazines and lots of testing. But just lots of testing is not enough .....................

Alex

What’s the biggest challenge facing Testing currently? 
According to me, the biggest challenge facing the testing industry is : Test cases replacing human brains. Management feels that test cases will solve the problem. If a defect is missed, add it to the test suite. The vicious circle continues. And finally, testers are bored


What’s the biggest challenge facing Testing currently? 
I’ve a feeling that testers have given up the passion to learn something new. There are exceptions, but the majority of testers I met here in my place are not interested in reading blogs and writing one themselves. They are just doing testing because their employer wants them to do it!

What’s the biggest mistake you’ve ever made when testing? 
Working 36 hours straight without sleep trying to finish testing and make the release/production date.  And this was after working 8 weeks straight putting in 60-70 hour weeks.  Because I was tired I missed a last minute change and bug in the application, and when it got out in the real world it caused the application to corrupt data.  Thus we didn’t have a lot of Jim Hazen
www.softwaretestingclub.com happy customers on our hands, the press ate us alive for it, and management was breathing down my neck asking why this was missed.    The lesson I learned is that you cannot kamikaze yourself and at the same time be effective in your job.  Working insane hours will only lead to mistakes and defects escaping to the wild.  I didn’t push back on the deadline and say we needed a few more days to finish.  I put a big ‘S’ on my chest thinking I was Superman when in reality it only stood for ‘Stupid man’.  It’s a mistake I have not repeated the rest of my career .


What’s the biggest challenge facing Testing currently? 
Commoditization.  There has always been a mindset that Testing is not a ‘skilled’ profession (or a profession at all), and that anyone can do it.  This has become worse with outsourcing and off shoring of the work.  There are too many people using it as a way to ‘get in’, and companies (both client and provider) that see it as a job that doesn’t need the same skills and calibre of people as development.    The fact is you need people that are highly skilled and experienced to do the job effectively, and economically.
What’s the biggest mistake you’ve ever made when testing? Trying to please your boss and accept his demand for making a release-recommendation statement. If you as a tester and/or test manager are the only person who has to judge over Go or No-Go, then you will probably be the only person blamed for either delaying a release or getting held responsible for a bug that slipped through. The best approach I have experienced was at a company where the complete team, BA, DEV and Testing was involved in the decision.

How to improve the software testing craft? 
Seek out new knowledge. Read. Learn. Talk to other testers. Try new things. Start a blog 

How to improve the software testing craft? 
Don’t be afraid to switch jobs frequently in your early career.  You will gain a greater variety of skills faster,  plus get a clearer picture of what you are looking for in your career.  Once you figure out what you love to do and are good at, then you can start specializing.   

What is the most valuable “tool” you use to aid your testing? 
One valuable tool I’m discovering at the moment is the value of coaching and teaching others as a tool to deepening your understanding.   I’m starting to think that perhaps coaching and mentoring testers is an essential tool in a testers toolkit. 

Scripting languages comparison

Related article:
Thoughts on test automation (Brett Pettichord)

Last week, I went through a lot of printed articles waiting to be read and among them were a few from Brett Pettichord on test automation.

If you don't know who he is, he wrote LESSONS LEARNED IN SOFTWARE TESTING with James Bach and Cem Kaner and is one of the experts in test automation.

The HOMEBREW TEST AUTOMATION article (available on www.pettichord.com) has interesting comparisons between scripting languages as follows:




Ruby, Python and Perl are all supported by SELENIUM.

The article is rather old (2004) but the comparison is still useful especially for testers that consider learning their first scripting language.

This convinced me of learning Ruby so will give it a try in the next months.

So far, the only language I used for test automation is VB Script with QTP.

But I am open to better language alternatives, especially since QTP is so expensive and Selenium is free :)

Alex







Brett Pettichord - thoughts on test automation

The following were selected from various articles of Brett Pettichord from 2002 and 2004. 
                                                               
- Focus the automation strategy on key features or concerns that can benefit from the added power of automated testing

- Find a way to leverage the staff skills available for testing

- Test automation is a software development process:

    1. establish milestones and deliverables
    2. define requirements
    3. manage source code, test data, tools
    4. design before coding
    5. review the code
    6. test the code
    7. track automation bugs
    8. document for other users

- Test automation is a significant investment:

    1. staff time commitment can dwarf tool cost
    2. prepare for 10 times manual effort
    3. maintenance effort can be large

- Automated regression tests find a minority of the bugs and most of them are found when the tests are created

- Can you automate at times when you can't otherwise test?

- Capture-replay fails; tests are too sensitive for user interface changes

- Test tools are buggy

- The problem with bad automation is that no one may notice:

    1. tests may not do what you thought
    2. tests may no longer be interesting
    3. coverage may be poor
    4. false alarms may be common
    5. test results may be false

- Test automation projects require skills in
    1. testing
    2. development
    3. project management

- Don't mandate 100 percent automation

- Use pilot projects to prove feasibility

- Use abstraction techniques for the user interface changes:

    1. window maps
    2. data driven tests
    3. task libraries
    4. keyword driven tests
    5. api driven tests

- Avoid complex logic in your tests

    1. keep tests linear: easy to understand, hard to make mistakes
    2. encapsulate necessary complexity

- Don't build libraries simply to avoid repeating code; hodge-podge libraries make tests hard to understand and maintain; design your libraries, don't just whip them together on the fly

- Use standard scripting languages, avoid proprietary languages

- Have testers and programmers jointly charter automation projects

- Speed the development process instead of trying to save a few dollars on testing

- Test automation tool components:

    1. languages

        * tie other components together
        * describe tests
        * provide dedicated libraries

    2. interface drivers

        *interact with the product software under test

    3. test harnesses

        * collect and execute multiple tests
        * report test results

    4. remote agents

        * provide test related services on remote machines

    5. test parsers

        * interpret and execute tests expressed in convenient form

    6. test generators

        * create new tests based on models and algorithms

- Scripting languages for testing

    PERL
        1. well established
        2. vast libraries

    TCL

        1. well established
        2. compact
        3. popular with embedded systems

    PYTHON

        1. concise support for object oriented programming
        2. integrates well with java

    RUBY - best

        1. everything's an object
        2. principle of least surprise

    VB & VBSCRIPT

        1. popular
        2. integrate well with Microsoft technologies
        3. not open source

    TCL, PYTHON and RUBY have line interpreters.

    Another up and coming scripting language is GROOVY. Like Jython, it runs inside the JVM.

    PERL has the most libraries of any of the languages listed here. For many people, this is a good reason to use PERL.

    The lack of a line interpreter for PERL is to me its greatest weakness.

    The lack of native support for general templating is PYTHON's greatest weakness.

- Understand the motivations of the test tool vendors

    1. want you to think they are experts in testing: guess what? they are not
    2. encourage belief in tool magic
    3. achieve lock-in when your test library is in their language
    4. focus on improvements that people will see during the eval period: enhancements for power users go on the back burner

- Test automation architectural patterns
       
        1. scripting frameworks
        2. data driven scripts
        3. screen based tables
        4. action keywords
        5. test first programming
        6. api tests
        7. thin gui
        8. consult an oracle
        9. automated monkey
        10. assertions and diagnostics
        11. quick and dirty

- Test automation common problems

        1. spare time test automation
        2. lack of clear goals
        3. lack of experience
        4. testing the wrong stuff
        5. high turnover
        6. reaction to desperation
        7. reluctance to think about testing
        8. technology focus
        9. working in isolation

- Rules of software development

        1. define requirements
        2. manage source code, test data, tools
        3. design before coding
        4. review test automation code
        5. test the code
        6. track automation bugs
        7. document for other users
        8. establish milestones and deliverables

- SEVEN STEPS TO TEST AUTOMATION SUCCESS

        1. follow the rules of software development
        2. improve the testing process
        3. define requirements
        4. prove the concept
        5. champion product testability
        6. design for sustainability
        7. plan for deployment

- 2 focuses for test automation

        EFFICIENCY

            - reduce testing costs
            - reduce time spent in testing phase
            - improve test coverage
            - make testers look good
            - reduce impact on the bottom line

        SERVICE

            - tighten build cycles
            - enable refactoring and other risky practices
            - prevent de-stabilization
            - make developers look good
            - increase management confidence in the product

        Automation projects with a service focus are more successful.


- User interface change: your gui test automation will likely break. what can you do?

        1. prevent developers from changing them
        2. design your automation so it is adaptable
        3. test via non-user interfaces

- Quality attributes for test automation

        1. maintainability
        2. reviewability
        3. repeatability
        4. integrity
        5. reliability
        6. reusability
        7. independence
        8. performance
        9. simplicity

- Top 10 reasons for automating tests

    1. manual testing sucks
    2. tool vendor said that capture replay works
    3. afterwards, we can fire all those pesky testers
    4. everybody else is doing it
    5. big bucks already spent on the test tool
    6. looks good on the resume
    7. keep the intern busy

- Gradual test automation: test automation benefits from a gradual approach; build some tests and se how they run before adding complexity

- Use a pilot project:

    1. validate your tools and approach
    2. demonstrate that your investment in automation is well spent
    3. quickly automate some real tests
    4. get a trial license for any test tools
    5. scale your automation project in steps

- Reasons for automating

    1. speed up testing
    2. allow more frequent testing
    3. reduce manual labor costs
    4. improve test coverage
    5. ensure consistency
    6. simplify testing
    7. just want testing to go away
    8. define the testing process
    9. make testing more interesting and challenging
    10. develop programming skills
    11. justify cost of the tools

    REASONABLE REASONS
    - high reuse
    - speed development
    - expand reach
    - smooth development

    UNREASONABLE REASONS
    - simplify testing
    - force organization
    - 100% automation
    - justify tool purchase

    MIXED BAG
    - regression testing
    - build skill and morale

- What are your success criteria

        1. the automation runs
        2. the automation does real testing
        3. the automation finds defects
        4. the automation saves time

- ARE YOU READY TO AUTOMATE?

    1. is automation or testing a label for other problems?
    2. are testers trying to use automation to prove their prowess?
    3. can testability features be added to the product code?
    4. do testers and developers work cooperatively and with mutual respect?
    5. is automation developed on an iterative basis?
    6. have you defined the requirements and success criteria for automation?
    7. are you open to different concepts of what test automation can mean?
    8. is test automation lead by someone with an understanding of both programming and testing?

- WHAT HAVE WE LEARNED ABOUT TEST AUTOMATION

    1. keep it simple
            - test automation tends to complicate things
            - the test suite itself will need to be tested
            - make sure the test suite meets the original goals

    2. build flexibly and incrementally
            - build and deliver test automation in stages
            - deliver a proof of concept early
            - deliver automation updates regularly
            - package the automation so that it can be installed easily
            - document all dependancies

    3. work with development
            - test automation is development; get help from your development experts (developers)
            - incorporate automation milestones into the development plan

    4. keep tests visible
            - visibility facilitates review
            - review encourages realism about test coverage
            - test suites require review and improvement
            - dont assume that old features are covered by existing tests
            - assess test suite weaknesses and product risks
            - are these tests still useful?

    5. use multiple approaches
            - it is better to use several approaches half-way than to use one perfectly
            - test expertise and manual testing are still required
            - manual testing is a sanity test for the automation
            - there will always be need for exploratory, non-repeated testing

    6. get an early start
            - an early start makes it more likely you can improve testability and get test APIs
            - your tes strategy will include automation from the start

    7. commitment is essential
            - it is easy for test automation to be designed as a side project. it wont get the resources it needs
            - commitment ensures that test automation gets the resources, cooperation and attention that it needs
                    * from management
                    * from development

Thoughts on testing - James Whittaker

              
- Take your testing up a level from test cases to techniques

Test cases are a common unit of measurement in the testing world. we count the number of them that we run, and when we find a bug, we proudly present the test case that we used to find it.

I hate it when we do that.

I think test cases - and most discussions about them - are generally meaningless. 
I propose we talk in more high-level terms about test techniques instead. for example, when one of my testers finds a bug, they often come to my office to demo it to me (i am a well-known connoisseur of bugs and these demos are often reused in lectures i give around campus).

Most of them have learned not to just repro the bug by re-running the test case. They know i am not interested in the bug per se but the context of its exposure. there are the type of questions i like to ask during bug demos:

1. what made you think of this particular test case?
2. what was your goal when you ran that test case?
3. did you notice something interesting while running the test case that changed what you were doing?
4. at what point did you know you had found a bug?

At Microsoft, we have begun using the concept of test tours as a way to categorize test techniques.

- It is our task to use testing as an instrument of improvement

- This is the true job of a tester: to make developers and development better; we don't ensure better software - we enable developers to build better software; it isn't about finding bugs, because the improvement caused is temporal

The true measure of a great tester is that they find bugs, analyze them thoroughly, report them skillfully and end up creating a development team that understands the gaps in their own skill and knowledge

Making developers better, helping them understand failures and the factors that cause them will mean fewer bugs to find in the future

The real value of tests is not that they detect bugs in the code, but that they detect inadequecies in the methods, concentration and skill of those who design and produce the code (Tony Hoare)

- Testing without innovation is a great way to lose talent

Testing sucks. now let me qualify that statement: running test cases over and over - in the hope that bugs will manifest - sucks. it's boring, uncreative work. 

What is interesting about testing is strategy, deciding what to test and how to combine multiple features and environmental consideration in a single test. the tactical part of testing, actually running test cases and logging bugs, is the least interesting part

High Stakes, No Prisoners - Charles Ferguson

I just finished this great book about the first 5 years of the Internet and the many changes it brought to the high technology companies and everybody's life in general.

Written by one of the founders of Vermeer Technology (creator of Front Page, later sold to Microsoft), the  book is an excellent presentation of the rise and fall of Netscape, the Internet revolution and of course Microsoft, both the smartness of the company and the predatory behaviour.

There are so many interesting things in the book and on so many topics like:

- everything about a high tech start up
- why is Microsoft so successful at destroying other companies
- venture capitalist practices
- how to create a software product architecture
- how to hire and not to hire a CEO
- and many others

Some of my favourite paragraphs are below:


- Whether through haste, overconfidence or ignorance, in 1994 and 1995 Netscape 
made a series of catastrophic technical and strategic errors that eventually proved their 
undoing. These included sloppy, indeed almost non-existent, technical architecture; 
foolish, immature hype that awakened Microsoft; failure to create proprietary advantage; 
failure to generate 3rd party support and lock-in;poor testing and quality control; 
excessive attention to minore markets to the neglect of windows

- the next mistake was the hiring of a non-technical CEO

- the CEO of a serious high technology company must have a serious technical 
background, or at least the ability to understand technology and a deep appreciation of 
its importance in strategic and organizational decisions

- i have a generally low opinion of professional CEOs, although some are superb. They 
frequently have poor technical backgrounds, no concern for anything other than their 
bank accounts, and skills that are more political than substantive. And their track records 
are not great. Of the industry's most successful companies, there's only one - Cisco - that 
has been run for a long time by a conventional professional CEO. Intel, Microsoft, Oracle, 
Aol, Compaq, Dell and Gateway are all run by founders, early employeesand/or former 
academics who somehow do okay despite not having Harvard mbas and perfect resumes. 
When you stack them up against the people responsible for the last 20 years performance 
of Apple, IBM, Netscape and Lotus and many others, you come away thinking that 
unqualified, socially dysfunctional, impatient, ruthless, egomaniacal founders arent so 
bad after all

- writing a clever piece of code that works is one thing; designing something that can 
support a long-lasting business is quite another. Commercial software design and 
production is, or should be, a rigurous, capital - intensive activity. Software products 
should be based on a broad, deep structure that can support much more than whatever 
the product contains at any given time. In addition to code that works, you need 
documentation, help functions, error handling, multi-platform support, and multiple 
languages. You also need an underlying architecture that allows you to add and 
change features, purchase and integrate external software components, and allow 
other software vendors to make their products talk to yours, add customized widgets to 
it, or embed your product into something larger of their own. A good architecture, one 
that will carry you for a decade's worth of unpredictable technology and market 
changes, takes months to develop. But if  you skip this step, as Netscape did, you 
have made a truly Faustian bargain

- one goal of good architecture is to enable systems to be partitioned so that people 
can work effectively in parallel, their progress can be measured periodically and 
everyone can finish at the same time

- There were lots of kids and Unix people at Netscape, but few seasoned technologists 
with PC software experience. Andreessen's job as chief technology officer was 
supposedly deciding what Netscape's future products should be. But he had no 
experience, and there was no chief architect; so for architectural change, who was 
minding the store? Moreover, of the entire top management team, only one person 
had any experience with a pc succssful software company

- the mangling of large companies by polished, politically astute, non-technical CEOs, 
which is a major part of what happened at Netscape, is a movie that Silicon Valley 
has seen many times before. ….. firing highly visible CEOs is all too rare, no matter 
how bad they are. Ben Rosen has done it twice, when he replaced the CEO of 
Compaq in 1991 and again in 1999. More often, however, everyone sits around, 
afraid to be the first to blow the whistle and provoke a fight. But by the time an obvious 
crisis forces action, it's often too late. 

- Netscape's story also provides a remarkable case study in how to run a high tech 
company, and how not to, at both strategic and operational levels. 

- Perhaps never in American history has a new company faced larger opportunities 
and such profound choices as Netscape did.

- Netscape's browser was a mess from the very beginning. Their first browser was 
relatively simple, so choosing hacker style and spaghetti code to reach the market 
fast was tempting. But there is a general rule in software engineering that the cost of 
fixing an error doubles with every step down the engineering sequence, from initial 
conception to architecture to commercial release, and these costs continue to double 
with subsequent releases. 

- Navigator 1.0 had almost no architecture. In Netscape's rush to market, it was 
conceivably justifiable to do this. Even if so, the failure to fix it immediately by developing 
a real architecture for the next product was utterly, totally fatal. Navigator 1.0 was 
throwaway code that they didnt throw away.

- underlying each of the next browsers (navigator 2.0, 3.0, 4.0) was the non-architected 
faustian bargain of the navigator 1.0. With each release, Netscape's cost structure, 
technical limitations and development times worsened relative to Microsoft's, as did its 
ability to support new features and interfaces, with the result that Netscape's lead, which 
was at least a year, was eliminated within two years

- Netscape's failure to architect its browser was just one of many engineering errors. 
Another, also serious, concerned testing. Software quality assurance is a complex activity, 
with a range of best practices and capital-intensive software tools for automating testing, 
bug tracking and error correction. For complex products, you even design the testing 
systems into the original architecture of the product. That's not the way Netscape did it, to 
put it mildly. According to some reports, Navigator 1.0 testers were hired by placing notes 
on bulletin boards offering to hire random college students at ten dollars per hour. A 
dangerous casual attitude toward QA persisted even well after Netscape had focused 
on mission critical application and server products for conservative, quality-conscious
 Fortune 500 clients

- during the development of Communicator 4.0, Netscape allocated about half of its 
browser development team to an effort to redesign the browser from scratch, using the 
java language. It would be difficult to exxagerate the idiocy of this choice. At this writing, 
nobody yet uses Java to write large Windows applications, because its performance is 
still mediocre and its tools, environment and user interfaces are insufficiently mature. 
After a few months, Netscape canceled the effort

- Netscape went to great lengths to make its own life more difficult and succeeded.

- Netscape decided to develop its early browsers so that they can be developed and 
released for many operating systems simultaneously, not just the multiple versions of
 Windows but also the McIntosh, OS/2 and a half dozen varieties of Unix. These operating 
systems and their user interfaces are fundamentally different from one another. 
Consequently, Netscape developed a major piece of software, the Netscape portable 
runtime layer that covered up the specific features of various operating systems. Netscape 
developers then wrote code targeted to this generic intermediate layer rather than to 
specific operating systems. This decision was an enormous strategic error. …. it was a 
major technological and engineering disaster. It meant that Netscape deprived itself of the 
best available tools for developing software, particularly for Windows.