This post is part 2 of my “autotests” series. First part is How do I Encourage my Manager to Support Automated Tests? This article is not about the technical details on how exactly to write autotests, but rather about the approach one could take to ensure the autotests initiative is not rejected. Once you've persuaded to support automated testing, you need to plan it right — the acceptance of the initiative doesn’t guarantee unlimited probation time. your manager Remember, step into the manager’s shoes: once having yielded to someone’s plan, they still nurture the doubts and hesitations. Provided there are no noticeable (and by noticeable I mean measurable) results, those hesitations and doubts will cherish. Let’s see what we can do with numbers. It's a widely accepted consensus that automatic tests (and TDD) benefit the software development process in the following ways: saves time (reduces time to market) [ ] link improves quality and lowers total cost of ownership [ ] link improves team morale (mundane, repetitive tasks are among the sources of developers’ unhappiness) [ ] link reduces onboarding costs (developers have less fear of changing and breaking things) There’s a consensus in the software development area that , so I wouldn’t recommend going that route. measuring quality is a bad idea It’s also impossible to measure with numbers, so this route is useless too. team morale We can show only two measurable things: (time) and . onboarding cost time to market However, will reduce noticeably only after some time while we want to show immediate results. onboarding costs So we are left with showing how is reduced. time to market TTM comprises the time taken to pass all the steps required to develop and deliver certain functionality to the client. The manual QA stage usually takes significant time: a feature awaits for the QA team to pick it up, and then the testing itself is done. Also, the manual QA stage implies massive delays in a case when the feature is returned to development due to defects. The reason for the delay is that when the feature is passed to QA, the developer usually picks a new feature to work on, and when the tested feature is passed back to development, it has to wait again. If the developer picks the returned feature straight away, context switch costs apply. I’ve mentioned studies on context switching costs in my article: code review limits to applicability There are multiple publications on how multitasking and switching contexts are ineffective: The myth of multitasking, Nass, 2013 Multitasking: Switching costs (american psychological association) Executive Control of Cognitive Processes in Task Switching — Joshua S. Rubinstein, David E. Meyer, Jeffrey E. Evans Reconfiguration of task-set: is it easier to switch to the weaker task? Executive Control of Cognitive Processes in Task Switching There’s good scientific evidence that it’s more effective to work on one single task at a time with as few context switches as possible. This proves that to reduce time to market (and show immediate results in this initiative), manual QA phase should be reduced as: automatic tests run as soon as the developer runs them (0 waiting time) automatic tests run quickly (much lower testing time) and therefore provide almost instant feedback, meaning that there will be no context switching cost. Where to start As we want to show our manager some immediate benefits, obvious idea would be to start with automating something that would show immediate results. I’d advise automating tasks that have significant ‘manual testing’ time. Every task tracker can show you the time a task spends in the ‘testing’ phase, and if you use a test management system, you can get even more information. Here’s what I have in my TMS: Qase As you can see, the obvious choice here would be to start automating ‘authorisation’ first as it takes 9 minutes to be tested manually every release. These 9 minutes yield spent directly on manual testing of this particular feature if we have one release per week. 8 hours a year As soon as we automate this check, we can show our manager that TTM is reduced by 9 minutes for each task. This will inevitably gain us more trust. The more trust you have, the more you can do what , potentially something which cannot be ‘measured’ or is not quantifiable. you know is right calls ‘managing only what’s quantifiable’ one of the : Deming 7 deadly diseases of management Management by use only of visible figures, with little or no consideration of figures that are unknown or unknowable. But I’ve rarely seen managers knowing of this, hence this whole approach of showing results and gaining trust to do something that’s truly right. So, to summarise: you persuaded your manager to support autotests you constantly show them immediate results you gain trust to be able (and have resources) to develop proper testing strategy you start doing what’s right To proceed with the proper testing strategy, first check Fowler’s . document

How do I Encourage my Manager to Support Automated Tests?

Qase TMS

How to Start with Autotests

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Code Review: It's Bad, Expensive, and Ineffective [in most cases]

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

12 Essential Coding Standards for Quality Web Development

Code Review: It's Bad, Expensive, and Ineffective [in most cases]

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

12 Essential Coding Standards for Quality Web Development

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps