Software Testing a C program (Can't see anything wrong)

[Midnight]

That is my point. Having so powerful PC's, it does not make sense to waste time on C. C is okay for 8MB Flash on a Router, not for a PC.

C++, Java, Python, Ruby etc. are all far superior to C, and they are written, in C.

The mentality: "If i know C i know all the languages." is wrong.

Go write a simple CLI program that displays help when --help is passed and version when --version is passed, and add error handling.

How much time do you need with Python? 

How much time do you need with C?

My time > PC time

If it takes me 2 hours to speed up a program 2 seconds, it is NOT worth it.

 

Why are you comparing an interpreted language over a compiled language? It doesn't make sense. Also, you do know that the Python interpreter is written in C, right?

 

If it took 2 hours to speed up a program that has a runtime of 4 seconds to 2 seconds, then yes, it would be worth it.

[Midnight]

The problem is precision, especially when you input the mean.

[LukeTim]

To learn programming, yes. To build advanced applications, uhm sorry, no.

There is a heck of a lot more to programming than "advanced applications".

Perhaps OP is interested in systems programming, drivers, firmware etc. They never specified what they were interested in learning for, so we don't know, but there are still a lot of appropriate situations to use C.

[alex_read]

I've been a software testing specialist & test manager 8 years now - this seems right up my street! :c)

 

Some things you could look at:

1. What happens if your users pass in a word? If a user enters "eggs", "bacon", "beans" and "I'm not right now, no - why do you ask?"
2. Different numerical variable types have different ranges (decimal point lengths and full number lengths, - and +). What happens if you specify a reeeeeeeeeeaaaally huge number, or number with 100 decimal point-based values?
3. Typically whenever there's a divide symbol in the code, it's always best to test for a "division by 0" error.
4. What happens if no values are entered at all?
5. Does the user receive understandable and informative warnings back? I.e. "you gave me numbers 1 and 3, but didn't give me a 2nd one - nice try but you can't fool me!"

 

This is a small code sample right now, but if you're going to get more samples, you could also take a look at "100% code coverage" and "100% branch statement coverage" as a next step (I'm commenting here not knowing if you're on a programming course, testing course etc. & how heavily you're studying this side).

[Mojo-Jojo]

I've been a software testing specialist & test manager 8 years now - this seems right up my street! :c)

 

Some things you could look at:

1. What happens if your users pass in a word? If a user enters "eggs", "bacon", "beans" and "I'm not right now, no - why do you ask?"

2. Different numerical variable types have different ranges (decimal point lengths and full number lengths, - and +). What happens if you specify a reeeeeeeeeeaaaally huge number, or number with 100 decimal point-based values?

3. Typically whenever there's a divide symbol in the code, it's always best to test for a "division by 0" error.

4. What happens if no values are entered at all?

5. Does the user receive understandable and informative warnings back? I.e. "you gave me numbers 1 and 3, but didn't give me a 2nd one - nice try but you can't fool me!"

 

This is a small code sample right now, but if you're going to get more samples, you could also take a look at "100% code coverage" and "100% branch statement coverage" as a next step (I'm commenting here not knowing if you're on a programming course, testing course etc. & how heavily you're studying this side).

This is a good answer. A lot of people here have gotten sidetracked.

 

Basically, when writing software you have a specification. This tells you what the software should do.

If it accepts input, not only should you think in the intended direction, but also in the direction of wrong inputs.

Should it ignore this input? Should it warn the user? These are test cases you can describe and test against.

You describe software not only in what you want it to do, but also how to handle situations you don't want it to do.

 

Software testing is not just about "Does my software do what I want it to do?"

It's also about "Does my software not do what I don't want it to do?"