thoughts from the test eye

One heavyweight way of testing charisma is to use dozens of potential users on dozens of alternative product solutions/prototypes.
For lightweight charisma testing, it is often fast and fruitful with an awareness of charisma violations.
This method requires an understanding of the unique charisma for your product.

Testers probably won’t be in charge of developing an explicit charisma model, but you can take part, e.g. by recommending the following process:

1. Write down what you believe are the special things about the software (gamemakers might use “playability”, but please be more specific)
2. Get inspired by thetesteye’s generic list of Charisma characteristics (provided below)
3. Document the important characteristics with as much details as possible (to make’em truly mean things in your context.)
4. Share, review, refine and gain approval for your Charisma Guidelines across the teams

When you have this list, it is fun and attention-inspiring to keep these things in the back of your head whatever type of testing you are performing.
Just remember to report appropriately, probably verbal.

Charisma: Does the product have “it”?

– Uniqueness: the product is distinguishable and has something no one else has.
– Satisfaction: how do you feel after using the product?
– Professionalism: does the product have the appropriate flair of professionalism and feel fit for purpose?
– Attractiveness: are all types of aspects of the product appealing to eyes and other senses?
– Curiosity: will users get interested and try out what they can do with the product?
– Entrancement: do users get hooked, have fun, in a flow, and fully engaged when using the product?
– Hype: should the product use the latest and greatest technologies/ideas?
– Expectancy: the product exceeds expectations and meets the needs you didn’t know you had.
– Attitude: do the product and its information have the right attitude and speak to you with the right language and style?
– Directness: are (first) impressions impressive?
– Story: are there compelling stories about the product’s inception, construction or usage?

I want to open for a discussion on pair testing or at least widen the concept. By saying pair, we say two people, but why should we limit us to that? Depending what your objective is a different number might be more applicable?

Several of the referred authors in this article have elaborated around pair testing as something that could be wider and be used in different ways, many of the things I have expressed below has also been brought up by them. Still, I’ve added some parts and changed the scenery a bit.

Looking back at pair testing

“Pair testing is a way of approaching a test design process by having two people test the
same thing at the same time and place, continuously exchanging ideas. Even without any
special method or process, the dynamics of pairing enables the generation of more and
different ideas than either tester is likely to produce on his own. It’s an effective
complement to individual testing.” a quote from a draft article by James Bach and Sam Guckenheimer [1] on Pair testing.

This draft goes through the basic concept of pair testing. They discuss how it can be used in different forms and where it might be useful and in which situation.

“Two testers and (typically) one machine.
• Typically (as in XP)
– Pairs work together voluntarily. One person might pair with several others during a day.
– A given testing task is the responsibility of one person, who recruits one or more partners (one at a time) to help out.
• We’ve seen stable pairs who’ve worked together for years.
• One tester strokes the keys (but the keyboard may pass back and forth in a session) while the other suggests ideas or tests, pays attention and takes notes, listens, asks questions, grabs reference material, etc.” a quote from an article on Exploratory pair testing by Cem Kaner and James Bach [2].

Here James Bach and Cem Kaner elaborate around exploratory pair testing, how they suggest the pairing should be done, benefits of doing it and some drawbacks and risks with it. They also identify that it can be done in different combinations and that it is suitable in different situations.

“Working alone is working without a safety net” a quote by Brian Marick in an article [3] on Pair testing.

He summarized what seems to be a discussion in a workshop, where several parties were present. Several examples are listed where pair testing would be good, but he also identifies areas when it is not suitable. Furthermore he points out the importance of it not being more than two, thus naming it pair testing.

Jonathan Kohl takes on a different approach in an article about Pair testing [4]. He gives some examples where he has worked with developers in pair testing sessions with great result. He provides some hands-on tips on how to go about this and things to consider. He is focused on working in pairs, but he also adds the concept of using this technique as a way to teach testing and to grow the relationship between different parties in the organisation.

“As in pair-programming, two people simultaneously test an application at the same computer. It can involve: testing an application from a customer’s perspective and more technical kinds of tests”, a quote from a presentation [5] about Pair Testing by Jonathan Kohl.

In this presentation Jonathan elaborates deeper around the usage of the Pair testing technique. He touches a range of areas and brings up some other aspects than previous writers.

One thing that I notice from the various writers is that you use pair testing or as a technique to accomplish different objectives. Each writer includes different things to the concept of pair testing. Based on that, I saw that a pair testing session could consist of different dimensions. One of these dimensions was the amount of testers involved in a session, which in turn made me question the name of pair testing. Instead I call it group testing, since I think it can be two or more based on the objective. Beside considering that there can be different amount of testers I saw that there are other dimensions worth exploring.

Dimensions of group testing

There are many dimensions that could be investigated and experimented with. Here are the initial dimensions I’ve identified and experience with:

• Amount of participants – how many are part of the group testing session?
• Role as a tester – which role do you play as a tester? Is it explorer/tester, documenter/observer, checker, coach/trainer/teacher, reviewer, manager or something else?
• The scene – Are you running a specific user scenario or perhaps combining a set of user types? What scene have you painted that you are acting in? What personas are valid in this scene? What storytelling aspects have you considered when setting up this scene?
• Mission of group test – What is your objective[s]? What do you wish to have achieved when the group test session is finished? Do you wish to find information quickly, teach, coach or train a member of the group, review testing skill, report information quickly, help trouble shooting or something else?
• Note taking style – How are you taking notes? Do you take note in one single document that all of you write in simultaneously, is one of you taking notes only or are you all writing your own material?
• Partner combo – Which other stakeholders are part of this group test session? Do you pair up with developers, project managers, line managers, CEO, sales and marketing, system managers and business analysts … who?
• Lateral thinking style – Should part of the participants take on different lateral approaches such as thinking the opposite or wearing different thinking hats?
• Personality mix – Consider how you mix personalities such as introverts, extroverts, slow thinkers and quick ones. Which combinations work better than others in your context?
• Debriefing style – Do hold a debrief after each session or is it sufficient with the ongoing discussion you have?
• Accountability focus – Do you have one driver who is accountable or do you have many driving at the same time?
• Focus areas – Does each participant focus one specific characteristic (usability, security etc), a mix of focus areas between persons or possibly everyone focus on one characteristic?
• Test Environment setup – Do you sit behind one system or test environment, one system or test environment per person or possibly a mix of systems per person?
• Session duration – Do you do a longer session or short ones? Do change driver during or after each session, either way consider how this is setup  depending on the duration.
• …

Conclusion

There are many dimensions to the group testing technique that need to be experimented with. My point to this is that I fail to see the point in limiting the technique to a specific setup, but instead let its content/dimensions change depending on context. There are a few major pros that you probably get by using this technique, no matter which dimension you alter. Some of these are:

• an increase in creativity
• an increase in cooperation in the team/organisation between different roles
• an ongoing training of the participants in expressing themselves both in written and verbal form
• …

Based on my own experience, I think this is an excellent way of testing with great result. Therefore I intend to dig further in this area to see what comes up.

References

[1] Pair testing (aka Extreme Testing) by James Bach and Sam Guckenheimer –  http://www.exampler.com/testing-com/test-patterns/patterns/XT-Pattern-jb.pdf
[2] Exploratory testing in pairs by James Bach and Cem Kaner – http://www.kaner.com/pdfs/exptest.pdf
[3] Pair testing by Brian Marick – http://www.exampler.com/testing-com/test-patterns/patterns/pair-testing.pdf
[4] Pair testing – How I brought a developer into the testlab by Jonathan Kohl – http://www.kohl.ca/articles/pairtesting.html
[5] Presentation on Pair testing by Jonathan Kohl – http://www.kohl.ca/presentations/pair_testing.pdf

I have been doing and teaching quite a lot of scenario testing lately.
I have been surprised by the ease and speed, and ability to find important problems, (also giving an embryo to a compelling bug report.)
Maybe it can be useful for you as well, probably as a complementary technique, or as a powerful activity for mature products.

My basis comes from Cem Kaner’s writings, Introduction to Scenario Testing, but mostly BBST Test Design.
The latter is Creative Commons, so I can quote the basics:

“A scenario is a coherent story about how someone uses (or tries to use) the program.
A scenario test uses a scenario as a tool for evaluating a program’s behavior
The elements of the story (adapted from Carroll, 1999)

• Setting
• Agents or actors
• Goals or objectives
• Motivations and emotions
• Plot (sequences of actions and events)
• Actions & events can change the goals”

(slide 301 in BBST, Test Design)

When documenting, I also add a purpose of the scenario test, so it is clear why we’re doing it.

Kaner lists five key characteristics for an ideal scenario test: story, credible, motivating, complex, easy to evaluate:

• “The test is based on a coherent story about how the program is used, including goals and emotions of people.
• The story is credible. Stakeholders will believe that something like it probably will happen.
• The story is motivating. A stakeholder with influence will advocate for fixing a program that failed this test.
• The story involves complexity: a complex use of the program or a complex environment or a complex set of data.
• Test results are easy to evaluate. This is important for scenarios because they are complex.”

(slide 302 in BBST, Test Design)

I am not rigid about Easy to evaluate, rather the contrary; I want rich scenario tests and trust our ability to find out the details when encountering problems.

To find out what to base the scenario around, Kaner suggests 17 ways.
These can help, but you get even further by understanding what’s important. To speed that understanding, 37 Sources for Test Ideas might help.
Build the scenario around something important, add complexity (sequences, data, environment) and a credible goal, often spanning outside your product.

I guess you’d like an example, but I won’t give you that, because too many of you will use it as a template and don’t make the effort to find out what matters in your context.
But make sure to not try to cover as much as possible, and don’t be afraid to add corny details (they add life.)

Try it and see if the technique can help you!

As everyone else, I fell into testing by chance. I wanted to work as a developer, and saw testing as a stepping stone (this quickly changed, though.)
My first day I tested a Service Pack of a big, localized product. An experienced tester guided me at the start, and I can still remember the conversation.

Rikard: So is this machine the right one to use for this test?
Anders: Yes, you can start testing. Tell me what you are thinking, so it’s easier for me to help you.
Rikard: I double-click the installer and a welcome screen appear. I click Next.
Anders: Wait! Did you read the text?
Rikard: No.
Anders: Well, read the text and tell me what you think about it.
Rikard: OK. I think the welcome screen looks good, it tells me what it’s about to do, and the Swedish is correct.
Anders: Good. You know, some people actually reads this kind of information…
Rikard: Now I follow the script and select a custom install and click Next. I select all components as the test case tells me and click Next, and now it’s time to actually perform the installation.
Anders: Stop! Why do you just follow the script and click Next all the time?
Rikard: Because it tells me to.
Anders: But do you think all users will follow a script and know what to do all the time?
Rikard: I suppose not all of them.
Anders: So then you need to do some variations, click Back and change your mind, act like a normally confused end user.
Rikard: But why isn’t that included in the test steps?
Anders: You can’t specify everything, you can’t just do only what’s required; you are a tester, and supposed to find most of the important bugs.

I did variations, I soon found that the installer would forget the selected components after Back/Next, and that it was easy to not be aware of this.
The bug was reported and fixed, not a big deal perhaps, but a very important lesson for me:

Regardless of what they say, they probably want you to find issues that will annoy end users.

Last week I entered the first bug in a bug system for a new service that I just started to work on. Me and my team spent quite some time in getting it right, setting the standard for bugs to come. If the first bug is crappy, the rest can be as well. We considered the format, what was included in form of logs etc, how to reference to the build, the configuration setup, the ever so important title and the to-the-point-repro-steps. We did not add any expected result, it was too obvious. If had, it would have made some of the stakeholders go Duh! most probably. We even tried to make sure that the pinpointing task would be so much easier. As I see it, we made a good case for getting it prioritzed to get fixed.

I even set up some guidelines on how to report bugs with some nice references to BBST Advocacy course and other great materials from blogs.

Being first has its advantages. You set the level of expectation and hopefully you set your own ambition for what is to come.

In Julian Harty’s keynote Open Sourcing Testing at Let’s Test conference, RedNotebook (together with Sikuli and CiviCRM) was suggested as an open source project where ambitious testers could collaborate and share their testing efforts and results.

I have done a small start by contacting the RedNotebook team (they are interested in bugs and enhancements, especially in the areas of usability and performance.), and creating 7 charters (or exercises) to start with.

Details can be found at https://answers.launchpad.net/rednotebook/+faq/1971

The charters are available in the question forum (we’ll start there), where methods (here’s where we’ll learn) and results (here’s where the project will learn) can be entered as answers:

1: Test changes in the latest RedNotebook version
2: Usability heuristic evaluation
3: Performance investigation
4: Evaluate automation tool applicability
5: Platform compatibility
6: Save/Load
7: Bug Advocacy

Perform these, create new or test in your own preferred ways.
If we test the same product and share the way we do it, we can improve our testing skills!

Preparation

The hardware setup of the testlab was 1 server and 4 laptops brought by Compare TestLab, 5 laptops by Adecco IT Konsult and finally 2 laptops brought by James Lyndsay. Many participants brought their own laptops. Before the conference I worked some on setting up a wiki, bug system etc. I tried to find a balance in not over-planning, but noticed later on that I had written down too little information making it hard for the participants in getting started and in knowing the overall missions.

By having a base of 11 laptops we were able to bring at least a few testers into the lab. Many thanks to Compare TestLab for sponsoring with both hardware and someone assisting us with the testlab environment, namely Torbjörn Wiger. Big thanks to Adecco IT Konsult for letting me utilize their laptops in the final minutes of preparation. Big thanks to James Lyndsay for being part of this confused setup and being patient with acting in the unknown and unplanned.

We had selected three applications as part of this setup, namely Sikuli, CiviCRM and Red Notebook. They were chosen because they were fairly buggy, open source and would make a good subject for interesting testing.

The planned agenda for the testlab had been published here with a bit more detail on what I had in mind here. During the conference the agenda changed and its content became something different, still within the planned concepts.

When we arrived to Let’s Test we started to setup things up almost immediately. I got help from Steve Öberg with some installation and by Torbjörn Wiger to set the server up. Doing everything on your own is hard so the help was greatly appreciated. I did not feel that we were fully ready when we stopped on Sunday night, but are you ever fully ready?

Day 1

During the day I talked to more speakers and participants to be part of the events in the test lab. I was very dodgy in details, since I only had rough ideas on what would happen. At 20:00 the door open to the test lab. Quickly afterwards Rikard Edgren, Simon Morley and Christin Wiedemann arrived and agreed to take a team and an application each as their focus area. The first event was collaboration test planning using Corkboard.me to plan in.

Participants started to arrive and we assigned them to the teams. Each of the team leaders did things differently based on what the team members needed. I noticed that some created missions/charters to be tested later while some wrote down their sessions directly. The content of each corkboard.me was different for each team depending on application/system and the team members. At the end of the collaboration session we held a debriefing where each team talked about what they had learned and experienced. Rikard, Simon and Christin held the groups together in an excellent way.

Start of the next session “Group Test Experiment”.

I held a short presentation about the various dimensions of group testing. I selected not to direct them in this, but left them to choose themselves what they wanted to try out. After a while I interrupted the teams and unfolded a scene/scenario that was about to happen. It went something like this “I, the test lead, am going to the release meeting for our products in 15 minutes. I want you all to give me the three most important bugs, where each team focuses on their application”. After roughly 15 minutes, I asked each of the teams to give me a 30 second report. Being able to give the essence of what is important is good to practice and often. Each team delivered some important facts all with a different pitch and undertone. The time was roughly 23:00 and it was time for a last beer before bedtime, at least for me.

Day 2

Discussion about having coaching session with Ilari Henrik Aegerter and Anne-Marie Charrett. Talked to more participants to get them into the lab. I let Rikard test some of the concepts for the evening event in the lab, and got some good feedback which made me change the agenda somewhat. Then I started setting up the lab so that it was possible for more teams instead of the initial idea of just two big teams, which must have been a good decision consider we were at the most close to 60 people if I read the tweets right. I selected Sikuli as the application/system for the evening event as the only system under test. A few people started to arrive at 20:00, but it was not that many to start with… so I considered if I had made the right move. All of a sudden the tables started to fill and the test lab was almost full.

I did a short presentation about the focus for the evening event, at least what I thought at that time. The idea was to have coaching of the teams in the first hour and later on to try out some group testing experiments. But I had to change that since the expectations of the participants were so diverse. Instead I said we would do a little bit of both during the whole evening, but with the major mission of creating a compelling status report.

Even more people arrived, who we filled up in the existing teams and by now we had 8 teams of 4-7 members (if I remember correctly). The context of the test lab had changed a bit from what my initial thoughts, I knew that the plan never survives when reality hits it. We had not put that much focus in describing in detail the full content of the test lab and how to get started in a good way. We thought that it would be easy to fill in that information as we went along, but that never became true.

Ilari and Anne-Marie came up with an idea for how they could coach the teams, which we tried almost directly. I told the teams that “HR (Human Resources) had decided that each team need to appoint someone to be tested.”. This act caused some confusion. Just prior to that I had told the teams that the focus was on creating a status report. So we had conflicting missions. Ilari and Anne-Marie did an excellent job even though it was a tough situation. Some teams were very focused on the testing mission and did not feel they had time for coaching, while others took it in and used the coaching to affect how the testing was done in the team.

Ben Kelly had joined in the test lab and I explained the current context and I explained roughly what I wanted him to do. I general I gave very thin outliers in how they could act in the test lab scene. Instead letting each player expand what was possible. Ben talked to the teams and coached them about what our mission was and about the creating of the status report.

During all this me and James were interacting with the teams. James gave some teams missions while I sometimes instead tried to confuse them. All-in-all we tried to simulate a situation where confusion and the unknown is our arena, but where me and James were roughly sure of what the other was doing in order to act on it.

After roughly 30 minutes of coaching by Ilari and Anne-Marie, I addressed the teams in the role of a project manager stating that “We don’t have time for coaching! I want those status reports!” The confusion was somewhat diminished and a renewed focus was visible. We decided that we would round up and hold debrief in about 40 minutes time, which was at 22:10. Some teams worked in X-Mind, another in the Corkboard.me UI, another in Post-It notes and yet another in Notepad. Each team focused on different areas, but some had found the same obvious issues. Some had found many issues and some found less.

It was my impression that Sikuli was quite buggy and that it really was not able to solve the automation in a good way without many workarounds. Many in the teams did not trust the application.

Even if we tried to keep the teams confused, that the team members where new to each other and new to the applications as well as to the test lab environment, they managed to produce quite good results. The traditional role of a test lead/manager could be questioned based on this or at least investigated further.

A few times when I confronted the teams and asked for specific results or information, where time was a factor, I noticed that some of the seemingly experienced context-driven testers returned questions, poking for more information. This is most often a good trait, but when time and timing is important you need to consider which questions you really want to ask that you believe bring value. Is this a common mistake that context-driven testers do? Still, a lot of the traps and confusion that was thrown on the teams was deflected in an excellent way.

Ben moderated the debriefing by asking for clarification then asked me in my role as a project manager if I was satisfied with the result of each time. It was a difficult question. From a test lab facilitator point of view, I wanted the teams to have a good time but also learn new things. I believe that objective was met. As a project manager I would probably had wanted to see a more consistent reporting style even though the information was on different areas. I was a bit split in what I actually thought here.

By setting up a scene it was easier to let the teams and their team members manoever in a changing context. It was very hard to balance between giving detailed instructions and giving a general outline in which they could act. Some teams embraced the scene quickly, while others found it harder. I believe it is important to be able to roleplay like this as a tester, to be able to act in a scene painted/described by someone else. It lets you explore so much more, with different mindsets.

During the Keynote of Julian Harty, he refered to “the testlab” but at this conference it was “a testlab” namely The Let’s TestLab, which was focused on learning, collaboration and experimentation. I am not sure we were fully doing open source testing nor any scientific method, is that still ok? I think we should embrace that many other testers run testlabs the way they want it to be. Otherwise we limit ourselves in what we can learn.

On previous test labs, I believe, the emphasis has partly been on the systems and applications. On this test lab it has been on the testers themselves and their collaboration. They have been able to explore some dimensions of group testing, note-taking techniques, collaborative test planning/preparation and finally seen different styles of status reporting. As a tester we know things could be different, but also that there is no one true way of performing a task. Hopefully this year Let’s TestLab showed that.

A big thanks to those who wanted to be part of the scene and acted in it. Another thanks to the speakers who helped facilitate with me and James. Finally, thanks everyone who participated that made it great!

On 7-9 May the Let’s Test Conference will take place. During the day there will be lots of interesting tutorials, keynotes and sessions. During the evening the events will continue. One of these activities is the Testlab, that we call Let’s TestLab. Initially I misunderstood Henrik Emilsson when we started to organise the lab. I thought the evening event was the testlab. At the time I did not consider anything wrong with having 150 people or more in the testlab. As I saw the evening event program I considered how could I compete with such a fine setup of activities. Well, this is a conference with many context-driven people. We will have different interests, expectations and focus area. So instead of admiting defeat, I considered what elements that we could add to the testlab to bring a great crowd, but perhaps not all of them.

Here is the line up of events in the testlab:

• Collaborative test planning
• Group Test Experiment
• Test Competition
• Making a compelling status report

Collaborative test planning

We will create possible charters, missions for the coming testing in the lab so that those who wish can practise different testing techniques. Everyone is invited to share his or her idea on how to plan testing in through collaboration.

Part of the line up in this event is:

• Rikard Edgren
• Christin Wiedemann

Group Test Experiment

The context of the testlab will be single testers or groups of testers going in and out of the testlab in different time intervals. Each tester will be unique in the sense that they bring different level of experience, skills and approaches to testing. Based on this, we will start experimenting with group testing. I think we have limited ourselves too long with the setup of pair testing. Going back to the early recommendations and experiences from Brian Marick, James Bach, Cem Kaner, Jonathan Kohl and many others, the setup is nearly the same. With new tools and techniques appearing over the years, some assumptions could be questioned.

Let us assume that there are different aspects and combinations of group testing that serves different purposes, we can say that there are different dimensions that could be explored.

Here are a few dimensions that we will experimented with:

• How many testers (2 or more)
• What role you play as a tester
• User types, User Scenarios or storytelling
• Mission of group test
• Note taking techniques
• Partner combination
• Lateral thinking aspects
• Personality types
• Debriefing techniques
• Accountability
• Focus areas or Characteristic focus
• Test Environment
• Basic Configuration Matrix
• … and new ones that we find along the way

We will explore and experiment with different tools that we use when group testing and share experience on what works in what context. We also experiment with a few pre-defined group test setups such as:

• Cinema testing
• 15-min test run
• Coaching a group of testers
• Wolf pack concept
• Testing Dojo

Part of the line up in the test lab is:

• Ann-Marie Charrett
• Markus Gärtner and Meke Mertsch
• Johan Åtting

Test Competition

Can you really compete in testing? Can you compete between two or more teams?  Can you really estimate the value of one piece of information against another? Well, it depends.

I have been an Ultimate Frisbee player for 34 years. I’ve not played for some time, but once a frisbee fan, always a fan. I think the same goes for testing. There are many things that I feel is similar. Craftmanship/sportmanship and passion is major part. Here is one description I like:

Ultimate has traditionally relied upon a spirit of sportsmanship which places the responsibility for fair play on the player. Highly competitive play is encouraged, but never at the expense of the bond of mutual respect between players, adherence to the agreed upon rules of the game, or the basic joy of play. Protection of these vital elements serves to eliminate adverse conduct from the Ultimate field. Such actions as taunting of opposing players, dangerous aggression, intentional fouling, or other “win-at-all-costs” behavior are contrary to the spirit of the game and must be avoided by all players.

One important element in Ultimate Frisbee is the spirit of the game, which you can see more in detail here [1]. Passion and humility as a tester are important traits, the spirit of the game concept might help us here.

So, my idea for a tester competition will be based on some of these ideas. Two teams compete against each other in form of best bugs and session notes. The two teams go through the opposite teams material and conclude who they think should be the winner with a good reason why.

Make a compelling status report

As the last event in the testlab we want to investigate how we can make a compelling status report for our stakeholders. Having many different testers, session notes spread all over, half-finished bug reports and test ideas half-finished… can we create something that is still valuable to someone? I guess this is a common situation at any lab at any company, still we will dig deep into how to go about this.

Part of the line up in the test lab is:

•  Ben Kelly

References

[1] Ultimate Frisbee Rules –  http://www.cs.rochester.edu/u/ferguson/ultimate/ultimate-simple.html

Many of us has a title that is connected to what we do at work. Every now and then I come across titles that makes me wonder what it really means. This time it is one that has been around for some time now: Thought Lead, what does this mean? I would not be suprised if there is a good explanation of how this title first came into place, but I do not think this is well known and I have not researched it.

You can learn a lot by testing something very different from your normal job. I’d love to professionally test a suggested law, or a chainsaw. For now, I give you an opportunity to test a bread recipe, in English or Swedish.

FAVORITE SOURDOUGH BREAD

FAVORITBRÖDET

It should be possible to bake from it if you know, or can learn, how to breed a sourdough, and bake any bread. I’m interested in correctness, ease of use, inspiration and taste (the last one only for the bread, not the documentation) and other things you think might be worth knowing about.

If you only have a little time and interest, the challenge is to come up with the different test strategies you would use.

Test results in comments or in mail (About page) are more than welcome!