I seem to read always on Nairaland where people brag about their programming skills the question is " Does your program meet it is core functional business need    I doubt it ".  The Uk Information Technology companies spend roughly about 30 - 40 billion pound sterling on software development and about  30 to 75 percent of this budget is spent on software testing a lot of this testing is done inhouse and about 15 % is outsourced.  Trends shows that these companies would rather have independent software testing team.  I am sure you know the old saying " developers only see what they want to see and are  not critical with their work"

The Standish Group reports that around 30% of IT projects will be cancelled. Around 52% of projects will cost 189% of their original estimates.  Only 16% are completed on-time and on-budget. In larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget.

What is software testing?

Software Testing  is the process used to help identify the correctness, completeness, security, and quality of developed computer software. Testing is a process of technical investigation, performed on behalf of stakeholders, that is intended to reveal quality-related information about the product with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding errors. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of Software Quality Assurance (SQA), which encompasses all business process areas, not just testing.


Types of Testing

• COMPATIBILITY TESTING. Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.
• CONFORMANCE TESTING. Verifying implementation conformance to industry standards. Producing tests for the behavior of an implementation to be sure it provides the portability, interoperability, and/or compatibility a standard defines.
• FUNCTIONAL TESTING. Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, APIs, database management, security, installation, networking, etcF testing can be performed on an automated or manual basis using black box or white box methodologies.
• LOAD TESTING. Load testing is a generic term covering Performance Testing and Stress Testing.
• PERFORMANCE TESTING. Performance testing can be applied to understand your application or WWW site's scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. This sort of testing is particularly useful to identify performance bottlenecks in high use applications. Performance testing generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.
• REGRESSION TESTING. Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process. Though regression testing can be performed manually an automated test suite is often used to reduce the time and resources needed to perform the required testing.
• SMOKE TESTING. A quick-and-dirty test that the major functions of a piece of software work without bothering with finer details. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.
• STRESS TESTING. Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. A graceful degradation under load leading to non-catastrophic failure is the desired result. Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.
• UNIT TESTING. Functional and reliability testing in an Engineering environment. Producing tests for the behavior of components of a product to ensure their correct behavior prior to system integration.

What are some recent major computer system failures caused by software bugs?

1. A September 2006 news report indicated problems with software utilized in a state government’s primary election, resulting in periodic unexpected rebooting of voter check-in machines, which were separate from the electronic voting machines, and resulted in confusion and delays at voting sites. The problem was reportedly due to insufficient testing.
2. In August of 2006 a US. government student loan service erroneously made public the personal data of as many as 21,000 borrowers on it’s web site, due to a software error. The bug was fixed and the government department subsequently offered to arrange for free credit monitoring services for those affected.
3. A software error reportedly resulted in over-billing of up to several thousand dollars to each of 11,000 customers of a major telecommunications company in June of 2006. It was reported that the software bug was fixed within days, but that correcting the billing errors would take much longer.
4. News reports in May of 2006 described a multi-million dollar lawsuit settlement paid by a healthcare software vendor to one of its customers. It was reported that the customer claimed there were problems with the software they had contracted for, including poor integration of software modules, and problems that resulted in missing or incorrect data used by medical personnel.
5. In early 2006 problems in a government’s financial monitoring software resulted in incorrect election candidate financial reports being made available to the public. The government’s election finance reporting web site had to be shut down until the software was repaired.
6. Trading on a major Asian stock exchange was brought to a halt in November of 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day.
7. A May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights and occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.
8. Media reports in January of 2005 detailed severe problems with a $170 million high-profile US. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March of 2005 it was decided to scrap the entire project.
9. The latest to the list  The Heathrow terminal 5 ( I am very sure it  is costing BA millions every day)


Why do so many IT projects fail?

It is a fact of life that as many as 80-90% of IT projects run over budget or are terminated prematurely.  And even those that reach some sort of completion often fall far short of meeting user expectations and business performance goals.



What is the problem?

Common problems nominated in failed projects are:
• lack of user involvement in the design
• lack of management involvement
• lack of a clear scope

The single major reason for the failure of most projects is simple: 

These projects fail because they have attempted to automate an ill-defined process
The method used to develop in-house IT systems consists of "paving the cowpath": taking an existing process and automating it.  That's fine if you have a nice straight, mapped, cowpath.
When business analysts from IT turn up at a user department, they are often faced with users who have only a vague idea of the actual process which is in place.  Different users will have different ideas of the same process.  Process steps will be ill-defined and often ignored by those operating the process.
Inevitably, the analysts will come back with a user requirements statement which represents what they have been told, plus perhaps what they themselves imagine the user needs.  With no other input but their own (faulty) recollection of the process, users are often more than happy to sign off on this.
None of this is the fault of the IT methodology, or the analysts themselves, or even the users interviewed.  The fault is in the gap between operations and IT.
Hammer's "Business Process Re-Engineering" tries to solve the problem by ignoring the users (and the cowpath) altogether and building roads where IT thinks they should go.  Unfortunately (as Hammer admits), this often fails.


Alternative


  It's very simple: 

Before you start, document the processes that you want the system to automate



Conclusions

How do you avoid failure in a software implementation project? 

The key is to have in place, before you start the system specification phase, a clearly defined and accurately documented set of business processes and procedures.  If you have these, you will have:

• a precise appreciation of business needs and expectations; this will enable you to see the way ahead
• a firm basis for the development of the software specification; this ensures that the software will come as close as possible to meeting the business needs sooner, and ensure a smooth transition for the business
• an ideal platform for continuous improvement of business processes, either during the implementation, or after
• an accurate outline of the project on which you can base your implementation plan and monitor project progress
• a readily adaptable set of parameters on which to base system testing
• a vastly improved appreciation of business needs and expectations against which you can gauge the success of the project





Software testing is a critical component of the software development cycle. And software testing procedures are critical to the success of the testing phase. Software remains in a perpetual state of change which is why software testing, whether manual or automated, is so vital to a software product’s success. Typically, 30 – 40% of the software engineers employed at larger software development companies work on software testing and each of these individuals needs to understand his or her role in this ongoing process. Software testing procedures help ensure that they do.

Source – Testing brain, wikipedia,

NIce information there. more of an advert though.

Software testing is indeed something which, at least based on posts I see on Nairaland, is lacking. I am on the web dev side of things, but it is still applicable. One need only to check out a site and see the broken links, forms that don't work, etc. On the software development side, how many of us in here (not a knock, just asking) performing unit tests?

Granted, for the most part, programming jobs are a one-man affair with one person doing everything including the kitchen sink, we should still set aside time to do some testing of some sort. Does this mean we won't make mistakes? Nope. We are human and besides, any programmer who tells you they get it right on the first try is a liar. That being said, I firmly believe we can eliminate at least critical defects if we just carved out a section of our time to do some quality testing.

If cost is a factor, I suggest time for testing be put into the development plan and its cost built in to our estimates.

As always, my 2 cents.

What automated software testing tools do u guys use

?

candylips:

What automated software testing tools do u guys use

All the mercury suite and rational robot

Going through the threads on this forum i ran unto this topic and had a lil laugh. 'The importance of software testing'. Like popular saying , Software that hasn't been tested simply does not work. You must continously with emphasis go through the iterative process of analysis,design,implement ,test.ur work ain't done yet till u r convinced each stage has been considered to a depth. You don't need to be a rocket scientist to decipher that. Ha ha!

dueal:

Going through the threads on this forum i ran unto this topic and had a lil laugh. 'The importance of software testing'. Like popular saying , Software that hasn't been tested simply does not work. You must continously with emphasis go through the iterative process of analysis,design,implement ,test.ur work ain't done yet till u r convinced each stage has been considered to a depth. You don't need to be a rocket scientist to decipher that. Ha ha!

@dueal Software testing is much more than unit tests or the typical tests that a development team might integrate into the Software dev life-cycle.

To put it in perspective, how many programs or applications have you written and is certain is fail safe or fail hard ?
There was this Greek thing, about "if a Builders work collapses and kills the tenants son, then the builder's son too must be killed" .Can you imagine the number of people that would sign-out of software development if such things were still in practice ? 

Software fails!!! simple ,
How can the customer get some level of comfort that business critical processes would not end in catastrophe ? How can the developer give this assurance ? (Its not by saying, "we did unit tests throughout the SDLC).

Hint : Quality assurance !
so @blacksta's mix of testing and Project management is okay, but that's not the whole story
Solid testing suites and practices cannot by itself deliver projects, so i'm wondering how reference to the, now famous, Standish group report is relevant.

@Ghenghis. I don't remember saying that software doesn't fail if that's wat ur assumption is. Software is always infested with flaws no matter how much effort u put to testing or how large ur development team might be. The essence of software programming is to deliver a product that satisfys(no mob reaction if something fails) its customer and there is no implied 100% assurance that it will not show its quirks. The developer can only give his/her customer some measure of assurance that the most disastrous things won't occur from their reliance on the product( like the total loss of data). Even the Giants give no 100% assurance but we still use those products they provide (no developer or his kid gets killed). If they did then we won't have the issue of getting new service packs for an already delivered product. I only made my previous post becos i was surprised that we programmers here have to be told of the importance of software testing by the starter of this thread. If that's the case then we all shouldn't be give the title of a programmer (what's a programmer if he doesn't test).i'm certain testing is a node in the software development tree .So what's the use of a topic like 'The importance of software testing and not just software programming'. What do u think?

The measure of the reliability/fail saftyness of a software system is a function of many factors in which even the design of the programming language used is one.

@dueal i agree with you perfectly
but imagine a life support system that would require service pack 14.8.19p

Software failures in some areas are actually so critical that even you the developer might be reluctant to release the product.

So lets imagine you develop a Life support system; how much time and after what activities would you be ready to tell the customer to give you your money (cause you're done )

software dev no eazee o ,

I agree with u my brother, e no easy at all, but that hardened end of it gives us our job security cause not everyone has wat we have to remain in this business (die hard determination and a craftmans sense).

Howdy everyone, I think that i can ask you right here regarding my difficulties. The truth is I need some money soon , and I though inside a discussion board like this there can be people who can assist me. I cannot devote a lot of time mastering new stuff and invest etc, I need speedy quick funds , if possible to be continuous - has anyone learned any possible way for me to make some money in the following like 30 days? Please give me any facts that you might have and think it can be helpful? (no NETWORK MARKETING offers, please).

HAhhahahhahah

Software testing is actually a very rewarding career in IT. A key aspect of it is penetration testing. This has become invaluable especially with the rise of kid hackers intent on breaking into every major corporation website. Think of hacker groups like Annonymous, Lulzsec etc. Realise the danger they pose to corporate information security and you would know why penetration testers earn a lot.

Penetration testers exercise an application in order to identify security loopholes so developers can patch them. They are different from other types of tester who may be focused on performance issues like load and stress testing or general quality assurance. You have to have the mindset of a hacker to be a good performace tester. You need good knowledge of networking, programming and operating systems like UNIX. You have to know the common vulnerabilities associated with certain systems/operating systems. Penetration testers are basically white-hat hackers.

You need not be a penetration testers to benefit from software testing. Automated testers and manual testers simply exercise systems to ensure they are built to conform to business requirements. You use testing tools for your activity or you write programmes to automate certain test functionalities. An automated testter would need to know a bit about programming. Knowing any of VBScript, php, java, javascript would help a lot. A manual tester need not be a programmer.

For example, on a site like nairaland, testers would check through all the menu systems, buttons etc every unit of the site to ensure they are functioning without errors and according to how Seun has stated in an initial website requirements document. Business analysts would have sat down with Seun to map out and agree on these requirements before development starts. Of course requirements can change in future. Afterall the business owner is funding the project. How dare you think he cant come up with changes to the website features. Of course drastic changes would affect fees too .

As a software tester, you would be rubbing shoulders with Business Analysts, programmers (developers), Project managers, Business owners etc. I dare say developers generally dread very good testers because they have a sharp eye and can spot a bug from 20 desks away. This calls for maturity and effective comminucation. Developers do their job at great expense to their grey cells. Imagine a code that took a week to develop and you came from nowhere to find a bug in it within minutes of implementation. The programmer wouldn't like you a lot - depending on how you present your case.

Testing requires logical thinking and a break it mindset. Your whole purpose is to identify loopholes and bugs in a system. Your daily activity would be to write and execute "Test Cases" to verify and validate system behaviours.

testers can be a pain in the butt

candylips:

testers can be a pain in the butt 

Is it because your work is full of defects  - You must be a crap developer or programmer 

am not a crap developer.

but they sometimes  raise irrelevant issues and sometimes misinterprete requirements.

i hate having to explain why something is not a bug.

to get around the problem we now draft test plans as a team at the begining of an iteration

but i still don't like testers  but i hate DBAs the most

candylips:

but they sometimes  raise irrelevant issues and sometimes misinterprete requirements.
i hate having to explain why something is not a bug.

I detect a hint of attitude here. Mind you most testers are programmers as well or have some knowledge of systems development. Testers only dispute system behaviours that dont conform to original requirement. Testers are constructive critics.

candylips:

am not a crap developer.
to get around the problem we now draft test plans as a team at the begining of an iteration

This should have been standard policy. What were you doing before? Free for all scenario? Coding and testing should be guided by a plan. Of course test plans and technical specification or use cases should be properly analysed and signed off AS A TEAM. Programming in isolation may make you produce bugs you are conviced should be acceptable.

Testing and Debugging in Software development CANNOT be over emphasized. Though some errors may still arise later after extensive testing, I think the keys to a great product are:
Graceful Exits and Updates. Graceful exits, I mean when an error occurs in the app, it still allows the user save current data before exiting. Updates should be able eliminate bugs while preserving user data.

hmm, interesting topic

Software testing is different from debugging. Debugging is done by developers/programmers. Software Testing or Software Quality Assurance is done by testers analysts/software testers.

A lot of people confuse debugging with testing. They are two different things.

Debugging involves locating bugs and taking steps to correct them (fixing). This activity is typically done when developing an application by programmers. You find a bug, re-write the code to solve the problem.

Software Testing, on the other hand, are the various techniques you adopt in measuring the quality of a system against predefined requirements. The tester does not go further to solve identified bugs. This will be passed on to developers (as defects/ussues)

Therefore, while debugging involves finding and fixing bugs, testing only finds errors but the tester does not do the fixing.

Testing and Debugging in Software development CANNOT be over emphasized. Though some errors may still arise later after extensive testing, I think the keys to a great product are:
Graceful Exits and Updates. Graceful exits, I mean when an error occurs in the app, it still allows the user save current data before exiting. Updates should be able eliminate bugs while preserving user data.

Thanks for the clarification but I didn't mix 'em up. I said Testing and Debugging.

very interesting topic. I'm learning quite a lot

.NET

Most software testers go on to become Business analysts (BA). These people draw up requirements after sitting with business owners. Developers now build the system based on the drawn up requirements. Testers ensure the system has been built exactly as the BA drew it up. A frequent cause of defect is when requirements keep changing. That is, the business owner keeps asking for changes here and there.

Business Analysts earn quite a lot especially when on contract. A combination of Project mgt, Software Testing and Business Analysis is the bomb. Employers will chase after you like Mr Biggs chicken.

IBEXY:

Most software testers go on to become Business analysts (BA). These people draw up requirements after sitting with business owners.

With more organisations adopting agile methologies like scrum. the role of testers and Business anaylst are becoming irrelevant .

the days of some random BA pushing requirements to developers are numbered.

In agile, business owners and developers sit down define and prioritise requirements and test criteria.

Developers write automated unit, integration, functional and regression tests based on test criteria

in more complex systems some manual testing might be required which migh be done my testers

Automation might be a God sent but you cannot automate everything. There will still be stuff that needs done manually. Stuff like performance testing can be done automatically. YES. What about visual checks, etc.

Again developer bias means tester independence continues to be a large and favourable factor for proper software quality measurement.

Would developers really make good testers of[b] their own code[/b]?

hmmmmmm

IBEXY:

Automation might be a God sent but you cannot automate everything. There will still be stuff that needs done manually. Stuff like performance testing can be done automatically. YES. What about visual checks, etc.

it is true . . automatically testing gui functionality can be a pain so u typically need to have someone do it manually

however i have found out that a properly architected and designed code is actually very easy to setup and test automatically.

it typically just involves automating the setting up the environment to a know state, performing the test and asserting the result.

IBEXY:

Again developer bias means tester independence continues to be a large and favourable factor for proper software quality measurement.

Would developers really make good testers of[b] their own code[/b]?

it is not entirely true. what typically happens is that when the tester goes off and start testing independently without collaborating with the developer, they sometimes misinterpret requirements or functionality.

Also manual testing is just error prone especially when you have many moving parts.

the idea behind automated test is to capture whatever a tester will do manually in an automated test and run this whenever the software is built. That way you not only save time you also overtime have a suite of rigorous regression test for your software.

Manual testing however is still essential but i tend to make it important for my team to only manually test  the more complicated stuff that can't be captured automatically

candylips:

it is not entirely true. what typically happens is that when the tester goes off and start testing independently without collaborating with the developer, they sometimes misinterpret requirements or functionality.

Thats not what I meant by independence. Testing in isolation of the developer never really happens and is wrong. I was trying to say an entirely different person (different from the person who wrote the codes) should do testing. Like the popular pidgin English saying goes: "Every pikin fine for im mama eye" Every developer believes they are gurus. Developers may be blind to coding errors for various reasons. Only an outside person can really point out errors they may want to pass on as expert programming.

candylips:

Also manual testing is just error prone especially when you have many moving parts.

Didn't get that one.

candylips:

the idea behind automated test is to capture whatever a tester will do manually in an automated test and run this whenever the software is built.

There is limit to what can be automated.

what i ment was that manualy regression testing your software everytime you want to release your software is error prone because a human is involved.

for example if a tester is required to test a sequence of steps to assert a functionality. How do i prove with absolute certainty that the tester performed all these steps in the right sequence. i can't . . .

but i can code all the steps and assert the functionality and be absolutely sure that the software was tested