Every model is wrong but might be useful.
- Stampede to mobile – technology on the go
- Big Data – comes with a pressure to understand performance testing and scalability
- Internet of Things
- Wearable computing – I personally haven’t looked into this area much yet, but it is very interesting as it often touches on things such as health and fitness
- Continuous Delivery – This seems to be the next big thing in terms of the software development lifecycle now that agile isn’t new anymore
- Analytics, Data Driven Development – Test Analytics – drive development through the data from new features in the production environment rather than develop based on assumptions
- No test teams but embedded testers – This is something we are attempting and recently it has worked well to make testing everyone’s responsibility in the scrum team
- Has Agile peaked?
- “Agile doesn’t work but being agile might” – Agile is not innovative anymore – rapid feedback is good, challenge is to be an agile organisation – the decision process needs to be agile in order for agile software development to work.
- Often agile doesn’t work because there is mostly a cultural business problem – when the business isnt agile, agile development may not work therefore Hybrid approaches often called wagile are most common.
- In software development we shouldn’t get stuck with agile processes but use the things that work – after all agile is a philosophy and not the goal so to speak
- Examples of this are dev in test, testers in development, testers everywhere
- The focus of test from the end to across the life cycle – test early and test often!
- Make testing an activity over a process.
- Redistributed testing – test requirements and stories by asking questions.
- BDD/Test driven
- Move testing effort to the beginning of the software life cycle – challenge requirements through examples – ie gherkin format – EDIT: I brought this up straight away with our scrum masters and am hoping to trial this in the next project we are going to be working on. Hopefully it will be beneficial to the whole team. I will report on the outcome of this trial as I found this really interesting and had not thought of applying BDD model without a BDD framework, as in without actually applying automated tests myself.
- This will result in test cases being applied as part of requirement defining.
- The idea of shift left is to save time at the end of the development process by investing testing effort into requirement and design elements
- Who does this? Depends on the company set up.
- “Continuous deployment is not the same as going live” – EDIT: My dev manager and one of the tech leads walked up as this slide was displayed and stated that this was the most sensible statement they had seen in connection with CD in a long time.
- CD not the same as agile
- agile and structured are very goal driven
- agile and continuous are a lot more autonomous
- structured and continuous both have very high process and high discipline
- Therefore there are parallels between all 3 patterns
- BUT there are many more patterns to consider and are 3 patterns enough? Hybrids were mentioned and these are just as valid to be considered.
- Is the right thing to do to adopt a hybrid approach that suits the context?
- The industry is seemingly moving from high process to DIY process. EDIT: I liked this a lot. Some may want to make a too small shoe fit but adapting processes to fit your context makes complete sense to me.
- “Software is a people problem not a technical problem”
- Agile is high process in the small and true agility is adaptation on the fly
Below the key bullet points I took from this.
- Do we need some flexible process
- The two extremes waterfall vs agile
- Strip logistics away
- ALL testing is exploratory
- Explore knowledge sources to build test models that inform our testing
- All testing is based on models
- models are predictions of reality or versions of reality
- models are innate, essential and human – we use them everywhere in everything all the time
- our brains make and use models all the time
Interestingly enough I went to a talk at Brighton Java that same evening and the developer doing the talk talked about their process and it went along similar tangents. Use hybrid models when defining your software development process. Even as much as having different ways of developing in different teams across the same whole development team. He stressed how it is not important necessarily which tools you use as long as you are comfortable and produce good code.
To come back to Paul’s webinar he then proposed his new model. The basics as I understood them being:
- exploration of sources to create models and as we explore we model and at some point we decide the models are useful enough to inform testing
- sometimes models are not adequate so we explore again
- judgement is used to make the decision (this can be experience in the job, with the technology or product)
- developers explore the same way but with a different goal in mind.
- Consequences of this new model?
- dev and testers have v similar exploration process
- TDD not about testing – a mechanism to implement testable code – design process
- BDD – is modelling using stories
- Testing vs Checking – check is a test that can be applied by a human or tool – but only humans can interpret
The webinar ends with a summary on how the capabilities of a tester may change as a result of such a model for testing.
- inquiring, modelling, predicting, challenging, informing, applying, etc
- shift left is more important than agile
- everyone can test
- end manual feature checking – free people to do the testing
- we test systems, not software
- we test early, we test often but it may not be called testing
- testing is about measuring achievement and not quality – align systems delivery with project goals and risks and you win
- testers do not own testing anymore – assurance through the lifecycle – support the test activities
- are devs and testers the same? v similar skills
- testing must align with development not compete with it or rescue it
- embed testing early
Overall I found this to be very interesting and want to try and apply some of these things. I actually already started questioning the stories before the sprint planning (if they are available) in a “given when then” format to see if this will help us define acceptance criteria early and more precisely.
Note: images were taking from the webinar as screenshots can be found in the link at the top.