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.

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.

  • 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 '15 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 '15 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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