AI and QA

 This is not a pitch to replace QA with AI; however I do believe that you're QA is going to be so much better working alongside an AI. 

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/

Why BDD isn't working and why SDD is solving the problem?

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 maintenance, overhead and refactoring. 

Enter Specification Driven Development, (SDD), this methodology encompasses the development style working for your Team; BDD, TDD, spaghetti code, get stuff done development by any means necessary. SDD, is changing the way we think and execute development and testing and is only possible with the evolution of machine learning and artificial intelligence in the space of quality and test engineering. 

Executing tests validates the expected behavior and when that behavior changes based on a new specification the test case changes so we test again. And if we’ve broken a test in our automation framework we have to code again. With SDD the execution of the testing IS what is building out the test suite for test automation and simultaneously validating the product specification all without building out an environment to have a test automation framework run where those automated tests typically won’t even be refactored until after the delivery of the new specification. 

I cannot count the number of times I’ve been asked to test a deliverable but don’t have any documentation or just a couple words in a ticket, much less a test that is written by the engineer as a part of their BDD, not the unit test but an actual test that describes the required behavior for success. 

There is no guesswork when using SDD, there is turning on the testing tool and starting your test, no need to stand up an environment, automation framework, create meetings to collaborate with business analysts, product owners and engineers to ensure that we’re automating the correct tests. Instead just start testing and reporting on the results of those tests based on the specification delivered. 

In SDD product owners can read a test case just as easily as the tester or software developer, since they are written in a natural language and run as steps as the user would. This test methodology is agnostic to the development methodology. 

Complex end to end tests are created as a manual tester validates the specification. In years past this was only accomplished by a quality analyst that ran the manual tests to work with an SDET to build automation around the parts of the end to end rarely covering a full end to end via test automation.  

In SDD testers are able to verify the product, prevent bugs and reduce cost, faster Because the product is built as a software engineer does what they do best and build great software. SDD accelerates deployment and maintains the quality of our software products by allowing anyone to be a tester not just an SDET and a QA engineer because the tests are written in natural language and run the same way, (go here click here, see result).  

• Testing is agnostic to the engineering practice used to develop the product

• The test can be read by anyone 

• No need for a complex environments and frameworks to support 

Specification driven development is changing the why we think about delivering a product and the testing that goes with that. What happens when the product owner changes their product? In BDD all or the majority of the test cases are likely no longer useful until a refactor can take place so we end up with a lot of red, knowing that it will never go green. In SDD, your tester runs through the product re-writing the test automation as they manually test without a huge load on refactoring test code or changing the framework to match the ever changing product specifications. 

With ML and AI taking over so many other areas in the software industry this is the natural next step in quality; having people that are good at what they do best, solving problems and allow the tools and software to do the rest. 

Manager/coach/leader...what the differences and why you should know?

 Do you have a manager, leader, or coach? 

Can you tell the difference and why does that matter? 

What Motivates you?

 Purpose 

Autonomy 

Learning 

Cattle versa Pets

 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