4. Industrialization
• Testing and Software development in general must move from being a craft to
being an engineering science
• The analogy is that software should be built and tested just like a bridge, in that
there is a way to build a bridge, and even if there are differences between
bridges, there are even more similarities
• When an action is performed, as long as the operator meets competence
requirements, the output should be the same independent of operator
5. Smart Automation & Testability
• It is not possible to do good automation without a software that is designed for
being automatically tested
• The value of a static test cases that is executed automatically over and over
again is not high, even though it still has value
• There needs to be support in software for creating more dynamic test cases
which retain their value over time and evolves – this requires both better design
of production code, and better design of test cases
• There also needs to be standardized and easier ways to write unit tests
• Automatic unit test design
• Model based testing
6. Customer Feedback
• With software releases becoming more and more frequent, the time for testing
decreases, and the possibility to get feedback from the customer improves
• Feedback mechanisms must be in place to utilize the vast information flow that
the customers generate when they use the products
• There must be a way to quickly analyze and take actions based on the feedback
from the customers to get the fixes in to the next release
• Imagine if a new product software is released each week – ideally even a critical
error that is missed by test will be fixed within a week as soon as customers find
it
• Critical systems will of course be handled differently in that they cannot release
hazardous software even if they can fix it within a week, but will still benefit
from user feedback
7. Competence Shift
• There will be many tester roles in the future, but in general testers will move
closer towards development
• Better understanding of automation and testability design
• Testers that mimic actual users will to some extent be replaced by actual user
feedback and quick software releases
• Even testers who work with end-to-end testing will have major tool focus to
empower their testing
8. Tool Supported Testing
• All testing will be tool supported in one way or another
• Using the software as an uninformed user is not effective or efficient
• Real time information on what is going on in the software system will
continuously be provided to the tester to help steer the testing in the right
direction
• Risk analysis will be tool supported to a much higher extent than is today
• All setup, prerequisites and reporting for testing should be automated – the
tester should spend time testing not administrating
• Designing automated test cases will also be tool supported so that the tester is
not required to have the same extensive knowledge about software
development as an actual developer
10. Reference
• None of these ideas are new
• James Whittaker, Alan Page, Alberto Savoia, Bj Rollison and many others have
influenced and/or formulated these thoughts before
