1

In a test case, what qualifies as an input? Must it be what the tester types as input with their keyboard?

IEEE 829-2008 only lists values, constants, transaction files, and their storage locations as examples of inputs.

A test case could double as a tester-performed or automated test case. In the case of an automated test case, selecting something could be handled the same way as keyboard input.

This arose when translating decision tables where conditions are identified into test cases where inputs must be identified.

Appreciated.

Improve this question

2 Answers 2

Reset to default
1

I have not read IEEE 829-2008, so I cannot speak to what an input might mean in that specific context. That said, in general, in the testing vernacular, a input is any external value that you supply to a system.

Improve this answer
2
  • Thanks. So, entering a value from the keyboard makes sense to a text field because the value was not there in the text field to begin with. How about selecting a radio button option, or selecting specific column headers in a table and then dragging them? I'm just trying to separate decision table conditions from test case inputs and it doesn't seem fair to restrict an input just based if it was typed?
    – user176692
    Jan 20, 2015 at 22:06
  • Yes, radio buttons are inputs too. Dragging column headers is a more complicated case; most likely it impacts how the data is displayed but not how the data is processed or retrieved. Your system will have different components, each with its own set of inputs. If the system under test is designed properly, you can test those components separately. In a badly designed system, it might be that selecting and dragging a column header changes how radio buttons or text fields are interpreted, which will make your job harder.
    – user246
    Jan 20, 2015 at 22:42
1

That's a good question.

Different testers and teams have very different opinions on the topic.

Personally, I find using a very expansive definition of inputs tends to suit my purposes best. I find it useful to vary many of these "inputs" in different scenarios being executed in a set of tests.

I'll update this answer later when I'm back at laptop to make incorporate the following screenshot summarizing different types of possible test case "inputs":

http://help.hexawise.com/m/7438/l/108544-how-can-i-best-identify-variation-in-the-system-i-m-testing

(I can't add the image from my cell phone; just a link to it)

Other people find it sufficient for their purposes to have a much narrower definition of inputs for their purposes. At the end of the day, what's more important than what you call things like "operating system" and "user type" and "method of entering data" is that you include multiple different variations of each of them in your tests if it is appropriate to do so.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.