Software Quality Assurance

 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 ...

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 ...

The idea behind behavior driven development is that testers are able to verify the product, prevent bugs and reduce cost. Because the product is built using coding practices that put testing upfront in the process.  This is supposed to accelerate deployment and maintain the quality of software products by allowing software developers engineers in test (SDETs) to build frameworks to verify the behavior defined by product owners and developed by software engineers.    So why is it that the more automated tests we build the more they fail, the more maintenance they have and ultimately creating noise in our quality metrics; reliability, maintainability, usability, security and so on:  Software engineers build software and are not particularly good at writing tests.  Product owners and manual testers do not read code they read natural language  The more the product evolves the more complex the testing framework the more likely the tests are going to require...

 Do you have a manager, leader, or coach?  Can you tell the difference and why does that matter? 

 Purpose  Autonomy  Learning 

 I heard about this a couple years ago, (see link below) and it has changed the way I think about my QA environments.  https://www.youtube.com/watch?v=zWgq6sd1Ols Which do you prefer and/or are you doing both?  What tools are you using to build it out?  Docker Kubernetes  Tugboat   

 Simply put, it is the right thing to do. I also has the added benefit of quality. 

 Engineers are not great testers QA is naturally collaborative; we can't work if nothing is engineered  Accessibility