Why can't developers be testers discussion

Editor's Notes

• #2: 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
• #3: Software delivery is changing…. Actually I think in fact…
• #4: Software delivery has already changed!
• #5: 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) But even the worse performers are significantly reducing their lead times for getting production changes released The best performers are deploying 1000’s of times a year. This is a problem for the traditional ways we have tested
• #6: Added to this code bases have grown massively. Looking at Photoshop – a world class image manipulation product 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?
• #7: 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.
• #8: Added to all these changes, we are focusing on more things to test
• #9: 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….
• #12: 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
• #13: 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? 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.
• #14: 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
• #15: What challenges have people had getting testers to understand unit test coverage? “The test triangle” – no talk about testing is ready without one of these! 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 developers who don’t have a coding background
• #16: Is this normal? I don’t know – Have any of you captured this type of data for your products? 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%
• #17: 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
• #19: A selection of the skills/knowledge needed for a tester to become a good developer – even just focusing on automated testing
• #20: Who has had success transitioning testers to development? Is this feasible for someone to pick up without a proper training programme? How about taking the opposite approach?
• #21: Let’s look at the skills a tester brings to the team Initially let’s focus on the general softer skills
• #22: 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
• #23: Let’s look at some more testing skills
• #24: Again not a complete list
• #25: Has anyone tried getting developers better at testing? 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…
• #26: 3 general steps Let’s look at each in more detail
• #27: 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
• #28: 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
• #29: What skills do testers bring that cannot be easily taught to developers? What challenges are there to get developers performing exploratory testing? 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!!!
• #30: OK so what about the current team? Split into the role and the people
• #32: The big question…. For some it does work – look at Atlassian For me……
• #33: 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 