# Shared lecture notes on the QASD visiting lecture 6.10. by Anssi Lehtelä

**Topic: Stuff we do to make quality products**
by Anssi Lehtelä (Visma Solutions)

# Intro
* Bugs vs quality => starting point by Anssi
* Lack of bugs => a good product?
* Some of the topics
* Continuous delivery
* Teamwork
* Test automation
* Understanding the context
* Scream testing
* Exploratory testing

# Understanding the context/purpose

Three amigos => business, development, & testing present

Impact mapping by Gojko Adzic

=> Alright, everyone, now it's your turn to continue below =>

Shared understanding that comes from the planning may be more important than the plan itself

# Continuous delivery

*Fig. CI process vs other, more "traditional" processes*

When testing is only done at the end of the project, testing turns into "fixing" and actual testing is not performed

Frequent deployments are the way to ensure the quality is built into the product

"Quality needs to be incremental process"

https://continuousdelivery.com/

# Test automation

Safety net, prevents regressions (breaking existing features)

A lot of bad test automation, it can be misused

Quick feedback enables faster development

Test Driven Development (TDD) means that unit test cases will be written first and the code after that to test that everything works all the time and you don't break something when adding new code.

Test automation is one of continuous delivery activities, which ensures constant and fast feedbacks to developers during development cycle.

Some automated steps in CI
* Static analysis
* Unit tests (functional tests)
* Security testing

AI Cucumber Test (https://cucumber.io/): Feature, Background, Scenario, Scenario,.. - test structure.
Cucumber tests will be run trough BrowserStack Automate (https://www.browserstack.com/ paid service). Manual exploratory testing can also be done via BrowserStack - a web app can be tested in various browsers.

Detectify for automated security scans & bounty program (find security problem and report it for reward)

If you ask to review you code for...
1000 lines -> No issues found
50 lines -> 5 issues found
-> Keep your commits small (if you want them reviewed carefully)

Should happen with the team! Team should own this together.

# Exploratory testing

Exploratory testing is also called manual testing, which can be a misleading term.

Focuses on usability and on the value

Requires imagination

Finding the happy flow and making sure it works vs breaking things

Try crashing services should not be done in production and performed in a very careful manner, e.g. finding performance issues (1GB Attachment to invoice) - overall there are a lot of possibilities but should not be considered as the most valuable bug to find.

Priorities can be set using cheat sheets e.g. https://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf
In a nutshell: only crash the service if it is necessary and if it provides value. Also taking notes can be a very helpful tool during exploratory testing.

James Bach's Satisfice, contains resources like Tester’s Syllabus:
https://www.satisfice.com/resources

# Scream testing

aka a/b testing, piloting, monitoring
Scream testing basically means to wait "till it screams". Demonstrated on the example of Graylog:
GrayLog (https://www.graylog.org/) - one of the tools for monitoring system logs.

Graylog has nice statistics and dashboard features for monitoring.
Therefore it allows to analyze for potential bugs during production.
DataDog (https://www.datadoghq.com/) - Unified monitoring for metrics, traces, & logs

# Team work

Super important part of building a high quality products/services.

Pair, or even group programming ("mob programming") is possible (done at Visma)

Discussing about the topic: Why? How? Plan what to do. Plan how to test it.

Ideology behind the collaboration:
*"Each bigger task or project shall be done within a work group, becausee we believe that in the long run it is throught teamwork that we can deliver fast and with good quality every time"*


Other option for tracking bugs/issue is to make a decision should we fix it directly when those are found or not. Toyota's total quality management: problem is a problem that should stop the development.

# Tips

* Don't do exploratory testing in production if you aim to crash the system :D And only do it if it's valuable

* Fix the problems as you notice them (rather right away than later)

Testing cheat sheet:
https://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf

Resource on testing:
https://www.satisfice.com/resources

### Other, random (offtopic) notes
Thanks for all contributors! You have received a point in Moodle.

Visma uses Ruby, Codereviews, Paircoding
Ruby linter is called Rubocop :D