Are you in early…on a project?

[Jesper]

not in the morning.. I mean, are you involved early in the project or customer deal?

Frequently I find myself involved in bid teams and previously I have been involved in planning releases. I have written about it here

In the article “A Context-Driven Approach to Delivering Business Value” testing can help establish viable market, match to vision and in identifying business risks.

 

What ways can we deliver valuable input early?

[Archana]

Having moved into freelancing, I have not been involved into the early phases recently. But I will soon be transitioning into a role that requires early involvement. It would be good to hear inputs from other members

[Roman]

I was. The following points are things I actually did in this or that project on early stages.

1. I helped my team lead with early project documentation.
2. I read through a specification and asked questions for something what was not clear.
3. I tested first working piece of code. I couldn’t call that piece “app” or even prototype. It had one input field where you could enter database ID to request piece of data from server and parse it. Within a day I found first bug: server could return “unpurified” data parser couldn’t handle.
4. I reported bugs on one piece of functionality for month until it was changed (requirements simplified and problematic stuff causing bugs removed).
5. When I had spare time, I was asked by team lead to find something alike to Microsoft Hopper Test tool to test app under development by “monkey testing”. I hadn’t find a suitable tool at the time, so I developed my own implementation of concept. It served us well.Speaking more generally, when you have time during early stage of project or feature, you can look for or develop your tools to help you with testing or data for it.
6. I asked PM why 2 server developers, 2 client developers and 2 testers have only one instance of server to work on. He asked customers if project budget could afford 2 instances and the next day we had them, so we could less block each other.

 

And the last thing I’d like to add is rather negative example. When you came to project later and get to sort out what your predecessor(s) wrote, you may wish you were there earlier. No joke.

[JerryWeinberg]

I would never agree to lead tests on a project if I wasn’t in it to begin with. @rpwheeler gives a good list of the reasons why.

I would add one more item to his list, which might actually be an unmentioned part of his second point, reading through the specification. That is, I always look for testability of each spec, and then when there’s a design, I look for testability of that. And code, too, later. This kind of preview makes testing 100% easier when it comes time to actually run tests on a machine.
<p style=”margin: 0px; font-size: 23px; line-height: normal; font-family: ‘Times New Roman’;”><b>Perfect Software And Other Illusions About Testing</b></p>

[Author]

Posts