I have a Dream that Testers extend their horizon and toolsets and not only test for functional correctness but make a step towards what developers need in order to fix critical issues. I am talking about architectural, scalability and performance metrics such as # of JS Files on a page, Page Size, # of SQL Statements, # of Log Messages Written.
If Testers start to capture this information as well and share it with their bug description I am sure it will both increase the value of testers as well as reduce the total time it takes to fix problems.
DevOps Transformation at Dynatrace and with Dynatrace
Tools That Make Dev, Test and Ops Hug Each Other
1. 1 @Dynatrace
- Of Tools That Make Dev, Test and Ops Hug each Other
- More on http://blog.dynatrace.com
- Dynatrace Free Trial: http://bit.ly/dttrial
Hosted by: Andreas Grabner - @grabnerandi
I have a Dream …
28. Mobile Landing Page of Super Bowl Ad
434 Resources in total on that page:
230 JPEGs, 75 PNGs, 50 GIFs, …
Total size of ~
20MB
http://apmblog.dynatrace.com/2014/01/31/technical-and-business-web-performance-tips-for-super-bowl-ad-landing-pages/
29. m.store.com redirects to www.store.com
ALL CSS and JS files are
redirected to the www domain
This is a lot of time “wasted”
especially on high latency mobile
connections
http://apmblog.dynatrace.com/2013/12/02/the-terrible-website-performance-mistakes-of-mobile-shopping-sites-in-2013/
35. Using Hibernate results in 4k+ SQL Statements to
display 3 items!
Hibernate
Executes 4k+
Statements
Individual
Execution VERY
FAST
But Total SUM
takes 6s
http://apmblog.dynatrace.com/2014/04/23/database-access-quality-metrics-for-your-continuous-delivery-pipeline/
47. •# Images
•# Redirects
•Size of Resources
•# SQL Executions
•# of SAME SQLs
•# Items per Page
•# AJAX per Page
Remember: Use Tools that provide these Metrics
•Time Spent in API
•# Calls into API
•# Functional Errors
•3rd Party calls
•# of Domains
•Total Size
55. Putting it into Test Automation
12 0 120ms
3 1 68ms
Build 20 testPurchase OK
testSearch OK
Build 17 testPurchase OK
testSearch OK
Build 18 testPurchase FAILED
testSearch OK
Build 19 testPurchase OK
testSearch OK
Build # Test Case Status # SQL # Excep CPU
12 0 120ms
3 1 68ms
12 5 60ms
3 1 68ms
75 0 230ms
3 1 68ms
Test Framework Results Architectural Data
We identified a regresesion
Problem solved
Exceptions probably reason for
failed tests
Problem fixed but now we have an
architectural regression
Problem fixed but now we have an
architectural regressionNow we have the functional and
architectural confidence
Let’s look behind the
scenes
56. And in your Pipeline
Commit Stage
• Compile
• Execute Unit Test
• Code Analysis
• Build installers
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual testing
• Key showcases
• Exploratory testing Release
Unit & Integration Tests
Functional Tests
Performance Tests
Production
Monitoring
Functional Tests
57. 57 @Dynatrace
Andreas Grabner
Free Tools @ http://bit.ly/dttrial
Follow me @grabnerandi
Email me agrabner@dynatrace.com
http://blog.dynatrace.com
Win a GPS Watch: http://apmchallenge.eu
Hinweis der Redaktion
I have a dream
To change the Status Quo that many development organizations still have
A lot of time developers and testers see the world from a DIFFERENT POINT of View
Nobody wants these bugs that testers are discovering all the time …
And afterwards CHASING developers with these bugs even though developers would much rather like to focus on building new cool things
Due to time constraints we also often end up with this
I have a dream where
Despite all bugs and time pressure, developers and testers still like each other
Actually getting to a situation where we give hugs instead of bugs
But how do we get there?
We should start by figuring out that we are all ONE TEAM working on a COMMON GOAL
And this should be easy – BECAUSE …
The newly developed and tested software just doesn’t work …
Latest release of our mobile app fails -> just as it happens last year 1 week before the football world cup
War Rooms and a lot of tension between all people involved
Bad publicity which jeopardizes all of our jobs in the future
In the current time a lot of the software we develop is publicly accessible and commented on and decides how success it will be …
Its very expensive and we cant develop as many new cool products as we need to keep our jobs
INTERESTINGLY – its always the same problems we see out there that cause this pain
That when Testers Level up and use similar tools and the right tools for analyzing problems within the application
You can easier get on the same table to discuss your findings
Blaming somebody is then based on facts/measures
SO – go start capturing and understanding the basics of these metrics
The War Room as all other crazy stuff is canceled …