Please enable JavaScript.
Coggle requires JavaScript to display documents.
All B361 stakeholders can sleep well at any given night (We catch bugs…
All
B361 stakeholders can sleep well at
any
given night
We know before the releases that there won't be any rollback
#
We know how our customers use the system
We visit our biggest customers regularly
We watch them using the product
We collect feedback through questionnares
We have the biggest customer's settings cloned
We have step-by-step use case guides for our VIP customers based on that
New customers get templates from us for the onboarding
We teach our customers on how to best use b360
On youtube
TAM teaches them
We have interactive onboarding
From time-to-time we track the used features
We run SQL scripts to track these
Based on the output we create test cases
We have great load/performance tests
There are no security breaches in our system
We catch bugs during development
We test each of the user stories carefully
Stories are tested with capable developers
Our developers have great domain knowledge
We continouosly provide them training
Our developers have QA mindset
We provide them QA trainings
Developers cross-test each other's work
Our developers can ask for QA support for the testing
Our JIRA stories are very-well defined
Summary shows what we are trying to achieve
Acceptance criteria shows the most important test scenarios
Part of the acceptance tests are the UI plans.
They contain "affected areas"
Changes can not be merged without testing all the changes
Gated check-in can contain all the tests we have
Slow test cases (like E2E) are heavily parallelized
We use 3rd party infrastructure for testing
They can be ran independently
Using separate accounts
We create them on the fly
Or we have test account pool, that keeps accounts clean
Test cases clean up after themselves
Even if there is a failure, we run all the test cases, so that we know all the failures
We document Manual test cases
Developers see early (before beginning to work on a story) what steps will be tested
Teams (including PO) figure out the test cases and document them BEFORE starting to work on the feature with the support of the QA
QA writes test cases, that are accessible to the developers before starting to work on the story
We have a trusted daily feedback loop
We can trust in our test cases
We do PR-s on the test cases as well
We can trust in test run results
They are stable even if they are being run in parallel
If a test case fails, we retest them automatically
Report contains failed test case runs, but if retesting is green, we consider the test case green
#
Test cases themselves cannot be flaky in the "develop"
New tests are ran multiple times before merging on a common environment
We recheck all the failed test case runs, even the ones resulting in green test run
We know our tests are valuable
#
They test only a single thing only
We run our automation on a daily basis
We test the system thoroughly (alaposan! :D)
We also develop unhappy test cases
Create test cases for error messages
We check if the system degrades gracefully
We cover functionality on different levels
We enable developers to write test cases on all levels
Test cases are the result of a teamwork
#
#
We have a continouos integration environment
We have a high test coverage
We show the results to the PO
Our services are available 7/24
Our features are always available for use
We validate them with regression tests before releasing them
80% automation
Our Scrum teams help us improving the coverage
We retired our biggest legacy, .NET client
We are creating tests retroatively
20% manual
We test only complex flows, that are too difficult to automate
Teams think about it before trying to implement test cases.
We test manually the user-critical flows.
We have a list of the basic functionalities.
We do quick-UI checks as well.
#
Fixed bugs are retested during regression.
We can simply generate a report for the list of fixed bugs for any given version
Fix Version / Label / Issue type?
When creating Regression plan, we schedule them.
We do new feature happy flows.
We have Acceptance tests for the stories.
We do phased releases
We can select only the affected and active customers for release
#
We have a selection process in place
If phased release may affect non-upgraded customers, we may move them to a separate server
In order to get rid of the possible DB issues
We have a plan for rolling out phased releases
We carefully plan and track all the in-progress phased releases
Our releases do not cause any outages
We can release in a way that our customers worst case have to relogin
We can move accounts without stopping them
We can notify users to reload the application, as there's a new version
We release when our customers don't use the product
Any concerns you have, we answer immediately
TAM
Professional services :
feedback@email
Our datacenter moves do not cause any service outages
Our uptime is 99.??%
We track it
Our customers know what does uptime mean for us
Our systems are easy to use
Created by:
Agota
Misi
Bence
Peti
Sosi
Andy
Quotes
"I've learned a lot, and now I see how the dots are connected" / Bence /
"I will have an atomic bomb in my hands out of this plan!" / Sosi /
Extras:
E2E tests not for story, but feature levels
Exploratory testing
Logging, anomaly detection