Let's Do a Thing and Call it Foo

•

0 gostou•50 visualizações

The document discusses computer programming concepts like foobar, foo, and bar which are used as placeholder names. It then discusses using computer-assisted software authorship (CASA) to generate code and tests. Finally, it discusses lessons learned from pair and ensemble testing including how fast exploratory testing can be, useful testing techniques like parametrized and approval tests, and challenges of domain testing.

Software

@maaretp
Let’s Do a Thing and
Call it Foo
by Maaret Pyhäjärvi

@maaretp
The terms foobar (/ˈfuːbɑːr/), foo, bar, baz, and others are
used as metasyntactic variables and placeholder
names in computer programming or computer-related
documentation.[1] They have been used to name entities
such as variables, functions, and commands whose exact
identity is unimportant and serve only to
demonstrate a concept.
https://en.wikipedia.org/wiki/Foobar

@maaretp
Stakeholders happy,
even delighted
–Quality Information
Good Team’s Output
–Quality Information
Less than Good
Team’s Output
–Quality Information
Results Gap
Surprise!
Results Gap
on aTeam that thinks
Testers ==Testing
Pick up the pizza boxes…
”Find (some of) What Others May Have Missed”

@maaretp
For pair / ensemble testing this with me <3
Thank You
Alex, Elisabeth, Bertold,Thomas,
Mirja, Karen, Moroni, Isidro,
Benjamin

@maaretp
Computer Assisted
Software Authorship
https://github.com/features/copilot/

@maaretp
WE are
accountable
1. Intent / Implementation
2. Domain for the Layman
3. Domain for the Expert
4. Reference Implementation
5. People Filtering

@maaretp
CASA (Computer
Assisted Software
Authorship) in action

@maaretp
https://en.wikipedia.org/wiki/Roman_numerals

@maaretp
Say it in English - Options
#We want to translate numbers to
roman numerals.
#convert numbers to roman numbers
# Convert numbers to roman numerals
# convert decimals to roman numerals
# Convert numbers to roman numberals
# translating numbers to roman numerals
# convert decimal numbers to roman
numerals
#Check that roman is an integer
# Raise an exception if not a numeric
value
# Raise an exception if not a valid
number
# catchTypeError if num is not an integer
# catchValueError if num is not within
range

$@maaretp Answer key to some of the bugs • Values over 4k don’t work (without extending to line-on-top notation) – Zeros, fractions, large numbers later in scope • Decimal values truncated vs. rounded • *some of the implementations* – Boundary values miscalculated – Infinite loop • Implementing Classic when expecting Simplified$

@maaretp
Insights from 8 rounds of pair/ensemble testing
• Unit Exploratory Testing is FAST
• Concepts: Parametrized tests, pytest.raises, approvaltests
• 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
• Fooling a domain expert on conflicting domain rules
surprising how versatile a simple appearing domain is

@maaretp
A majority of the
production failures (77%)
can be reproduced by a
unit test.
https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf
Through https://www.slideshare.net/Kevlin/the-error-of-our-ways

@maaretp
Everything that does not
need to be automated gets
done while automating.

@maaretp
Foo
Contemporary
Exploratory Testing

@maaretp
Find (some of) what
others may have missed!
Testing
… and never be bored.

@maaretp
2020 2016
MIATPP
Most Influential Agile Testing
Professional Person
#PayToSpeak #TechVoices
#EnsembleTesting #EnsembleProgramming #StrongStylePairing
#ExploratoryTesting #TestAutomation
#ModernAgile
#AwesomeTesters
Maaret Pyhäjärvi (from Finland)
Email: maaret@iki.fi
Twitter: @maaretp
Web: maaretp.com
Blog: visible-quality.blogspot.fi
(please connect with me through
Twitter or LinkedIn)
2019, 2020, 2021
https://exploratorytestingacademy.com
Ohjelmistotestaus ry
https://techvoices.org

Recomendados

Exploratory Testing on Computer interfaces

Maaret Pyhäjärvi

Tampere Testing Days: Exploratory Testing an API

Maaret Pyhäjärvi

AxiomSummit 2022: A Practitioner's Guide to Contemporary Exploratory Testing

Maaret Pyhäjärvi

AgileTD Scandia: Mob Testing

Maaret Pyhäjärvi

TestWorksConf: Exploratory Testing an API in Mob

Maaret Pyhäjärvi

SauceCon: It's More Complicated than THAT

Maaret Pyhäjärvi

Mob testing

Maaret Pyhäjärvi

AgileTD: Learning through osmosis

Maaret Pyhäjärvi

Agile2016: Exploratory Testing an API

Maaret Pyhäjärvi

This document discusses exploratory testing of APIs. It provides tips for exploring an API including focusing on calls and operations, inputs and outputs, exceptions, the target system versus dependencies, specific user scenarios, understanding the purpose and lifecycle of the API, collaborating with others, and creating documentation during the exploration. Patterns may emerge with repetition, and disposable automation can be used. The goal of exploratory testing is to discover risks and build understanding of the system.

How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018

Mike Harris

I never wrote it; everybody else did! How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die? How many times have you heard someone say that what really needs to happen is a complete rewrite? I have heard this many times, and, have uttered that fatal sentence myself. But shouldn’t we love our legacy code? Doesn’t it represent our investment and the hard work of ourselves and our predecessors? Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy? We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code. https://www.youtube.com/watch?v=qRP45l5UugE

Selenium Conf: Patterns to Whole Team Test Automation Transformation

Maaret Pyhäjärvi

The document discusses test automation transformation and lessons learned from a team's experience improving their test automation process. Some key points: - The team was able to improve test automation maturity and increase speed of releases, decrease time to release, and improve productivity, despite not having an explicit test automation strategy or careful tool selection. - Perceived success factors included whole team effort, expert team members, self-motivated team members, allowing time for learning, and choosing the right test tools and infrastructure. - An incremental approach, observing and optimizing processes, and an internal open-source community mindset also contributed to the team's success in improving their test automation capabilities.

Open source bridge testing antipatterns presentation

mmrobins

Selenium Summit 21: Contemporary Exploratory Testing

Maaret Pyhäjärvi

Session on Contemporary Exploratory Testing by Maaret Pyhäjärvi

Agile Testing Alliance

Maaret Pyhäjärvi delivered a session on "Contemporary Exploratory Testing" at #SeleniumSummit21 Maaret Pyhäjärvi is a feedback fairy with a day job at Vaisala, where she works as Principal Test Engineer. She identifies as empirical technologist, tester and programmer, catalyst for improvement, author and speaker, and community facilitator and conference organizer. She was awarded as Most Influential Agile Testing Professional Person 2016, listed on 100 most influential in ICT in Finland by TiVi 2019, and has spoken at events in 25 countries delivering over 400 sessions. To know more about #SeleniumSummit21 please check : https://seleniumsummit21.agiletestingalliance.org/

Lab 10.doc

butest

The document provides instructions for a machine learning lab experiment using the Weka machine learning software. Students are asked to run several classifiers on a dataset containing RNA-binding protein sequences to predict whether amino acids bind to RNA or not. Classifiers include Naive Bayes, J48 decision tree, support vector machine (SVM) with linear and RBF kernels. Students record performance metrics from 5-fold cross validation and testing on a separate protein sequence, and analyze which classifier worked best.

Lab 10.doc

butest

This document provides instructions for a machine learning lab assignment. Students are asked to use the Weka machine learning tool to classify RNA-binding proteins using various algorithms, including Naive Bayes, J48 decision tree, SVM with linear and RBF kernels. Performance is measured using 5-fold cross-validation on the training set and classification of a separate test protein. Results for accuracy and other metrics are recorded in tables.

TestJSConf: Go Find What We May Have Missed

Maaret Pyhäjärvi

The document discusses testing and how to build better teams. It advocates for an approach called ensemble testing that incorporates unit, service, UI, and other types of tests. It emphasizes the importance of feedback, understanding, and finding what others may have missed. Examples are provided of integrating different components and dealing with user expectations. The document also provides biographical information about Maaret Pyhäjärvi and how to connect with her.

rTest, a Testing Tool for FME Workspaces

Safe Software

This document introduces rTest, an open source testing tool for FME workspaces. It was created to test large, generic FME workspaces for a geographical dataset quality control application called Qualigeo. rTest allows describing test scenarios and checking workspace outputs automatically through HTML reports. This improves reliability, speeds development, and reduces maintenance costs compared to traditional manual testing. The document outlines rTest's capabilities and limitations, and argues that testing tools are essential for large FME projects.

Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)

Robert Nelson

PuppetConf 2016: Enjoying the Journey from Puppet 3.x to 4.x – Rob Nelson, AT&T

Puppet

MoT Sfax: Good Exploratory Testing Tactics for Taking Over Testing

Maaret Pyhäjärvi

The document discusses exploratory testing tactics for taking over testing. It provides over 20 different tactics, such as finding bugs that matter without writing bug reports, using mind maps to model systems, following code changes and documentation to test different aspects, and classifying test charters. It advocates for a contemporary approach to exploratory testing that combines both manual and automated testing, and emphasizes learning and agency.

CraftConf: How Would You Test a Test Field?

Maaret Pyhäjärvi

The document discusses different levels of tester and their potential responses to being asked how they would test a text field. A junior tester may only suggest a few basic input types without considering other factors, while more experienced testers would propose a wider range of tests including special characters, character limits, formatting, and compatibility. The most senior tester would first ask questions to understand the purpose and requirements of the text field before designing tests. The document also provides examples of text fields with different levels of functionality that could be used to demonstrate testing approaches.

QAI QUEST 2016 Webinar Series: Pairwise Testing w/ Philip Lew

XBOSoft

Optimizing thread performance for a genomics variant caller

AllineaSoftware

Shift-Left Testing: QA in a DevOps World by David Laulusa

QA or the Highway

Shift-left testing involves injecting quality earlier in the software development process through techniques like unit testing, test-driven development, and regression testing. The presentation discusses principles for effective testing including equivalence partitioning, boundary value analysis, and combinatorial testing. It emphasizes the importance of collaboration between testers and developers through practices like dependency injection and test automation.

Design smells

Xavier Fornés Arrabal

This document discusses various design smells, which are indications of weaknesses or problems in code design. It categorizes design smells into five groups: bloaters, object-orientation abusers, change preventers, dispensables, and couplers. Bloaters include long methods, large classes, long parameter lists, primitive obsession, and data clumps, which make code hard to work with. Object-orientation abusers involve incomplete or incorrect use of object-oriented principles. Change preventers require changes in multiple places when a single change is needed. Dispensables are unnecessary code elements that could be removed to improve code quality. Couplers contribute to excessive dependencies between classes. Each smell is described with examples of signs,

Testing smells

Sidu Ponnappa

The document discusses unit testing anti-patterns. It describes implementation anti-patterns like long tests with many assertions, long test files, tests with complex logic, slow tests, and tests that cannot fail. It also describes workflow anti-patterns like writing tests last, only testing for regression, testing elsewhere than in unit tests, only running tests from the command line, and not using continuous integration. It suggests approaches like writing independent tests, avoiding redundant tests, and testing frequently to avoid these anti-patterns.

The Evolution of Development Testing

Cathal King

The document discusses the evolution of development testing. It describes how development testing has evolved from a practice focused on individual units to one that automates broader scenarios and exercises more control over the test context. The document also covers principles for writing high-quality tests, such as using structures that make tests readable and maintainable, and practices like helper methods and object builders that reduce complexity and improve test code quality.

ATAGTR '20 Keynote: Building status

Maaret Pyhäjärvi

The document discusses Maaret Pyhäjärvi's career and testing philosophies. It highlights some of her "signature moves" including not having a product owner, holding space for quality and testing, pair and ensemble testing, and exploratory testing with automation as documentation. It also discusses different types of testers and how Maaret went from a junior tester to principal tester over her career while maintaining a 37.5 hour work week.

MoT Cork: Exploring Realities of Testing - From Theory to Practice

Maaret Pyhäjärvi

The document discusses Maaret Pyhäjärvi's work exploring realities of testing and moving testing practices from theory to real-world application. It notes she has spoken at around 40 conferences in 2021 on topics like tester expectations, behavioral-driven development, pair and ensemble programming/testing, exploratory testing, and testing in production. The document provides biographical information on Maaret Pyhäjärvi, including her role as the 2020 Most Influential Agile Testing Professional Person and links to connect with her.

Mais conteúdo relacionado

Semelhante a Let's Do a Thing and Call it Foo

Agile2016: Exploratory Testing an API

Maaret Pyhäjärvi

How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018

Mike Harris

Selenium Conf: Patterns to Whole Team Test Automation Transformation

Maaret Pyhäjärvi

Open source bridge testing antipatterns presentation

mmrobins

Selenium Summit 21: Contemporary Exploratory Testing

Maaret Pyhäjärvi

Session on Contemporary Exploratory Testing by Maaret Pyhäjärvi

Agile Testing Alliance

Lab 10.doc

butest

Lab 10.doc

butest

TestJSConf: Go Find What We May Have Missed

Maaret Pyhäjärvi

rTest, a Testing Tool for FME Workspaces

Safe Software

Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)

Robert Nelson

PuppetConf 2016: Enjoying the Journey from Puppet 3.x to 4.x – Rob Nelson, AT&T

Puppet

MoT Sfax: Good Exploratory Testing Tactics for Taking Over Testing

Maaret Pyhäjärvi

CraftConf: How Would You Test a Test Field?

Maaret Pyhäjärvi

QAI QUEST 2016 Webinar Series: Pairwise Testing w/ Philip Lew

XBOSoft

Optimizing thread performance for a genomics variant caller

AllineaSoftware

Shift-Left Testing: QA in a DevOps World by David Laulusa

QA or the Highway

Design smells

Xavier Fornés Arrabal

Testing smells

Sidu Ponnappa

The Evolution of Development Testing

Cathal King

Semelhante a Let's Do a Thing and Call it Foo (20)

Agile2016: Exploratory Testing an API

How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018

Selenium Conf: Patterns to Whole Team Test Automation Transformation

Open source bridge testing antipatterns presentation

Selenium Summit 21: Contemporary Exploratory Testing

Session on Contemporary Exploratory Testing by Maaret Pyhäjärvi

Lab 10.doc

TestJSConf: Go Find What We May Have Missed

rTest, a Testing Tool for FME Workspaces

Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)

PuppetConf 2016: Enjoying the Journey from Puppet 3.x to 4.x – Rob Nelson, AT&T

MoT Sfax: Good Exploratory Testing Tactics for Taking Over Testing

CraftConf: How Would You Test a Test Field?

QAI QUEST 2016 Webinar Series: Pairwise Testing w/ Philip Lew

Optimizing thread performance for a genomics variant caller

Shift-Left Testing: QA in a DevOps World by David Laulusa

Design smells

Testing smells

The Evolution of Development Testing

Mais de Maaret Pyhäjärvi

ATAGTR '20 Keynote: Building status

Maaret Pyhäjärvi

MoT Cork: Exploring Realities of Testing - From Theory to Practice

Maaret Pyhäjärvi

Testing Voices '21 keynote: Testing Becoming Harder To BeValuable

Maaret Pyhäjärvi

The document discusses challenges that testers face as development practices have become more agile. Specifically, it notes that the cost of fixing defects is lower under agile but the cost of overengineering has increased. It also suggests that testers should get involved earlier, collaborate more with developers, and focus on learning and teaching skills rather than just finding bugs. Automation is important but must be integrated into continuous integration practices. The document advocates for techniques like holding space, telling stories of early value, and focusing communications on business needs rather than just the team.

TSQA: Something In The Way We Test

Maaret Pyhäjärvi

This document discusses exploratory testing and compares traditional test case-driven approaches to more contemporary exploratory approaches. It notes that test cases are better thought of as outputs that convey relevant information rather than inputs used to direct testing. The document also emphasizes that exploratory testing is a verb describing the active process of doing testing rather than a noun referring to pre-defined tests. It advocates for change-focused testing and shares examples of moving from traditional test documentation like test case documents to more lightweight charters and specifications.

ATAGTR: Targeting Errors Of Omission

Maaret Pyhäjärvi

The document discusses various topics related to software testing including: 1. The importance of considering errors of omission and actively searching for what others may have missed. 2. A 1-2-3 model for test coverage that includes code, requirements, results, environment, and data. 3. How pictures can convey different information than text and the value of visual modeling. 4. References to documentation on integer to Roman numeral conversion tests and reproducing a majority of production failures with unit tests.

Pivotal Moments, Pivotal Experiences

Maaret Pyhäjärvi

This document summarizes Maaret Pyhäjärvi's career journey and experiences in software testing and agile practices over several decades: - It begins in the late 1990s when she started in functional and localization testing in Finland, and began researching exploratory testing. - In the 2000s she worked as a senior tester, test manager, and principal tester while also teaching and researching testing methods at a university. She helped companies transform to agile practices. - Recent pivotal moments include advancing ensemble and pair programming practices for testing in 2014-2015, and unifying manual and automated testing in 2018 with her work on contemporary exploratory testing. - Throughout her career she has overcome challenges like public

Keynote at Sanae Beer.EX: The Automationist's Gambit

Maaret Pyhäjärvi

The document discusses exploratory testing and test automation. It advocates that exploratory testing and test automation should be used together, not separately. You cannot automate testing well without exploring features, and you cannot explore efficiently without some automated tests. The document also provides examples of how exploratory testing and test automation can inform and enhance each other when used as complementary techniques.

Testing Assembly: From Observations to Insights on Test Specialist Careers

Maaret Pyhäjärvi

This document discusses insights into becoming a test specialist and building a career in testing. It touches on topics like recognizing testing as a career path, gaining experience and education over time, learning from communities, dealing with imposter syndrome, taking on more responsibility, and balancing different skills like testing, programming, communication and learning. The overarching messages are that gaining experience, learning from others, developing confidence, and staying active in your learning and community can help one succeed in a career in testing.

Geekle QA: Automationist's Gambit

Maaret Pyhäjärvi

Programming Assignments in Tester Interviews

Maaret Pyhäjärvi

The document discusses programming assignments that are given during job interviews. It begins by sharing an experience from a recent interview where the expected assignment was to implement Roman numerals but the interviewee was surprised with a numbers to text conversion problem instead. It then provides the code for a function to convert integers to text from 0 to 999. The document discusses observations about test-driven development (TDD) and different focuses on teasing out solutions versus problems. It also considers internal versus external focus and explores modes for interview assignments like homework, during the interview, or open book. Lastly, it provides suggestions for doing interviewing with code problems better such as asking the interviewee how they would showcase skills and giving feedback during the session.

ATAGTR Keynote: I have a rock in my shoe - Navigating Improvement

Maaret Pyhäjärvi

The document discusses navigating improvement at work and changing more than we think is possible. It provides tips for naming discomfort, sharing work, dealing with rejection of ideas, and turning failures into learning opportunities. Specific problems mentioned include long release testing times, testing queues, and meeting expectations. Corresponding solutions proposed include more frequent releases, exploratory testing, test automation, discussing testing earlier, and explaining/stretching rules and expectations.

MoT Sarajevo: How to get better at Exploratory testing

Maaret Pyhäjärvi

This document discusses how to get better at exploratory testing through understanding, practice with feedback, and continuous growth (GROW). It emphasizes learning through experience and feedback, practicing a variety of techniques like pair and ensemble testing, and gaining leadership skills to continuously improve testing practices. The goal of exploratory testing is to find issues others may have missed through an interactive, learning-focused process.

HUSTEF '21 Keynote: Hands Off Exploratory Testing - Managing at Scale

Maaret Pyhäjärvi

This document discusses exploratory testing and managing testing at scale. It describes Maaret Pyhäjärvi's experience transitioning to exploratory testing and facilitating testing for multiple teams. Some key lessons learned include focusing on finding bugs and creating test automation, protecting testers' agency, limiting testing scope but extending it through networking, and using ideas like small continuous changes and automation to help guide testing at scale. The document emphasizes the importance of testing and encourages testers, programmers, and others to work together.

EuroSTAR '21 Keynote: Automationist's Gambit

Maaret Pyhäjärvi

While we draw parallels to Queen's Gambit the series on Netflix and Software Testing, this talk is not about how substance abuse is like testing. Instead, the movie guides us to to its name and figuring out what is this gambit. With exploratory testing, we have the opening moves, the midpart and the end game. The start can be anything but it builds our platform for the end game. And while exploratory testing, automation is part of that way of staying in tune with learning to win in the end game.

AppiumLite Keynote: Many Hats to Make a Tester

Maaret Pyhäjärvi

Hands off Exploratory Testing - Managing Testing at Scale

Maaret Pyhäjärvi

The document discusses exploratory testing and managing testing at scale. It advocates for a hands-off approach to testing that balances exploring to find issues with automating tests. It also emphasizes the importance of testing being a collaborative effort between testers, developers and product owners to continuously improve quality. The document provides guidance on focusing on impactful results, learning, and maintaining tester agency.

Breakpoint 2021: Contemporary exploratorytesting

Maaret Pyhäjärvi

This document discusses exploratory testing and test automation. It provides tips for exploratory testers such as focusing the first test execution on gathering information and the repeating executions on automation. It also notes that testing is important for more than just testers and those who automate tests still need to explore systems. The document is authored by Maaret Pyhäjärvi and provides her contact information.

SLASSCOM: Breaking illusions with Testing

Maaret Pyhäjärvi

The document discusses exploratory testing and lessons learned. It advocates for being intentional about learning, embracing serendipity through play, and pushing constraints to find workarounds. Testers should focus on understanding over just using a system, and help improve testability for developers. Automating tests can document edge cases. While scores may not reflect quality, what engages users? Overall it promotes skills like deliberate discovery and practicing to get luckier at exposing assumptions.

Mimmit Koodaa - Testiautomaatio on testauksen dokumentointia

Maaret Pyhäjärvi

The document discusses exploratory testing and test automation. It notes that exploratory testing involves designing and executing tests to focus on learning, while an exploratory testing organization allows and supports exploratory testing. It also contrasts the focus of testers doing exploratory testing versus test automation specialists. Finally, it provides biographical information about Maaret Pyhäjärvi, naming her the Most Influential Agile Testing Professional Person in 2016 and listing her areas of expertise.

Testing United - Social Software Testing Approaches

Maaret Pyhäjärvi

The document discusses social software testing approaches, including mob programming, pair testing, ensemble testing, and bug bashes. It provides descriptions of different testing approaches like traditional pair testing, strong-style pair testing, and ensemble testing. It also discusses the benefits of social testing approaches for larger organizations, agile teams, and training groups. Mob programming, accidental learning through being intentional, and learning through osmosis are presented as well. Contact information is provided at the end.

Mais de Maaret Pyhäjärvi (20)

ATAGTR '20 Keynote: Building status

MoT Cork: Exploring Realities of Testing - From Theory to Practice

Testing Voices '21 keynote: Testing Becoming Harder To BeValuable

TSQA: Something In The Way We Test

ATAGTR: Targeting Errors Of Omission

Pivotal Moments, Pivotal Experiences

Keynote at Sanae Beer.EX: The Automationist's Gambit

Testing Assembly: From Observations to Insights on Test Specialist Careers

Geekle QA: Automationist's Gambit

Programming Assignments in Tester Interviews

ATAGTR Keynote: I have a rock in my shoe - Navigating Improvement

MoT Sarajevo: How to get better at Exploratory testing

HUSTEF '21 Keynote: Hands Off Exploratory Testing - Managing at Scale

EuroSTAR '21 Keynote: Automationist's Gambit

AppiumLite Keynote: Many Hats to Make a Tester

Hands off Exploratory Testing - Managing Testing at Scale

Breakpoint 2021: Contemporary exploratorytesting

SLASSCOM: Breaking illusions with Testing

Mimmit Koodaa - Testiautomaatio on testauksen dokumentointia

Testing United - Social Software Testing Approaches

Último

How to write a program in any programming language

Rakesh Kumar R

WWDC 2024 Keynote Review: For CocoaCoders Austin

Patrick Weigel

UI5con 2024 - Bring Your Own Design System

Peter Muessig

How do you combine the OpenUI5/SAPUI5 programming model with a design system that makes its controls available as Web Components? Since OpenUI5/SAPUI5 1.120, the framework supports the integration of any Web Components. This makes it possible, for example, to natively embed own Web Components of your design system which are created with Stencil. The integration embeds the Web Components in a way that they can be used naturally in XMLViews, like with standard UI5 controls, and can be bound with data binding. Learn how you can also make use of the Web Components base class in OpenUI5/SAPUI5 to also integrate your Web Components and get inspired by the solution to generate a custom UI5 library providing the Web Components control wrappers for the native ones.

Need for Speed: Removing speed bumps from your Symfony projects ⚡️

Łukasz Chruściel

No one wants their application to drag like a car stuck in the slow lane! Yet it’s all too common to encounter bumpy, pothole-filled solutions that slow the speed of any application. Symfony apps are not an exception. In this talk, I will take you for a spin around the performance racetrack. We’ll explore common pitfalls - those hidden potholes on your application that can cause unexpected slowdowns. Learn how to spot these performance bumps early, and more importantly, how to navigate around them to keep your application running at top speed. We will focus in particular on tuning your engine at the application level, making the right adjustments to ensure that your system responds like a well-oiled, high-performance race car.

How Can Hiring A Mobile App Development Company Help Your Business Grow?

ToXSL Technologies

Using Xen Hypervisor for Functional Safety

Ayan Halder

zOS Mainframe JES2-JES3 JCL-JECL Differences

YousufSait3

316895207-SAP-Oil-and-Gas-Downstream-Training.pptx

ssuserad3af4

Unveiling the Advantages of Agile Software Development.pdf

brainerhub1

Oracle 23c New Features For DBAs and Developers.pptx

Remote DBA Services

Webinar On-Demand: Using Flutter for Embedded

ICS

Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.

Malibou Pitch Deck For Its €3M Seed Round

sjcobrien

Fundamentals of Programming and Language Processors

Rakesh Kumar R

All you need to know about Spring Boot and GraalVM

Alina Yurenko

Requirement Traceability in Xen Functional Safety

Ayan Halder

Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...

XfilesPro

Top Benefits of Using Salesforce Healthcare CRM for Patient Management.pdf

VALiNTRY360

Salesforce Healthcare CRM, implemented by VALiNTRY360, revolutionizes patient management by enhancing patient engagement, streamlining administrative processes, and improving care coordination. Its advanced analytics, robust security, and seamless integration with telehealth services ensure that healthcare providers can deliver personalized, efficient, and secure patient care. By automating routine tasks and providing actionable insights, Salesforce Healthcare CRM enables healthcare providers to focus on delivering high-quality care, leading to better patient outcomes and higher satisfaction. VALiNTRY360's expertise ensures a tailored solution that meets the unique needs of any healthcare practice, from small clinics to large hospital systems. For more info visit us https://valintry360.com/solutions/health-life-sciences

Top 9 Trends in Cybersecurity for 2024.pptx

devvsandy

Mobile app Development Services | Drona Infotech

Drona Infotech

E-commerce Development Services- Hornet Dynamics

Hornet Dynamics

Let's Do a Thing and Call it Foo

1. @maaretp Let’s Do a Thing and Call it Foo by Maaret Pyhäjärvi

2. @maaretp The terms foobar (/ˈfuːbɑːr/), foo, bar, baz, and others are used as metasyntactic variables and placeholder names in computer programming or computer-related documentation.[1] They have been used to name entities such as variables, functions, and commands whose exact identity is unimportant and serve only to demonstrate a concept. https://en.wikipedia.org/wiki/Foobar

3. @maaretp Stakeholders happy, even delighted –Quality Information Good Team’s Output –Quality Information Less than Good Team’s Output –Quality Information Results Gap Surprise! Results Gap on aTeam that thinks Testers ==Testing Pick up the pizza boxes… ”Find (some of) What Others May Have Missed”

4. @maaretp For pair / ensemble testing this with me <3 Thank You Alex, Elisabeth, Bertold,Thomas, Mirja, Karen, Moroni, Isidro, Benjamin

5. @maaretp Computer Assisted Software Authorship https://github.com/features/copilot/

6. @maaretp WE are accountable 1. Intent / Implementation 2. Domain for the Layman 3. Domain for the Expert 4. Reference Implementation 5. People Filtering

7. @maaretp CASA (Computer Assisted Software Authorship) in action

8. @maaretp https://en.wikipedia.org/wiki/Roman_numerals

9. @maaretp

10. @maaretp

11. @maaretp One Solution

12. @maaretp Some Tests

13. @maaretp References…

14. @maaretp References…

15. @maaretp References…

16. @maaretp ApprovalTests

17. @maaretp Two Tests, Three ways

18. @maaretp Say it in English - Options #We want to translate numbers to roman numerals. #convert numbers to roman numbers # Convert numbers to roman numerals # convert decimals to roman numerals # Convert numbers to roman numberals # translating numbers to roman numerals # convert decimal numbers to roman numerals #Check that roman is an integer # Raise an exception if not a numeric value # Raise an exception if not a valid number # catchTypeError if num is not an integer # catchValueError if num is not within range

19. @maaretp Answer key to some of the bugs • Values over 4k don’t work (without extending to line-on-top notation) – Zeros, fractions, large numbers later in scope • Decimal values truncated vs. rounded • *some of the implementations* – Boundary values miscalculated – Infinite loop • Implementing Classic when expecting Simplified

20. @maaretp Insights from 8 rounds of pair/ensemble testing • Unit Exploratory Testing is FAST • Concepts: Parametrized tests, pytest.raises, approvaltests • 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 • Fooling a domain expert on conflicting domain rules surprising how versatile a simple appearing domain is

21. @maaretp WE are accountable 1. Intent / Implementation 2. Domain for the Layman 3. Domain for the Expert 4. Reference Implementation 5. People Filtering

22. @maaretp

23. @maaretp A majority of the production failures (77%) can be reproduced by a unit test. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf Through https://www.slideshare.net/Kevlin/the-error-of-our-ways

24. @maaretp Everything that does not need to be automated gets done while automating.

25. @maaretp Foo Contemporary Exploratory Testing

26. @maaretp Find (some of) what others may have missed! Testing … and never be bored.

27. @maaretp 2020 2016 MIATPP Most Influential Agile Testing Professional Person #PayToSpeak #TechVoices #EnsembleTesting #EnsembleProgramming #StrongStylePairing #ExploratoryTesting #TestAutomation #ModernAgile #AwesomeTesters Maaret Pyhäjärvi (from Finland) Email: maaret@iki.fi Twitter: @maaretp Web: maaretp.com Blog: visible-quality.blogspot.fi (please connect with me through Twitter or LinkedIn) 2019, 2020, 2021 https://exploratorytestingacademy.com Ohjelmistotestaus ry https://techvoices.org

Let's Do a Thing and Call it Foo

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Let's Do a Thing and Call it Foo

Semelhante a Let's Do a Thing and Call it Foo (20)

Mais de Maaret Pyhäjärvi

Mais de Maaret Pyhäjärvi (20)

Último

Último (20)

Let's Do a Thing and Call it Foo