It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a programming paradigm also represents a way of thinking. It represents a set of patterns of problem framing and solving and contains the ingredients of software architecture.

This session explores the strengths and weaknesses of different programming styles, patterns and paradigms across different programming languages, past and present.

Target Audience: Developers, Architects
Prerequisites: Programming experience
Level: Advanced

Extended Abstract
It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a programming paradigm also represents a way of thinking. Having only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.

Perhaps even more problematic than being stuck with a narrow view of paradigms, is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation have a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.

This session explores the strengths and weaknesses of different programming styles, patterns and paradigms across different programming languages, past and present.

If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. It is hard to do because we need to deal with all sorts of group dynamics that cause people to stop sharing what they want, ending up in resistance behaviour from sarcastic jokes, to stopped communication. So how can we make collaborative design decisions better? Join us in this hands-on workshop where we explore different models of decision making.

Maximum number of participants: 24

Target Audience: Architects, Managers, Decision Makers
Prerequisites: None
Level: Expert

Extended Abstract
If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. Everyone can feel a part of the decision, and can potentially give the input they have. The group is aligned and knows what is to be expected onward. On paper this sounds great, but in reality we know it is hard to do because we need to deal with all sorts of group dynamics. Dynamics like cultural differences, conflicts of opinions, cognitive biases, and polarities that the group are part of. These dynamics cause people to stop sharing what they want, which ends up in resistance behaviour from sarcastic jokes, to stopped communication or leaving the session. No wonder a lot of people resort to a more autocratic form of decision making, where the architect analyzes and makes the decision. So how can we make collaborative design decisions better?

Join Gien, Evelyn and Kenny in this hands-on workshop where we explore different models of decision making that can help facilitate collaborative design decisions. We will dive into a variety of facilitation techniques such as:

• Working with climate reports to trigger hidden group conflicts
• Visualising trade-offs of different models with the pro-con-fix list
• Taking group decisions with full buy in with Deep Democracy

Test case design is one of the core competences of the testing profession. This tutorial is about an effective and elegant technique that is still too little known.

After an overview presentation of test design using coverage-based test design techniques and experience-based test approaches, this tutorial addresses one of the (seemingly) harder techniques from the condition-oriented group of coverage-based test design techniques, the Elementary Comparison Test (ECT) that uses Modified Condition Decision Coverage (MCDC).

Target Audience: Quality Engineers, Test Engineers, Developers
Prerequisites: General knowledge of IT delivery, quality engineering and testing
Level: Advanced

Extended Abstract
Test case design is one of the core competences of the testing profession.

Which test design techniques do you use? And is this effective and efficient?

In the TMAP body of knowledge we distinguish 4 main groups of test design techniques: Process-oriented (such as path testing), Condition-oriented (such as decision table testing), Data-oriented (such as Data Combination test) and Appearance-oriented (such as Syntactic testing and performance testing).

After an overview presentation of test design using coverage-based test design techniques and experience-based test approaches, this tutorial addresses one of the (seemingly) harder techniques from the condition-oriented group of coverage-based test design techniques, the Elementary Comparison Test that uses Modified Condition Decision Coverage.

Suppose you must test the entry-check of the new Wuthering Heights Rollercoaster in the QualityLand amusement park. Every person must be at least 120 cm tall to be allowed in the rollercoaster. What technique would you use? Boundary Value Analysis (from the group data-oriented testing), right? That’s not a tough choice.

But now the marketing department of QualityLand has a special offer for Halloween. To be allowed with the special discount-rate, a person must still be at least 120 cm tall, but must also wear a Halloween outfit and needs to be at the gate on 31 October (that’s a decision with 3 conditions). On top of this, if the person has bought a ticket online, and paid 10% extra, they may skip the line (that’s another decision, with 2 conditions).

So, all in all you have 2 decision points, with together 5 conditions.

Now what test case design technique do you use?

In the above example (with 5 conditions) choose a condition-oriented test design technique. But which? Probably you know Decision Table Testing. Applying this technique would lead to 2-to-the-power-of-5 = 32 test cases. That’s a bit too much to call this an efficient test set.

My advice is to use the Elementary Comparison Test (ECT) design technique, together with Modified Condition Decision Coverage (MCDC). This way, with only 6 (!!) test cases you can guarantee that EVERY condition has contributed to trigger EVERY outcome of the entry-check of the rollercoaster. So, it is both effective and efficient!

Have you never heard of ECT before? Well, even though it exists for decades, I can imagine, because ISTQB doesn’t teach you this. But is has been part of the TMAP body of knowledge since 1995 :-)

This HUSTEF conference you will get your chance to learn all about ECT & MCDC!!

Join me in this half-day or full-day tutorial and I will make sure that you will get hands-on experience.