Ash_Winter-DEWT7_V1
•Download as PPTX, PDF•
0 likes•410 views
This document discusses the author's experience consulting with various organizations to improve their testing capabilities. The author found that reviewing testing independently did not address root causes and that organizations often wanted quick fixes rather than systemic changes. The author eventually realized they needed to take a more holistic systems-thinking approach and focus on root causes rather than superficial solutions. They decided to focus more on systems thinking and become nomadic in their work.
Report
Share
Report
Share
Recommended
Bullseye or The Testing Wheel
One of my recent endeavours has been to create a "career model" for the testers within my organisation. I sat in my office at home and designed "the testing wheel". I wanted it to be simple, inclusive and offer questions but few answers.
Careers are long and winding. My own career has not been a linear progression, so building a linear model seemed wrong to me. But, this brought me into conflict with the ideas of others.
My experience report will show the highs and lows of this model after introducing it into the wild. People still tried to measure and rank with it, got mad people got when I refused to answer the questions it posed. Finally how it spread and entered battle with wider organisations career models.
The Wheel of Testing
One of my recent endeavours has been to create a "career model" for the testers within my organisation. I sat in my office at home and designed "the testing wheel". I wanted it to be simple, inclusive and offer questions but no answers.
Careers are long and winding. My own career has not been a linear progression, so building a linear model seemed wrong to me. But, this brought me into conflict with the ideas of others.
My experience report will show the highs and lows of this model after introducing it into the wild. People still tried to measure and rank with it, got mad people got when I refused to answer the questions it posed. Finally how it spread and entered battle with wider organisations career models.
Ash Winter - What is testing?
This document discusses different perspectives on what testing is and provides the author's axioms about testing. The author believes that testing is a team-based activity where they help enable testing rather than doing most of the testing themselves. They view testing as a human, intellectual activity involving thinking, learning, sharing ideas. Complete testing is seen as impossible due to logical limitations and infinite possibilities, so balance and variation are important. Testing is considered a performance where the value is in applying it, not just thinking about it. Tools can assist testing but not replace it. Context is also important, as what works in one situation may not work in another.
November 11 -19. idiom, novel groups
This document outlines the agenda for an English class, including a discussion of the idiom "jump to conclusions" and forming novel discussion groups. Students will take turns summarizing what they read in their assigned sections and answering discussion questions as preparation for an upcoming quiz. Homework includes a novel quiz and a reading test on Monday.
November 10 Class
The document outlines the schedule and process for an upcoming peer review workshop, including breaking attendees into groups and having them introduce their projects, goals for feedback, and questions for discussion. It provides assumptions about the usefulness of peer review for improving writing skills and notes that practice and feedback from others is important for development as a writer. The document also lists the groups and steps that will be followed during the peer review workshop.
Embodied Critique: Design critique methodology for the whole team and the who...
Bringing your whole self to your design critique practice is not only good for the soul, but good for the quality of a creative team's output. Resolve conflict, make awesomer work, and feel more satisfied and happy while doing it. Here's how.
Design Box Working Paper FDG 2014
The design box is a tool developed to aid in getting to the elevator pitch for a game or other creative product. It is intended as a tool to help groups deeply understand a problem and pitch creative solutions. This was presented at the Foundations of Digital Games 2014 conference aboard Liberty of the Seas as a work in progress.
Prototyping: Making Questions More Tangible
In this presentation, Christine Ortiz, . 4.0 Schools' Chief EIR, describes our prototyping process for education entrepreneurs.
Recommended
Bullseye or The Testing Wheel
One of my recent endeavours has been to create a "career model" for the testers within my organisation. I sat in my office at home and designed "the testing wheel". I wanted it to be simple, inclusive and offer questions but few answers.
Careers are long and winding. My own career has not been a linear progression, so building a linear model seemed wrong to me. But, this brought me into conflict with the ideas of others.
My experience report will show the highs and lows of this model after introducing it into the wild. People still tried to measure and rank with it, got mad people got when I refused to answer the questions it posed. Finally how it spread and entered battle with wider organisations career models.
The Wheel of Testing
One of my recent endeavours has been to create a "career model" for the testers within my organisation. I sat in my office at home and designed "the testing wheel". I wanted it to be simple, inclusive and offer questions but no answers.
Careers are long and winding. My own career has not been a linear progression, so building a linear model seemed wrong to me. But, this brought me into conflict with the ideas of others.
My experience report will show the highs and lows of this model after introducing it into the wild. People still tried to measure and rank with it, got mad people got when I refused to answer the questions it posed. Finally how it spread and entered battle with wider organisations career models.
Ash Winter - What is testing?
This document discusses different perspectives on what testing is and provides the author's axioms about testing. The author believes that testing is a team-based activity where they help enable testing rather than doing most of the testing themselves. They view testing as a human, intellectual activity involving thinking, learning, sharing ideas. Complete testing is seen as impossible due to logical limitations and infinite possibilities, so balance and variation are important. Testing is considered a performance where the value is in applying it, not just thinking about it. Tools can assist testing but not replace it. Context is also important, as what works in one situation may not work in another.
November 11 -19. idiom, novel groups
This document outlines the agenda for an English class, including a discussion of the idiom "jump to conclusions" and forming novel discussion groups. Students will take turns summarizing what they read in their assigned sections and answering discussion questions as preparation for an upcoming quiz. Homework includes a novel quiz and a reading test on Monday.
November 10 Class
The document outlines the schedule and process for an upcoming peer review workshop, including breaking attendees into groups and having them introduce their projects, goals for feedback, and questions for discussion. It provides assumptions about the usefulness of peer review for improving writing skills and notes that practice and feedback from others is important for development as a writer. The document also lists the groups and steps that will be followed during the peer review workshop.
Embodied Critique: Design critique methodology for the whole team and the who...
Bringing your whole self to your design critique practice is not only good for the soul, but good for the quality of a creative team's output. Resolve conflict, make awesomer work, and feel more satisfied and happy while doing it. Here's how.
Design Box Working Paper FDG 2014
The design box is a tool developed to aid in getting to the elevator pitch for a game or other creative product. It is intended as a tool to help groups deeply understand a problem and pitch creative solutions. This was presented at the Foundations of Digital Games 2014 conference aboard Liberty of the Seas as a work in progress.
Prototyping: Making Questions More Tangible
In this presentation, Christine Ortiz, . 4.0 Schools' Chief EIR, describes our prototyping process for education entrepreneurs.
Ash_Winter_Tested_to_Death
The document discusses how too much testing can trap a team and product in a "death spiral". It describes a scenario where a team assembled to build a product but their testing strategy became ineffective and led to slower development and frustrated teams. The document then provides tips on how to avoid this, such as making sure unit tests actually test units, writing tests first, keeping dependencies loose, and evolving one's testing strategy so that testing serves the team rather than the other way around. It emphasizes that the goal is learning rather than failure.
Ash_Winter_Testing_Mobile_Apocalypse_Online
The document discusses testing in a mobile context. It begins with a poll about mobile device and testing experience. It then tells a story about realizing the need to test mobile applications. Mobile testing was behind the curve, with early experts, dodgy tools, and outsourcing common issues. However, mobile presents an opportunity for testing as the same principles of testing still apply. The document lists several "axioms" or truths of testing that still hold for mobile, such as testing being a human activity and oracles being fallible. It argues that complete testing is impossible given device fragmentation, but test cases do not equal testing. Testing mobile is a performance in itself. The document concludes that bugs cost businesses and mobile is probably the
Main Talk v1.1
Pokémon GO faced several quality issues after its initial release such as app freezing, server overload causing scaling problems, inaccurate GPS, and device fragmentation affecting the ability to catch Pokémon. The document discusses lessons learned around testing and quality from these issues, including the need for a balanced testing approach with different types of testing like functionality, performance, compatibility, and usability testing. It also emphasizes that quality is multifaceted and requires continuously adding and improving features while focusing on the core idea.
Ash_Winter-Forgotten-ility_V1
The document discusses various topics related to software testing including testability, logging, environments, and feedback. It provides tips such as getting to know operations pain points, logging what matters without bloat, understanding past code intent, and focusing more on test flow and feedback rather than number of environments or testability. The document ends with inviting questions.
NWEWT_Slides_Ash_Winter_04_2016
This document discusses regression testing for a project to stabilize and upgrade the underlying technology of a system while maintaining normal service. It raises questions about how to test that nothing has changed when everything is changing, and whether changes to responsiveness and capacity would still be noticeable to customers. The regression testing involved risk modeling sessions with stakeholders to understand the system, exploring the system to determine what to test, and testing from the user interface down to the unit level. The results showed some issues were found and fixed, while other changes like increased speed and capacity were noticed by customers, raising questions about how to prevent customers noticing any differences after changes. It concludes that taking broad statements literally can be problematic, and that preventing all changes from being noticed may be
Turbo Mindmapping Your App
This document provides instructions for collaboratively mindmapping an application using the online tool mindmup.com. Participants are instructed to get into groups of three, with one person creating a real-time collaborative mindmap session for their application and inviting the other two participants. They are then instructed to collaboratively map out the functions, forms, fields, views, integrations, and other aspects of the application to document its functionality and coverage for testing purposes.
Teams and monoliths - Matthew Skelton - Velocity EU 2016
How to break apart a monolithic system safely without destroying your team - talk at Velocity Eu Amsterdam on 7 Nov 2016
You'll learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces.
http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/detail/52879
Courage, Curiosity, and Connection
This document discusses practical tools for navigating a changing world with courage, curiosity and connection. It outlines common responses to distress like trying to control situations, getting stuck ruminating, and lack of emotional management. It then presents newer tools like mindfulness, awareness, reducing distractions, finding intrinsic rewards, giving time to connect with others, and using checklists to standardize best practices and reduce mistakes. The overall message is that developing skills like managing emotions, creating space for reflection instead of just reaction, and cooperating with others can help one adapt successfully to changes.
Customer Interviews: Uncovering Product or Feature Ideas
This document provides tips for conducting effective customer interviews to uncover product or feature ideas. It outlines an approach with sections on opening, understanding problems, identifying solutions, and closing. Key recommendations include being curious, using open-ended questions, allowing silence, adopting the customer's language, and following up for clarification. The goal is to have a respectful conversation that helps prioritize opportunities and gather strategic insights to inform product development.
Selling UX
Presentation given at User Experience Edmonton meetup in January 2015. Gives an overview of how you can sell User Experience design methodologies to your boss or company. Talks about starting small, return on investment and not asking permission.
Games User Research by Valen
Games user research is conducted to validate that games are fun, easy to use, challenging, and provide engaging experiences. It explores how users interact with games rather than testing the users themselves. Common methods of games user research include focus groups, heuristic evaluations, interviews, questionnaires/surveys, and observational studies. These methods provide both qualitative and quantitative feedback on user experiences and can help identify issues for improvement early in the development process. The goal is to gather meaningful data to inform game design decisions while avoiding influencing users' responses.
How to Get My Paper Accepted at Top Software Engineering Conferences
This is a talk Sebastian Uchitel and I gave for students at the Latin-American School on Software Engineering
Creative thinking
This document discusses creativity from several perspectives including the creative person, process, product, and environment. It describes characteristics of creative individuals such as fluency, flexibility, and risk-taking. The creative process is explained as involving preparation, incubation, illumination, and verification. A creative product must be novel, meaningful, useful, and aesthetic. The creative environment should be stimulating, protective, and respect diverse ideas. Blocks to creativity like fear and conformity are also examined. Different learning and thinking styles are presented, as well as techniques to stimulate creativity like random word associations and morphological analysis.
Testers Guide to the Illusions of Unit Testing
One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. Being able to influence this type of testing in a positive manner is a skill that testers will need to get to grips with, as more companies start to embrace a model of lone testers in cross functional teams. The shift of focus from primarily the testing that testers do, to the testing that the team does, is a key shift in thinking and behaviour.
To facilitate this shift, I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers and help us realise what other layers of testing can cover most effectively. The last point is pertinent here, as knowing and guiding unit testing brings the role of integration, acceptance and exploratory testing into sharp focus.
This is a topic that has always intrigued me, having predominantly worked as a single tester on a team for the last five or so years. I reached out to the community with the question “What do testers believe about unit testing?” and received a lot of engagement. The good users of Twitter added another 50 or so illusions that testers might have about this layer of testing. I figured that based on that level of engagement, maybe this would make an interesting talk! It wasn’t only testers who responded too, suggesting that there might be some shared illusions about unit testing that are cross disciplinary.
The list alone is interesting but now I would like to share my analysis of it with you, focusing on:
* Recurring themes within the list and how to address them as a tester or developer.
* Particular illusions to look out for with examples from my recent past.
* A guide for developers to engage with testers on unit testing, and testers with developers.
What is design critique?
Short introduction to design critique process by Milovan Jovicic
www.practical-ux.com
twitter.com/violinar
Mbti stressors and coping
- The document discusses sources of stress and coping strategies for individuals with different personality preferences based on the Myers-Briggs Type Indicator (MBTI) dimensions of Extraversion/Introversion, Sensing/Intuition, Thinking/Feeling, and Judging/Perceiving.
- It outlines typical work stressors for each preference on each dimension, such as working alone causing stress for extraverts or focusing on possibilities causing stress for sensing types.
- It then provides tactics for coping with differences when an individual's preference does not align with their work group, such as extraverts planning private breaks or intuitives practicing brainstorming.
- The document concludes with guidance on delivering feedback in
Whose work is it anyway?
This presentation was for a workshop at the Institutional Web Management Workshop in 2005: http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2005/sessions/savory/
From the abstract:
Dealing with external agencies for your web needs can be a frustrating experience - for you, as well as for them. Whether you're dealing with institutional IT services or a third-party company, there are many common problems that can occur.
This workshop will take a look at the issues involved in getting the job done, including:
* how to efficiently specify your work
* how to pick an external company
* how to check on and measure progress
* how to sign off and quantify achievements
* liaising between external companies and internal IT services
* dealing with ongoing support and maintenance
Huib Schoots - Changing the context - eurostar -
This document discusses how a bank changed its software development methodology. It describes the bank's previous development context and challenges, including testing being treated as operating work and a lack of agile practices, passion, and documentation. The bank introduced context-driven testing approaches like rapid software testing and thinking skills over knowledge. It used agile practices like short iterations to help change the culture and build passion through learning communities. Over time the bank expanded its agile testing practices to include techniques like exploratory testing and test automation. Key factors in the success of the change included taking a step-by-step approach, cultivating passion, adapting practices to the context, building a learning community, persistence, and questioning assumptions.
Phase 3: Better ideas (Presentation at SalesForce 1-28-2015)
First came tools: programming languages, version control, testing, build automation and eventually continuous delivery. Somewhere along the tools curve, we began seeing that our process wasn't working and that we needed shorter, faster experimentation with better feedback cycles and communication, which produced Agile. Now that we have much better tools and processes (both of which continue to improve), what is the next big step in the evolution of software development, and development in general? Now that we've gotten pretty good at building things, I believe we need to get better at discovering good things to build. After a brief history of tools and processes, I will look at this need and explore how we must change our perspectives to address our next big challenge.
4 creative problem solving and decision making
This document discusses problem solving and decision making in management. It covers the six step decision making model which includes defining the problem, setting objectives, generating alternatives, analyzing alternatives, implementing decisions, and controlling decisions. It also discusses different decision making conditions, styles, types, techniques for generating alternatives, and models for evaluating alternatives. Group decision making can provide benefits like better quality decisions but also challenges like social loafing or groupthink.
How we daily manage and work in a dispersed company: Particular Software
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
On working in Particular
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
More Related Content
Viewers also liked
Ash_Winter_Tested_to_Death
The document discusses how too much testing can trap a team and product in a "death spiral". It describes a scenario where a team assembled to build a product but their testing strategy became ineffective and led to slower development and frustrated teams. The document then provides tips on how to avoid this, such as making sure unit tests actually test units, writing tests first, keeping dependencies loose, and evolving one's testing strategy so that testing serves the team rather than the other way around. It emphasizes that the goal is learning rather than failure.
Ash_Winter_Testing_Mobile_Apocalypse_Online
The document discusses testing in a mobile context. It begins with a poll about mobile device and testing experience. It then tells a story about realizing the need to test mobile applications. Mobile testing was behind the curve, with early experts, dodgy tools, and outsourcing common issues. However, mobile presents an opportunity for testing as the same principles of testing still apply. The document lists several "axioms" or truths of testing that still hold for mobile, such as testing being a human activity and oracles being fallible. It argues that complete testing is impossible given device fragmentation, but test cases do not equal testing. Testing mobile is a performance in itself. The document concludes that bugs cost businesses and mobile is probably the
Main Talk v1.1
Pokémon GO faced several quality issues after its initial release such as app freezing, server overload causing scaling problems, inaccurate GPS, and device fragmentation affecting the ability to catch Pokémon. The document discusses lessons learned around testing and quality from these issues, including the need for a balanced testing approach with different types of testing like functionality, performance, compatibility, and usability testing. It also emphasizes that quality is multifaceted and requires continuously adding and improving features while focusing on the core idea.
Ash_Winter-Forgotten-ility_V1
The document discusses various topics related to software testing including testability, logging, environments, and feedback. It provides tips such as getting to know operations pain points, logging what matters without bloat, understanding past code intent, and focusing more on test flow and feedback rather than number of environments or testability. The document ends with inviting questions.
NWEWT_Slides_Ash_Winter_04_2016
This document discusses regression testing for a project to stabilize and upgrade the underlying technology of a system while maintaining normal service. It raises questions about how to test that nothing has changed when everything is changing, and whether changes to responsiveness and capacity would still be noticeable to customers. The regression testing involved risk modeling sessions with stakeholders to understand the system, exploring the system to determine what to test, and testing from the user interface down to the unit level. The results showed some issues were found and fixed, while other changes like increased speed and capacity were noticed by customers, raising questions about how to prevent customers noticing any differences after changes. It concludes that taking broad statements literally can be problematic, and that preventing all changes from being noticed may be
Turbo Mindmapping Your App
This document provides instructions for collaboratively mindmapping an application using the online tool mindmup.com. Participants are instructed to get into groups of three, with one person creating a real-time collaborative mindmap session for their application and inviting the other two participants. They are then instructed to collaboratively map out the functions, forms, fields, views, integrations, and other aspects of the application to document its functionality and coverage for testing purposes.
Teams and monoliths - Matthew Skelton - Velocity EU 2016
How to break apart a monolithic system safely without destroying your team - talk at Velocity Eu Amsterdam on 7 Nov 2016
You'll learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces.
http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/detail/52879
Viewers also liked (7)
Teams and monoliths - Matthew Skelton - Velocity EU 2016
Teams and monoliths - Matthew Skelton - Velocity EU 2016
Similar to Ash_Winter-DEWT7_V1
Courage, Curiosity, and Connection
This document discusses practical tools for navigating a changing world with courage, curiosity and connection. It outlines common responses to distress like trying to control situations, getting stuck ruminating, and lack of emotional management. It then presents newer tools like mindfulness, awareness, reducing distractions, finding intrinsic rewards, giving time to connect with others, and using checklists to standardize best practices and reduce mistakes. The overall message is that developing skills like managing emotions, creating space for reflection instead of just reaction, and cooperating with others can help one adapt successfully to changes.
Customer Interviews: Uncovering Product or Feature Ideas
This document provides tips for conducting effective customer interviews to uncover product or feature ideas. It outlines an approach with sections on opening, understanding problems, identifying solutions, and closing. Key recommendations include being curious, using open-ended questions, allowing silence, adopting the customer's language, and following up for clarification. The goal is to have a respectful conversation that helps prioritize opportunities and gather strategic insights to inform product development.
Selling UX
Presentation given at User Experience Edmonton meetup in January 2015. Gives an overview of how you can sell User Experience design methodologies to your boss or company. Talks about starting small, return on investment and not asking permission.
Games User Research by Valen
Games user research is conducted to validate that games are fun, easy to use, challenging, and provide engaging experiences. It explores how users interact with games rather than testing the users themselves. Common methods of games user research include focus groups, heuristic evaluations, interviews, questionnaires/surveys, and observational studies. These methods provide both qualitative and quantitative feedback on user experiences and can help identify issues for improvement early in the development process. The goal is to gather meaningful data to inform game design decisions while avoiding influencing users' responses.
How to Get My Paper Accepted at Top Software Engineering Conferences
This is a talk Sebastian Uchitel and I gave for students at the Latin-American School on Software Engineering
Creative thinking
This document discusses creativity from several perspectives including the creative person, process, product, and environment. It describes characteristics of creative individuals such as fluency, flexibility, and risk-taking. The creative process is explained as involving preparation, incubation, illumination, and verification. A creative product must be novel, meaningful, useful, and aesthetic. The creative environment should be stimulating, protective, and respect diverse ideas. Blocks to creativity like fear and conformity are also examined. Different learning and thinking styles are presented, as well as techniques to stimulate creativity like random word associations and morphological analysis.
Testers Guide to the Illusions of Unit Testing
One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. Being able to influence this type of testing in a positive manner is a skill that testers will need to get to grips with, as more companies start to embrace a model of lone testers in cross functional teams. The shift of focus from primarily the testing that testers do, to the testing that the team does, is a key shift in thinking and behaviour.
To facilitate this shift, I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers and help us realise what other layers of testing can cover most effectively. The last point is pertinent here, as knowing and guiding unit testing brings the role of integration, acceptance and exploratory testing into sharp focus.
This is a topic that has always intrigued me, having predominantly worked as a single tester on a team for the last five or so years. I reached out to the community with the question “What do testers believe about unit testing?” and received a lot of engagement. The good users of Twitter added another 50 or so illusions that testers might have about this layer of testing. I figured that based on that level of engagement, maybe this would make an interesting talk! It wasn’t only testers who responded too, suggesting that there might be some shared illusions about unit testing that are cross disciplinary.
The list alone is interesting but now I would like to share my analysis of it with you, focusing on:
* Recurring themes within the list and how to address them as a tester or developer.
* Particular illusions to look out for with examples from my recent past.
* A guide for developers to engage with testers on unit testing, and testers with developers.
What is design critique?
Short introduction to design critique process by Milovan Jovicic
www.practical-ux.com
twitter.com/violinar
Mbti stressors and coping
- The document discusses sources of stress and coping strategies for individuals with different personality preferences based on the Myers-Briggs Type Indicator (MBTI) dimensions of Extraversion/Introversion, Sensing/Intuition, Thinking/Feeling, and Judging/Perceiving.
- It outlines typical work stressors for each preference on each dimension, such as working alone causing stress for extraverts or focusing on possibilities causing stress for sensing types.
- It then provides tactics for coping with differences when an individual's preference does not align with their work group, such as extraverts planning private breaks or intuitives practicing brainstorming.
- The document concludes with guidance on delivering feedback in
Whose work is it anyway?
This presentation was for a workshop at the Institutional Web Management Workshop in 2005: http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2005/sessions/savory/
From the abstract:
Dealing with external agencies for your web needs can be a frustrating experience - for you, as well as for them. Whether you're dealing with institutional IT services or a third-party company, there are many common problems that can occur.
This workshop will take a look at the issues involved in getting the job done, including:
* how to efficiently specify your work
* how to pick an external company
* how to check on and measure progress
* how to sign off and quantify achievements
* liaising between external companies and internal IT services
* dealing with ongoing support and maintenance
Huib Schoots - Changing the context - eurostar -
This document discusses how a bank changed its software development methodology. It describes the bank's previous development context and challenges, including testing being treated as operating work and a lack of agile practices, passion, and documentation. The bank introduced context-driven testing approaches like rapid software testing and thinking skills over knowledge. It used agile practices like short iterations to help change the culture and build passion through learning communities. Over time the bank expanded its agile testing practices to include techniques like exploratory testing and test automation. Key factors in the success of the change included taking a step-by-step approach, cultivating passion, adapting practices to the context, building a learning community, persistence, and questioning assumptions.
Phase 3: Better ideas (Presentation at SalesForce 1-28-2015)
First came tools: programming languages, version control, testing, build automation and eventually continuous delivery. Somewhere along the tools curve, we began seeing that our process wasn't working and that we needed shorter, faster experimentation with better feedback cycles and communication, which produced Agile. Now that we have much better tools and processes (both of which continue to improve), what is the next big step in the evolution of software development, and development in general? Now that we've gotten pretty good at building things, I believe we need to get better at discovering good things to build. After a brief history of tools and processes, I will look at this need and explore how we must change our perspectives to address our next big challenge.
4 creative problem solving and decision making
This document discusses problem solving and decision making in management. It covers the six step decision making model which includes defining the problem, setting objectives, generating alternatives, analyzing alternatives, implementing decisions, and controlling decisions. It also discusses different decision making conditions, styles, types, techniques for generating alternatives, and models for evaluating alternatives. Group decision making can provide benefits like better quality decisions but also challenges like social loafing or groupthink.
How we daily manage and work in a dispersed company: Particular Software
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
On working in Particular
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
Being the BEST we can be
Presentation given to Agile South Coast on the BEST View improvement model. Discussing why metrics are important, the format of the BEST View, how to create a BEST View and then leading the group through a practical.
FTC 2015-2016 Judging
This document provides information for judges at an FTC competition. It outlines the day from the perspective of judges and teams. It describes the process judges will go through, including team interviews and presentations, observing matches, deliberating on awards, and writing award scripts. Key awards are discussed like Inspire, Think, and Connect. It also provides resources for judges to learn about the game and engineering notebooks.
Building Resilience: Practical Tools for Keeping Your Head While Navigating a...
An updated version of a presentation I have given several times that offers some perspective on the challenges attorneys face in a dynamic business and practice environment. Hopefully you will find some practical nuggets for use in surviving- and perhaps thriving in- the practice of law
LSC Technology Initiative Grant Conference 2015 | Session Materials - Tools o...
LSC Technology Initiative Grant Conference 2015 | Session Materials - Tools o...Legal Services Corporation
This document discusses tools that can help people make choices. It describes how choices involve weighing multiple options and factors from different perspectives, which makes choices complex. An ideal choice management system would help people gather relevant information on their options and factors to consider, see how options compare on important factors, and get input from others. The document outlines features such systems could have and information people want when making choices. It argues we can make better choices with mindfulness and by managing choices as projects. Technology offers potential to develop new tools that support the choice-making process.Getting it right the first time March 2012
This document provides guidance on final steps for manuscript submission, including checking formatting requirements, verifying references, obtaining necessary permissions, and understanding the peer review and editorial decision processes. Key steps include double checking formatting, references, copyright forms, and permission for any copyrighted material. The peer review process typically takes 6-8 weeks and may result in an accept, reject, or revise decision from editors. Revisions should address reviewer comments to improve the manuscript.
Similar to Ash_Winter-DEWT7_V1 (20)
Customer Interviews: Uncovering Product or Feature Ideas
Customer Interviews: Uncovering Product or Feature Ideas
How to Get My Paper Accepted at Top Software Engineering Conferences
How to Get My Paper Accepted at Top Software Engineering Conferences
Phase 3: Better ideas (Presentation at SalesForce 1-28-2015)
Phase 3: Better ideas (Presentation at SalesForce 1-28-2015)
How we daily manage and work in a dispersed company: Particular Software
How we daily manage and work in a dispersed company: Particular Software
Building Resilience: Practical Tools for Keeping Your Head While Navigating a...
Building Resilience: Practical Tools for Keeping Your Head While Navigating a...
LSC Technology Initiative Grant Conference 2015 | Session Materials - Tools o...
LSC Technology Initiative Grant Conference 2015 | Session Materials - Tools o...
More from Ash Winter
Testability Advocacy Canvas
A coaching aid for those who want to help others achieve greater testability within their development team and wider organisation. Additionally can be used to track your own journey.
Testability Sales Pitch
Testability can make our testing lives so much better. But we need to sell it to those who can pay for the changes needed. Find out what they need (delivery, flow, stability, resilience), how it can be measured the use the handy examples below!
Architectural Testability Workshop for Test Academy Barcelona
Workshop delivered at Test Academy Barcelona on 30th January 2020. Including the Team Test for Testability, Testability Tactics, Testing Smells and the CODS Model.
Testability Squad Health Check
Based on the Spotify Squad Health Check and the 10 P's of Testability model by Robert Meaney, a means of seeing how your testable your products are.
Testability is Everyone's Responsibility
Testability is a first class concern for all disciplines within software development. There, I said it. No hedging, no nebulous phrasing, maybes or it depends.
Too often we labour under systems that are hard to test, manifesting themselves with frantic searches for more testers, lengthy acceptance test runs, fearful testing for regressions with a hopeful release at the end. Worst of all, it usually ends up with a project manager sat on the testers desk asking 'when will testing be done.' It's never done, it can only stop, just so you know.
Throughout my career, often the testability of a system has been deemed to be the testers concern. If something was hard to test, then it was the testers problem. However, the causes of low testability effect the activities of all disciplines, whether it be speed of feedback to developers or flow of value generating features for product managers.
During the talk, we will cover:
* How testability is a key advantage in building systems of ever increasing complexity.
* Why it's important for developers and operational stakeholders to build inherently testable systems.
* What testers can do to be catalysts for testability improvements.
The activity of testing is rarely the bottleneck, how testable your system is is your problem. Poor testability cannot be remedied by one discipline alone. It's for all of us to care about.
10 P's of Testability
Lightning talk based on the 10 P's of Testability by Robert Meaney, talk designed by Ash Winter. Make your testing life better by embrace testability as a team.
Making testability our mission
This is a call to action. On our cross functional teams and during our devops transformations we talk about how testing is for the whole team. Quality is everyone's responsibility. How much are we really doing to make this happen? Often we are working on systems that are hard to test for many reasons, but if we simply do more testing, write more automation we are neglecting what should be our main mission, advocating for increasing levels of testability, to truly get everyone involved in testing. We all have stories about how something is difficult to test, often never being tested or certainly left with the tester to figure it out. It doesn't have to be this way.
During my talk, I want to introduce a set of principles for testability engineering. A new way to approach our work as testers. These principles will tackle how we make our systems more observable, controllable, how we share knowledge across teams and improve the testability of our dependencies. I believe it is time to create a new focus on testability, as it affects everything we do, what our teams do and beyond into how value is delivered for customers.
I want you to take away from the talk:
* Why a focus on testability can multiply your effectiveness as a tester
* What the principles of testability engineering are and how to advocate for them
* How you can make iterative changes to what you do in order to embrace testability
New technology and complexity is rendering many software development techniques and paradigms obsolete at an increasing rate. We already exist in a space where an infinite number of tests of an array of different types can be performed. A new mission is needed, one that leverages the varied talents of all kinds of testers and culminates in a new focus on the exponential benefits that testability brings.
A Testers Guide to the Myths, Legends and Tales of Unit Testing
One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. Being able to influence this type of testing in a positive manner is a skill that testers will need to get to grips with, as more companies start to embrace a model of lone testers in cross functional teams. The shift of focus from primarily the testing that testers do, to the testing that the team does, is a key shift in thinking and behaviour.
To facilitate this shift, I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively. The last point is pertinent here, as knowing and guiding unit testing brings the role of integration, acceptance and exploratory testing into sharp focus.
Testing Below the Application
This document discusses testing infrastructure components that lie beneath applications. It defines infrastructure as the building blocks applications depend on, like hardware, virtualization, containers, and software. The author argues that testers should care about infrastructure testing because infrastructure problems are often found at the wrong level, and the product as a whole is symbiotic between applications and infrastructure. Various testing principles, examples, tactics, and tools are provided for both human/deterministic and machine/deterministic testing of infrastructure, as well as human/random and machine/random approaches.
Shift Testability
The document discusses the importance of testability in software development. It argues that focusing on testability, rather than just features, can lead to important benefits like reduced time to start testing, lower unplanned downtimes, and increased ability to observe and understand the entire system. The document advocates for approaches like enabling faster branching to devices for testing, more automation, and greater collaboration between development and operations teams to improve testability.
Part of the Pipeline
Nobody /really/ likes change, its human nature. Testers have a special relationship with changing tools and techniques, they change and we tend to flounder a little and end up very nervous about our place in the new world. Continuous delivery is one such circumstance, I see and speak to many testers really struggling. However, with a significant shift in outlook and a chunk of personal development, testers can excel in environments such as these. It’s time to start to get out in front of a changing world, rather than always battling to catch up.
I want to share my experience of adding value as a tester in a continuous delivery environment, what new technologies and techniques I've learned, using your Production environment as an oracle, advocating testability and most crucially, not overestimating what our testing can achieve. Testing is not the only form of feedback, it’s time to let go of some the aspects of testing we cling to.
Continuous delivery adds richness and variety to our role as testers. To me, it is a facilitator for the autonomy and respect that testers have craved for a long time, so let’s get involved...
Scroll Based Testing Strategy
No one paying attention to your test strategy? Its too long. More crucially, it has no scrolls. Here's a template for the agile testing quadrants, but with scrolls for extra unforgettability.
Coaching Model for Unrecognised Internal Models
This document proposes a coaching model to help testers recognize the testing models they already use intuitively and help them improve. The model focuses on using questioning rather than providing answers to guide testers to higher levels of thinking based on Bloom's Taxonomy. By getting testers to apply models through practice and reflection, and by iterating the model over time based on emergent needs, the coaching model aims to improve testing skills through collaborative learning.
Critical Thinking for Consultants-External
Critical thinking is important for testers as it helps them challenge assumptions, gather evidence to prove or disprove assumptions, and ask questions to improve their understanding. It is important for testers to think like a "Thinking Tester" by challenging beliefs, trying new things without fear of failure, seeing testing as an experiment to gather insights, and improving the product and project. When gathering data through questions, testers should understand stakeholders, consider different perspectives, and make it a collaborative and fun process. When analyzing data, testers should look at issues from different angles, understand limitations and biases, and determine root causes and risks. As consultants, testers need to apply critical thinking carefully and avoid antagonizing clients, while still facilitating
Ash Versus Consulting V1 - External
The document provides tips and advice for consulting based on the presenter's experience. Some of the key points covered include:
1) Consulting deals with human behavior and the variety that comes from people having different needs. Effective consulting requires questioning norms and focusing on root causes rather than symptoms.
2) As an agent working for clients, consultants have little direct power and must rely on building relationships and expertise. It is important to understand the different types of clients and their interests in advice.
3) A consultant's testing skills are more important than domain knowledge. Filling knowledge gaps for clients and adapting to their needs helps expand one's role.
More from Ash Winter (15)
Architectural Testability Workshop for Test Academy Barcelona
Architectural Testability Workshop for Test Academy Barcelona
A Testers Guide to the Myths, Legends and Tales of Unit Testing
A Testers Guide to the Myths, Legends and Tales of Unit Testing
Ash_Winter-DEWT7_V1
- 1. Ash Winter Short stuff here: @northern_tester Long stuff here: #DEWT
- 3. • “Reviewing testing capability independently of other aspects of an organisation is often like moving deckchairs on the Titanic*”
- 4. I was happy… • Reviewing • Interviewing • Strategising
- 5. Started seeing signs… • Few talked about testing • Structural Constraints • Too much WIP • No Product vision
- 6. A Teaching Hospital • Awesome ward dashboard product • Negative process == negative attitude • Testing as a symptom • Recommended balanced testing strategy
- 7. When I returned… • More (of our) consultants • Minor local testing improvements • Same pain existed
- 8. Next time… • Consider the system • Root causes • Options not solutions
- 9. Book Publisher • Great books, bad software • 3rd Parties • Wanted more consultants to solve their consulting problem
- 10. I recommended… • Deep system changes for external services… • Not more consultants… • Time to celebrate a job well done?
- 11. New directions… • Less sales that way • I quit • Deeper into systems thinking • Nomadic since
- 12. Questions
Editor's Notes
- Not lists - again
- But seriously, technical awareness is massive for testers to enhance testability. Knowing the strengths and weaknesses or a given technology potentially gives you insight into where enhanced testability will make the biggest difference.
- Environments do not equal testability – if you can’t administer one, having more will probably break you. Things are the way they are because they got that way. You cannot build a time machine. Be informed by the past but not a slave to it. Big testability scares those with cash and the team too, start small, ask small, but get a commitment to iterate. In your def of done for example.
- Questions? Yis?
- Gwen (please wave) and I are distilling some of this knowledge and experience (Fails) into the ‘Team Guide to Software Testability’ Its part of a wider series On other oft forgotten ilities like testability If anyone has a tale to tell, please give gwen or myself a holler, we’d love to hear from you