Tag Archives: checking

Update your (testing) skills

Posted on by
1

Two weeks ago I passed my motorcycle driving exam. I’m now illegible to drive a (high cc) motorcycle. It wasn’t my first (driving) exam. In Holland you first have to pass a skills exam and theory exam before you can have your final exam.

I was thinking, how does this align with testing? You could see this as getting my license is like getting certification, but I disagree. I now have my driver’s license and I’m allowed to drive. The more kilometres I drive the more experienced I get and hopefully, even better. But with certification you are already allowed to test (it’s your work/assignment) and you think you are better than before you got certified. That’s complete bullshit!

“Certification doesn’t get you more skilled in testing”

Let me start by saying I’m not against certification, but against the thinking that if you’re certified that you are a good tester or that companies only hire certified testers (read this post by Andréas to read why). No, you have a better knowledge of testing. You are not more skilled. You have to earn that! And when you get more testing kilometres and learn ‘hands on’ from some more experienced testers you get more skilled.

But you have to update the knowledge and skills you have mastered in your career. When we hire testers we make sure they are intelligent enough, teach them the basic testing knowledge and let them perform some exercises. And then we send them into the big, bad world. For a starting point it’s not bad. As long as you let them be taught by experienced people with vast enough knowledge.

“We only use DCT”

New testers will user this knowledge in their first assignment as best as they can do and (hopefully) learn from others around them. But after a few years and a bunch of different assignments they forget what they have learned. In Holland for instance we do a lot of checking during our testing. We learn a lot of test design techniques which we should put to use. But we tend to forget them. Why? Because we only use PCT or DCT. But is that enough? Sometimes “yes”, but most of the time “no”! And by the time we are promoted to a testing coordinator we only let our projects be checked with PCT or DCT. And what happens? The testing quality goed downhill, because the test coverage is not good enough.

I think we should keep up our knowledge and skills we’ve learned in the past, our basic toolkit. Before we get a promotion we should show we still have the basic skills and learned a few more. That way we continuously challenge ourselves to think more in terms of the best way, instead of the normal way.

In my opinion this is the same with a driver’s license. People tend to drive their way but don’t learn new rules and when they get older some people are still allowed to drive even if they are an accident waiting to happen. We should also update their knowledge and skills sometimes…

So update your testing skills once in a while. Get better at what you do and learn from others.

2009: The end is near…

Posted on by
65

As the end of 2009 comes closer and closer it’s time for a little reflection on 2009. This my first full year as a business developer at the company Andréas and I work at. Last year I started in April and we had one assignment: ‘write a book about BDTM’. But this year started with us doing more various things. We also started this blog (actually it was December 2008) and started to write about the things we come across in our work. Although the financial crisis didn’t really help I did a lot of nice things.

I thought of crowdtesting. Not totally new, but I tried to grasp it with all its potential and weaknesses. I thought of it while I was consulted by a game manufacturer on how their test process was. During the year I did 2 assignments for clients to implement it. One was successful, the other a little less (at least for me). The fun part was that also other people started upon it and we both posted several articles in magazines about this phenomenon. And I am invited to present on this subject on the Swiss Testing Day in 2010.

Evaluations became much more important in software development. Documents need to be checked more and more thoroughly before it can be used in later phases of the development lifecycle. I try to use reading techniques to help streamline this method of checking the documentation. A process that needs to developed even further next year.

And speaking of checking, Michael Bolton addressed this Testing vs. Checking on his blog, whereas I tried to take it a step farther. Software testing is a combination of checking, exploring and accepting. Where the added value of tester lay in exploring the software and coordination of the checking and accepting of it.

This because the new urge for industrialisation of software testing in Europe tends to outsource checking to India or software. Like the opportunities Model-Based Testing adds to automatically create test cases for checking an application. These test cases can from there also be executed automatically to decrease the amount of work testers need to do to check a software program.

Another big topic for me this year was Augmented Reality. This fabulous new technology also needs to be tested and we tried to create a method to test it. But most important was to think about the use of this technology for testing. This became Augmented Testing; a subject I will share with you in 2010.

2009 was a good year, but 2010 has a lot of potential to get even better.

The added value of testers

Posted on by
3

How can I as tester deliver an added value for my organization? Of course I check that the drawn up requirements and specifications are correctly processed in the software and that the software works correct. But more and more around me I see that this checking is rehabilitated. First there was the idea to automate the test execution software, then to outsource the work India when the automation didn’t hold up to its expectations. Then the ‘financial crisis’ arrived. That meant that automation of test executions could show us again that it seemed to work and it did. Lately you hear more about Model-Based Testing, as I wrote in this post. Model-Based Testing takes over part of the test specification to be automated. What should I do? Where is my added value as a tester? Of course Model-Based Testing shifts the activities of a tester and the automation ensures that you can test more, which means that specific parts can still be tested by a tester (with more attention to this). But really, where is my added value?

That added value is what testing really is about. Testing is a combination of checking, exploring and accepting. So what are checking, exploring and accepting? See The W-model and Check, Explore and Accept for more details on this.

Is checking an added value?
When I look at the trends and innovations about testing around me, I see that checking is no added value for a tester. This work can be performed by inexperienced testers, be outsourced and even done by a computer. Because we only check whether the expected results match the actual results. In specifying on what the results should be when checking lies perhaps an added value, but an important part of the checking, functional checking, can de done with model-based testing (at least part of it). Naturally I as a tester have a direct involvement in creating the model. I can even add some test cases into the model to process any issues I think of. As a test designer/architect I can even create the whole test model. Model-Based Testing only covers the functional part of a system. Other quality attributes should also be checked. A tester should create the test cases for these attributes. And also evaluations are an important part of checking. I think I have stated quite a few times how important evaluations are. When evaluating there is a clear added value of testers. Because testers look (very) critical at documentation. I as a tester can evaluate the documents in a good manner, but the effort of evaluations compared to creating test cases is however much smaller.

The added value of a tester in checking is:

  • * create models for model-based testing
  • * evaluate documents
  • * create non-functional test cases

Can a tester accept?
Can I as a tester accept? No! As a tester I’m usually not the future user of a product. So I cannot fully assess whether the solution is right for the user (in a UAT). This can only de done by the user. Accepting can also be seen as learning to work with the software and integrate it into business, but also getting acquainted with the System under Test (SuT). A testing coordinator can guide the accepting phase, but the real acceptance is done the users. The task of a tester is mainly a warning function; the user (client) self provides the acceptance. However by good cooperation (especially in agile projects) a tester can give a “binding” advice.

The added value of a tester in accepting is:

  • * help coordinate the acceptance of the user
  • * cooperate with other parties in an Agile project

Is exploring the added value for testers?
OK then, exploring. Exploring is something I as a tester can I do! I am an experienced tester and therefore have the test knowledge to do so. I can also ask the correct questions to get more information about the business and system. And also I don’t take first response as the best, as a result I interview people about their knowledge. A checking tester will not look any further then the written down information. And I also have enough in depth knowledge about the business that I’m testing so that I know where to expect problems. As a tester I should therefore look for in depth information about the processes of my client and from there go testing. I can do this with test cases, but also through (a more creative mindset with) exploratory testing. Using this test approach I can show where the system needs to be adjusted, because the system doesn’t resolve the problem of the customer. I use the specifications or requirements as a starting point and then build out the tests based on my knowledge of business processes and my testing experience. As a tester I can thus provide an added value to my client when I explore the software! To test better I need as much knowledge as possible of a client and its processes. Testers should be closer to the clients processes (business) rather than the technology. And of course specialists are needed that know more about certain technology (like security en usability experts). Besides our basic knowledge of testing, we need to have more business knowledge!

The added value of a tester in exploring is:

  • * create and executes test cases from other information than that is documented
  • * help the business with testing the business processes
  • * find those errors not derived from documentation
  • * have technology help in expert work.