SOGETI UK BLOG

Do you use a smartphone today? Yes. Did you use a smartphone 10 years ago? No. Do you use a robot today? Probably not. Will you use a robot in 10 years from now? Yes! Does that perspective bother you? What are the risks? What are the possibilities?

What by today’s definition is a robot? It’s a machine that gathers information about its environment by input of sensors and based on this input changes its behavior. Combined with machine learning and machine intelligence the robot’s reactions over time get more and more adequate. The use of Internet of Things, Big Data Analytics and Cloud technology make a robot versatile.

A Robot can come in many different shapes and forms. It’s not just the metallic man. It may just as well be an autonomous vacuum cleaner or a self-driving car.

Testing a Robot

How will you know you can rely on your robot (or more likely multiple robots)? We’ll have to learn how to test machines and can use machine learning for testing! To find out how to test a robot, I built my own robot, and started learning about testing it. In this presentation I will take you along my quest and share my experiences and insights.

Learn more about the Euro Star Software Testing Conference here.

Rik Marselis AUTHOR:
Management Consultant, Quality & Testing

Posted in: Big data, Cloud, Digital, Infrastructure, Innovation, Internet of Things, IT strategy, Research, Robotics, Software Development, test data management, Test Tools, Transformation, User Experience      
Comments: 0
Tags: , , , ,

 

We are three years away from the golden jubilee of the first human ever landing on the moon.  The 1960s was the era when everyone was fascinated by space travel. One of the first hits of the legendary David Bowie, “Space oddity” (about astronaut Major Tom) is testimony to this.

Neil_Armstrong_Piloting_Lunar_Module

As you know the first man on the moon was Neil Armstrong. A man with an eventful life, and a man who knew what he wanted     and made clear choices.Neil_Armstrong

The one thing Neil was always passionate about was flying.  During the       Korean War he flew many missions. Soon after, he graduated in                       aeronautical engineering and started looking for a job. He clearly knew         what he wanted to be: an “engineering test pilot.”

Aha, so Neil Armstrong wanted to be a tester. But not just any kind of             tester. He had quickly discovered there are two types of test pilots.

The first kind are the “production test pilots” who are employed by an             aircraft factory. Their job is to get a plane off the production line for it’s first flight in order to determine whether the aircraft complies with specifications and is working properly.

The second kind are the “experimental test pilots” who are employed by a research organization (e.g. the NASA). Their task is to test new concepts and opportunities and thus contribute to the development of better aircraft.

The above explanation provides a clear distinction between production tester and experimental tester. I wonder, can we apply this distinction in testing of IT-systems? If so, what are you? And what would you want to be?

Neil became an experimental tester for NASA and flew to the edge of space in the X-15.

I believe we don’t have such a clear distinction in our testing profession. Because all the software and systems that we make are produced only once (and then, if necessary, copied, that’s the advantage of software).

However, a nice parallel can be found. First, we have the distinction of regression tests and progression tests. In a regression test, we test a system after modification to see if the unchanged parts still do what they did already. This is similar to the activities of the production test pilot.

In a progression test, we test a new (sub) system to determine whether it meets the specifications and expectations of the client. This is more like the experimental test pilot.

Are you at the brink of a choice for your testing career? Then think about these options, it can help you determine your best options.

On the other hand, most testers I know, do both- Regression and Progression Testing. Sometimes the focus is on the one and sometimes on the other. Because really, doing nothing but regression testing, how long would you stay happy? And since doing just progression testing in today’s world simply isn’t sensible, you always need some mix of progression and regression testing.

In the world of testing there is a small group of people who are trying to improve the testing profession itself. In them we find resemblance with final job that Neil Armstrong applied for, the “research pilot,” which he became at NASA and which was the reason why he came to fly the lunar module that was really the top research opportunity for a pilot.

The story above demonstrates that even half a century later, we can find inspiration for our own field in the choices made by the first man on the moon.

Enjoy your testing profession!

Source: First man, the life of Neil A. Armstrong, by James R. Hansen, © 2005/2012

Image sources:Wikipedia, Getty Images, Nasa website.

 

Rik Marselis AUTHOR:
Management Consultant, Quality & Testing

Posted in: Exploratory Testing, Human Interaction Testing, Infrastructure, Innovation, IT strategy, Quality Assurance, Research, test data management, Test Driven Development, Test environment, Test Plans, Testing and innovation, Training, User Experience      
Comments: 0
Tags: , , , , , , ,

 

iStock_000050757486_Woman waiting for elevator

Many years ago I read the sci-fi-classic “the hitchhiker’s guide to the galaxy” by Douglas Adams. I was intrigued by the scene of the elevator that could see in the future. The Sirius Cybernetics Corporation Happy Vertical People Transporter has the capacity to see dimly into the immediate future, which enables the elevator to be on the right floor to pick you up even before you knew you wanted it. This way when you walk towards the elevator it just appears and already knows what floor to bring you to, so the waiting time is eliminated.

Back then it sounded totally impossible to me. How could an elevator know about the future? Only a human elevator-operator could add intelligence to an elevator, at least that was my experience back then.

But things have changed.

The first change I noticed some ten years ago, was that you had to enter the desired floor-number while calling the elevator. That way the elevator-system could plan the optimal route through the building and the group of elevators together works as optimal as possible. But although it was more efficient, that elevator wasn’t waiting for you when you walked towards it.

Nowadays, with RFID sensors omnipresent and all sorts of systems connected through the Internet of Things (IoT), it’s quite easy to connect the access-gate of a building to the elevator-system. As soon as you enter the building the elevator knows you’re coming. So it can actually be waiting for you. But then it only knows you have arrived, it doesn’t know where you want to go. Or does it?

Most people have a desk at a certain floor. (Even most people that work in a flexible office still go to the same part of the building every day). So  the elevator-system can remember the floor you normally go to in the morning. This still can’t be called intelligence, it’s just remembering.

iStock_000026113990_Elevator sign

So what about the rest of the day, how does the elevator know where you’re going when you’re already in the building? Here comes machine learning.

The elevator can store all of your movements and from that, learns to predict where you want to go, based on your normal pattern. A coffee-machine-service-lady for example always goes up one floor every time and when she has reached the top-floor she goes all the way down again. Unfortunately most people are not as predictable as this.

Luckily again the Internet of Things will help us. Your smartphone holds your diary. Your diary says you have a meeting at the seventh floor, connect your smartphone to the elevator-system using IoT and  the elevator knows where you want to go.

But still this is not enough, because do you put “go home” in your diary every day? (I don’t 
</p>
                 
                  </div>

                  <div class=

Rik Marselis AUTHOR:
Management Consultant, Quality & Testing

Posted in: Big data, Human Behaviour, Human Interaction Testing, Innovation, Internet of Things, mobile testing, Research, Robotics, Smart, User Experience, User Interface, Wearable technology      
Comments: 0
Tags: , , , , , , , ,

 

23_q74tnWhen organising testing, the test manager adhering to the traditional view on testing had to structure the testing activities in a hierarchical way, based on quality characteristics. But a test manager often distinguished various stages too. Defined terms such as Test Level, Test Type, Test Phase and Test Stage were often used.

In today’s view on testing, the people involved in testing are hesitant to use the word ‘Test Level’ since it seems to imply that various groups, based on various hierarchical responsibilities, will perform various testing tasks without any interaction between these test levels. Moreover, many testers have often struggled to distinguish between Test Levels and Test Types. And a Test Stage – is that identical to a Test Level or not? What should be our focus when organising testing?

All testing activities must collectively cover all important areas and aspects of the system under test – that is the main objective. To cope with the confusion around how to distinguish testing tasks, we introduce the term Test Variety.

The term Test Variety aims at making all stakeholders aware that there will always be different needs for testing, and therefore different test varieties will have to be organised. Whether these are organised separately or combined depends on the situation. There may be many reasons for having different test varieties. For example, there are different stakeholders who ought to be involved; programmers have a different focus in their testing than business representatives do. This is often related to responsibility and accountability for testing activities. The quality characteristics that have to be addressed form another reason for distinguishing test varieties. Maintainability for example, demands totally different testing activities than usability does.

Traditionally, different aspects were separately approached as a group of testing activities that had been brought together in a test level. Many people know the ‘functional acceptance test’, a name that already indicates that testing was not complete because it obviously didn’t focus on non-functional aspects. In the new view, functional and non-functional testing can be seen as test varieties. Depending on the circumstances, such as the application lifecycle model that is used, these test varieties are organised either together or separately. The main concern is that all relevant test varieties are carried out one way or another.

So let’s use the term Test Variety, to make everybody involved aware of the fact that there are different points of view towards testing activities, and we can make sure that the interests of all stakeholders will be covered by addressing these in a well-considered way.

To read the original post and add comments, please visit the SogetiLabs blog: TEST LEVELS? TEST TYPES? TEST VARIETIES!

Related Posts:

  1. The art of writing test cases
  2. Six corner stones of a Test Center of Excellence
  3. Testing is dead, long live quality
  4. Is it a good idea solving test environment problems “later”?

 

Rik Marselis AUTHOR:
Management Consultant, Quality & Testing

Posted in: Application Lifecycle Management, Big data, Business Intelligence, Developers, Opinion, Testing and innovation      
Comments: 0
Tags: , , , , , , , ,

 

RelaisMany people that have been around for some time in the IT business tend to feel a little bit puzzled nowadays. “The IT world is changing but what does that mean for me?” Join me in this blog post to look into the trends and how they affect anyone working in IT.

Have you noticed that every decade has its own focus in the computer business? The eighties were about new technological possibilities, e.g. the introduction of the PC. The nineties were about using IT to support daily activities, e.g. using a word-processor instead of a typewriter. The zeros were about getting connected – the internet came to every house. And the current decade is about ubiquitous IT – everything is connected.

But I noticed that creating applications has followed an unchanged pattern all through these decades. When I started in the IT business over three decades ago it was all about the process we had to follow to reach success, and in later decades it was still about process. I noticed that sometimes projects were very successful, whereas other projects were a disaster (and many projects worked out sort of well). If we compare those projects to sports, they were organised like the decathlon, everybody doing their own thing in their own little playground and passing the baton to each other. I started wondering why there was a difference in the success rate for projects even though they all used a similar approach. Obviously the process was not the differentiator.

Currently times are rapidly changing. IT watchers discovered that a good process in itself doesn’t bring success. The real key to success is… People! This marks the current trend in IT, less emphasis on process and more room for the initiative of people. People are flexible, adaptive, and agile. People can adjust their behaviour to a new context, especially when people get the trust and confidence of stakeholders to work together and pursue the project goals in the way the team thinks most appropriate. Making the comparison to sports again, nowadays IT is seen as a team sport – everybody in the team has complementary and overlapping skills that result in the famous statement “1 + 1 = 3”. Teams that are empowered in this way can move mountains, so to say. And working together in a good team also is much more fun.

More and more organisations recognise this trend in IT – less process, more empowered people. But, you may ask yourself, what does this mean for me? Forget your nice job title and your official role. In this new world of empowered teams it’s all about your skills. Every team needs a mix of skills and you must contribute by applying the unique skills you have. Skills may be in all sorts of professional and personal areas, don’t think from a professional perspective anymore. Someone who used to be called “analyst” may now just as well contribute by writing some code, a “tester” may contribute to the designs and a “developer” will also do testing activities. Applying a process whenever necessary is just one of the skills the team members need to possess. Another skill is to change the process if that is better, do retrospectives, and actually use the feedback to continuously improve in the spirit of “kaizen”.

Success is based on the mix of skills from people that don’t bother about the title on their business card, but work together and pick up the most important task that is waiting! So don’t let a process limit your success, but work together with inspired colleagues in an empowered team to achieve more success!

Rik Marselis AUTHOR:
Management Consultant, Quality & Testing

Posted in: Agile, Collaboration, communication, Human Resources, Innovation, IT strategy, Open Innovation, Opinion, Technology Outlook, Transformation, Transitioning, Working in software testing      
Comments: 0
Tags: , , , , , , , , , , , ,