LambdaTest TeamThe Day 2 of the Testμ Conference started with a special keynote from Maaret Pyhäjärvi, Principal Test Engineer, Vaisala, with our host, Manoj Kumar, VP Developer Relations, LambdaTest.
Maaret has been in the testing industry for more than 25+ years and keeps doing a fantastic job of shaping different proposals. She is a markable educator and an up strong advocate for diversity. She has appeared at 500+ conferences.
“Speaking is not my job; it’s my hobby” — Maaret Pyhajarvi
If you missed this session, here is the video link.
Maaret speaks a lot in conferences while staying at home. It was something of extra credit on top of her job. Being a testing practitioner by identity, she asserts that she got the opportunity to hear from many individuals beginning their careers as testers at various companies. She also claims that she cannot think of a better profession for herself than testing. Maaret picks up this conference opportunity to break the difficulties in explaining the testing. She always uses exciting words to deliver the work she does and the discoveries she makes.
Let’s hear it from Maaret on what and how Foo is done in projects and real practitioner life.
Foo is the first half of the crazy words that everyone ends up separating. Foo does not mean anything. They are placeholders for things you are unaware of and what to name them. In the programming language, in particular, we end up coding things ‘Foo’ when you want to delay the moment and make the choice of working.
According to Maaret, in the game of “Foo,” it is difficult to figure out what was missed by others in real-world tasks or assignments. You would have zero knowledge of what others might have missed. Other people might know how to find a solution if you have a specification. But that is enough for you to see what is missing.
Maaret has the condemned belief that there are two teams, the Developer and the Tester team. Even if both teams work closely, share quality time, and almost work on a similar task, there is a slight difference in the work they focus on. The Tester’s job is to find the slight invisibility.
“In today’s talk, I want to replace the developers with computers’, she says. Because she doesn’t want an actual person to demo the Foo. Therefore, the application she picked up for fooing is something made by GitHub co-pilot. It’s a computer-assisted software authorship program that is supposed to write code for you. It is AI in writing code.
She is performing the Foo for a developer, who is a computer. We are in charge of ensuring that the developer we work with is assisted in anything they do. But to build the right thing, we share equal responsibility with that developer. And we’ll go over this in roughly five layers of what we can contribute when we’re fooing, she added.
The above slide is the screenshot of the co-pilot, which is the starting point. The basic idea is to auto-complete the sentence when you start typing something. If you have the program intent, it knows how to translate to code. In this case, she is creating something that takes in numbers and makes roman numerals, which is one kind of common problem in the general space. So she is moving into the live idea rather than having things assumed.
The primary thing was ensuring she had the right tools for today’s activity. She just demonstrates the concept of being able to run a single test that has already been written. She executes two lines with:
Line 1: Name of the test.
Line 2: Pass.
She runs the code with Python. This is an important program that does roman
numerals conversion. It takes in an integer value and converts it to roman numerals. With GitHub co-pilot, one can press CTRL and ENTER to give synthesized solutions. If you feel that the last suggestion auto generates is correct, you have the full flexibility to choose any of the suggestions given.
For an application, there is always a relevant Wikipedia page. The product owner, a subject matter expert in aviation, is unaware of all the Internet is aware. So, Google searches will always be helpful for testing. It is not necessary to research the entire page. There would be a missing or unknown point that you need to concentrate on.
Maaret demonstrated the application of roman numerals with Excel and tried some mixes & matches with the Wikipedia page. She needed to filter it for people who put the text in places they don’t belong. It may be any type of number: two small numbers, two big numbers, or negative numbers, which can be handled together at the same level.
Maaret summarizes that there are many ways to say in English for a co-pilot. The below snippet shows some of the examples that the group has generated. To know more about the code implementation, watch the entire session by Maaret.
With the demonstration of performing the Foo, some answers and takeaways exist. They are:
Big numbers (values over 4k do not work) without extending to line-on-top notation).
Zeros, fractions, and large numbers are later in scope.
Decimal values truncated vs. rounded numbers.
Implemented with the miscalculation of boundary values.
Infinite loops that sometimes get revealed.
Implementing classics when expected to be simplified.
There are many other things you get to learn while you are testing. Testing on a lower level or Fooing on a lower level is faster, provided it needs a different knowledge. Below are the insights from eight rounds of pair/ensemble testing.
Unit exploratory testing is FAST.
Explored concepts on parameterized tests, pytest, and approval tests.
Selecting vs. Oversampling for finding boundaries.
Choosing later what is left behind (if dropping tests is worth the investment).
Both valid and invalid values, balance, and role-based heuristics.
The important aspect, if you are doing the Foo already on a unit level, you have a high potential of finding the problems that are now production failures. As per the research, while you are Fooing and building, it might be TDD or Unit/Exploratory testing that you’re thinking of. You might want to rename the Foo, but again you figure out things and get different kinds of answers. This can be done on any level, including end-to-end or API level. Maaret performed this today with the unit level. It can also be performed against the developer’s, customer’s, and past intent, which is called exploratory testing.
“Everything that does not need to be automated gets done while automating”
This is because there is so much thinking while automating, including the decision of not ever leaving something behind. As we do not want to perform too many things to implement. But it would require us to organize our work differently, maybe a lot more, rather than leave it to the testers to deal with it in a traditional sense.
Maaret again says that Foo is a substance that connects the stretching of everything into the right level of results. She personally calls what we Foo today contemporary exploratory testing, both manual & automated testing, where you get to write code for one percent of your work time.
Maaret has given a whole new definition for the word ‘Foo’. She said again, “Testing is finding some of what others have missed and never being bored!”.
It was indeed an insightful session with Maaret. The session ended with a few questions asked by the attendees to Maaret. Here is the Q&A:
What qualities do you expect or look for from a candidate when you interview for testing?
Maaret: I usually look for someone who is either strong in programming, and I will then teach them testing, or someone strong in testing and will teach them programming. I generally believe it might be easier to teach programming than testing. Also, I look for the learning potential of a candidate.
When did you feel confident to step into the test lead role?
Maaret: I don’t know if I ever felt confident enough. It’s weird about the whole confidence. At some point, you just start fitting and take the lead. I believe that in agile teams, everyone is a leader, and we need to start with that earlier.
Do you measure how your current testing approach is working? Do you adjust if it’s not?
Maaret: I don’t necessarily measure testing. I measure the whole team and figure out how much we’re leaking things the customers see. I refuse to give numbers like how many bugs I found. I never will summarize that to the managers. But I can tell that the ready thing that was already before me needed nine fixes after everyone else was done. So I know my results gap, and I can always tell you that in numbers. But obviously, I will still miss three more, maybe five more, maybe 500 more. I am as careful as the rest of the team in listening to what the customer has to say and what we can learn from each one of the misses.
How will you estimate the time? If you go with the described approach, it will take enormous time to complete the story.
Maaret: It actually doesn’t. Finding seven problems took me two hours. Maybe you should learn to do exploratory testing. Time awareness and cost awareness are one big part of what I call contemporary exploratory testing. You don’t need the test cases written down. You may have existing automation that you can add to share with the team. Many different ways don’t have to be big, but it would be a whole different conversation, and I invite you to pin me, and we should have that conversation.
Can you share your secret sauce in delivering so many talks, if possible?
Maaret: I’m talking about my real-life experiences here. It just happens on the side. So don’t over plan.
How do you think AI will impact the testing industry?
Maaret: We’ll be testing more AI-created software like GitHub co-pilot-created PCs in the future. I also believe we’ll see excellent tools we haven’t seen before, even exploring and remembering what we have already thought about and forgotten. I have a positive outlook on getting new things that help us, but they will never replace us.
