Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. Today, Peter gets on his first real project. In case you want to catch up with the previous parts, I published these ones earlier:

The Deliberate Tester

Chapter 8: The First Project

Peter enters Eric’s office right after the Lunch & Learn.
“Peter, I got another challenge for you.”
“Oh, a challenge like the login functionality?”
“No, we got a new customer, and I would like you to lead testing on the project.”
“What?”
“Listen, Peter, you have mastered your first challenge quite well, you amazed most of the others in the company. We would like to show our appreciation for your progress with an assignment to a new project on your own. I think you’re capable of doing this.”
“Oh, thank you, but what if I…”
“Of course, you will get full support from your colleagues on this.”
“When does it start? What should I do?”
“Let me give you some answers on this. The customer is Important Corp. They asked us to develop a product for them. Mike is managing this larger project. He will give you details on who to talk to in order to get more information. The project is currently getting set up, so I would ask you to finish what you began, and start working on it by the beginning of next week.”
“Great, I will get in touch with Mike then.”

As Peter enters the meeting room for the kick‑off meeting, he feels a bit uncertain. Mike and one or two representatives from Important Corp. are waiting for him to join them.
“Hi, Peter. Nice to have you on this project. Let me introduce you to Stella and Caesar. Stella is the subject‑matter expert for this project, while Caesar will help us with the infrastructure at the customer site. Stella, Caesar, this is Peter, the test responsible from our side.”
“Hi, Peter, nice to meet you.”
“Hi, Peter.”
“Hi, Stella and Caesar. There are actually some questions, that I would like to get some answers to.”
“Exactly that is why we got together here, Peter. “
“Yes, also we would like to see your test strategy for the project, …”
“Sure, Caesar, but please let’s stick to the agenda for this meeting. This point will be discussed later. Now, after we introduced ourselves, let’s try to reach a shared understanding of the project.”
Stella and Caesar explain what the project will be about. Important Corp. has an old legacy system that they stopped to trust as any change to the system seems to break some unrelated part of it. In addition, the old system is too unstable, and adaptations to the system get too often in the way of the fast‑paced business model of Important Corp. After some brief explanations about the vision of the new application, the discussion reaches the point where the test strategy shall be discussed.
“Now, as we continue to share our vision about the project, Peter, do you have an idea how we could make sure to deliver the right product?”
“Oh, I got lots of ideas, but I think we should strive for an emergent solution. Your business seems to be fast‑paced, and we surely need to keep up with the changes that your business will force on the product. How was the last product developed?”
“Oh, the other company that developed it for us told us they were using defined processes. Their company was certified with ISO and CMMi, and this would surely help in this regard. Then they asked us to describe the system that they would deliver in 6 months. Of course, things changed in the meantime, and over time we had to wait longer and longer for changes in the system.
“Now, this doesn’t sound too well. Now, here is a thing, I would like to try out ‑ with your buy‑in of course. I recently read about something called “Specification Workshops” and how teams reach a common understanding of the next few items on their list to be developed.”
“Oh, we attended one of those, too. It started right at the beginning of the project when we needed to discuss what the software should be doing. It still didn’t help, though.”
“Right, but we will limit the scope of our discussion to one or two months of up‑coming features. Of course depending on your time and availability.”
“So often? But we can’t set time aside for a whole week each month.”
“Oh, I see a misunderstanding here. Our Specification Workshops will be held more frequently, but more timely to the implementation of the new features. In addition, these will last only a few hours.”
“Ah, I think I got it now, and I think we could get this scheduled.”
“Now, during the meetings, we will take a short list of upcoming features. We will discuss what this feature is about, and try to note down examples of the functionality. Then, while implementing the feature, we will use the examples from the workshops as a stepping stone, and automate them as acceptance tests, which will be running continuously throughout the life of the product.”
“This sounds neat. But we are not so technical. How can we make sure that the right examples are automated? You know, I read an automated test once, but I couldn’t understand them.”
“Of course, while automating the tests, we will take care to automate the examples as literally as possible. Since we sit together during the identification of reasonable examples, we will be trying to express them in a reasonable way, so that automation later will be easier, but you will still be able to read them.”
“Hmmm, but can we trust what you automated? Who will test the tests?”
“The automated examples will just serve as a stepping stone. We will add more tests to these examples, and therefore further refine the specification we initially agree upon. Additionally, we will test our automation code as well. And from time to time we may invite you to a stakeholder demonstration, and evaluation of the functionality.”
“Oh, a demo? I know these, they’re just faked.”
“Not really, as we will operate the real system, and you may also get some hands on the application if you’d like to.”
“Oh, we may play with the application as well? That’s interesting. Your ideas sound nice, and I think we could work like this. Let’s try this out.”
“Yes, that sounds like a workable strategy. Let’s settle this as today’s result, and schedule a follow‑up to get the first set of scope and discuss it in one of these ‘Specification Workshops’.”
“So, let’s check our schedules, and find a date…”

The project takes off very well. After one or two iterations Peter’s team gets in some trouble but is able to work out of it. The team delivers their first version right on the scheduled date and receives another order from Important Corp.