Turning Developers into Testers
•Download as PPTX, PDF•
1 like•495 views
by Dave Longman, Headforwards. Modern software release cycles are getting shorter and shorter. Modern development languages and frameworks enable developers to produce new features faster than ever. With the trend of shorter sprints and a general move towards continuous delivery it is becoming more and more difficult to get everything ready to release without testing becoming a bottleneck. Existing testing processes cannot keep up with the rapid release pace demanded by more and more companies. So what can we do about this? One approach is to turn your development team into testers, get them to think more like a tester thereby reducing the number of issues that get past the developers IDE. But does this work and how do you go about doing it? In this session I will explain what we have done to help our developers become testers. I'll talk about the challenges we faced as well as the benefits that it brought for our projects. We'll also look at what impact this had on the developers and more crucially on the testers. From the FreshTech 2017 conference by TechExeter www.techexeter.uk
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Turning Developers into Testers
Similar to Turning Developers into Testers (20)
More from TechExeter
More from TechExeter (20)
Recently uploaded
Recently uploaded (20)
Turning Developers into Testers
- 1. Turning developers into testers Dave Longman | Headforwards | @dlongman
- 2. Software Delivery is Changing
- 3. Software Delivery has changed
- 4. We are releasing more often 2017 State of DevOps Report
- 5. Code bases have grown Version 1.0.1 128K Version CS6 4.5M 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 1990 2012 LinesofCode Thousands Year of Release Number of lines of code for Photoshop over time
- 6. Teams have changed 2000’S ProjectTeam Development Department Data Department Design & Architecture Testing Department PMO NOW Product Team Developer Developer Developer Tester Scrum Master Product Owner
- 7. There’s more testing than ever!
- 8. Device Testing Security Performance Profiling Accessibility Usability Safari MacOS Microservices Cloud Continuous Delivery Firefox Chrome Security Internet Explorer Network Topology Connectivity A/B Testing Automation Selenium iOS AndroidAPI REST SOAP JSON YAML Configuration UX Internationalisation Feature Toggles Monitoring Regression Testing Zero downtime deployments Test in Production Compliance Testing Guerrilla Testing
- 10. Voice as an interface
- 12. Finding defects later is expensive $5 $50 $500 $5,000 $- $1,000 $2,000 $3,000 $4,000 $5,000 $6,000 TDD Build Test Integration Test System Test Cost Testing Stage Cost of defects at Google Mark Striebeck presentation at XPDay 2009 Developer testing, from the dark ages to the age of enlightenment
- 13. Automation
- 14. Testers need to understand more oE2E oService/API oIntegration oUnit
- 15. Test code bases are big! [CELLRANGE] [CELLRANGE] [CELLRANGE] 0 5 10 15 20 25 Application Unit/Integration Tests E2E Tests LinesofCode Thousands
- 16. Modern testing requires more development skills
- 17. Can testers become developers?
- 18. Coding Skills Coding Skills Web Development •HTML •CSS •JavaScript Automated Testing •Selenium •Gherkin/Cucumber •Unit, Integration, API testing Security •OWASP •SSL •Networking •OAuth Cloud •Azure •AWS •GCP •Continuous Deployment Languages •Python •C# •Java •Ruby •SQL Design & Architecture •SOLID principles •Clean Code
- 19. That’s a lot to learn!
- 20. Can developers become testers?
- 21. Traits of a Good Tester Testing Traits Domain Expertise Analytical and Logical Thinking “Test to Break” Approach Great Communication Skills Awareness of Business Impact Takes Customer Perspective
- 22. Traits of a Good Developer Developer Traits? Domain Expertise Analytical and Logical Thinking “Test to Break” Approach Great Communication Skills Awareness of Business Impact Takes Customer Perspective
- 23. Testing SkillsTesting Skills Risk Management Test Approach and Design Ad-Hoc and Exploratory Testing Black and White Box Testing Capacity and Load Testing Usability testing
- 24. Good skills for developers…
- 25. How can we improve a teams’ testing? Improve developer awareness of tests 01 Improve tester awareness of development Improve developer awareness of exploratory testing 02 Improve developers exploratory testing skills Move to fully automated testing pipeline 03
- 26. Step 1 Testers focus on working through test scenarios with dev team at start of sprint During sprint, primarily exploratory testing Developers agree with tester whether test scenarios will be unit, integration or end to end tests Developers implement agreed scenarios Improve developer awareness of tests
- 27. Step 2 Tester pairs with developers on exploratory testing • Upskills developers to think more like a tester • Adds more ‘testers’ to team Developers pair with testers on automation testing • Improves testers’ coding skills • Peer review of automated test coverage Testers focus more on other areas • Coding • UX • Complex testing: security, performance, etc Improve tester awareness of development Improve developer awareness of exploratory testing
- 28. Step 3 Developer on Test •DoTing Remove full-time testers from team •Frequent review of testing •Mentoring role for developers Focus on automating everything •Enables more rapid releases •Shortens feedback cycle •Prevents team forgetting to do something Improve developers exploratory testing skills Move to fully automated testing pipeline
- 29. But…
- 30. What happens to the tester role? Treated more like Scrum Master role • The better you are the less the team needs you 01 Treated more like consultant role • Provides short-term upskilling on specialised skills to team 02
- 31. What happens to the testers? Change team role • Product Owner/Manager • Scrum Master • UX Designer • Developer 01 Become more specialised • Performance • Security • Automation • Accessibility 02
- 32. What’s in it for the developers? Less Bug Fixing • Understanding test scenarios better prevents defects 01 Better Quality Code • Designing code to make testing easier leads to more maintainable code 02 More Autonomy • Can make educated decisions about the “right” place to test the functionality 03
- 33. Does it work?
- 39. Step 2 Tester pairs with developers on exploratory testing • Upskills developers to think more like a tester • Adds more ‘testers’ to team Developers pair with testers on automation testing • Improves testers’ coding skills • Peer review of automated test coverage Testers focus more on other areas • Coding • UX • Complex testing: security, performance, etc Improve tester awareness of development Improve developer awareness of exploratory testing
- 40. Summary
- 41. Developers are capable of becoming effective testers
- 42. We need to be conscious of the impact of change to the testers
- 43. Moving away from dedicated testers allows us to scale better
- 44. Dave Longman | Headforwards | @dlongman
Editor's Notes
- Thank you all for coming along. I am super excited about this discussion, I think this will be a hot topic that will hopefully lead to a productive conversation. I am talking about how we can support the increased volume of testing needed for modern software delivery without recruiting 100’s more testers
- Software delivery is changing…. Actually I think in fact…
- Software delivery has already changed!
- We are releasing more frequently than ever. Latest State of DevOps report still shows a split between the best performers (orange) and the worst performers (black) The best performers are deploying 1000’s of times a year. This is a problem for the traditional ways we have tested
- Added to this code bases have grown massively. In 1990 it was only 128K lines of code (a mixture of Pascal and assembler) 22 years later the code base had grown to 4.5M lines of code This is a massive change! How many more issues are likely to be in 4.5M lines of code compared to 128K?
- The ways we work together have also changed In the early 2000’s we tended to be organised into areas of speciality or functional excellence and project teams were created by pulling individuals together for a defined period of time Now more and more companies are set-up with long lived product teams that ‘live’ throughout the lifetime of an application.
- Added to all these changes, we are focusing on more things to test
- A few examples of things we care about. Let’s focus on a few of them Device Testing – everyone is starting to expect even line of business apps work on their tablet or phone, often using poor internet connections API Testing – a lot of companies are now starting to consider their application API as a core product – this means this needs to be included as a key test area rather than just a way to test without using the UI UX – I blame the iPhone but now users care about ease of use more than ever. The days of delivering an internal system that had a mediocre UI are gone Monitoring – with the increase in release cadence and the rise of DevOps, the ability to monitor what the application is doing in production is becoming a key feature that needs to be tested Feature Toggles – again linked to faster releases, we are starting to release more incomplete work into production, hidden behind a feature toggle – this means we are starting to have to test the app with and without the toggle enabled – this massively increases the amount of test scenarios we need to consider. AND this is just the common stuff available now – what about….
- How can we expect to be able to test these types of applications with our current test approaches? Let’s go back a bit…. We know finding issues later is more expensive
- This is some old data from Google – how have we as an industry changed to deal with this and to help us release more often? AUTOMATION Mark Striebeck from Google opened XPDay 2009 today with a talk titled Developer testing, from the dark ages to the age of enlightenment. Google spends $100M per year on test automation, and wanted an answer whether they are actually getting a good return on that investment. They estimated that a bug found during TDD costs $5 to fix, which surges to $50 for tests during a full build and $500 during an integration test. It goes to $5000 during a system test. Fixing bugs earlier would save them an estimated $160M per year.
- AUTOMATION This is great – it allows teams to identify issues earlier than ever and enables us to release more frequently without shipping flaky code BUT it has a cost
- In order to leverage low level tests like unit tests as part of your test approach we need to have the testers understand what they do This is a pretty big learning curve for a lot of testers who don’t have a coding background
- In addition, automated test packs have a lot of code! An example from a recent team – 18 months, about 5 devs. This is not a best practice example! Just an example… 30% of the lines of code are feature code!!!! 70% of the code we wrote is specifically there to check the 30%
- I suggest that Modern Testing requires Development skills. Over the past 5 or so years the Testing community have been realising this and one suggestion is for testers to learn to code. Is this feasible? Let’s look at what this means
- A selection of the skills/knowledge needed for a tester to become a good developer – even just focusing on automated testing
- Is this feasible for someone to pick up without a proper training programme? How about taking the opposite approach?
- Let’s look at the skills a tester brings to the team Initially let’s focus on the general softer skills
- Things to look for in a tester – probably not complete I suggest that these are also traits that you find in the best software developers
- Let’s look at some more testing skills
- Again not a complete list
- I suggest these are also things that a lot of great developers are able to do Perhaps focusing on getting developers better at testing is more effective than trying to get testers better at coding? This is one thing I have been working on over the past 5 years with some of my teams Let’s look at how…
- 3 general steps Let’s look at each in more detail
- Objective to get developers to pay more attention to what testers do – and feel more ownership with the test pack Get the testers to own the test scenarios BUT get the developers to IMPLEMENT the tests Easy win – devs like coding, we all like automated tests, devs are lazy Testers are great at finding bugs and the best way to do this is to do exploratory testing
- Once the devs are comfortable writing automated tests we need to up the ante Get the testers to pair with the devs to get the devs better at doing exploratory testing Help the testers improve their knowledge – pair with devs on automated testing – this helps build ONE TEAM
- The holy grail – developers are actually doing proper testing, properly We need to get to the point that the testers actually believe that the developers are as good as testers!!!
- OK so what about the current team? Split into the role and the people
- 2 options
- Again 2 options
- 3 benefits for devs
- The big question…. For some it does work – look at Atlassian For me……
- Mike Gualtieri 2011 Real time data for financial markets Mike Gualtieri Vice President at Forrester research wrote a blog post in 2011 describing how one of his clients (providing real-time market data for financial markets) removed their QA team and got better quality software Forrester (2011) - https://go.forrester.com/blogs/11-02-17-want_better_quality_fire_your_qa_team/
- A ZDNet article in 2012 described how Facebook in 2011 did not have any testers "Facebook had no employees who were dedicated to QA or otherwise performed QA as their primary job responsibility. There were some employees who do some vaguely QA-like things, but this was a small part of their job." http://www.zdnet.com/article/why-facebook-doesnt-have-or-need-testers/
- In 2015 Yahoo introduced Warp Drive – an internal CD drive where developers could release directly to production without going through a QA team at all https://spectrum.ieee.org/view-from-the-valley/computing/software/yahoos-engineers-move-to-coding-without-a-net
- Atlassian have been a thought leader in the agile testing approach. They have a number of great blog posts and presentations about how they structure their testing teams At one stage they had (I think) 2 QA for the whole Jira team of 60 developers!! Atlassian - https://www.atlassian.com/agile/testing
- But what about Headforwards?
- Well I am stuck at Step 2 And the issue is probably not primarily the developers – it’s more the testers – I have not done a good job convincing them that they will still have a job