81duz1d0

Distinguished
Nov 29, 2007
17
0
18,560
LOTS of 'em
It depends on the methodology used.

If you use test-driven development, it is more likely that you won't find much errors because you do the testing first.
If you use Rapid Application Development (RAD, like the Borland/Embarcadero RAD Studio the later 'Delphi' and 'C++ Builder') you may find performance issues, database connecting issues, UI design issues and mostly RAM memory proper handling.
If you use languages of not-so-high level, like C, you may have some trouble with pointers, segFault, memory handlers, etc.
If you use some methodology that relies too much on the user's machine, like .net-dependent applications and (unusual to have issues but still counts) JVM, you may find some implementation issues.

Of experience I can say: if it works, it may fail. If it fails, it may work.
And there are things that are not 'bugs' or 'problems' but lack of features or improvements. By example: I can easily develop an application that populates a table with 1.000.000.000 entries. But I can make it work in a LOT of ways and one (or some) of them will have a better performance. About the lack of features, it is easy to IMAGINE the software you want. You can think 'uh, I wanna build a web browser that recognizes the face of the user and, according to its smile, it loads some specific URL'. Well, GREAT! But, HOW to 'make it work'? It is not a problem nor a bug, but it is something that will easily show up on a test.

Final words: if you don't wanna have problems with testing, go test-driven. If you wanna easy development, go RAD and learn some performance tricks. If you wanna go 'easy', go with ultra-high-level languages like python. And if you wanna go suicidal, go ASM ;p
 

majju2

Distinguished
Nov 30, 2010
20
0
18,560
I just need to mention 5 problems that one can encounter and go in a little bit a detail (like a paragraph each) for example like not meeting user requirements ...
Thanks for your info and help!
 

Zenthar

Distinguished
Dec 31, 2007
250
0
18,960
It all depends on the kind of tests, if we assume it's just basic functional testing, then I can think of the following (most of them are called non-functional requirements):
■Not meeting the requirement (you mentioned it, but I think repeating it is important since this can cost a lot and happens more often than it should)
■Security issues (like logging credit card data)
■Performance issues (in term of CPU, RAM, network or other resource usage)
■Scalability issues (a bit like performance, but related to many simultaneous users/requests)
■Operation issues (tough to monitor, operate, ...)
■Keeping documentation up-to-date
■Source code management and configuration management (managing dependencies and the like)

I'll let you write the text explaining all of them ;)
 

TRENDING THREADS