Embrace Meetup - Continuous Testing in a Nutshell
MicroFocus an Embrace Meetup . This event for the testing community was exciting and packed with informative presentations. I'd like to highlight the day's key moments for you!
Amir Khan opened the event together with Joel Flückiger and spoke about Business Due Diligence (BDD). Due to the digital transformation of various industries, delivering software quickly has become increasingly important. Time to market is the key phrase. Therefore, many companies are currently undergoing agile transformation and trying to overcome the hurdles of ever-shortening release cycles. One hurdle is the technology or methodology for efficiently defining high-quality requirements, making them readable for every member of the team (in the project), and ensuring quality assurance through testing. Amir shared some insights on this topic.
Despite the agile transformation, risk-based testing is a hot topic. Despite the paradigm shift, implementing quality assurance remains essential. In his presentation, Reto Armuzzi demonstrated how risk-based testing works and shared his experiences with the audience. The role-playing exercise, which illustrated how risk coverage and risk weighting of test cases might play out in everyday practice between project managers/product owners and test managers, was particularly engaging. Further exciting presentations followed, covering topics such as test automation with AI, value stream management, and load test design for an IDE.
Of course, as with every Embrace event, there was a Community Track (Team Game). These games demonstrate, for example, how simple solutions can be forgotten in the daily grind. Sometimes, in stressful situations, it helps to sit back and breathe – perhaps take a short break – to clear your head.
Photos from the Embrace Meetup can be accessed via the following link: https://embrace-devops.com/2019/01/29/embrace-meeting-28-01-2019/
Continuous Testing
I personally had the opportunity to present on the topic of Continuous Testing. I must admit that when choosing the topic, I felt I was already familiar with it, but while creating the first PowerPoint slides, I quickly realized that my knowledge of Continuous Testing was very patchy. Therefore, my presentation preparation evolved into an almost scientific research process. I soon discovered that different companies understand Continuous Testing differently. So, I tried to create a comparison of the selected companies – and what Google suggested. The result looked like this:
This graphic is called a word cloud in German, and there are many online toolsthat make this possible.
The conclusion of the merger:
Each of the companies studied interprets Continuous Testing from a different perspective.
Raffaele Russo, Infometis
This analysis did not give me a consistent picture that points in the same direction.
So I continued my search to find out exactly what Continuous Testing means and what it is. I came across many interesting articles, which I compared and consolidated for my presentation at the Embrace Meetup, and thus arrived at a clear understanding of Continuous Testing.
During my presentation, I asked the audience what they understood by Continuous Testing. The following outline emerged from this discussion:
The answers were also quite varied, which reassured me somewhat. There are more people out there who don't have a clear understanding of exactly what continuous testing is.
The search for a suitable definition
The English definition I found on Wikipedia really stuck with me. Somehow, this statement didn't convince me. The more I researched the topic, the more skeptical I became of the definition. There were statements like, "Continuous Testing is synonymous with Continuous Delivery ." This isn't the case . Continuous Testing can be a part of Continuous Delivery, but it's not equivalent. Continuous Delivery is primarily about ensuring that the developed code is deployable at any time. And how can this be achieved? By using a combination of automated and manual tests to ensure quality in the Continuous Delivery pipeline. This involves checking both functional and non-functional requirements using different types of tests. That wasn't my main topic, but it's important to understand the difference.
Finally, I was able to unlock the button and answer the question of what Continuous Testing means and what it is. Dan Ashby's graphic illustrates Continuous Testing in a single image.
What exactly is Continuous Testing?
Continuous Testing is a type of "software testing" that involves the testing process in all phases of the DevOps Infinity Cycle.
Test often, test early, test everywhere, test in the right place, and test effectively.
It is a strategy that ensures the quality of the software at every stage and at every time.
Raffaele Russo, Infometis
Or, in short, the goal of continuous testing is to test early and often.
I broadened the scope and asked how one can test efficiently. In other words, how can I define test cases in increasingly shorter cycles without suffering a loss of quality?
Behavior Driven Development
One possibility would be the use of Behavior-Driven Development (BDD). This methodology originates from the two techniques Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD).
For BDD to work, some rules must be followed, such as:
- Use the five “Why’s”
- Describe a single notation that is understandable to every team member
- Think from the outside in to generate business value and eliminate waste
By using the specific spelling of BDD, i.e., "Given-When-Then", you not only kill two birds with one stone, but you also secure three important factors:
- Ensuring functional documentation
- Ensuring technical documentation
- The described requirement is also understandable for team members without technical know-how
To bring things full circle, I looked for a role that aligns with current trends. This role needed to have a clear overview of the whole picture and possess the necessary skills. In the agile world, I've noticed that autonomy within the various teams works quite well. However, what's often lacking is a holistic perspective. Things get tricky when multiple teams work together towards the same goal (e.g., Scrum within Scrum).
Software development engineer in testing
I came across the role of "Software Development Engineer in Test" (SDET). This role is appearing for the first time at Microsoft. It's described as a developer role with advanced skills. SDETs are expected to possess collaborative abilities, meaning they can bring together team members with different roles. This includes testers with in-depth domain knowledge, developers who understand the code, and business analysts or business owners who understand the rationale behind implementing a requirement. By bringing these team members closer together, a shared understanding of the common goal is developed. Another key skill is staying up-to-date with the latest tools. In today's rapidly evolving world, testing tools need to be current. Equally important is the ability to automate the right tests, rather than blindly automating everything. Test automation skills are also crucial for SDETs. This skill should help eliminate waste. Repetitive tasks, such as test data creation or log parsing, can be automated. Setting up an entire environment could also be efficiently ensured through automation. There are other capabilities that an SDET should offer.
I'm not sure if this is a developer role with advanced capabilities. Personally, as of today, I see the SDET role more closely resembling that of today's tester or test manager. Or to put it another way: Could this be Test Manager 2.0?
At infometis, we simply call this role Automation Genius.
I'm curious to hear your perspective in the comments section below.
I'm already looking forward to the next event!
