Testability is Everyone's Responsibility
•Descargar como PPTX, PDF•
1 recomendación•192 vistas
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.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a Testability is Everyone's Responsibility
Similar a Testability is Everyone's Responsibility (20)
Más de Ash Winter
Más de Ash Winter (20)
Último
Último (20)
Testability is Everyone's Responsibility
- 2. Your system is hard to test @northern_tester Your testers are at the sharp end (And you should feel bad about it) (I don’t know you but its true) #expandconf
- 3. Lets drop some truth bombs @northern_tester #expandconf
- 4. If its hard to test… …it won’t get tested …the tester will test it …it won’t work …you will drive your ops people mad …your team testing culture will be a distant dream @northern_tester #expandconf
- 5. Its about time that testability became everyone’s responsibility @northern_tester #expandconf
- 6. Coverage… • Testability smells • Testable architecture • Power of operability • Maintaining the mission • Polished sales pitch @northern_tester #expandconf
- 7. What is that subtle yet over powering smell… @northern_tester Release Management Theatre Mono strategies Fear of change Teams looking for more testers Too many user interface tests Valuable scenarios not tested Lack of resilience testing “Sunny” days only Cluttered logging with no insights Excessive test repetition Issues hard to isolate and debug Tests that don’t die Lengthy build times Too many persistent environments Environments no one cares about Inanimate documentation Customer hand holding Poor relations with Ops Long lists of deferred bugs Hard to test dependencies Wrangling over scale 95th Percentile? Tester turnover #expandconf
- 8. That’ll be your system architecture… @northern_tester (And your team structures…) No big deal #expandconf
- 9. Get the right people in the room… @northern_tester #expandconf
- 10. The rooms where architectural decisions are made… @northern_tester #expandconf
- 11. But what do you do when you get in the room… @northern_tester #expandconf
- 12. 20 000 transactions per second @northern_tester #expandconf
- 14. @northern_tester #expandconf Operability Operability Operability Operability Logs to events Retired unused API’s New services for high throughput API’s Circuit breakers Throttling Tracing ID’s Actionable alerts Architectural Decision Records Feature Toggle Dashboard
- 15. Operability matters… @northern_tester Thanks to Matthew Skelton for this awesome template and research #expandconf
- 16. After some hard work… • A useful run book • Isolatable services for load testing • Less services to melt our brains • Ask questions of the system • Closer to production • More sleep, less stress • Better testing experience! @northern_tester #expandconf
- 29. This is all very nice but sales… @northern_tester https://blackswanfarming.com/cost-of-delay/ https://martinfowler.com/bliki/TechnicalDebtQuadrant.html • Predictable • Known quality • Testing debt • Tests you trust #expandconf
- 30. Sounds like a testers problem… @northern_tester • Fast feedback • Less context switching • Customers • Claims • Build the right thing • Resilience • Configuration • Observability • Less toil https://en.wikipedia.org/wiki/Margaret_Ha milton_(software_engineer) https://twitter.com/mipsytipsyhttps://twitter.com/lissijean #expandconf
- 31. It affects us all, especially our friends in operations. Testability makes software better. It is a collective responsibility. Testers are often seen as responsible for testability. Not alone. They need advocates. @northern_tester #expandconf
- 32. Thank you for your attention. http://leanpub.com/s oftwaretestability @northern_tester #expandconf
Notas del editor
- Some people say this, but it is slightly less vague than quality is everyone’s responsibility. Describes what a bit better and who might be doing it. Still hard to aim at while building hard to test systems.
- We’ve all worked on hard to test systems. If you think you haven’t then you are or were in such denial that you were a captive reliant on their captor. Stockholm syndrome. So, lets drop some truth bombs on our candy asses.
- Simply won’t get tested - here’s a secret for you. IF IT HASN’T BEEN TESTED IT DOESN’T WORK, new stuff rarely does. You the tester will be burdened with it. Volunteers will be hard to find. Automation will target the areas that don’t break, or will just cover new stuff, rather than old fragile areas. Even if you can do performance and load testing, it will be brittle, late and on inappropriate environments. Probably mislead you more than lead you. One of the key indicators of poor testability is lack of diversity within your testing. IMPORTANT - your poor ops people. Sys Admin, DBA’s and App Support will be driven mad by your application. Hard to test means hard to operate in live, where it matters. Finally - your team will be divided by this system that you all hate, right down the lines of role. Unchecked, this will persist FOREVER.
- Im not sure testing is really working out that well. We always seem to be in the middle of existential angst. Agile, DevOps, what shall we fail to embrace next? Lets change our footing.
- Reverse inspiration Core concepts Testability Engineering Its about YOU
- 2000 bugs in 2 years Communicated through tickets Longs test cycles against builds on long lived environments Mastered weirdly named tooling “Quality Centre” Left with a weird feeling - we did tons of testing, but we never got any faster, no one got what they wanted…
- Superset as in, other ililities are contained within it Which makes it ethereal at times which is part of its problem, it his hard to describe but makes the world better. For me this is true of a lot of aspects of testing, where we co-opt other technologies to enhance our testing. One of the things that makes testability so intuitive as a direction for the craft of testing. But also makes it important, it is telling us to focus on the whole system, rather than making local optimisations. Let’s make this a bit more real, by talking about 4 core ilities of testability. In no particular order though.
- Observability allows us to understand the system as it actually is - we can explore and ask questions of the system Observability determines what problems we can detect and how we evaluate if they are problems observability tools and techniques are the lens to view and filter that information. Tracing through a micro service architecture is a great example of this. Seeing the whole transaction throughout a set of dependent services. Great for seeing effects and side effects of a behaviour.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Reverse inspiration Core concepts Testability Engineering Its about YOU
- The more complex the system, the harder it is to test. Sounds intuitive right? The harder it is to reason around a system, how many technology types, transport mechanisms, input, outputs, dependencies it has, the more problems can occur. Lots and lots of problems means lots of time spent testing, clarifying, checking, asking, exploring, re-exploring. You get the picture.
- ## People The people in our team possess the mindset, skill set & knowledge to do great testing and they are aligned in their pursuit of a shared quality goal. ### Mindset Each member of the team feels motivated, fulfilled and is focused on delivering a high-quality product. Team members understand that quality is a whole team responsibility, appreciate that testing provides critically valuable feedback, strive to facilitate better testing, shorten the feedback loop and endeavour to prevent defects over finding them. ### Skillset Each member of the team has the skills and experience necessary to perform risk analysis, exploratory testing, write unit, integration and end to end tests. The team also has access to a testing specialist with deep testing expertise should their expertise be required. ### Knowledge Each member of the team either has adequate knowledge or has a means of accessing adequate knowledge of the problem domain, technical domain, testing tools and techniques required to do great testing. ### Alignment No one individual on the team is responsible for quality, the team has a shared vision of quality and work together to build quality in, facilitate better testing and to improve the team's way of working.
- ## Philosophy The philosophy of our team encourages whole team responsibility for quality while building trusting, collaborative relationships across team roles, the business and with the customer. ### Whole team responsibility for quality All team members actively identify and mitigate risks, consider testability during architectural discussions, collaborate on testing, prioritise the investigation and resolution of automation failures over new feature work and distil as much learning as possible from customer impacting issues. ### Collaborative relationships Team members work really closely making changes to the code to facilitate better testing as well as helping each other complete testing and automation tasks. Each team member talks regularly with people from the wider business and the customer in order to gain a better understanding of the stakeholders' needs.
- ## Product The product is designed to facilitate great exploratory testing and automation at every level of the product. ### Designed to facilitate exploratory testing Team members can quickly and easily set-up whichever test scenarios they wish to explore and evaluate whether or not the system is behaving as desired. ### Designed to facilitate automation Team members can write fast, simple and reliable automation that is targeted at the appropriate level. The majority of the automation is written at unit and integration level with only a bare minimum written at end to end level.
- ## Process The process helps the team recognise risk, decompose work into small testable chunks, and discourages the accumulation of testing debt while promoteing working at a sustainable pace. ### Recognise risk Team members are encouraged to identify risks as early as possible so that they may be mitigated in the most appropriate manner. ### Small testable chunks The team works together to create a shared understanding of what needs to be built and slices the work into small testable chunks with clearly defined acceptance criteria. ### Testing debt Team members work together to ensure all the necessary testing activities are completed and findings are addressed before moving onto the next iteration. ### Sustainable pace The team works together to ensure each chunk of work is adequately tested before moving onto new work. Overtime and out of hours work is actively discouraged.
- ## Project The team is provided with the time, resources, space and autonomy to do great testing. ### Time The team is provided with the freedom required to think, prepare and perform all the testing activities deemed necessary to mitigate the risks identified without being put under time pressure or working outside of normal working hours. ### Resources The team has access to the information, test data, tooling, infrastructure, training and skills necessary to achieve their testing goals. ### Space The team is provided with the space to focus on completing their testing tasks without too many distractions and minimal context switching. ### Autonomy The team is given the autonomy to find their own solutions to testing challenges.
- ## Problem The team has a deep understanding of the problem the product solves for their customer and actively identifies, analyses and mitigates risk. ### Customer problem Each team member is constantly improving their understanding of who the customer is, what the customer values, their challenges, needs and goals. This knowledge enables team members to better recognise potential threats to the value of the solution. ### Risk Team members have a deep understanding of their context which allows them to analyse business and technical risk, consider the potential impact of failure and mitigate it with the most appropriate techniques.
- ## Pipeline The team's pipeline provides fast, trustworthy and accessible feedback on every change as it moves through each environment towards production. ### Feedback The team members are confident that the various forms of automated testing provide comprehensive test coverage, detect functional regressions and provide feedback that's reliable, timely and actionable. ### Environment The team can deploy a change into a production-like environment on demand and can safely perform a range of testing activities including resiliency testing, performance testing, exploratory testing, and so on.
- ## Productivity The team considers and applies the appropriate blend of testing to facilitate continuous feedback and unearth important problems as quickly as possible. ### An appropriate blend of testing The team works together to identify risk and take a holistic approach to mitigating risk using the appropriate combination of pre-production and production testing. The team uses a blend of targeted unit, integration, end to end, exploratory and nonfunctional testing to find problems as quickly as possible. These approaches are supplemented with the appropriate level of logging, monitoring, alerting and observability in production. ### Continuous feedback The team breaks their work down into tiny testable chunks, pairs or mobs on coding, automation and testing tasks and seeks stakeholder feedback as early as possible.
- ## Production Issues The team has very few customer impacting issues but when they do occur the team can very quickly recover. ### Customer impacting issues The team uses an effective test strategy that ensures the majority of issues are either prevented or detected before escaping into production. This means that the team spends very little time firefighting customer impacting issues. ### Recovery The team has built the system with monitoring and alerting that allows team members to detect production issues before they impact the customer. When issues are detected adequate logging, observability and reversibility is in place to quickly debug and remediate.
- ## Proactivity The team proactively seeks to continuously improve their test approach, learn from their mistakes and experiment with new tools and techniques. ### Continuously improve The whole team regularly reflects on how effective their test approach is, discussing activities that are valuable, wasteful or need improvement and taking action where necessary. ### Learn from their mistakes The whole team reviews each costly mistake in an effort to distill as much learning as possible, to identify and address gaps in the team's testing efforts. ### Experiment Each team member is encouraged to learn about testing tools, techniques and is supported in experimenting with new ideas that they believe may benefit the team.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- Controllability determines the dept and breath of our testing efforts - how deep you can go while still knowing what breadth you have covered. Without this you can go down the rabbit hole and miss the bigger picture. Without control testing is pushed later and later, Controllability determines what scenarios we can exercise - whether it be setting test data to the right state or ensuring a dependency returns a specific response.
- You will find the principles of testability engineering here