00:00:12.789
Welcome back! Did you enjoy your activities? Thank you, Ramon. Much appreciated! I still remember the first time I saw Anastasia giving a talk. We were at ThoughtWorks in Munich, and she was discussing Scrum and agile testing. I was awestruck. She has a great stage presence, and the concepts she explained were, in a way, obvious, like all good things appear to be, but they are not. Especially now, I feel that sometimes they get forgotten.
00:00:23.330
At that time, she was working at XING, and I'm now very happy to say that she is my colleague at Freeletics. She is helping us improve our quality culture and guiding the teams in understanding the concept of whole-team testing. She is doing a fantastic job. Her talk is titled "Improving Development Quality and Speed with Agile Testing." She will share her perspective and techniques as an agile tester to help us discover risks early in the development cycle in order to release high-quality products, engaging the whole team in the testing process.
00:01:03.710
Here it is, Anastasia Chicu. Thank you! It's really loud in here, right? You can hear me? Good. On July 23rd, 1983, an Air Canada flight between Montreal and Edmonton had to stop midway because they ran out of fuel. This is a highly regulated industry, and these guys knew exactly how much fuel they needed. However, the amount of fuel loaded was incorrectly indicated in the documentation: it was noted in kilograms but loaded in pounds, leading to less than half the needed fuel for the flight.
00:01:45.590
Such miscommunications happen so often. I'm sure you've experienced at least one today. We, as humans, tend to miscommunicate, misjudge, and misplan. In fact, there's a term for this called the planning fallacy, where we tend to be overly optimistic about the future and overestimate our current experience. This often leads us to underestimate the problems that will arise. Does anyone resonate with this when it comes to Sprint planning? Well, these misestimations contribute to 68% of software projects failing.
00:03:02.680
Moreover, according to Accelerate, in low-performing teams, 31% of the time is spent on rework. If you add the time spent in meetings on top of that, you will find that you spend half of your time on tasks that you thought were completed but are still not resolved. So, what can we do to ensure we lower the odds of your project failing, or in other words, how can we make your project suck a little less? This is the aim of today's talk.
00:04:01.990
We are going to discuss improving development quality and speed. As Monica mentioned, there are numerous reasons why projects are unsuccessful. One thing that successful projects have in common is effective agile testing, or effective testing in general. Before I can discuss the tools and experiences I've gathered to share with you, we should define what quality assurance (QA) is.
00:04:36.370
Trish, you gave a beautiful talk about transparency and the importance of transparency in the whole team approach to testing. She asked testers and developers what they were doing daily, and here are the responses from testers: they mentioned gathering information, checking expectations versus reality, and diminishing risks. This is something I can completely identify with, but you might relate better to the responses from developers, which focused on working towards the team goal, looking for edge cases, or breaking the application.
00:05:12.160
As you can see, those two perspectives do not quite match. The developers' emphasis on looking for edge cases or breaking the application does not seem aligned with the testers' focus on risk reduction. This confusion led me to seek advice from a friend, Delbert, about my job as a QA engineer. Delbert defined my role as overhead. If you were to ask me what quality assurance means, I would define it by the three roles that a QA professional wears throughout the software development lifecycle.
00:06:09.380
First, we are quality analysts, then quality assurance professionals, and lastly, quality ambassadors. Let's dive into what the quality analyst does. This role involves determining whether we are building the right product in the context of a user story. It is crucial to understand who we are building the product for before diving into the problem-solving process. This is where data becomes critical.
00:07:25.340
I find several sources of data essential for this purpose. The first is business intelligence (BI). When I began working at Freeletics, I assumed that half of our users were female looking to lose weight and generated test data accordingly. I logged in as female users and navigated through training flows. To my surprise, I found that over 70% of our users were males trying to gain muscle. This insight significantly changed how I gathered data in the future.
00:09:15.200
Secondly, I have asked myself if anyone here has experienced a situation where a tester blocked a release because the layout looked awful in Russian. I know at least one developer who has had that experience—myself. While I believe Russian, the most beautiful language in the world, deserves to look awesome on all screens and layouts, it is not always the priority at Freeletics.
00:09:49.800
For instance, if we analyze the data, our top five languages do not include Russian. Understanding what languages our users actually use was invaluable when testing layouts, particularly on smaller screens. Thirdly, BI tells us the types of devices and browsers our users are using. I still vividly remember when we had to support IE9 for an extended period because many of our users lacked administrative rights on their workstations and could not install a modern browser.
00:11:01.990
Despite that experience being quite frustrating, especially with Flexbox issues, it empowered us to make better decisions regarding testing and cross-browser compatibility. The second source of important information is customer engagement or customer support. At Freeletics, receiving feedback from users who write emotional emails about how Freeletics has changed their lives provides positive motivation to continue our work.
00:11:58.440
Of course, if you’re selling fridges, you might not receive such heartfelt messages, but you can still benefit from being aware of bugs reported by customers. Moreover, user feedback often reveals misunderstood features. For instance, when we started consulting our customer support team at XING about user expectations when pressing a ‘plus’ button, many thought it meant adding something to another entity rather than creating a new entity altogether.
00:13:29.630
This information turned out to be very useful for our designers. Additionally, the customer engagement team is invaluable during testing sessions due to their extensive product knowledge. Regarding bugs, there are two key points to address. First, they often accumulate in technical debt areas. When working with a less technical product owner, showcasing the number of bugs that can be resolved by refactoring offers a more compelling argument than what we usually discuss with developers.
00:14:05.160
Secondly, existing bugs highlight areas that the business may not prioritize, indicating lower risk areas. Understanding this allows for better testing decisions and prioritization of test cases. Now, with all this data in mind, we can revisit the initial question: Are we solving a problem? Understanding whom we are solving for enables us to evaluate whether the problem is clear and whether the user story and acceptance criteria are defined.
00:15:09.000
From my experience, it has been helpful to have an idea of the scenarios that need testing—not in extensive detail, but at least broad enough to clarify my role in the team. This way, others can grasp what I am working on, and it permits the testing effort to be estimated alongside the user story size.
00:15:49.649
Developers often volunteer to help with complex flows, allowing us to draft unit tests or lower-level tests before diving into exploratory testing. We should also consider how a user story will add value. By understanding business objectives, we can provide simpler solutions that offer user value while simplifying our implementation processes.
00:17:09.028
To visualize these concepts better, having examples, mind maps, or functional tests can be beneficial. Let me illustrate with an example from Freeletics. For a long time, we employed a training system that had endless workouts, where every week was a new challenge, and progress was not linear. Our product thought that introducing training journeys, with set periods focusing on specific goals like gaining muscle or definition, would provide a more structured experience for users.
00:18:19.450
We aimed to validate this assumption through an A/B test, where we discovered that changes to the payment flow could affect both our existing subscriber base and potential new users. Therefore, the risk during the A/B test was significant. We took a step back and recalibrated, aiming to bring value without overexposing ourselves to risk by focusing on smaller segments of users without subscriptions.
00:19:05.980
Next is the quality assured role, which drives the testing effort. While I'm not going to focus on the testing pyramid, I will discuss testing goals. I often divide testing into supportive parts, which help the team move faster and provide feedback vs. critical tests, which aim to expose more bugs. In many teams, I have observed a tendency to focus solely on the latter, overlooking the importance of tests that support team productivity.
00:20:17.360
As a tester, I often found myself concentrating on the happy path, leading to neglect of more intrinsic tests and complex scenarios where edge cases might exist. Exploratory testing is where we uncover most bugs, thus having a team approach is highly advantageous. This way, developers have a broader range of insights beyond my own perspective.
00:21:09.900
One effective strategy is to create personas, such as ‘Jack the Training Junkie,’ who trains six times a week, or an older individual seeking training that minimizes joint pressure. These personas arise from actual user data and enable our team to empathize with diverse perspectives and test our application accordingly.
00:21:59.520
Pushing boundaries, we also consider legacy bugs from past experiences, which help shape our test sessions. Incorporating notifications during testing ensures that the team understands not only the particular persona but also the complexity surrounding that user experience. Lastly, the role of the quality ambassador is vital; this involves rallying the team around a common goal to enhance quality.
00:22:37.680
By asking developers what significant actions could be taken within a set timeframe to drastically improve our product's quality, we can coalesce around a shared goal that drives our development efforts. In our case, our goal is to increase confidence in releases. By integrating this mindset into our daily development, aided by relevant KPIs as information radiators, we can monitor our progress and adjust as necessary.
00:23:59.330
Having gone through a post-mortem process, I initially approached it with trepidation. My aim was to focus on solutions rather than assigning blame for mistakes made in the system. By framing our discussions around what went well, what went wrong, and how to avoid issues in the future, we kept our conversation constructive, ultimately improving our processes.
00:24:43.150
What does all this mean for you? I’d like to share a couple of ideas and techniques that I hope you can implement in your environment to improve both speed and quality. First, gather data and ensure you are testing thoroughly.
00:25:09.210
Utilize examples and persona insights while writing unit tests, organize post-mortems following failures, and facilitate exploratory sessions with your team. Implementing story mapping and determining test scenarios at the user story definition stage can significantly reduce long-term risks.
00:25:32.550
To conclude, quality is never an accident; it is always the result of intelligent effort. Thank you!
00:25:57.470
Does anyone have questions? I'll be glad to take them.
00:26:03.670
I have a question: how do you convey to developers that quality is also their responsibility? It's something they should actively participate in and not outsource to QA.
00:26:14.180
What I noticed is that if you provide developers with a clear quality goal, it helps them visualize the larger picture, focusing not just on immediate bugs but on long-term improvements. Developers tend to care about the code they write, and cultivating pride in their work and project fosters greater accountability and involvement in quality processes.
00:26:55.670
Additionally, early involvement in discussions about acceptance criteria clarifies expectations, and as time progresses, developers begin to appreciate and ask these questions themselves. Providing examples of quality goals leads to a more cohesive and proactive team environment. Is there anything else?
00:27:21.230
Good! Awesome! You can all still enjoy a beer afterwards. Thank you!