jump to navigation

Testing Methodology January 19, 2010

Posted by mwidlake in Testing.

This is my 101st posting and {almost} my start for 2010. I was going to kick off 2010 on something I knew well, so I could look all smart – specifically, handling stats for big databases. But I have decided to kick off on something I know very poorly. Security. Namely, use of SQL AUDIT. Why? Why blog about something I know little about?

Because I want to blog about the process of finding out about stuff and testing that stuff. It’s actually going to be a thread about testing – the SQL AUDIT is just an excuse {and matches my work life, which is jolly important when time is limited and you need to keep the employer happy}. I started out my whole blog (before almost anyone paid any attention to my meanderings) on what you could find out just from doing a “select count(*)” from a table. You can find out a lot from simple beginings.

How do you test something? Well, that question is actually a step or two down the line from “how do I understand something”. Sorry, I was trained as a scientist at college and you get sold this line as a trainee scientist about Baconian Science whereby you record all the data about something and then come to conclusions. It does not work really. You need an idea first and then you need to test that idea.

So, in the case of IT, you come across something (the initial idea) and you want to know how it works. It is usually a feature of the software new to you. With software (and the Oracle Database is really just a huge pile of software) there is a source of starter information and it is called the “documentation”. If I was a Baconian scientist I would just use the feature and record everything I could think of about it and record what I discovered. But this is software and some human (or humans) designed it and implemented it. And documented it.

So, First thing, don’t google it. Go and read the official manual on it. It is not going to tell you everything (it is, after all, written by people desperate to put it in the best light possible – and yet leave space of consultancy and training dollars to be earned) and remember that the manual can be wrong, but it is likely to be more accurate than 80% of what you come across on web searches. {If I was a tabloid newspaper I would go and ask a bunch of people who knew little about the subject what they thought and then publish an article on it, emphasising any shocking or outrahgeous parts. Remember that when you Google or Bing or Yahoo anything, Anything. }.

Having read (and I would suggest you start with) the Concepts Manual on the feature and then any specific manual covering the feature, now do your web search and…
(a) look for sources you have grown to trust. Not popular sources necessarily, sources where you have rarely found them wrong or they publish examples and worked proofs of their utterences.
(b) look for repeated claims about that feature and keep them in mind. They could be urban myths, they could be accurate. Just keep them in mind.

Now go and do some tests. Yourself. Otherwise, you just never know…

And this is the nub, I think, of testing. Get some basic information about how it should work, throw in there your experience to date (eg, this AUDIT stuff is putting data into an oracle table, so it is inserting and updating rows in a table, it should react like data going into a normal table. What do I know already about insert and updates to tables?) and ask yourself a few simple questions:-
– How do I think this should work?
– How could this go wrong?
– What scenarios can I think of for using this?
– What are the simplest examples I can think of for this process?
– How can I reduce tests down to trying only this feature or even one aspect of this feature?
– How could this go wrong?
Yep, I ask that last question twice and it is no oversight. I want to try and understand where this new feature might break. I need to ask the “ahh but” questions.


1. Pete Scott - January 19, 2010

I was a scientist too…. Baconian Science is very good for ‘discovery’ of true unknowns and can be translated into IT terms – I used it a lot when I was a data analyst, it also has a role in problem cause identification. But as you say it is not so good a method to learn about a technology. Here it is read, understand, test understanding, read again. explore the edge cases of your understanding.

A nice post – and a great start to the second century of posts

mwidlake - January 19, 2010

You provided the 500th comment on this blog Pete. There is a nice “roundness” to that, given we humans work in base 10 (neither 100 or 500 would strike us as significant in base 8 or base 12).

Oh, and as a little pause for thought, very early land-dwelling vertebrates did not all have 5 digits. There is some fossil evidence to suggest “we” started of predominantly with 8 or 10 digits and they quickly reduced down to 5 as our long-ago ancestors adapted and evolved to the 5-digit form that is the norm for Amphibians, reptiles, mammals and (under the feathers) even birds.
Would computing be generally easier if we still had 8 digits on each hand and so hexadecimal was our natural numeric base to work in.
Early tetrapod with 8 digits
Scarily dry text book on the subject of digits in early tetrapods

2. Testing Methodolgy – The Groundwork « Martin Widlake’s Yet Another Oracle Blog - January 20, 2010

[…] Testing Methodolgy – The Groundwork January 20, 2010 Posted by mwidlake in Perceptions, Testing, Uncategorized. Tags: data dictionary, knowledge, Testing trackback I want to start learning about using SQL AUDIT, as I mentioned a couple of days ago. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: