My manager asked me to test some hardware, but this hardware has been tested by someone previously and they had automated tests.

I do not have any test plan, all of the functions of this hardware are tested by scripts.

Can I still test it?


First of all, your question is way too vague and board, we can not help you without knowing specifics.

Having said that, in general, from a function point of view, there are two categories of tests we can perform.

  • Functional: this is perhaps what those scripts are for and as you described, you are not planning to test functional features.
  • Non functional: there are lots of other aspects that you can still test. For examples, does this piece of hardware conform with its own specifications in terms of dimensions? Imagine yourself as a customer, can you comfortably pack up and unpack it from its box and foams? Is there a user manual included? (assuming this is a consumer hardware not an internal not-for-sale hardware.

By coincidence, I have had a similar experience as you do now.

  • I was given a piece of repeater to test, its functional features were all tested using scripts
  • There was no test plan
  • It was a consumer electronic hardware
  • I imagined myself as a consumer, knowing nothing about this hardware. I was looking for a user manual, looking for if there was anything that could hurt me when unpacking it;
  • Its manual stated, this repeater should be disassembled within 15 minutes so I tried to do so, then I noticed, this repeater's dimension was off by 1 mm and due to this oversizing, it was scratching its metal casing, damaging both itself and its metal casing. This was a manufacturing flaw, hence no scripts could ever catch it.

Without a plan or scripts, there are still lots of tests that you can perform. Use your common sense.

  • Use your common sense and also: - Use your (and other's) technical knowledge. - Review the automation suite to make sure the more risker areas are covered correctly and thoroughly. - Go crazy (Try to do unimaginable things). Dec 25 '16 at 19:10

A test plan is one source of information to guide testing. That test plan was generated using other sources of information. All of these information sources are oracles. These oracles can be useful, and can also be fallible. There are a number of different oracles to consider. Here are a few:

  • Existing automated checks. What are the checks looking for? What might they be missing?
  • History. Does this version work like the last one?
  • Image. Is the product consistent with the image the company wants to project?
  • Comparable products. Does this thing work like its competitors?
  • Claims. What does the marketing material say? What about the user manual? Someone dreamed of it and told someone else to build it. What did the dreamer tell the builder, and how was that information conveyed?
  • Users' desires. Does it work the way a user wants and expects?
  • Product Consistency. Is each element in the product consistent with other elements in the product (ie. is the Help button in the same place on each page?)?
  • Purpose. You've seen and interacted with similar things, and built a model in your head regarding their purpose. Is the function consistent with that?
  • Statutes. Does it follow the laws of the land?

Michael Bolton describes these in this blog post: http://www.developsense.com/blog/2012/07/few-hiccupps/


When a formal test plan does not already exist, consider the following factors in making one:

1) Finding High Level Functions As always high level functions are of central purpose to the site or an application, modify those functions based on the priority frequently according to their significance to a user's ability. Determine the test direction as soon as possible to see changes happening rapid.

2) Test Before Display Before the product is being displayed test it using different browsers and platforms also use designers and developers to review the tests. This is an instant where testers run out of time and they need to test without a formal plan.

3) Concentrate on Ideal Path Actions Testers should assume themselves as users, focus on the ideal path and identify those factors most likely to be used in a majority of user interactions. Get to know about the sections where the user makes a frequent visit, because most of the user doesn't think the same way hence make a set of guess based on user's interest when he visits your website.

4) Focus on Intrinsic Factors Intrinsic factors are internal and it can be fixed only by the tester also the user can do nothing with it. Hence these factors require an immediate attention before the error reflects in the user's end. These errors are time sensitive hence it needs to be fixed without a formal plan.

5) Boundary Test from Reasonable to Extreme The systematic testing of error handling is called boundary testing. Unknown values may choke the system therefore start with all you know when you perform a boundary test. Finding reasonable and predictable mistakes is a better way to perform a progressive boundary test.

6) Good Values Always use valid and current information. Enter in data formatted as the interface requires. Include all required fields all these good values will help testers to make less errors.

7) Reasonable and Predictable Mistakes It is easier for testers to predict errors done based on design especially with interface interpretation. These errors are very common and occur frequently due to complex design in fact it is easy to fix without a formal plan.

8) Extreme Errors and Crazy Inputs Testing for maximum size of inputs, long strings of garbage, numbers in the text fields and text in numeric fields will reduce extreme errors, proceed from most likely to less likely to save time.

9) Compatibility Testing from good to bad It is always good to start a test with the configurations which is more familiar. Therefore when you test a cross platform application begin your testing process with the most used browser and then with least used browser.

10) Expected Bad Values A tester should make sure that an error message pops out each time when some invalid entries are entered in places like online forms. Such test cases don't require a formal plan. A tester can easily give random values to test the application.


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