~70% of SDLC Effort is on Software Testing and Related Activities
Wise IT Executives or Software Engineers focus on improving the testing process first.
In 2013, one architect (of a government department) told me that 70% of the budget was spent on software testing for the aged mainframe system. I was surprised. Since then, I started observing the team’s activities on various projects, and my conclusion: ~70% of all software development effort is on software testing or related activities. A clarification on the meaning of ‘related’ here: this task can be significantly shortened (and made much easier) if E2E test automation is implemented well.
New readers might think, “Zhimin, you said so because you are a test automation coach”. I worked as a full-time programmer between 1997–2010, and since 2007 I have started coding my own apps (in my spare time). The fact is that I have always been actively involved in software development (including coding).
Yes, I spent most of my time in software testing (see below for more).
Table of Contents:
· Supporting Figures (kind of)
· Testing Efforts breakdown for all team members
∘ 1. Programmers / Developers / Software Engineers
∘ 2. Functional Software Testers (manual & automated)
∘ 3. Business Analysts / Customers
∘ 4. Project Manager
∘ 5. Performance/Load Testers and Security Testers
∘ 6. UAT Testers
∘ 7. Support Programmers
· Defending effort in a Football Match
· My Personal Journey on Discovering this
Supporting Figures (kind of)
70%! Many readers, especially programmers, would disagree.
Over a year ago, I wrote a short article analysing the European Software Testing Benchmark Report 2022.
“38% think 51+% of SDLC is spent on Testing.” — European Software Testing Benchmark Report 2022
From the chart above, 12.3% think the testing effort is > 70%. There you go; about 1 in 8 agree with me.
Then readers would say, “Zhimin, even relaxing to 51% (not 70%), there are still 62% disagree with you”.
70% is a general indication, not exact, of course.
Like the famous “80/20” rule, few will question the exact 80% of all outcomes derived from 20% of causes.
For my own development projects, the testing-related activity is more like 80%. Why? Because I do daily end-to-end (via UI) regression testing.
A broader definition of testing-related tasks
I might have a slightly broad definition of testing-related activities. For example, when a programmer starts fixing a bug, typically three steps: replicate, fix, and verify. I regard Steps 1 and 3 as testing activities. Also, when a business analyst creates a data scenario, it is a testing-related activity, too.
All these become obvious when a good test automation process is implemented.I exclude useless overhead activities, e.g. meetings.
Meetings are mostly unnecessary overhead, which I exclude here. For more, check out Jason Fried’s famous TED talk: Why work doesn’t happen at work? (video), or “Meetings are Toxic” (video and transcript).
Also, when a good Continuous Testing process is implemented, the unnecessary of most meetings become apparent.I see testing efforts from multiple perspectives.
I worked in many roles: developer, architect, business analyst, tester, tech lead, project manager, support engineer, trainer and product owner. For my own projects, I have performed all activities. My view might be more complete than most people, and in a long perspective.“Release Early; Release Often” means a lot more testing effort.
The foundation of Agile is Testing, Automated Testing. DevOps means Continuous Testing.
One defect means at least two testing activities are required, one by a developer and the other by the tester (retesting), and quite often, a business analyst needs to do as well. — Zhimin Zhan
Not convinced? Let me break down how a typical software team member works daily.
Testing Efforts breakdown for all team members
1. Programmers / Developers / Software Engineers
50% — 80%
Generally speaking, programmers are considered the stars of a software team. The software they created ultimately is why all teams get paid.
I started working as a software engineer in 1997 and worked on numerous projects (Perl, C++, Java, C# and Ruby), mostly as a contractor. I would say that a large percentage of my time (when working as a programmer) was on testing.
To set a tone, let’s look at the two joke images.
There is some realness in the jokes.
In this article, Benefits of Continuous Testing (Part 4: to Developers), I listed all the typical activities a programmer does daily. Over 50% is end-to-end software testing. For more, check it out. Here, I will just point out the simple fact: defects and debugging are all associated with testing.
If we include unit testing and integration testing, the figure is even bigger.
Keep reading with a 7-day free trial
Subscribe to AgileWay’s Test Automation & Continuous Testing Blog to keep reading this post and get 7 days of free access to the full post archives.