What a surprise I experienced when I discovered that you are speaking the same language as a software developer.

With what I learned about Behavior Test Driven Development, I asked a couple of developers to have a look at some frameworks and give me feedback in an understandable way. I organized a short meeting to go over the different frameworks and how they could be mapped on our specific needs. We have an environment that is a bit challenging. It is not so easy to integrate embedded development with a .NET web service back-end.

Looking for a BTDD framework that suites both is not that easy. An extra requirement that the developers brought on the table themselves was the understandability of the top layer. I conclude they automatically thought in the direction of business. Actually it is not realy a surprise. They face the daily challenge of implementing poorly described user stories. User stories are still not defined on team level. Work has to be done there too. We have to improve our communication with the marketing and sales team. They need to learn to translate the needs into a form that can be processed by a technical team.

The developers were surprised I was pushing for a BTDD framework. And it was a positive surprise, they told me. "We are not used to testers that look into technical solutions to improve the overall deverlopers workflow". Not many developers were familiar with the concepts of BTDD. And those who were, didn't ever see it working. So It will be a challenge. The developers are with me! That is a good start and the first real achievement I managed to acomplish in the 3 months I'm working with them. 

I will surely convince my R&D director too. He's a pragmatic person which has a good view on concepts. He's able to quickly understand the idea behind an idea, a framework, a BTDD framework.

It will be necessary to convince the marketing team of the strength of a well designed BTDD framework. Only if we have the buy-in from them, we can create testable user stories.

I have been following a lot of courses in the past. At Alcatel-Lucent we had an internal "university". So learning and gaining new insights was not unusual to me. But meeting so many people from other domains was quite interesting.

Being a tester for almost 12 years, I have experienced a long and spectacular evolution. In 2000 testing was mostly done manually. There was no framework to write automated tests in. Most bugs were found with exploratory testing. Trying to follow scenario's "normal" people wouldn't think of.

Somewhat later, the need for automating tests popped up, since the product was evolving and more and more features were added. It's in that period I got disgusted of automated testing. It was a real burden. Most of the energy was put in debugging the scripts themselves. As processes were in waterfall mode, testing was at the end of the cycle. Very limited time to execute tests. No time to debug them. As a result, tests were never properly debugged and thus not refactored. Debugging was a nightmare, since the automation code was far from readable. TCL is not the most novice-coder friendly.

When the product entered into an end-of-life phase, I went to a completely different area of testing. In an innovation team that was driven by mainly proof of concepts, automated testing didn't make sense at all, since the duration of the project was about 3 to 6 months. The scenario's were so specific, that automating them wouldn't have given any added value. Testing was more like investigating. Finding out how a technology worked. Assessing if the technology provided the features for the POC. Again a lot of exploratory testing. But also characterisation testing. Trying to find out the performance and or characteristics of a newly designed technology. It was mainly investigation and describing the findings and conclusions.

These days I'm back into product testing. Here, automation is key, since we work in Kan-ban mode for creating new features. But what has to be automated?

To answer this question, I subscribed for the Belgian testing days. My first conference in my career.

The tutorial, given by Lisa Crispin was enlightening. It gave me some insights I didn't have before. But surprisingly most of the things she told me, I was already using, or at least I had a good understanding of it. Some pictures were very interesting to use for explaining my team the importance of automated testing.

I was mainly collecting references to useful tools and websites. I heard about Fitnesse which could simplify the creation of good user stories that are testable.

The workshops on day 2 and 3 were very exiting. I got a very good insight in what are the latest concepts in the testing world. The company I worked for last year implemented a testing language, but was not aware of the latest concepts like behavior test driven development.

Main interest I wanted answers for were

• Performance testing
• Web UI testing
• Acceptance Test Driven Development
• Changing a team into the right mindset
• Finding convincing material for management

There were plenty of sessions about performance testing, which is a popular subject these days. Performance characterization is a huge challenge when you have a solution in the cloud.

• How do you measure performance?
• What are the criteria?
• Does everybody in the organisation has a common understanding about the performance criteria?
• What is the impact on your software model, if you have to improve performance?
• What are the hardware requirements
• How do you generate load?

A lot of questions where I found some answers on. Nice to meet the speakers and exchanging contact details. Setting up a performance benchmark platform will remain a challenge for sure. In our situation we need to cope with a constant incoming flow of measure data which is randomized in time. But each single data stream has a granularity of 15 minutes. Our first threshold is 10K data flows.

Most probably we will have to divide the load over a certain amount of threads. without shifting too much from reality.

The other topic that looked very interesting and powerful to me, was acceptance or behavioral test driven development. This seems to be the hot item these days. And it is hot too. As a person that highly prefers to cooperate with other team members to reach a goal, this is the ultimate concept to defend in my organisation. I will post my strategy in an other blog.

This concept invites the whole team to develop test cases that perfectly match business' user stories. It would even be possible that Business people write test cases themselves in human readable text. This is a very powerful concept that only can be used when a whole team is involved. It kills ignorance and indifference.

Concluding these very exiting experiences, I have thrown away the idea that only I had to introduce awareness about testing and quality, but the whole team should find out. It will remain my task to take initiative. Providing information about concepts is also key. Both managers as developers have the right to discover how we can evolve into a team that is driving technology instead of to be driven by it.