Software Testing; a bit of "lite" reading.

Te koop: Adriaan van Altenastraat 10, Dordrecht

2011-06-07T15:46:00.000+02:00

Te koop: Adriaan van Altenastraat 10, Dordrecht

Huis te koop: Dordrecht, Adriaan Van Altenastraat 10 - HuizenZoeker

2011-05-27T14:55:00.000+02:00

Huis te koop: Dordrecht, Adriaan Van Altenastraat 10 - HuizenZoeker

The Open Source Test Tool paradigm

2010-12-01T10:33:00.003+01:00

Article to be published soon. Detailes will follow.

Assumption is the mother of all....

2010-10-19T16:16:00.006+02:00

It still amazes me that the statement "Assumption is the mother of all F*** ups" is present in almost every project. We all seem to know what is best and what the other means without verifying it. Why is this?

In theory there are several options;

1. We assume the other person thinks like us;
As we are all human we think for and from ourselves. This means that we have a certain order in the chaos in our head that is very logical to the individual. Since we cannot look into the other person’s chaos (yet), we assume he/she has the same kind of structure, because to us, this seems logical. In doing so, we forget the fact that every chaos is unique as is the structuring of it. This structuring of the chaos is compulsory to make sense of it all. If we can make sense of something, the other person should be able to as well. And thus the assumption has been created.

2. We presume that the other party is on the same level as us;
We are all professionals, working in projects or departments and have been selected by a company because we have a certain level of education and or knowledge. Because of this, we should be at least on the same level of "brainpower". Even though this might be true if speaking in general, the application of this "brainpower" is different for everyone. As some people can think abstract, others might never be able to. Next to this, different levels of approach are often causing the problem. Someone from the business might have a complete different idea about a certain requirement then someone from IT.

3. We think we know it all (been there, done that);
As we execute more projects, we tend to do the same thing in every new project because of the fact that this is a best practice and/or it works best for us. Which is not a bad thing obviously (don't invent the wheel every time). But by doing so, we might forget that new project means new people, means new...well actually everything. We should not be sure that the best practice is applicable here as well without some fine tuning and adapting to the current situation.

4. We don't read thoroughly enough;
When we read documents, we can do this in many ways. By just reading what it says or intensively trying to make sense of it all and finding out if what it says really is correct. Even the later can be done from many viewpoints. As an example, executing a fagan inspections is done by multiple parties from multiple angles (e.g. testability, maintainability, etc...). A very thorough Fagan inspection might even take 30 minutes to an hour per page to review. But overall, we don't do this kind of review and we only notice the obvious statements, even not bothering to map multiple documents. We assume that statements in the documents are overall correct and that the professional that wrote it, would probably know what he/she was talking about. Especially when it seems to be very complex (or technical).

5. We don't dare to ask, because the other party might think we are stupid;
We all know it; afraid of asking a question because everyone seems to know what someone is talking about. But...there are no stupid questions, only stupid answers! We don't like to be seems as stupid or ignorant, so we just avoid asking the questions and might try and find out what is being said in another way. Or make an assumption (and there it is again). Asking questions in the start of a project is easy, if the project has progressed, this becomes more difficult, because people would expect you to know what it is about. Then again, we cannot read each others minds.

6. We don't dare to ask, because we are stupid;
Well....that is certainly the case with some people....but actually this is a lost case...just replace them ;)

All in all, some points why we make assumptions in my opinion which is one of the biggest pitfalls of any project! Especially when assumptions across parties are made (client-supplier in particular).

Most effective tip I can give as a tester; DARE TO ASK ANYTHING & EVERYTHING!

Test Process Improvement; Do we really need it?

2010-05-04T14:49:00.001+02:00

Everything we do and know can or even should be able to be improved. At least that's how I look at things. If this is not the case, it would mean a complete "standstill". As a testing professional I know that nothing is perfect. And even if it appeared to be, the world around this perfect object still moves forward. So in the end even this object should improve and adapt. It’s like I said before (some posts back):

"In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change”
Charles Darwin

So if everything should be adaptable to change, the Testing process should be as well. As testers we know a lot of our own issues, but most of the time we blame the environment for it. "The developers don't takes us serious", "We don't get any budget to test what we want to test", "We're always at the end of the chain, so it's not our fault there are still some bugs in production" etc. And some of it is valid and some of it might be questioned. Is it because people don't know what testing is? Or is it because we (as testers) aren't transparent enough? Or could it even be because of the fact that we don't even know how mature our own process is?

This last question is not that strange to ask. The testing profession is not even a profession in it's true nature. Compared to (for example) lawyer, doctor or bartender, we are just beginning to find out ourselves what software testing is. But before I dwindle to far away from the subject, I wanted to talk about improving our test process. Every projects starts with the best intentions and maybe even a complete test process in place, but during a project things always change. How adaptable are we then with our standardized test process?

Using methods like TPI NEXT, we can make a snapshot of our current situation and work our way toward our (pre) set goal(s). For example, if we want to be cost effective, more effort should be put into getting the test environment more mature instead of getting our meetings formalized. But methods should only be used to support practice and not be the leading factor of your process. Let it become a tool for yourself to get an overview, insight and something to "hit" management with in order to get resources/time/money to improve and/or change.

Being at the top level of maturity does not guarantee that "all goes well". It does give some basis of a proper process at that given time. Keep in mind that every project changes and that at a mature level, so should your test process!

To state it more boldly;

"We don't want to be CMMI level 5!"

The Dolt's Guide To Self-Organization

2010-04-22T13:09:00.001+02:00

One of the best presentations I've seen lately:

The Dolt's Guide To Self-Organization

View more presentations from Jurgen Appelo.

TPI NEXT is a big improvement from "TPI Classic"

2009-11-26T15:32:00.010+01:00

On November 17th, Sogeti organized the TMap® day. During this day
customers and other interested people were invited to Hotel Vianen to participate in lectures and workshops. One of the themes addressed was the introduction of the new TPI® NEXT book.

This new book is the follow-up of the “old” Test Proces Improvement (TPI) book. Ben Visser, one of the writers of the TPI® NEXT book, notices: “also a book about Test Proces Improvement needs to be improved”.

The new model differs in several aspects from the previous one:

The total number of key areas is reduced from 20 to 16. Some key areas are combined, whilst others are revised or added;

The maturity levels are uniformed for every key area, with the levels ‘Initial’, ‘Controlled’, ‘Efficient’ and ‘Optimizing’;

The test process is classified in three areas (Stakeholder Relation, Test management and Test Processes), with corresponding key areas.

But perhaps the biggest improvement of the new model is the implementation of clusters. Clusters are groups of related checkpoints, which can be defined depending on the business driver that is of most importance to the situation. This enables an improvement strategy, in which the checkpoints of the key areas that are related to the business drivers can be addressed first, before the rest of the process is improved. This brings an enormous amount of new possibilities regarding the applicability of the model within different business environments. A detailed description of the new model, the clusters and a detailed summary in which situation the new model can be used (and how) can be found in the new TPI® NEXT book.

Also, discussing business drivers and how Testing can support them, provides a possibility for Test Consultants to enter on a higher level in an organization. No longer only Testmanager and Project Managers are their counterpart, but now also CIO’s and “the business” come into view.

In the final stage before publication of the book, field tests were performed in several countries to prove (and test) the application of the new model in practice. In the Netherlands, this field test was performed in a collaboration between Sogeti and Capgemini in the UWV Test Improvement project at the Dutch Socoal Security organization (UWV). Thomas Som, Reinder Otter and Ralf van der Ven from Cap-NL conducted an extensive field-test, and . Maurice Siteur, John van Veen and Gerwin van Eersel were involved in reviewing the manuscript.

To support the use of the model Reinder Otter has developed a practical tool in which the different aspects are combined. By using the tool it is possible to create a graphical representation of the maturity level of a test organization with a single click of a button. Next to this, business drivers can be defined and manipulated, the clusters can be manually altered and different overviews can be generated. In short: to use the new model properly within a business situation, this tool is indispensable. This is emphasized by the fact that Sogeti has made the use of this tool an essential part of their presentation of TPI® NEXT, including a demo of the tool. Also Reinders’ tool is downloadable from Sogetis’ TPI® NEXT site: www.tpinext.com.

The TPI® NEXT model can be used in different situations, one of which is combining TPI® NEXT with CMMI. For this situation, Ralf van der Ven together with Sogetis’ testguru Rik Marselis has made a thorough comparison between the two models and published a white-paper about the subject. This white-paper is a good starting point to determine the TPI® NEXT maturity level of an organization that has already implemented a CMMI approach. A unique accomplishment, since so far this subject has not been addressed in so much detail. The whitepaper is also downloadable from www.tpinext.com.

It can be concluded that it the TPI® NEXT approach will create a massive following within the coming years. With the book, the tools and the white-paper, a complete package is provided to improve the test process. Feel free to look on the website of TPI® NEXT at http://www.tpinext.com for more information on how to order the book, the free download of the tool and the white-paper.

Acceptance & completion criteria

2009-09-14T14:29:00.008+02:00

I just read a piece from Michael Bolton; When Do We Stop a Test? To me almost all of these points should be covered in a Master Test plan under the headers Test strategy and entry and exit criteria. Where the exit criteria can be divided into acceptance- and completion criteria (as shown below).

Stop 1: This stop is when all cases are executed within the set time and the system has met the acceptance criteria. Most of the times this stop will occur after several releases.

Stop 2: This is the most common one since most of the time Testing is done, but the system is not OK (acceptance criteria have not been met). The decision now has to be made by the client if he still want to go to the next stage, or that he will give the testing team a new assignment (time, money etc) for retest.

Stop 3: This is the most uncommon stop since testing is not yet completed (not all cases are executed for example), but the acceptance criteria already have been met.

The completion criteria are for the test process itself and the acceptance criteria for the quality of the test object. IEEE829 speaks of the completion criteria as "suspension and resumption criteria". But almost always, we don't use them in our planning and reporting of test activities. This might be because the client only wants to know: can I go into production (Go/No Go)? This is a question we should not be answering for him as testers. We only should provide him with the information on which he can base his own conclusion. So if he asked for 5 pounds of quality and we found that the object only was about 4,5 pounds, it could be that he is willing to take the 0,5 pound of risk and go into production anyway. But it should be his choice and not (even as an advice) the testers'.

Coming back to the post of Michael; Nice and funny post, but if he would have set up his completion and acceptance criteria correctly, would this approach still stand? I agree that most of the times there is no strategy or we haven't thought the criteria trough properly. So to conclude the quote from Michael can be said for having these criteria as well:

If we don't care now, why were we testing in the first place? Have we lost track of our priorities? If someone has checked out, why? Sometimes businesses get less heat for not knowing about a problem than they do for knowing about a problem and not fixing it—might that be in play here?

Becoming a developer

2009-09-08T11:13:00.006+02:00

I know this will sound strange for a tester, but I'm actually developing at the moment! Even though I have no background of developing and actually have no clue what I'm doing (feeling like a senior developer already ;)). No, I'm not doing any C# or other new program language only real developers understand...I'm programming in VB....yes you guessed right: Excel!!

Easy thing about Excel is creating macros by recording them and change a bit to your needs. And I'm actually quite enjoying it even though I know my coding sucks. It's not really easy to maintain, it's not flexible (hardcoded) and it's probably full of bugs :) is

Why would I even start programming then? Well, it's becoming a sort of hobby trying to automate my Excel sheets in such a way that I don't have to do any repetitive work. Especially when filtering (e.g.) bugs or creating workloads for other testers, this can be done with just one simple click and a neat sheet will be created (and even printed or mailed if needed). I know the time I invest in this programming is not always won back when I would have done it by hand. But I always try to look to the future and a way to transfer these documents to others (so they can win that time).

The more I create, the more it's beginning to look like a real application (with popup windows, buttons and all :)). So who's going to test the stray tester and his hobby sheets? Maybe a developer should be the one who test this.

Nature vs. Nurture

2009-07-09T06:56:00.005+02:00

What does it really mean, Nature or nurture. Simple question; simple answer. You where either born with it or you learned it along the path of life. So did we learn to become testers or where we just born to be a tester?

If you look at our childhood and even further back as a baby, we all tested at some point. Putting anything in reach in our mouth, trying out that delicious looking and tasting thumb and (a bit later on) testing how far we could go with our parents. Kind of boundry value analyses in real life. Even then we knew different testing techniques in order to test life and the world around us. Monkey testing might have been the biggest technique we used as a kid, but even an exploritory test was applied. Smoke testing is applied as well for a quick intake of a new situation we encounter. Trying to asses if this situation is workable for us or if we just should send it back (e.g. by walking away).

Even though we never applied the technique as it should be (writing things down for example), we did execute them.

A test like performance testing (which is not a technique by the way) was something we obviously do all our life. Some of us more than others (if you look at sports), but if the requirement is that we should be able to walk to the next bar or do some shopping; that is a kind of performance test. And I will not even go into Acceptance testing. we can all imagine how this is applied I guess.

So, where does nurture kick in? If you really look at it, aren't we all testers by nature? Does nurture kick in when we need to write down what we always have been doing? To apply a technique to a situation unknown to us and not even related to "real life"? This might be the case, but it might also be the fact that we now have to explain what we know by nature.

So nurture your nature and become what you have been doing all your life; a Tester!

Lessons learned...whats that?

2009-04-21T17:39:00.007+02:00

I keep being amazed about the fact that in most projects we do not learn from previous projects. Most executed projects do have a lessons learned report afterwards. Projects that are PRINCE or even PINO (PRINCE In Name Only) usually have something like points to improve or reviews of the projects. But what do we do with these reports and all those wheels which were invented along the way?

I can be very short about that: NOTHING!

At least that is what I see within projects of myself, but in other projects as well. To give an example of how we do not use our Lessons Learned in new projects:

A colleague of mine asked me to help him with setting up an issue tracking tool. The client did not have anything yet and the money pot was already depleted. So I asked;
"what do you currently use then?". Where his answer was: "We log the issues in an excel sheet and mail (!!) this to India to be solved." If he could have seen my face at the time it would probably have been hilarious....for him.....I was stunned to even hear we are still in the stone age with the most basic things....namely traceability.

How would they know what the status of an issue was or even know what has been solved and when? So I started setting up an Open Source issue tracking tool and made it available (already filled in) to the project manager. After not hearing anything for a while I contacted him again. And this was the answer:

"The client and the project manager decided not to use the tool in the end." So I asked what they were doing now: "We now get issues by mail and have to distribute this to India somehow." This is a project within our own company where in prior projects we do have lessons learned which all state that we should have something already available at the beginning of any project....but we don't read them apparently.....and if we do, we have no interest in using them.

Because why should we invest in something that from the past tells us should be used to prevent problems (which will cost more money in the end)?? I see it every time with new projects: You start by setting up a whole new test process with templates and issue trackers and all. Which is good for that project, but in fact a waste of time for future projects. You are going to do it all over again anyway. No, let me rephrase that; you are going to use the same setup of prior projects in new projects (of other customers) again, but you are going to set it up mapped to this specific project and match it to the customer anyway.

For me as a tester/consultant, it's not a big problem to do this obviously...keeps me busy and the customer paying. But it would be so much better if we just used our lessons learned (within the companies, not as testers) instead of doing it all over again.

Being on the bench

2009-03-31T11:52:00.005+02:00

It's funny that when you don't have an assignment (= are on the bench), somehow you have less time for all the extra projects you normally undertake (next to the client hours). Even this blog wasn't updated in that time, but that might be because I usually write posts in the train and the last few weeks I've used the car to get to work (or worked at home).

So now I’ve taken the time to write another post about the Testing Bench in the current climate. Is there a bench at all? Yes there is. Mostly because projects are at an end. And somehow they all seem to end at the same time. And the second thing what creates (and maintains) the bench is that the requests are "normal" for this time of year, but the supply of testers is much more than normal. In this way testers are being put forward with a very small fee. And as we all know, the client mostly looks at the price and chooses the cheapest.

This is a problem for the Young Professionals because they do not yet have any experience but are as "cheap" as the testers that do have experience. They need an assignment to get the experience but are not hired because of the fact that it will take time for them to learn (which costs money...). Hence they mostly enter the vicious circle. A solution could be to assign them to a project for a €0 rate for the time they need to learn.

The problem for the Test professional is that he is not alone. Like I said; there is a small market for a lot of supply in this category. So you will have to show that you are not just a test professional. Give the client something extra and make them aware of the fact that you are the only one with the knowledge asked. This and a very low price can lead to an assignment quickly with any customer. Problem is of course that the company does not want such a low price for his tester, so the client has to offer something extra like being a new customer (opportunities) or the tester is on the bench for a long time (any assignment is better than nothing, right?).

The last category is the Test coordinator/Test manager who might have the biggest problems. It's true that there are not as many TC's and TM's as there are professional testers, but it's also true that they are more expensive. Therefore the client mostly only wants to give a low rate and on top of that, the demand for a "hands-on" TC/TM is increasing. Most clients seem to think that writing a testplan and maintaining, monitoring and communicating about it gives you enough time to help with creating testscripts and executing them. In a climate like this, more is asked and therefore more should be given. Problem however is still the money issue thingy where a Testing professional is asked to do the same as a TC/TM . Role become more alike, but the prices do not. So only being a very good or very experienced TC/TM gives you a head start over all the other professionals at the moment.

So after being on the bench for about a month (didn't do nothing, but still), it's time to roll up those sleeves again and what do you know; 3 potential assignments at the same time.

As the saying goes:
Elk moet haspelen volgens het garen dat hij heeft. (Dutch)
Translated something like: Take what you can get

Testing? Whats that?

2009-03-10T14:41:00.003+01:00

For all thos who haven't got a clue what a software tester (and in this case test manager) does all day, see the following blogpost:

Capgemini Technology blog Acceptance Test Manager

Why the crisis needs testers!

2009-03-03T16:22:00.014+01:00

It's a crisis alright when the AEX (dutch stock exchange) is heading for the magic 200 number and probably will plummet even further. Funny thing is; the companies are healthy, the economy is healthy, it's the trust thats rotten. And how can we get this trust back into the heads and hearts of the public and more importantly, the investors? By showing them black on white what the quality of their investment is so they can make a sound decision based on these risks.

As Jonathan Jarvis explains in his creation (even I understand), risks where taken when no one really understood the impact of the risks when things would actually go wrong.

Herein lies the biggest part a tester can play in any project; defining risks and explaining them to the client (be it a manager, CEO or other decision maker). Of course some managers may be deaf to the risks explained to them, but some might even take notice and act upon those risks. I don't want to insinuate that testers could have prevented the crisis. As we all now; Love makes people blind. And in this case it was the love for money. Not wanting to hear that things could go wrong very soon very fast is not something we like to hear about our big love.

So what does this leave us with? A broken up economy and no trust from investors. It's like I said in the beginning; giving back the trust by proving something is as it is and nothing more. In this way investors dare to invest again because they now know the risks involved and therefore can base their choice on the risks they want or dare to take.

We are not bias about our loves, we reveal risks with which trust can be given back.

The credit crisis explained!

2009-03-03T13:56:00.001+01:00

The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo

Practice what you preach.

2009-02-12T17:25:00.001+01:00

All companies do it, or rather; don't do it. They do not practice what they preach within their own department. A gardeners’ garden will probably look like it's never been used. a cooks kitchen looks like he had the same one when he was still studying and the IT infrastructure of an IT company still looks like everyone thought they had the best idea, but never integrated it.

Even within a large company as Capgemini, only recently a new intranet was introduced and not only that, standardized across the world. So now every sector, every department and every country has the same intranet look and feel and we can finally say we are one team!

With this collaboration within our own company we as testing community still where completely divided. Sure top management was connected, projects where connected and within our own companies we were connected. But most of the time we had no idea what was happening on the testing area in e.g. Australia (do they even test there?).

So it was time for more integration and collaboration using our new Knowledge Management system (km20) and Wiki. Accompanied with this should (of course) be a newsletter with all the testing news of "what's going on with our colleagues".

and finally it happened; the launch of the Global Testing & QA community:

Every month there will be testing news from around the globe delivered in our inboxes. Everyone can add their assets to the KM20 and every person can add his own testing knowledge or information on the wiki.

Is this going to work in contrary to what we had? I think so as a firm believer of the "Open platforms" (like wiki) and "knowledge sharing". I like to know what's happening out there even if it doesn't really affect my way of working. As long as I know...

Getting lost or being in control?

2009-02-05T12:59:00.006+01:00

I was just reading a blogpost from Rick Mans about getting lost being nice for a change ("I like to get lost"). And I think he is completely right. Getting lost opens up new possibilities in many ways.

On the other hand, when talking about testing and Quality assurance, we like not to be lost at all. Knowing where we are and what has to be done in order to reach the ultimate goal; a 100 % tested software product on time and within budget (keep on dreaming).

Tools might help, but there is a glitch...they are expensive and hard to maintain at this moment. But maybe, just maybe, in the near future, they will create tools that are as easy as Google Latitude which let us monitor our progress and update statusses as easy as knowing exactly where we are.

Wouldn't that be nice.....

A comic says more then a thousand words!

2009-02-03T08:18:00.002+01:00

Adaptive testing?

2009-02-02T16:16:00.005+01:00

Should we always test according to certain rules? Or are we as testers the most flexible and adaptive persons in the company? Not with our results and quality of course, but with the extra work we do and the way we change to a situation.

Let me elaborate on that; As an acceptance test manager I started at a certain company for 3 projects. As we all know, all those 3 projects where not synchronized to each other which resulted in very busy periods. Which is no problem of course. But my point is that development and design both get more and more time to complete the project, but do not exactly know when it will be ready to test.

Problem #1; Planning will always change at the last minute, especially for test.

Still, we all know the planning will change (it is a project, so inevitable). But you don't really count on the fact that with 1 project, development is so bad, you still have to execute a system(integration) test when all you had to do was the acceptance test....something went very wrong you could say.

Problem #2; Delivered software will sometimes suck and a strict process should be in place to counter this effect.

But, still nothing out of the ordinary. The last acceptance test of one of the projects is coming into focus and about 300 users wanted to participate...not really an acceptance test, so we reduced it to 30. However, no manual for the system was available. Usually there is a department who is specialized in creating this. Not in this case; project manager and acceptance test manager (read: my own person) had to create it.

Problem #3; Use a manual for the final and complete acceptance test, but be sure there is a department that creates this. Because it is A LOT OF WORK!!

Anyway, this was not all; a regression script was asked/demanded by the client as well. That's all fine and all, but for the (user) acceptance test there is no real regression script, only scenario's. So...adapt and create the bl**dy thing.

Problem #4; Be sure that the whole organization knows about the test plan before hand so they know what’s coming and what not.

I think we are adaptive as testers, more than any other person (can) be in the organization because we are at the end of a chain and we do know what it is all about. It can be a curse to be in the middle of it all, but a lot of fun as well!!

Old Testing Pic

2009-01-29T16:31:00.002+01:00

Found an old Test Pic I once created...the ultimate question....(I know corny, but still).

Innovate or perish

2009-01-26T14:12:00.006+01:00

In the current market, IT has to innovate to survive. At least that is my opinion on the matter. For Testing this is not different than for other professions; we should be innovative (and therefore adaptive). Join the discussion? See below to join in:

Software testers will survive the crisis.

2009-01-23T11:43:00.003+01:00

The top 10 credit-crunch proof jobs in the UK, according to Learning and Skills Council, are:

IT Security professional
Software tester
Network engineer
Pharmaceutical/medical sales
Web designer
Project manager
Computer programmer/developer
Business analyst
Child care worker
Viral marketing professional

Source: Is4Profit

Test a bit more, test a bit better.

2009-01-20T09:17:00.009+01:00

It might be me, but this seems like a perfect example of "bad" requirements.

I can imagine the requirements said something like;
"Send a High Prio mail every day to the user when he has too many MB's."

This is why a tester should be there to ask the client: "How many?"

Statement of the day....

2009-01-20T08:26:00.001+01:00

Bug #1: It doesn't work!

Bron: Loesje

What Are You Testing Today?

2009-01-14T11:02:00.002+01:00

What Are You Testing Today?

Posted using ShareThis

70% of all software testers are business oriented!

2009-01-13T16:56:00.002+01:00

It's a bold assumption to make since it is not based on any numbers. Call it a gut feeling, but in my humble opinion this is the case. What do I mean by business oriented anyway? Well, maybe another assumption will clarify this; Less then 50% of all software testers have no idea how to program (apart from html which is not a programming language as some might say).

It seems a bit odd since the testers do test the software and therefore should know how the damn thing was build. Or do they? One can also argue that a tester does not have to have any affinity with programming, coding and other development terms, but that he has to test whether the delivered software does what the customer asked for. And in a way these people are completely correct. Testers do have to show the customer that the software works according to the requirements set up or at least approved by the customer.

Then why should a tester know more about programming and be less business oriented? My personal opinion would be that when you know what you are testing, you know where to put your testing effort. This is what a tester is for; be in the middle of it all, know everything about anything within the software project. What testers should know:

How the software was programmed; what language was used, what are the strengths, but mostly; what are the weaknesses?
How is the infrastructure organized; Which other tools are connected or influence the newly developed software, which parties are involved, what is the live span of the infrastructure, etc
How is the architecture organized; a bit the same as the infrastructure, but deeper. Testers should read this design before testing starts. even better; we should review it to find mistakes in an early stadium!
What unit tests were executed and what was the result; unit tests usually are executed by developers, but mostly never read by testers. If you know the problems found within these tests, testers might create cases related to these findings in order to find the biggest risks.
Look over the developers shoulder when he tries to find your bug in the code; this will give a big insight in the way not only the software was programmed, but in the way the developer thinks as well. Testers are smart enough to understand code (even though we have no idea how to create it), so we can help developers in this as well.
What other projects are running; this is not exactly technical or has anything to do with coding, but knowing this, we as testers might find risks of mismatching or upcoming problems developers did not think about. For example; if one projects is working in .net, an other starts with COBOLD and these have to be integrated.....do I need to say more....

I could go on and on, but I think I’ll leave it at this for the moment. The point is made….

In conclusion; Testers should be focusing more on the technical side in order to get the correct balance between technique and business!

Things to look out for as a Tester.

2009-01-13T12:47:00.003+01:00

Concerning security testing, we all know it's nececary, but most clients don't do it or simply try to ignore it (I'll take the risk). Even or maybe especially software that is only used in-house and should not be in contact with the "bad" outside world will never be tested on security. Is this wise? Maybe you should read the following page:

The 2009 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most significant programming errors that can lead to serious software vulnerabilities. They occur frequently, are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

Source: http://cwe.mitre.org/top25/

Reality Check

2009-01-12T09:21:00.006+01:00

Customer: "I really support the idea of using Open Source Test Software....but not on my environment!"

From the field

My first blog

2009-01-07T09:19:00.001+01:00

Well, this seems to be attempt #xxx for me to start a blog....why start one anyway...well social media is fun and all, but you never have 1 place where you can dump all you thoughts and ideas...so....let's start a blog. I know...a bit late, since blogging is not new, but better late then never.

So what will this blog be about? Me? My own small world? My pets, hobbies? Not really. I would like to dedicate this blog mostly to my work...(ok maybe my hobby after all)...TESTING! Not testing of cars, products or other nice things we all like to do, but Software Testing. There is much to tell about testing, but mostly there is much to explain about it.

Still it is not yet considered a profession on it's own and mostly degraded to "something a developed does in his spare time". If this was the case, then why do we need testers? Maybe because there is no such thing as a flawless developer? Or mabye because the customer did not ask for a blue but a green button (but didn't tell design)? Or even maybe because the designer didn't quite understand what the cusomer asked? To keep it simple; all of these thing are true! A tester is not there to irritate the developer (sometimes maybe), or to tell the client the software sucks; he is there to get all parties alligned (development, business and design) and to pinpoint the risks of the product by finding bugs as early in the project as possible.

We, as testers, should have an overview of the whole project. Not only the design or the code, but the combination of all parties involved in order to be able to get a proper software product delivered. Because (in most cases) isn't this wat we are all working for; creating a product that the customer can use which has the best quality available (given time, money and accepted risks).

For now I'll leave it at that...first posts shouldn't be 50 pages I guess :-)