Infratester

Demey Definition of a Boombastic Test Style

2011-10-10T20:24:00.004+02:00

In a blog post I talked about My Definition of a Boombastic Teststyle since there is no official Definition what Infrastructure Testing is. Recently I attended an event about Cloud Testing organised by Testnet.

One of the presentations was by Wim Demey and he talked about Infrastructure Testing. In this presentation, called Knock, knock, knockin’ on infrastructure’s doors, he talked about the need and importance of Infrastructure Testing. He also gave his definition of Infrastructure Testing:

Infrastructure testing is any test activity performed as result of an intervention made on hardware, network and/or software components which are part of an integral infrastructure platform in order to facilitate applications in a managed and controlled way.

I like the fact that this definition stresses the fact that Infrastructure testing is more about Chain Testing and not a single Test. So let's start with this Definition and see how we can enhance it.

Don't call it a comeback

2011-09-30T23:43:00.007+02:00

The Infratester blog has been silent for a long time. In the fast paced world of the Internet it might be called dead. Forgotten with all the followers gone. This might be true, but the "patient" is not dead.

Let's get this blog back on track with posts, comments and interaction to (re)discover the world of Infrastructure Testing!

The cloud of unknowing

2011-09-30T22:29:00.008+02:00

Around the 14th Century an unknown author wrote the book "The Cloud of Unknowing". A guide to get into contact with God, not through knowledge and education but through love. Forgetting what you know and following your heart to reach the ultimate goal; understanding God. How different is today's Cloud, a place filled with knowledge and the urge to assemble as much understanding as possible.

The ancient "Cloud of Unknowing" teaches us how to reach God, but what do we reach with our modern "Cloud of Knowing"? What motivated medieval people to seek God and what is our modern motivation to seek Knowledge?

This blog post is not about companies, but just as in the "Cloud of Unknowing" about individuals, like you and me. Three companies offers us now a cloud. A search engine company, a music player and computer hardware & OS manufacturer and a server & client OS + Office firm.

All three offer a place to store our contacts, files, photo's, music, e-mail, etc. They offer us easy ways through mobile solutions (software and sometimes hardware) to get to their Cloud.

We all have our motivation to use the "Cloud of Knowing", but what is our motivation to use a specific provider? Is it the mobile phone, the services they provide or the "I have been using it for years" and/ or the "all of my friends use it" argument.

As testers we look at requirements and think about ways to test & validate these. But how can we do this for a Cloud environment? An interesting aspect about Infrastructure Testing I want to dive deeper into.

Keep following this blog and see what our "Knowledge in the Cloud" will bring us.

Are you following me?

2009-06-25T13:57:00.006+02:00

Some years ago, a web blog was a new and creative thing to have. Nowadays Twitter is the latest trend in blogging. I can't let this opportunity go by and see that we (im)possibilities are of a 140 character blog. So Infratester will be twittering on http://twitter.com/Infratester. Will you follow me?

My Definition of a Boombastic Test Style

2009-06-14T21:59:00.014+02:00

While surfing the Web I came across an interesting post on Test Republic. One of the Member Pradeep C asked a question "Wanted to understand the definition, and process involved for Infrastructure Testing". He got a reply by Michael Bolton which, although it had some valid points, was not really an answer to his question.

It got me thinking about a good definition about Infrastructure Testing. In my opinion definitions have more value if they are based on Standards. I took a look at the well known OSI Layer model for a quick answer

Although this is about Infrastructure, it is about Network Protocol design. So this does not give a definition of Infrastructure Testing. I have to look for other standards to help me describe Infrastructure Testing.

So for the moment I can not help Pradeep C by telling him what Infrastructure Testing is about, but I can tell him that it is an exciting and challenging form of Testing. In other words Boombastic!

Virtualisation Architecture

2009-04-17T16:14:00.017+02:00

Virtualisation has changed from a gadget to a hype to a proven solution. There is a myriad of products providing Virtualisation from servers, desktop, applications, appliances and data centers. The advantages are clear, but choosing which steps to take is often unclear.

An Organisation can choose to become a "Microsoft Shop or VMware Shop" and use only Virtualisation products from that Vendor. With that comes vendor lock-in but also good integration and management. A mixed Vendor solution is also possible, which requires more effort in setting up integration and management.

From an Infratesting perspective whatever solution you choose is irrelevant, every solution can be tested. What is important, is that there is a clear Architectural view and Roadmap for Virtualisation. Virtualisation often starts bottom up and is IT driven. This could result in the wrong choice for a solution.

Therefor Virtualisation should be lifted to a higher level and give a top down approach.

That is the only way to get a Real instead of a Virtual Solution.

Seek and Find

2009-03-14T21:26:00.006+01:00

At the end of the nineties the Internet was like the Wild West; a lot of unknown territory and even more people looking for gold. Alreay one of the big issues was how to find information. I remember doing a project to implement the Netscape search engine on a company's Intranet. A lot of work getting it to search and return results properly...

Ten years later a lot has changed. Most of the Wild in the West has gone and more territory is mapped. Setting up a Blog is easy with just a few mouseclicks and so is adding a search engine.

To facilitate finding information on this Blog I added Google Custom Search. It is below the Label section on this Blog. I hope it will be useful for you to find the information you want.

This information was provided by...

2009-03-06T16:48:00.005+01:00

Since my current work involves a lot of Packaging and Deploying of Applications, I searched the Internet for websites for knowledge, faqs and information. During this search I stumbled upon the website AppDeploy.com

As an Infrastructure Tester you try to work independently of Suppliers and Products and seek the best solution for every situation. When I seek information about a subject I like to have it unbiased and without a Supplier flavor.

Allthough AppDeploy.com is sponsored by the company Kace it still holds a lot of valuable information that is not specifically tied to their products. So if you need more information about Application Packaging and Deployment be sure to check this website out, I know I will

Don't get locked in

2009-03-05T21:18:00.009+01:00

In my recent blog I advised not to skip Microsoft Windows Vista unless you are sure that it is possible. I am not biased to Microsoft and off course there is the option of moving away another platform. However there is always the issue of vendor lock-in.

The easier it is to move to another platform the less there is a problem with lock-in. Be aware though that this is a two way street. There are costs when moving from a Microsoft OS + Exchange Mail Server to a Linux + SendMail + Courier solution. However there are also costs if you decide to move back after a few years.

Remember that you should not choose Open Source but Open Standards. This makes migrating from one platform to another easier, but just as important cheaper.

Use ICUR to test several scenario's to make sure you don't try to free yourself from one vendor to be locked in by another.

Buena Vista

2009-03-02T22:07:00.009+01:00

Ever since the launch of Windows Vista there has been a debat about migrating or not. There were issues with Performance, Availability of drivers and Compatibility with older Software. At a certain point even Microsoft advised to wait with Windows Vista. In the mean time Gartner's advice was clear, "don 't skip ". Recently Microsoft changed their view and now advise to migrate.

All very confusing but a perfect opportunity for an Infratester to use ICUR to see if it is worthwhile to migrate. Luckily help you are not alone, companies such as ChangeBASE AOK and Klokwork have solutions that might be helpful in setting up tests and making decisions.

My advice is not to skip, but if you do, make sure that it is possible.

ICUR, the Infrastructure CRUD

2009-02-03T21:26:00.019+01:00

Every Software Tester is familiar with CRUD (Create, Read, Update and Delete). A standard test covering the whole lifecycle of any type of object. It helps detect a lot of basic defects, such as invalid settings, incorrect access rights and wrong dependencies.

In Infrastructure Testing a similar test can be used, that I call ICUR (Install, Configure, Update and Remove). This test covers the Lifecycle of most Infrastructure Components, be it Hard- or Software. The idea behind ICUR is that you put the Lifecycle in fast-forward.

Let's take the example of a new Mail Environment. First install the Mail Server Software. Then configure you first Mail Domain and all the settings. After that update with another Mail Domain+settings. Finally remove the Mail Domains and their settings. This is not very complicated if you concentrate just on the Mail Server.

My idea with ICUR is that also the usage is fast-forwarded. So when you update with another Mail Domain, you will also use that Mail Domain. How is this new Mail Domain used in your Organisation?, who is allowed to sent/receive Mail?, etc. When you remove the Mail Domain, how to archive the received mail?, what to do with bounced messages?, how to inform that the Mail Domain is not used any more?

The same strategy is applicable for an upgrade to a new version of the Mail Server Software, merging with another company or outsourcing the storage to a SAN provider. The moment you have an idea what changes might happen in the future, Fast Forwarding with ICUR gives you the benefit of bringing the future a bit closer so you can use ICUR to determine the impact.

Ranking: Last Chapter

2009-01-07T12:57:00.004+01:00

In my post Ranking I wrote about my goal to end on Page 1 for the search term "infrastructure testing". In August I managed to get close. This is the final result for 2008:

http://www.google.nl/ (page 3)

http://www.google.com/ (page 3)

http://www.altavista.com/ (page 1)

So I got to page 1, but not on Google. Guess what one of my goals for 2009 is?

Test-M: Minimal Effort, Maximal Result

2008-12-05T10:47:00.005+01:00

A new Test Methodoloy has emerged that is called Test-M. Test-M is not a general Methodology but is specialised in the testing of Out Sourcing, Software Package Selection/Implementation and Infrastructure Changes. The Methodology comes with a Website, Forum, Templates, Best Practices, etc. If you can read Dutch check it out and see for yourself.

SMART and DUMB

2008-12-03T09:45:00.004+01:00

Everybody is familiar with Projects which run out of Budget and Time. All of them ending in the infamous "Blame Game" full of accusations, discussions and the occassional team of lawyers.

To prevent this from happening several strategies are used. One of them is to switch from Time & Material to Fixed Price. The intended result is to deliver within fixed price and time boundaries a predetermined product. No quarrels afterwards, everything is decided beforehand, in other words problem solved. To determine what will be delivered, requirements have to be defined. Nowadays SMART (Specific, Measurable, Acceptable, Realistic, Time-Bound) and DUMB (Doable, Understandable, Manageable, Beneficial) are not just hyped acronyms, but are really used during the requirements phase. A very good trend which I fully support.

What can be misleading, is the idea that the requirements phase is a peaceful step in a project. For example, the customer wants a new Infrastructure. Complete with SAN, Virtualized Applications and Role Based Access within six months. The IT provider can deliver a new Infrastructure, complete with SAN within six months. Virtualized applications will take an extra two months and setting up Role Based Access can take up to six months.

To make a requirement Specific, Measurable or Time-Bound. is often not the problem. The big argument is whether it is Realistic or Acceptable.

The customer might think the fourteen months needed by the IT provider is not acceptable and shop around for an IT provider that can do it in six months. The question is if this is Realistic?
Another example, to comply with new regulations an update of a software package has to be built within eight months. To fully implement the new regulations will take a year. Only part of the new regulations can realisticly implemented within eight months, but is this Acceptable?.

Getting into an argument afterwards is always bad, it show both parties have not taken their responsibility. But arguing beforehand, is very good. That shows commitment and professionalism before the real money will be spent.

IT's About Uptime

2008-11-19T09:51:00.004+01:00

As an Infrastructure Tester you can't keep up just with the latest trends just by yourself. A valuable resource of information is the Blog from StackSafe: IT's About Uptime. It covers a myriad of topics with one common point, keeping services up and running.

So whether you use their product or not, take some time to follow this Blog, because it really has valuable information.

Generalist Improved

2008-11-07T14:18:00.013+01:00

In Track & Field you have two types of Athletes, those who do Heptathlon or Decathlon and the others. In the IT these two types were also used: Specialists and Generalists. There was also a division between useful (Specialist) and useless (Generalist). Specialists being the Gurus in their field of expertise; Unix Specialists, who knew every secret about a specific Operatings System, Java Experts who were familiar with all classes, methods and objects.

That these people knew very little about project-, change- & release management, communication, business requirements, architecture principles, etc. was not an issue. For that you had the Generalists who took care of that not so important stuff.

In a blog from Tarry Singh I came across the term Versatilist, which was first used by Gartner. According to Gartner; "Versatilists are able to apply a depth of skill to a progressively widening scope of situations and experiences, equally at ease with technical issues as with business strategy."

If there ever was a term that could be applied to an Infrastructure Tester, this would the correct one. The need for Deep Knowledge, but also the sense of Architecture, Processes and Procedures, etc. , anything needed to get the job done. Like Heptathletes and Decathletes performing well in various disciplines instead of excelling in one.

"Common" Quality

2008-10-03T13:59:00.017+02:00

As an Infrastructure Tester you need to test hard- & software. How can you make sure that you get the expected Quality? How can you for example measure and compare the Quality of the Configuration of a Router and a Mail Server?

If you try to define Common Quality Criteria for every Infrastructure Component you will face a big challenge. What is good in one situation, might be flawed in another. Every organisation has different Quality Criteria for their Infrastructure.

The trick is not to look at Quality Criteria, but at what you need to make sure that there is Quality. For this you need four items:

Version Number

Documentation

Testplan (& -report)

Automatic Installation

A version number is there for Administrative reasons; to make sure that you test the correct version of the soft- & hardware, read the correct version of the documentation, etc.

Documentation is crucial to obtain information and is used in static testing and prepare for dynamic testing.

A Testplan (and report) gives information about what is / should be tested and the results.

The use of Automatic Installation assures that every Configuration is installed identically.

If an Infrastructure Component is accompanied by these four Items you can determine the Quality. So next time you are asked to test a new Infrastructure Component or Release request these four supplements.

Server Sold

2008-10-02T17:09:00.005+02:00

Some time ago I put my server on sale , but it has been sold. I hope it feels at home with it's new owner :-)

How to read...

2008-09-26T16:39:00.010+02:00

Many years a go Mortimer J. Adler wrote "How to Read a Book" with the intention of helping the reader read specific books. His concepts have been used numerous times in different publications. In Infrastructure Testing we read documentation instead of books, but the method introduced by M.J. Adler still applies.

Good reading means reading a document three times. The first time is "structural reading" and is intended to understand the goal and structure of the document. The second time is "understanding; what information/knowledge is transferred. The final time is "critical" to see if the document answers the readers questions.

So to properly read documentation, it should be read three times. Often documentation is delivered in the end and there is not enough time to read everything three times. This is where (again) Deep Knowledge is necessary.

Ranking part II

2008-08-20T14:49:00.005+02:00

In my blog Ranking from March 5 2008, I said my goal was to end on the first page. Searching the term ""infrastructure testing" gave the following results:

http://www.google.nl/ (page 2)
http://www.google.com/ (page 2)
http://www.altavista.com/ (page 6)

My goal for 2008 is getting closer!

An Angel on your Shoulder

2008-08-15T16:16:00.014+02:00

Alexander Pope once said "For fools rush in where angels fear to tread". Which I interpret as "think before you act". I am a big fan of Static Testing, which I translate as testing on the left side of the V-Model. The reason?, the earlier you find a Defect, the easier and cheaper it is to fix. I recently read Jeroen Rosink's blog about Request for Knowledge and I liked the idea of formalizing the process of gathering information.

With this approach you kill two birds with one stone. First, on the left side of the V-Model, the more information is documented beforehand, the easier it is to write a good Requirements Document which improves the Architecture Design. Secondly, on the right side of the V-Model, the chance of Request for Changes is reduced, which reduces the time for re-design/re-work/re-test.

In previous posts (1) (2) I already mentioned the need for Deep Knowledge for Infrastructure Testing. Architects, Business- and Information Analysts, should Request the Knowledge of System Specialists, Test Managers, End Users, etcetera to get as much Knowledge as early as possible.

Let these Angels help. Preferably while they sit on the Left Shoulder!

Server 4 Sale

2008-08-08T17:10:00.004+02:00

Dual Opteron 248 E4 processor
Tyan Tiger Mothterboars S2880 with built in Dual Gigabit Network card
8GB RAM
6 *15k / 73GB SCSI Hot Pluggable HDD
LSI Logic MEGA-Raid controller (RAID 0,1,5,10,50)

The server runs VMware ESX 3.0 without a problem.

If you are interested mail me!

StackSafe Evaluation

2008-08-08T16:45:00.006+02:00

In the last few weeks I tried to evaluatie StackSafe TestCenter. It turned out that my server did not support Intel VT or AMD-V so I could import, but not start imported machines. One could say that if a product installs, it should work. On the other hand in the documentation the requirement for virtualization support for the processor is mentioned.

So was this Evaluation a failure? I tend to look at the broader picture and try to learn from my experiences. The documentation I read was well written and as I found out the hard way correct. The support I got from StackSafe was quick to respond to my questions and very helpful in finding solutions.

Mailing and talking on the phone to the people from StackSafe, I have come to known them as very enthusiastic and dedicated to improve the product and service. In this fast moving market I can fully agree with them that it is more important to bring out new features, then support old hardware.

Again, was this evaluation a failure?. In my opinion just the hardware failed. I can't say anything about the software, because that did not run. What was a success was the attitude of the people at Stacksafe. They showed the dedication to compete in the market.

Next step? Move the old server out and get a new one in and then restart the evalution!

Book Review "The Complexity of Chain Testing"

2008-08-07T11:10:00.004+02:00

Recently a new book has been published by CapGemini that treats the subject of Chain Testing. According to the authors, Chain Testing is the newest and most important addition to the testing profession. As part of the job of working as a tester is keeping my knowledge up to date, I started reading to learn more about Chain Testing.

The idea behind Chain Testing is that more and more systems are integrated and depended on each other. Testing is therefore not restricted to a single system. The authors take the reader through the steps needed to execute a Chain Test. In the appendices topics such as roles, quality attributes, references, etc. are treated.

The second chapter Project Assignment was an eye-opener for me. In the introduction the Chain Test is placed in the classic V-Model after the Acceptance Test. It is common knowledge that the earlier you find a defect or problem, the cheaper it is to repair. With Chain Testing taking place in the end, the room for errors is very little. Bad preparation means bad testing. You therefore test the Chain in the end, but the preparation should start very early.

Chain Testing is not about black box testing with equivalence partitioning, boundary value analysis, etc. Chain Testing is more about communication, cooperation, roles and responsibilities. People familiar with Project Management will recognize the terminology; stakeholders, deliverables, acceptance criteria. The book gives a clear approach what steps to take and anecdotes, hints and tips to help the reader understand the steps taken.

A lot of the information in this book is based on standards and common practices which you can find somewhere else. However I really like the book, not because it gives you new information. I like it because all the information is one book and it gives you new insights. Also you can pick it up and start using it. I highly recommend it for Project -and Test Managers that need to get the job done and quickly need to get up to date.

Finally, you should not judge a book by its cover and beauty is in the eye of the beholder, but the design and photographs add to the message of the book. The style can be described as no nonsense, with large margins and a clear distinction between the chapters. The photographs are both color and black & white and could be tagged with labels such as building, technique, traffic, cooperation, etc.

Since sharing is caring, if you would to know more about the book or Chain Testing you can contact Barbara van Wijk van Brievingh

The Complexity of Chain Testing
Successful Integration across Organizations
Jacolien Vukkink, Julien Bensaid, Marco Koomen, Maurice Siteur, Thomas Som, John van Veen

StackSafe, preparing to evaluate

2008-07-04T16:07:00.005+02:00

Some time ago I published a post about StackSafe . This led to a positive comment from StackSafe, which led to an online meeting and demonstration of StackSafe™ Test Center.

The people from StackSafe are so kind to give me the opportunity to work with their software. I am preparing the bare metal and next week I will start evaluating StackSafe™ Test Center.

So keep a close I on this blog for the next few weeks as I will report about my experiences running StackSafe™ Test Center