When it comes to ATDD, people, teams, and companies usually put the wrong emphasize on the elements. This blog entry is going to explore the relevant areas for successful ATDD, and how to overcome some of the misconceptions about it.
When it comes to functional test automation, most legacy application have to deal with the problem, that retro-fitting automated tests to an application that was not built with it from scratch, can be painful. In the long-run, teams may face one problem. The automated tests constrain further development on the production software. The tests are highly coupled to the software that they test. Let’s see how we can solve these problems with a clear architecture in the beginning of our automation journey.
During the last week, there was a Behavior Driven Development (BDD) related question on one of my mailing lists. For me it expressed a large misconception about BDD that is so widespread, and so common. Let’s see what it is, and what to do about it.
Software testing has come a long way. We have more than thirty years of experience with software testing. The world turned around in that time period. Depending on who you listen to, there are various opinions on what to learn about testing. Thinking about testing and learning, I am aware that there are different learning methodologies, and preferences. Nonetheless, I think the topic of testing can be split up on three general skill-levels that have brought me value: beginners, practitioners, and journeymen. Let’s see what’s in for you on each of these.
Back in June 2013, I met Olaf Lewitz in Vienna at the XP conference. In a coffee break discussion, he was speaking very passionately about something called Temenos. That’s Greek, and translates roughly to “your room”. I grasped the concept, and immediately had a couple of clients in mind where I thought this would help a big deal for the team members to understand each other on a deeper level – mostly because personal stakes and misunderstandings over a long period of time had piled up. I never thought about applying it to the situation with my colleagues at it-agile. Some of my colleagues influenced enough from us to try this out. We did a company-wide Temenos so to speak as kick-off for 2014 just last week facilitated by Olaf Lewitz and Christine Neidhardt. Beforehand I was suspicious about the two days. Here is what I learned.
The role of the product owner in Scrum is probably the one that is cursed with the most misunderstandings. Personally, I curse the updates of the Scrum guide – the official guide to Scrum – and people’s lack of following-up with these changes for the variety of opinions about different pieces of Scrum around. This blog entry will deal with the role of the product owner.
There is a lot of fuzz currently going on the Agile communities around the topic of “scaling”. Why does scaling matter? Let me try to express my view on the matter.
Back when I studied, I worked part time in a local store. I was responsible for juice, soda, beer, wine, and other bottles of alcoholic drinks. I was responsible to order them, and to manage and refill remains over the week. Being a small shop, I also needed to be a jack of all traits. At times I had to have an eye on refilling vegetables, and fruits. At other times, I needed to refill milk, or answer inquiries from our cashiers. That said, there are some lessons I learned in that shop that helped me find my way once I joined my first job. Here are some nuggets from that time.
Over the course of the last year, I decided to dive deeper towards the source of traditional testing wisdom. That said, I read a book on the foundation knowledge behind one of the testing methodology (I won’t name anyone to protect the guilty). In the end, I was both surprised, and shocked. Here are some of the things that stood out to me. I will not name the book or the authors, as I was able to receive them as sort of a gift. If you want to know more details, feel free to contact me privately, and I might share more on the book.
Over the course of the past year, I had the opportunity to work with some great trainers. I learned a lot from them, and by delivering co-trainings together. Today, I decided it was time to reflect on some of that stuff. Blog entries work great for me to do so. Here is a first blog entry in a series of entries to come.
Stick long enough into testing, and you will face an argument pro or contra traditional test cases. Most of us have been there. Most of us know what worked for them in the past. Most of us won’t agree with each other. During a particular co-training, I became aware and reminded again about process control, and realized why I think exploratory testing is better suited in most software development shops around. Let’s see what process control consists of, and check in which of the models testing falls, and where exploratory testing can help you.