Storage Testing : Getting Started!


Testing Network Attached Storage (NAS) and Storage Attached Network (SAN) are complex yet interesting topics. Although there are various vendors and products available in this space, at the core of the testing stack it all boils down to validating following things –
1           
  •     Protocols
  •     Filesystem
  •     Network
  •     Security
  •     Manageability
  •     Proprietary features


This article will mostly cover things at a high level that you may want to include in NAS testing and can be used as a point of reference for developing test plans and creating test cases.

First things first!

As with any other product testing, the Storage testing begins with requirements gathering and understanding the product under test. By doing requirements gathering you would be able to collect all the necessary information to scope out your QA effort and carry out your test cycle. From the testing point of view, following things would be of a high importance to know –
·         What type of Storage Array is it? Disk-based, All-Flash, Software-Defined? Your test strategy needs to be altered depending on the type of storage.
·         What type of testing need to be performed? Functional, System, Security, Regression?
·         Is it going to be an all manual effort or automated?
·         What is the targeted industry for the product?
·         The product is likely to be undergoing what types of workload?
·         Is there a possibility that a product will be deployed in a multi-application workload scenario?
·         What are the product’s limits, such as scalability (number of manageable files, raw and available storage capacity, maximum sustainable IOPs and Throughput, maximum number of supported objects)?
·         Is the storage unified? File and block in same box? Does it support Multi-protocol?
·         The versions of protocols that the product supports, ex. NFS v4 and SMB 3.0?

Plan you’re testing

Once you have collected answers to all the questions from the above section, it’s time to prepare for product testing. Typically Storage systems are best tested when they are under workload. The only exception is, when you are testing the product’s accessibility interfaces such as GUI, CLI and APIs. The reason why you should have test system under load is, that’s how they will be used in actual, production environment for which they are destined to. So if you test these systems in a similar way, your testing will possibly yield bugs much early in the product’s life-cycle. There are bunch of IO generator tools, synthetic or application specific available in both proprietary and open-source domains. Few examples are IOMeter, FIO, Workbench, VDBench, JetStress etc. You need to choose the tool based on your requirements and the type of workload you wish to test with.
For creating quality test cases, the answers that you gathered earlier will provide good pointers. Additionally read and understand product specifications, design specifications/limitations, recent customer escalations and supported features. Your test plan must cover extensive coverage for these things and your attempt should be to leave no corner untouched.

How do you think about storage testing? Please post your comments…


Happy testing!

Comments

Popular posts from this blog

Docker: What is it? How can it be used in Testing?

What DevOps mean to QA/Test?

Smart Testing – In the age of Machine Learning!