Learn something new every day
More Info... by email
Software includes operating systems and programs that are made to run on one or more of them. Software testing is a process of examining and using software during and after development, but before release, to verify that features are working, to detect bugs, to check bug fixes, and to make sure that it works well for users. Dynamic testing, also called dynamic analysis, is the process of evaluating software as it is being used. It stands in contrast to static testing, which is analysis of a program that is done without running the program. Other types of testing include response time testing and retrospective testing.
Static testing and dynamic testing together are two of the main types of software testing that are undertaken and they balance each other in certain ways. On the one hand, static testing finds syntax errors and other coding issues and covers the entire program. On the other hand, dynamic testing of a large and complex program often may not cover the entire program because not every possible scenario can be imagined or created in the time set aside for testing.
Dynamic testing analyzes the software program in different operating environments. This includes different brands of computers and other hardware differences, possibly including multiple monitors, different operating systems, and different sets of software applications coexisting on the machine. In addition, testers may have external modules or plug-ins that they use in connection with the software being testing that increases the differentiation of the testing environments in the dynamic testing.
Dynamic testing within a software development company is likely to follow the guidelines and protocols set by IEEE (Institute of Electrical and Electronics Engineers) for software testing and the testing plan that the company has developed in accordance with these. Beta testers external to a company are often used for additional testing, and these testers are usually entirely involved with dynamic testing. Attempts are usually made to have a diverse group of beta testers in terms of hardware, operating systems, and program usage, as applicable. Beta testers, who may have a non-disclosure agreement with the company, may have a protocol to follow or be asked to use the software in the way they would normally use it, or they may do some of each. There is generally a formal reporting system for beta testers to indicate crashes, suspected bugs, failure of features to work as described, or any other unusual, unexpected, or inconvenient aspects of working with the software.
@David09 - It’s interesting that you mention ISO quality control. The software world indeed does have something similar.
It’s called QA testing, for quality assurance. They do more than test the product. They create things called test plans and they try to work on preventing problems before they occur.
It’s not uncommon for software companies who skip QA testing to create a buggy software product that they keep trying to fix with patches.
The problem with this approach in my opinion is that eventually the patches create more bugs, and the whole product eventually collapses in on itself. When that happens the whole thing will need to be scrapped.
@David09 - I’ve done some independent work myself.
In my work, I religiously follow the software development life cycle. If I cheat, even a little, it will probably come back and cost me more development time and money later on.
So I make sure that I understand what the user requirements are, design the product and build a prototype before final release.
I would have to say that building a prototype is probably the most important part. This is where I test the product, ship it off to the user, and have them test it.
It’s certainly true that when the end user puts it through its paces, they will uncover things that I didn’t expect. Since
I am the sole developer I don’t need to hire a software tester, but the user fulfills that role.
That’s OK for a side project. It’s not OK for a bigger business, in my opinion. Users tend to get a little testy when software breaks.
@hamje32 - Yeah, I definitely think you should hire software testers.
It’s a science in and of itself. Software testing is a profession with its own methodologies, procedures and testing tools. It’s kind of like following an ISO standard for business processes. The same thing exists in the Information Technology world.
I can’t imagine a business company telling an auditor that they don’t need to follow ISO quality control guidelines, because they basically figure it out on their own.
Some of the tools that testers use include unit testing. That’s where they check a small piece of code, one section at a time, to make sure that it works as intended. Little by little the pieces are verified to ensure that the whole application, when run, will work.
Software testing is something that unfortunately gets a lot of short shrift in the development world, at least from my experience working at a software company.
We’re a small shop with a few programmers so the programmers are mostly responsible for testing their own software. This is good and bad.
It’s good because the software developers know their code inside and out (or at least they should), but it’s bad because they don’t always anticipate how the end user will use the software.
For all practical purposes, the dynamic software testing is pretty much done by the end users. They report bugs and issues on a fairly frequent basis and the developers have to respond quickly and upload new patches to the website for customers to download.
I approached the boss about hiring dedicated software testers but he thinks it’s not important. He says that’s the developer’s responsibility.