Modern Testing (MT)

The principles are not just theoryWhy Do We have MT Principles? modern testingTo make contrast with Traditional It's much easier to compete with any companyThanks to advancements in Continuous Delivery, the customer has much more options to choose fromSoftware is much easier to produceWHAT GOT US HERE WON"T GET AS THEREThey are based on Experience and observationTraditional testing is not only a cost but also delay MT is looking how to get "THERE"For customers, the switching cost has gone way downWhat it means to improve the business?Our priority is improving the business.Principle 1“You don’t get value from engineering effort until it is in customer hands”Get that mvp out with just enough quality to get feedback from customers Delta from Idea to deployments is rapid Boiling FrogsMTer needs to be seen as positive influenceNo one tests your product better than your customerCompanies are shipping fasterThere are bugs and bugs that customer cares about The GOALShort TermAdoption has to be gradual Being Force multiplierMoving test from cost center to cost benefit Long TermOur goal is to accelerate team adaptiblityReactionBrent went on tagnent and never finished his thought.its aboutthat doesn't mean "we have to go fast"???Making sure Principle are FollowedProvide Value to customer FrequentlyLean PrinciplesI.E World is changing and Tradiotnal Testing is not catching upWHATwhat in case of software houses? They don't have product per seWe accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system.Principle 2source: fast by managing the flow they create the bottleneck instead of resolving themIt’s important cause far to much of The TEST is reverse of thisBy focusing the MT Practitioner on identifying their role as acceleration” Don’t forget MT contextWHYLean ThinkingPhonix ProjectThe Goal: A Business Graphic NovelBooks to readFast feedback loop is critical in context of understanding what is quality Quality is problem solved to humans beingMt don’t want testing to be viewed as bottle neck This mantra is About completion and predictability not about value in order to accelerate you need mechanism to identify what value is and what the next bottleneckHOWBy Balancing fallacy of value with failure to launch“We are going to favour continuously adapting and improving above safety net presentation model.”Thou shall kill your safety netIf we are going to move quality upstream, we have to retrain developers without the safety netIt’s wrong that testers feel validated by the fact the developers don’t want to test.The tester can coach code correctness, but devs own it. Continuous improvement is about not being afraid of making mistakes but embracing them as a learning opportunity.Developers have to learn from their mistakes. Code correctnesYes it is. And it should be there. TESTERS aren't though.Isn’t unit testing a safety net too?WHAT Brent test harness lead to developers stopped using design patterns and ended doing code reviews. Cause automation would catch mistakes. - it’s terrible cause sloppy architecture can’t scale and is hard to maintain.ExampleSafty net is a problemTo remove safety net, you need also ensure minimal risk of getting harm and consequences of damage cannot be severeEvery time, *not* every half year, *not* every two weeks getting better all the timeActionable vs vanity Continuous improvementWe are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures.looking for improvement every time everywhere Principle 3reducing the waste.KaizenEfficiency vs productivity It’s a critical process change directly related to Quality WHYTester has to see the system as a whole because of this they can easily spot place for improvement Testers are well suited to drive continuous improvement Testers are specialists in asking questions Visibility By measuring Specialists is a bottleneck!Unified engineering Lots of small changes HOWTesters are well suited for driving retrosFrequent retrospective (only 1-3 action)Also starfish model for long term retrosMVP!A small vertical slices of architecture Master branch owned by the business they can release it whenever they wantQuality culture and leadership Testers need to stop being passiveis not Bugsis not code correctnesWhat is a higher quality app with no bugs but with few users, or app with lots of bugs but 100k users?is user reaction to what you built Qualityis about eliminating friction (enchanting positive, reducing negativities)Alan DefintionThe shared mindset that delivering high-quality software to the customer is our top priority and all our practices support this effortBren DefinitonIT is how do we build healthy, actives, not intuition based, useful view of users empathy within the organisation, caring about problems that users have principlesModern Testing (MT)Getting people closer to understanding the problems that users are facing, how software developers are geared to solve it and how to stay current. It is maturity model use with caution Quality cultureTesting breadth Quality test ownership shipWHATBug life cycle how do you use code corretnes toolsData analysis What it mature Quality cultureDevelopment approach Learn and improvement We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture.Principle 4adulthood exampleinfancy exampleadulthood exampleinfancy examplethis model were chosen because they are provenThink not only how to get it out but what’s next adulthood exampleinfancy exampleInstead we are force multiplierinfancy exampleadulthood exampleinfancy exampleadulthood exampleinfancy exampleadulthood exampleinfancy example“Hey, customer are you happier ?”Getting people closer to understanding the problems that users are facing, how software developers are geared to solve it and how to stay current. bug backlogoblivousdata centriczero bug policyfunctional testingits alan model - it doesn't has to work for youcontextual testingno learning happensad-hocTraditional testing is treated as safty netevery failure is oportunity to learnsuper small pathesTester are doing all the testingNo testeres needed, cause team gets itTesters are coachesAny time there is a change there is opportunityALL THE TIMETest Complete date It’s easier to "build quality In" instead of trying to test "quality in"Example: stabilization period just before releasegood quality pratices are praised suported and celebratedadulthood exampleretrospectives are for whiningBook leadership on the line Leadership support “Too many people think the quality is limited to testing “read book and oportunity is taken“If you test after test complete you will find bugs and that will cause us to miss the deadline"No i don't mean the toolADKAR Model AwarenessDesireKnowledgeAbiltyReinforcment we want to reduce risk in the ability to do thatwe want to understand and react to what they are doing,The reason is we want feedback from our customers more oftenWHYTo work in the way we want to function, to keep, retain and engage more users we need the quality culture to reacting to knowledge gained. From Risk minimalisationto move testingUnless the whole team has a common understanding of the problem trying to solve it is pointless Small Batches Knowledge sharing (software is knowledge works)Experiment Don’t make sweeping changes at once Try stuff -> fail -> learn Don’t try to change all at once Small changes, and don’t give upHOWReaping the band-aid works only when people are ready.After learning/rumbling period was over, the whole team mentioned they would not ever go back to old history: most time as QA, then as dev, now DS. I went to dev as a manager. Half of my dev were old school we dont test and half were ex Testers. 3 things I did to start: 0 bug backlog allowed , trained everyone on TDD , and lastly, bugs will not be fixed by the code the social pressure... teammates do not appreciate having to fix a bug in code *you* should have tested.... motivates correct behavior in long term.Brent example on slack TL:DR verionbugs will NOT be fixed by the code author? great way for knowledge sharing about code.Definition customer - it is a human who takes a dependency on what you are releasing, and that human can make decisions what quality is WHATHow do we help business to go fasterIt is not about preventing harm Customers don’t want software; they want the problem solved.It is seductive to believe “hey I am doing it forever I know what I am doing which is not often trueFeatures are developed cause we think they are cool, not because It solves problems. There is a risk in trust that QA belife in requirements doc and PMs , are solving a customer problem “They will use it”lead to answerQ: “What problem it solves? “Quite often asking teamsUsually, you need to decompose the want to Find the needWHYEven in B2B case delivering what customer want not what they need, may end with customer leaving and never returningNeed vs wantB2BMicrosoft KinWe believe that the customer is the only one capable to judge and evaluate the quality of our productPrinciple 5 of building wrong thing Q2:“What value does it bring? “ “They will use it”What about toxicty and hostilyEven better is to assign bug fixing to the peeps who approved the checkinand a clear non-negotiable expectation that the team works as a team combine with retrospective BothWho is customer then? Buissness or its customer?What is the case when I am delivering software to business?You need to be able to help your customers help their customers.Who is my customer ?Ask your selfEnd users who benefit from software you are producing.HOWUnless you are selling software for testers.Testers are not customers. Requirements from the business should be treated as hypothesis “Imagine you had that what would you do with it?” For each feature request you can ask question:Small changes!ergoLeaders ship is disappointing people at level they can absorb Validating hypotheses doesn’t mean pushing buggy software.WHATYour reaction time is important. What metrics meter we need to be able to knowWhat part of your product Data is critical to scale As long as you have good telemetry, you can find and fix bugs WHYRelaying on telemetry and customer data doesn’t mean it is using the customer as testers They care if theirs problem was solvedCustomer don’t care about test cases run, nor about a code coverage We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact.Principle 6Instrument the hell out of your software Use automation as a load generator and let the telemetry be a test oracle.Data tells you where to focus.HOWCheck episode 82tl:Dr data is importantOnce the product ship - look at the data and try to figure out which testing effort was wasted.It will help you count What is the ROI of current testing Which feature is barely used? Who values your product?Principle 7mitigateds the problem