How to convince project managers that onboarding a tester early is important?

Question

I've recently transitioned to a software engineer in test role--currently the only person in this role. We have a number of projects that are in the early feasibility stages, and I'm trying to convince project managers that I need to be involved even in these early stages. I've had a hard time getting the point across though: they seem supportive, but keep saying things like "we're not quite ready to think about testing yet" or "we don't want to waste your time [with general project stuff that isn't strictly related to testing]".

I don't want to wait until teams think they know what they need for testing; rather, I want to get up to speed on what developers are thinking, planned features and tech stacks, etc. so I can start doing the same feasibility work on the testing side, and foresee problems we'll encounter during development while I have a chance to get out ahead of them.

I think if I had already gone through a few projects in this role I'd have a much easier time articulating my concerns--and I have done so as a developer so I do have some thoughts--but with this being my first rodeo in a role we've never had before, I'm having trouble making my case.

I'm actually less concerned about getting support from developers once I actually get "onto" a project, and I can likely learn a lot from grabbing developers and asking questions, but how can I convince project managers that onboarding me now will add value when they have the impression that it's too early?

Note: I should clarify what I mean by "early feasibility stages": our group writes software that interacts with hardware, not software-only products, so when a project starts out there's a lot of work to do before writing production code to prototype things and determine whether our planned approach is, well, feasible. For example, can we use computer vision to detect a user error before it causes us to crash and bend metal? If we make this set of assumptions for the underlying control architecture, will those assumptions break when we integrate this other hardware piece?

I believe there are similar questions to be answered about how we will test the product, which is the focus of this question.

Answer 1

I was torn between making this a comment or an answer, because the answers here already give a very good set of advice, but I think it's long enough and useful enough to be an answer. Please just think of it as an addendum to the other answers.

The trick is that you cannot sell "testing." Why? Because the customer doesn't need it.

Read that again. It's an evil and very true phrase. Why's it so true? Because the customer already has a preconception of what "testing" is. They may be right. They may be wrong, but they have an opinion, and that opinion is that it is something they don't need. They told you as much. And, if they are like any program managers I am used to, they really don't have time to relearn what a gerund like "testing" means. Those guys can get swamped with the realities of managing a program.

What you need to do is find something they do need and want. Sell them that, but sell it in a way which gives you room to sell the things you consider to be "testing" which may or may not have been "testing" to them.

"we're not quite ready to think about testing yet"

This shouldn't come up if what you're selling isn't testing.

"we don't want to waste your time [with general project stuff that isn't strictly related to testing]"

Now this is an interesting one. It means one of two things. One is that they understand the purpose of testing in the business, value it, and don't want to take your time away from it. If so, great! You can then explain to them why it isn't a waste of your time (because the aspects of testing appear everywhere. No matter what they have you do, you can do it in a way which makes your life easier in the "testing phase," right?)

The other possibility is that they have an alternate reason for not inviting you into the team. Maybe they have a fixed resourcing level that gets thrown a curveball if they bring someone in from test engineering. Maybe there's someone on the team that has trouble working with you. The reasons are numerous. If you explain why it isn't a waste of your time carefully, you may be able to get a glimpse of what the real issue is. That issue won't be testing. It will be something else.

this being my first rodeo in a role we've never had before, I'm having trouble making my case.

This is another reason not to sell "testing." If it's your first rodeo, you don't really know what it is. I mean, don't get me wrong, I'm certain that you have done testing and have taken some classes, but your wording suggests that you understand there is a substantial difference between how someone thinks after 10+ successful projects are under their belt and someone who is working on their first.

The solution is to sell yourself, not "testing." By your phrasing "recently transitioned into a software engineer in a test role," it implies that you have some past experience. You probably have successful projects under your belt. Sell yourself as a developer with your experience, who is willing to work "lesser" tasks with an understanding that you will be looking to complete those tasks in ways that encourage people to want "testing" in the future. It's almost like a loss-leader.

A final consideration would be to look at the management that transitioned you into a test role. It is a truly foolish manager indeed who transfers an employee into a newly created role in the company without seeing a value proposition for it. They always have a plan and a reason, whether they state it or not (or whether they even know it themselves or not). If you can find out why management thinks this is the right time to have a test engineering role, then you can figure out how to put yourself in a position to do what might be the single most important job there is in a business: making your boss look good. If you can help your boss sell their idea of what that test engineering role should be, and why it helps the company, you will always have someone in your corner. (or at least you should. I paint a rosy picture because I think optimism helps in these cases)

Answer 2

In this situation - unfortunately - your best option is the slow and painful method. I've used it as a general tester, and for test automation.

The way I approach this is to use these techniques:

• Find gaps in use cases/specifications wherever possible - Every time a tester finds a hole or an unconsidered situation in a use case, specification, or design document after developers have started coding is a cause of rework. The more of these you find and ask about (I've found "What happens when X?" is a good way to handle these, especially when the answer is usually "Oh, I didn't think about that"). It gets easier to do this as you get more familiar with the software you're working with, but that doesn't mean you can't find potential issues before you're intimate with the AUT.
• Keep track of wasted time - Any time you have to go hunting for an alternative way to access a field you need to interact with, track that time. After a while, the number of your time added because the dev team neglected to provide you with a unique identifier for the fields you're chasing will be well into negative ROI and you'll have a hard numerical argument ("It takes a developer less than a minute to designate an ID. I needed 3 hours of testing that I was transversing the DOM correctly to access this field through automation. I'm not paid that much less than the development team. This is costing the company money." - only more politely)
• Track problems that could have been avoided - This ties into the first point. Any time you find yourself creating a defect or reporting a problem that could have been avoided if you'd known what was going on in earlier stages of the development, record it. Management prefers hard data, especially hard data that ties directly into money. When you can show that a significant percentage of the issues you raise or the time you spend reworking your automation is caused by not being in the development team loop, you have a good argument because those issues and your rework is time (therefore money) that the company need not have spent.
• Never be smug - Absolutely no "I told you so" type comments - that will just feed resentment. You need to always work from the perspective of someone who wants the software to be as good as it can be.
• Track your progress - This isn't quite so obvious: given that you aren't being given access to the software you're testing until fairly late in the piece, you're going to be running behind. You need to keep track of how far behind (e.g. if the rest of the team is on iteration 4 but you're only now able to work on automating iteration 1, you track that your automation is 3 cycles behind development, and why). This information can come in handy when work you haven't automated because of the cycle delay has problems that are discovered by customers.

It can take a long time to build enough faith from traditional-minded project managers who see testing as something that gets tacked onto the end of a project to show they've done due diligence. The last time I had to do this, it took a year before the project managers realized that every time I started testing a new feature I had a lot of questions that caused rework and delayed the feature. This improved when I started being included in the design and specification meetings, and improved more when we started moving to a more agile way of working.

Answer 3

To convince the average manager you should operate with the risks since the risks is what the average manager works with. I would make a quick research using the "public" data of the project or the data that is available for you.

Then I would build three scenarios on how the project would perform in the case you would be onboarder on early stage (optimistic scenario), on middle phase (realistic scenario) and late phase (pessimistic scenario).

As you want to force your manager to take your side, I would concentrate on describing (and emphasizing) the negative sides in the case they choose the latter two options (I would also research for some statistics of similar projects to add the value to my estimates).

Answer 4

OP, your gut feeling is exactly right. It is never too early to think about the quality, and how to test it.

This paradigm shift in thinking even has a name: "Shift left testing" (shift testing to the left in project flow chart activities).

Your developers (or even managers) might be familiar with test-driven development of units on code. One of the benefits is that it allows (forces, even) to design units of code in a way they are easier to unit-test, because functionality is exposed to unit tests in a different way than it would be for just internal calculations.

Exactly same works for whole systems, test-driven development of whole systems will allow your team to structure the system in a way beneficial for end-to-end testing. Because someone will be thinking from the very beginning about how to test that interface, what information should be logged where to have good idea what is happening, and make sure that right thing is happening.

If you will be forced to bolt testing as an afterthought onto an existing design, it will be just that: an afterthought.

Quality cannot be bought: it has to be paid for. It cannot be added to the system afterwards, quality has to be build to the system from the beginning.

Cheapest way to fix inconsistency or missing requirements is before they were implemented in the code. Someone needs to be responsible for mapping requirements to tests, someone who cares about the tests. It will force developers to provide additional API functions for testing, and to design API in a way beneficial for testing.

If you have developers using test-driven development, they are (or should be) on your side.

In my experience, analyst who is responsible for business/customer-facing features, gives little thought of how to test them. Instead, analyst relies on developers. But if developers have only pressure from analyst about implementing a feature, they are less concerned about testing it (beyond unit tests). This is exactly the opportunity for SET to deliver value: thinking about where, what and how regression test part of the system and interfaces.