Monday, March 28, 2022

Exploratory testing

 BUG hall of Fame !!! 

Got to create my own 

Checked and explored 

TDD 

All nets have holes 

Your money is no good hear - payment flow SAAS

Go ahead and grant those privileges 

Role based - all roles and no roles 

Can edit the role they wanted - SU 

Is not done only manually - similar to telephone support system 


Only be found via exploratory - key QA attribute 


Is methodical - sessions are a day to half a day 


What is the charter to execute and observe 

What can I vary 

Mini experiments 

Observe 

Debrief - capture the lessons learned 


Charter - can come from anywhere - just before you start to Team effort 

Target 

Resources 

Information 

Using suppot 

What can I vary 

Change directly or cause to be changed 


Does not tie back to a written requirement - 


Mar rover bug

Not size of date but rather the number of files 

Tell rover to delete 

Variable are fractal ….wow, I mean WOW!


What or where is the most risk 


Play with boundaries and constraints 

Times too late or to early  


Strings tool long too short 


Experiment w/ sequence 


Any time you can say "while", you have found a state 


The real world is WAY more complicated than the real world 

While state of updating - 

Observe 

Use all your resources 

If something goes wrong how would I know 

File bugs have conversations - value in the information is taking actions on that information 


AS a pair or pare :D 

Exploring is learning 

When and who? 

Everyone and always 

This is a tester or QA mindset 

Giving us the language 


Proves that a QA's job is NEVER done 

Explore IT from pragmatic bookshelf  


Risk or Fear: what drivers your testing....


Great meetup on what drives testing...

 https://www.meetup.com/ministry-of-testing-santa-barbara/events/284315114/


Details

Come join virtually and we'll meet, mingle and watch a recording of Jenna Charlton giving her session: Risk or Fear - What Drives Your Testing? together and after chat and discuss.

This session dives into using risk to approach test coverage:

What motivates your test coverage decisions? Fear or Risk?

Many teams are realizing after implementing a risk-based strategy, they continue to test from a place of fear as opposed to calculated risk. Others never reassess or renegotiate risk as their application matures. As the application under test matures, so must your strategy.
Key takeaways:

- Discernment: Test decisions, what is your real motivator?
- Embracing the concept, "What is good enough quality?"
- Reassessing risk by integrating new data
- How to overcome bias created by fear and previous failures

All are welcome, so lets come together and support and learn together!

My notes 

Treating QA as a optimization not a gate keeper 


Value add w/o fear 


Testing as an empathy exercise 

Watch devs work 

Have devs watch QA work 


What are people scared of because of change? 


Pat on the head QA 


Get my Team to think in this way….


Scoring risk ties into Agile 

Quantify risk 

Show me the math 

History of issues 

Complexity 

What did we learn? From re-evaluating risk 

What test cases have what level of risk ? 

Automation is something that should have low risk 

Understanding where the risk is and focusing efforts gives QA back time to focus on high impact work 

How to apply human capital 


Good enough is OK… 

Done is the goal; perfection is a myth 


How are re looking at risk 

Every 3 months 

Automate the repeatable 

People solve problems 


https://www.youtube.com/watch?v=VL-_pnICmGY

https://app.riskstormingonline.com/