Description:

My grandmother is 85 years old, she has been struggling with the technology boom since the 1950s. For many years she was thinking that the whole technologic boom was an offense to her intelligence, but eventually, she realized that product and service providers were not keeping her in mind as an end-user. One of the most critical technological industries in the user experience of my grandma is the excessive production of radio, televisions, and associated remote controls since the 1950s. She is a frustrated end-user but at the same an expert Senior tester. But so far my grandma is still dealing with the boom of mobile apps, she does not like mobile apps. She says “if that people don't think about me, they don't deserve my money, That's it”. The usability or UX for mobile or Web apps is very important, but a well-designed website isn’t just about how easy it is to use or how elegant it looks. An aspect often overlooked is the performance of an application in terms of response times. Web and Mobile apps need to respond quickly to requests from users and this means optimizing the application with performance in mind.

Key Takeaways:

• How my grandma struggled with technology since the 1950s as an end user and also as a tester testing devices like radios, tvs, and remote control.

• How response times impact the user experience.

• How you can optimize the performance of your web or mobile application from Front End, Back End, and Perception of Web Performance.

Description:

Successful software projects require corporate support and buy-in. Learn techniques to effectively gain support and increase the odds of success.

Description:

About a decade ago people with advanced knowledge built test automation frameworks with essentially two separate layers: Test Scripts and Test Libraries. The problem with this Bi-Layer architecture is the challenges of reusability in other applications, specifically, the size and complexity of test libraries along with the application-dependent solutions being intertwined made it very difficult, sometimes impossible to reuse them.

That's how the idea of the Tri-Layer Testing Architecture was born: why not add a 3rd layer, for all the libraries that can be easily reused anywhere?

In this presentation, Peter will talk about the main differences between the Bi-Layer and the Tri-Layer architectures. The three layers are Test (runnable test scripts), Business (all the application-specific libraries), and Core (independent, reusable libraries). Peter will provide examples from his experience at big fintech and other companies, where he successfully implemented the Tri-Layer Testing Architecture and dramatically lowered the test automation costs for these big companies.

Key Takeaways:

• Attendees will be able to identify signs of a smelly architecture

• Designing a test automation architecture is way easier than you would first think

• Reusable components and properly designed layers are the heart of a great test automation framework.

Description:

In the software testing game, it is all about the details. Testing is really a simple thing to describe; does the software behave as expected? The complexity comes in knowing the details of what to expect and then designing tests to verify the behavior is as expected. Human brains are great at testing given knowledge of what the application should do. Automation tools have no knowledge. The trick is to find a way to make the tools know what you mean. Let’s discuss.

Description:

We've all heard of test-driven development (TDD) (Beck 2003; Astels 2003), as an evolutionary approach to development which combines test-first development. You write a test before you write just enough production code to fulfill that test and then refactoring. Now in 2022 with the increased attention to full-stack operations and scalability, the importance of engineering attention to system performance is shifting left. This talk with introduce the adapted concepts of TDD to performance engineering and scalability: Performance-driven Development. One way to think of this is that you must think through your non-functional requirements or system design before your write your code. This implies PDD can be an inherent principle for agile requirements and agile design techniques. Another common experience in shifting-left performance testing is that PDD is a programming technique - a skill set for writing performant, efficient code and configurations that scale and are reliable.

Key Takeaways:

• What is PDD and how is it different from TDD, Agile Development, early performance testing and abstracted performance engineering practices

• An overview of different suggested implementation strategies to begin adoption or change to a PDD model

• Simple things you can change to start driving development via non-functional performance requirements.

Description:

Event-Driven Architectures (EDAs) are an increasingly popular way for enterprises to create high scale, fault-tolerant, low latency, cloud-native applications. IDC recently predicted that by 2024 10% of enterprises would be using an EDA for the majority of their applications and 70% would be using EDA patterns in at least some of their ongoing applications. In this talk, we will give you a high-level introduction to how EDAs work, discuss the testing challenges they pose and look at some strategies for testing them.

Key takeaways:

• A deeper understanding of Event-Driven Architectures

• Understand challenges around testing EDA

• Practical suggestions for tackling those challenges.

Description:

Accessibility is a large topic and one that often gets a variety of approaches to deal with. Often it is seen as having to focus on a large checklist (the WCAG standard) and make sure that everything complies. While this is a great goal and focus, often it is overwhelming and frustrating, putting people in the unfortunate role of having to read and understand an entire process before they feel they can be effective. It does not have to be this way.

Key Takeaways:

My goal is to help condense this a little and give some key areas to focus on and be effective in identifying Accessibility issues quickly and helping testers become effective advocates.

We will look at ways to:

• find issues

• advocate for them

• help make strides to greater understanding and focus moving forward.

Description:

Case study of how a small Agile ERP implementation team can use SpiraTeam to (a) rapidly collect and validate stakeholder requirements and (b) perform stakeholder UAT testing with low implementation defect rates and high user satisfaction.

Key Takeaways:

• Why formal requirements management should be used by Agile teams

• How SpiraTeam is easily used and rapidly deployed collaborative by an Agile Team

• How SpiraTeam testing and defect management in an Agile environment is a best practice to be embraced.

Description:

Organizations and leaders are often supportive of DevOps, but they don’t always understand what DevOps is and what it will change. It isn’t a one-size-fits-all issue; different environments need different benefits from a DevOps transformation. Join Gene Gotimer as he explains the most important parts of understanding DevOps. We'll discuss how to determine what parts of DevOps your organization needs to concentrate on first and how you should measure improvement. This session boils DevOps down to its most basic parts and makes sure you have a foundation for understanding how to make it work for your situation and organization.

Key Takeaways:

• DevOps is a culture. Embrace the Three Ways.

• The Four Key Metrics are measures of DevOps maturity, not goals.

• Use value stream analysis to understand your process and find your biggest impediments.

Description:

TBD

Description:

Whether you’re working on a team or in a leadership position, being able to lead is an essential skill for a professional.  Therefore, everyone needs to have a leadership voice that can inspire and influence others.

These voice skills work if you practice them whether you are fresh out of college and it’s your first job, brand new to a team, brand new to leadership, or have been in leadership for years.  Even if you aren’t a leader yet of a team and that’s your goal, you still must master these vocal skills to stand out and be recognized for your leadership.

When you have mastered your internal and external voice of confidence which is instrumental in being a leader you will become so much more powerful and empowered.  You will know how to use your voice to showcase your ideas, your leadership capabilities, and the value you bring to any business or corporate team.  Who doesn’t want to have this? 

Key Takeaways:

• Be able to make the sounds of confidence

• How to sound instantly more intelligent

• Know how to change your internal and external voice for new improved results

• Feel confident in asking for a raise

Description:

It’s true that an automation framework is like a puzzle piece that brings a testing practice together, an engine that makes a car zoom, and a conveyor that transforms system analysts into automated testers. But do some frameworks do this better than others and what role does it play in DevSecOps? Is it possible that your automation engineers are spending a tremendous amount of time maintaining legacy solutions? Even more important, can regaining that time increase your return on investment? To truly understand the possibilities, we need to recognize that automated testing, like any technology, is an evolving practice.

Key Takeaways:

• What role does an automation framework play in DevSecOps?

• How can you best implement to streamline processes and shorten development time?

• How can a stronger testing plan improve security?

Description:

Many quality engineering leaders say they do risk-based testing, but walking the walk is showing to be more challenging than enterprises realize. Often, quality engineering teams practicing risk-based testing end up testing “everything” because they continue to test from a place of fear as opposed to calculated risk. Others never reassess or renegotiate risk as their application matures. Additionally, sometimes quality engineering teams lack accurate testing data in order to make well-informed decisions.

Enterprise quality engineering leaders must apply a truth-telling question: What motivates your test coverage decisions? Fear or risk?

Key Takeaways:

• How quality engineering leaders assess and measure risk

• The real motivating factors behind test decisions and how to overcome bias created by fear and previous failures

• How to judge if software quality is “good enough” before a release so that testing does not harm development velocity

• How to reassess risk by integrating new data

• How Software Quality Governance empowers enterprise risk-based testing.

Description:

Many people in business and industry assume they are leaders, simply because they have a title and/or have people reporting to them. In fact, most of them are, by definition, managers. Successful organizations thrive on great leadership, not management.

Key Takeaways:

• Great leadership triumphs over technical skills in creating a successful organization.

• Great leaders are grounded in emotional and social intelligence.

• Great organizations depend on visionary leaders and successful change agents.

Description:

Organizations have adopted Agile, Scrum, DevOps, CI/CD practices widely in order to increase their adaptivity. While doing so, they learn that it is impossible to speed up the IT deliverance without trusting the quality. Lean and SAFe have Built-in Quality as a core principle, but what does that mean for teams and organizations?

In this presentation, Derk-Jan will share the challenges he encounters at various organizations. How do teams work and collaborate in order to release valuable increments, and what are approaches to increase quality awareness? We will discuss the role of testers on the team level but also investigate how quality is organized in scaled settings where teams need to collaborate on a single increment. How can you organize quality on release level, what types of releases can we distinguish and who is responsible? What do we see in practice and how should it work? In order to have quality built-in, we need more than just good tests. But a strategy also. Implementing this on various levels is challenging and has an impact on the way we develop our software.

Key Takeaways:

• Understand that built-in quality is a multi-level challenge that is gaining importance

• Discover real-life patterns that make grip on quality a challenge

• Have a look at practices in order to improve the quality

• How to define quality feedback loops and the impact on the development and business.

Description:

Is your team made up of some of the best talents in the company and consists of a Project Manager, Certified Scrum Master (CSM), Solution Architect, Data Architect, Developers, a Senior Performance Test Engineer, and an Automated Functional Tester. Your customer is open to HCD but has no idea what that entails. As a professional skilled and experienced in the Software Development Life Cycle (SDLC), the Agile Scrum methodology and with some knowledge of Human-Centered Design (HCD), as you start a project, this two-part session will take you on a journey on how to incorporate HCD when delivering using a DevOps workstream.

• What are some of the benefits of using HCD for a software or systems integration project?

• Does your team anticipate challenges using HCD now?

• What risks exist if you do NOT use HCD?

• If you are already sold on HCD, how do you incorporate it into Agile Scrum and/or DevOps environments?

• If you need to start using HCD, how will you reorganize your work to continue to deliver?

Well, this two-part session is for you and your team. You will experience how HCD methods can be incorporated into both Agile Transformation and DevOps Planning. Bring your thinking caps and be ready to work collaboratively during this interactive event as you take a DevOps problem and take it from Epic to Feature Test employing HCD methods.

Part 1: Using Empathize and Define to plan Epics and Features

During Part I, we will apply HCD methods and frameworks for user research and problem definition to develop Epics and Features for a DevOps case study.  

Part 2: Using Ideate, Prototype, and Test to detail Features and Work Items

During Part II, we will apply HCD methods and frameworks related to brainstorming, prototyping, and testing at the Feature- and Work Item-levels such as user stories, associated wireframes, and additional Work Items based on test results.

Description:

Agile Coaches may be asked to have many skills, but which skills are most important to you? Do you need a teacher, facilitator, mentor, consultant or something else?

Understanding the different “hats” an agile coach may wear, helps in hiring the right coach, upskilling your current coaches and setting expectations with your teams. This understanding also helps Agile Coaches have better conversations with leadership by framing and naming the different characteristics, skills and outcomes needed to wear each hat.

An experienced Agile Coach will put on 12 different hats and discuss the pros and cons of wearing each one.

While this is a presentation, the use of many hats and props will provide unique visuals and allow the audience to connect to the various skills, behaviors and outcomes associated with each hat an agile coach may wear. While a presentation doesn’t allow for Concrete Practice, it does allow for Connection, Concepts and Conclusion.

During this session, a seasoned Agile Coach will put on 12 different hats with appropriate props while discussing the distinct differences of each. Some of the hats such as a teacher you expect. Others such as the “Yes Person” may come as a surprise.

1.       Teacher (Graduation Cap)

2.       Mentor (Hogwarts Wizard’s Hat)

3.       Facilitator (Party Hat)

4.       Coach (Ted Lasso’s Hat)

5.       Consultant (Surgery Scrub Cap or my Judge’s Wig)

6.       Dojo Coach (Karate Kid Headband)

7.       Project Manager (Hard Hat with Head Lamp)

8.       Auditor (Green Accountant Hat)

9.       Agile Police (NY PD Hat)

10.   Spy (Sherlock Holmes Hat)

11.   Deliver This Product! (Crash Helmet)

12.   Yes Person (Propeller Beany)

Key Takeaways:

• Understanding the various agile coaching skills

• Taxonomy for better discussions with agile coaches and leadership

Description:

Is your team made up of some of the best talents in the company and consists of a Project Manager, Certified Scrum Master (CSM), Solution Architect, Data Architect, Developers, a Senior Performance Test Engineer, and an Automated Functional Tester. Your customer is open to HCD but has no idea what that entails. As a professional skilled and experienced in the Software Development Life Cycle (SDLC), the Agile Scrum methodology and with some knowledge of Human-Centered Design (HCD), as you start a project, this two-part session will take you on a journey on how to incorporate HCD when delivering using a DevOps workstream.

• What are some of the benefits of using HCD for a software or systems integration project?

• Does your team anticipate challenges using HCD now?

• What risks exist if you do NOT use HCD?

• If you are already sold on HCD, how do you incorporate it into Agile Scrum and/or DevOps environments?

• If you need to start using HCD, how will you reorganize your work to continue to deliver?

Well, this two-part session is for you and your team. You will experience how HCD methods can be incorporated into both Agile Transformation and DevOps Planning. Bring your thinking caps and be ready to work collaboratively during this interactive event as you take a DevOps problem and take it from Epic to Feature Test employing HCD methods.

Part 1: Using Empathize and Define to plan Epics and Features

During Part I, we will apply HCD methods and frameworks for user research and problem definition to develop Epics and Features for a DevOps case study.  

Part 2: Using Ideate, Prototype, and Test to detail Features and Work Items

During Part II, we will apply HCD methods and frameworks related to brainstorming, prototyping, and testing at the Feature- and Work Item-levels such as user stories, associated wireframes, and additional Work Items based on test results.

Description:

The two primary contributors to poor quality in an organization are lack of involvement by management and lack of knowledge about quality. Without the right process and people, quality will be either a cost center or forgotten component by development. To achieve organizational success, enterprise quality must take action to build quality from top down. Managers must accept responsibility for the quality practice within the organization and promote it across the organization. Everyone is responsible for quality, not just QA. The journey is fraught with obstacles – maturing the quality practice of an organization builds long term success with robust process and will train employees.

Key Takeaways:

• Everyone is responsible for Quality, but Management is responsible for Quality practice.

• Quality is not a destination, it’s a journey.

Description:

Coming Soon

Description:

Is what a business analyst (BA) does on an agile project much different from what is done on a waterfall project? Yes and No. Do the three amigos include the analyst or not? It certainly does! Although how the work is done depends on the team and project. During this session we’ll review how the role of a BA on an agile project can vary, how BAs impact the development team, the various roles a BA does, and what makes a BA good at their jobs. All analysts bring excellent communication, collaboration, and trust to their work on project teams – but how we communicate and collaborate will differ. This session is targeted at anyone on a project team that has never worked with an analyst before.

Key Takeaways:

• Understand the progressive elaboration with analysis staying several sprints ahead of development

• Understand the Roles a BA plays on a project other than BA

• Know and utilize the skills an analyst brings to the team

Description:

We are very aware of biases that are a threat to delivering software quality. But those biases can also be used to our advantage and there is a name for it: nudging.

Biases have been the subject of quite some talks on stage nowadays. Biases that are a threat to delivering high-quality software. And for sure there is a lot to worry about, we all know for example that we assume that we know exactly what our stakeholders want, and we still produce not working software. But is it also possible to use those biases in the favor of quality and testing? In fact, there is a way that biases are used positively, and it has a name: nudging. Nudging uses ‘choice architecture’, which means creating a situation where you can make an unconscious choice for a good purpose. It is used a lot in marketing and politics, for example how a grocery store, using green arrows to the fruit and veggie aisles, increase the sale of healthy food. I looked at different opportunities that nudging gives us for the sake of better agile testing. For example, in a refinement or in a discussion about bugs or when we are delivering our results to our team or our stakeholders. In my talk, I will elaborate more on what nudging exactly is, the ethical questions around nudging, and how we can apply nudging while testing. It will be an exploration so bear with me.

Description:

No doubt you’re an amazing tester. If we could clone you and have twenty such team members we would. Life would be good! We’d crush the testing! But…we can’t clone you. When it comes to our team, the best we can hope for is to hire the right people with the right attitude and aptitude and nurture their QA and testing skills. How do we accomplish such a monumental task?

Throughout my 31 years in IT, I’ve been tasked with building and mentoring testing teams regularly. I do so now to build and sustain my own successful business. Agile and DevOps…no problem! Test automation and frameworks…piece of cake! Build and grow a team…YIKES!

Many years ago, I had an epiphany…GAMES! I recalled my military days and the war games we’d play. I thought back to my consulting for the U.S. Navy to teach them how to automate tests against flight simulators. I flashed back to the puzzles I had to solve in my attempt to become an air traffic controller. History tells us games go back over 2,300 as a tool to teach with Chess being a perfect example. It was used as a strategy teaching game to prepare soldiers to do battle! The games many of us play to improve specific skills…such as memory, speed of thinking, creativity…came to mind.

Thus, I began using games and puzzles. I use them to assess if a potential new hire has what’s needed to be part of our engineering team and to continually hone the skills of our software test engineers.

Join Bob Crews for this interactive, high-participation, fun presentation as we play the games and solve the puzzles which can assist in building and developing phenomenal software testing teams!

The audience will learn:

• How games have been used throughout history to hone specific skills of the participants

• The types of games to use to assist in identifying personality traits and key attributes

• The value of games, puzzles, and games and what both the player and observers can learn

• That games do more than teach…they boost moral!

Key Takeaways:

• Specific games, puzzles, and brainteasers and the personality traits and attributes they target

• An understanding of when to play and when to observe

• The correlation between skills needed for games and skills needed by testers

Description:

The way we navigate and interact with information is constantly evolving to keep up with our rapidly increasingly digital world. Social networks and digital media platforms backed by subjective influence have paved the way towards complete polarization, and diverse sets of perspectives are being highlighted in technologies that are built to attract and connect consumers. This means that improving the trust and quality of information we use has become even more essential to effectively adapt to the new media age and set the tone for the future of work. Through this, consumers have begun to adapt to the new age of information consumption. Automating answers in real-time and continued support has boosted the workforce morale and validated the trust coming from those using the information.

Key Takeaways:

• The development of emerging technologies that are changing the way we use the information to make decisions

• The vast amount of opportunities for business information growth that stems from an expansive technological landscape that combines human and artificial intelligence

• The workplace and industry benefits of integrated technology that provides information in real-time.

Description:

A data-driven organization is imperative for the future. The smartphone and the ubiquitous computing have produced an exponential data explosion. From fueling the recent success of “artificial intelligence” (AI) and the rise of “digital transformation” to its accelerated growth due to Covid-19 to new approaches to its “monetization” to how it makes businesses and consumers both anxious and animated, data dominates our deeds, debates, and dreams. If the last decade was about “software eating the world, this decade is about “data eating the world”. Organizations are now faced with the huge challenge of managing, harnessing, and leveraging all of this data. We are still at the very beginning of the data revolution, and of understanding its second, third, and fourth-order effects. Organizations that are successfully transforming their business, technology, and operations strategy to align with their data strategy are the ones that will have a sustainable competitive advantage.

Key Takeaways:

• A mental-model for managing, harnessing, and leveraging data within an organization

• Strategies for improving data culture and democratization within an organization

• Key blockers and challenges on the journey to becoming a data-driven organization

Description:

Teams using Scrum sometimes struggle with operational or emergent work blowing up their sprint plans. As DevOps delivery is increasingly used by organizations the need of Scrum teams to accommodate operational work also increases. After all, it does not matter how interesting that new feature is if production is down. By combining the disciplines of Scrum and Kanban teams can find that happy balance of planned work and emergent work while still maintaining discipline and continuous improvement.

As an example, we will build up a hybrid process for a hypothetical team to discuss the reasoning behind different combinations of practices that could be used. I will review 3 categories of hybrid ScrumBan delivery methods that are typically seen in the industry.