Geek of QA

We all are living in an Information age. We have all our devices connected and even a bigger human network sharing data in the form of ideas, thoughts with each other. We need a place where we can store all this data, access it as and when we want and get rid of it after the purpose is achieved. Traditionally data have been stored on following devices - Hard Disk Drive: A block device comes with every computer out there… Floppy disk: Probably you can see one in a computing museum now a days CD/DVD: More advanced for of floppy; and now becoming obsolete pretty fast USB: A flash device which is handy Now some of the above mentioned devices are not in use these days, other still are! But all these devices have one common drawback; a limited storage space! There comes the Network('ed) Storage; which sits on your network and stores/serves to all your data access needs. Let's dive deeper in this fascinating world of storage systems. Typ...

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     M anageability      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 t...

Recently I worked on a project, where lack of documentation necessary to plan the testing activity was an issue. Although this is not a very common scenario, the possibility can't be ruled out completely. So how should the test team proceed when there ain't any input documentation such as design specifications, feature specification et al? It sounds like a tricky situation, isn't it? Well, it is a somewhat tricky situation to deal with, but then there are tools/methods which would come to your rescue. Let's see which are these tools and how to make best use of them... Using product simulator: Although simulators are miniature versions of the fully functional product, they certainly give us a look and feel of the end product. By using the simulator, we can define functional workflows and get some feel about the product's UI. These things then can be used to write test plans and test cases. However one thing is very important to note here, it's a simulator w...

Software testing and any other profession for that matter is a continuous learning process and every project that you do, would teach you something or the other. Such learning can then be taken along as you travel further into your career. Based on my experience in the industry so far, these are my thoughts about few essential qualities required in any software test professional. Be curious: Software testers need to be curious all the time, while understanding the product they are going to test, while deciding on what to test and how to test that, writing test cases, writing bug reports and even while convincing developers about why your bug is legitimate. Be open to learn: Any profession does require continuous learning and software testing is not an exception. In fact, software testing requires a bit more learning and knowledge upgrade than few of the other professions. Why so? A constant change is a property of the IT industry and with the pace that technology is changing...