Tag Archives: exploring

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.

The W-model and Check, Explore and Accept

Posted on by
2

In an earlier post I wrote about the W-model. I wrote this: “Every different product generated in the development life cycle should be checked.” So how should I check this? The checking with software product should be done with testing. For this it is easy, but how is this testing build up. In my opinion the testing is build up out of three things: check, explore and accept. This post is a brain dump for me about this subject. How do you think about it? Am I wrong, did I miss things or do you agree with me? Please let me know.

W-Model

How do approve, accept and explore compare to the W-model? First we have to know what everything is.  These three are:

  1. ‘Check’ is the determination whether a created software product complies with the specifications.
  2. ‘Explore’ is an (in depth) investigation of non-specified parts of a (created) software product for errors.
  3. ‘Accept’ is whether the described specification or product is the correct solution of the (user) problem.

    You can agree or disagree with these statements, but this is my opinion on it. I’m not setting the definition on it, but for me testing consist of checking, exploring and accepting a product. With my idea you get the most of all three worlds.

    Check
    Checking a product is maybe the most important thing to do as a tester. As stated above approving means the product complies with the specifications. When do we do this? When looking at the W-model this starts early. The client states its business requirements and after they are written down he reviews them if they are correct. If they are correct the client approves them.

    After this all the separate deliverables are checked whether they are correct and if they still comply with an earlier product. When the software is built it is checked whether it complies with the deliverables. But is this what the client wanted? But are all errors found in the product? I don’t know! To know this the software needs to be accepted and explored.

    AAE-Approve

    Explore
    By exploring a software product you investigated the product to look for errors. Why do I look for errors? Because it is time consuming and the software can be approved. But what about security issues, usability and other non-functionals. These parts of the software are often ‘forgotten’. But also software that has been approved isn’t always good. It’s working as requested, but it also should be secure. Or functioning in a manner nobody at the start of the project thought about. This is why you explore a product. In my opinion the most fun of testing and also the most difficult part. A tester should be skilled enough to perform these exploratory tests. My experience is that testers who often explore a product find many serious errors. The preparation of the testing in such cases is difficult because the tester cannot rely on an exemption from the specifications, but the tester needs to be creative and skilful to find defects. Exploring can be done on all the deliverables in a W-model. But especially on functional and technical design and during the testing. Explore has some ideas from Exploratory Testing like the Context Driven School of James Bach, but they also use exploratory testing with approving. This is something I don’t comply with in the use of explore. But the use of heuristics and oracles is definitely a thing you should use when exploring with testing.

    AAE-Explore

    Accept
    Accepting a product is maybe the most difficult to comprehend for an IT professional. I had a discussion with an information analyst and his answer was when I asked him “how do you accept a product?”, he said to me “when the acceptance criteria are met”. This is where I disagree. Some of the acceptance criteria are specifications and should therefore be approved. Suppliers always want quantified acceptance criteria which makes them specifications. But a user (client) has to accept the product as the correct solution to his problem. Thus for me users are the only group that can accept a product. Accepting requires knowledge and experience with the process, and the system.  This knowledge can be acquired by using interview techniques or teaching the user on what to expect. Acceptance is done at the beginning and end of the W-model. Starting with the creation of the business requirements, during acceptance testing and operation and management.

    AAE-Accept

    I am not for one of these approaches for testing, but for the combination of this. When time is a problem you could use either checking or exploring while testing the software. But always use accept. Because the user has to work with it!

    In a next post I`ll write more about the ‘how’ of, for example accepting. Where this post describes the ‘what’ and ‘where’.