When does testing start?
I am currently working in a team of testers in a quite big project. It should be noted that the project size and process limits my personal scope and the things I can really change. The test team has not been there for very long, and our environment responsible s haven’t yet gotten the test environments completely up. One reason for that is that some parts of the system have not been completely delivered just yet, so the possibility to test the functionality flow is limited. But when do we start testing?
A developer that has helped us getting some of the environments in place asked me when we are going to start testing those parts, which he has been developing. I have worked with him before, and I know he is a good developer that has really understood that testing provides him with feedback.
-“We are already testing” I told him.
-“But the test environments are not up yet?”
-“No, but at the moment we are testing the requirements and the documentation that really exists”.
For the developer, who is really used to testing being his way of getting feedback on his work, this answer did not really satisfy him. At the moment we are really not giving him feedback, but other parts of the project that deliver the requirements and documentation.
Since we have gotten his involvement in getting some of the environments up, it is a real bugger that the rest of the software has not been delivered yet. And until that release, we cannot really “start testing” his parts, in the sense he thinks of testing. Instead we have been bothering him to finish up and deliver his documentation, which is of course also a deliverable to test.
Of course, the product under test is really the code. But until delivered, testers can do no better than work with the material available and provide good information about the status of the product that way. Do you agree or disagree?
When does YOUR testing start?
Leave a Reply
Speaker at Lets Test Oz 2014
Speaker at CAST 2012
Speaker at Agile 2012
Speaker at Agile Testing Days 2012
Program committee member at Öredev
Happytesting 
I agree. Testing requirements helps us understand what we are trying or need to build.
What I find dangerous in Agile teams is withholding information from other team members. In our team setup, QA is responsible for the overall test cases of a story. When development starts using TDD, there could be a some weird edge case QA already knows about. The trick is to give feedback as soon as possible to the team. So no-one feels like having missed out some information about what we’re building.
Thank you for the understanding us testing the requirements.
To be clear on one thing, this particular project is not an Agile project. I tried to enlighten this fact in my first paragraph, but maybe that was unclear.
I do agree with you that it is dangerous to withhold information in a project, and that fact applies to ANY project setting. What I really want to highlight is that Agile processes handles this by making the withholding of information hard. In other process models that are more waterfall like, the withholding is easier to do, thereby harder to prevent.
I also want to quote James Coplien from Öredev 2010 on this. “The best way to hide information is to put it in a tool”.
Sigge, I think you raise an important point. Although I think there may be some value in giving feedback on a build that is not formally released. Maybe you could sit down with a developer at their computer and take a look at whatever they have working there. You might help them catch some missing scenarios and edge cases rather than fixing them only in the requirements spec.
Rachel
Thank you Rachel for your comment. I do agree on sitting down with the developer to find missing scenarios. And that is actually something I have done some of, even if that has not really been in my scope for the project.
Then there are two more context related things to think about when reading my post.
-There is a huge test scope, where breaking into smaller pieces/phases and prioritization’s on these is a very big issue. The prio that has been decided upon is to first gather all different documentation and requirements into test scope, for the testing to be able to proceed smoothly whenever software is delivered.
-The developer in the post is actually creating an integration point between different systems, where these systems are the ones we are waiting for. We can test his integrations to a certain point, but really need the integrations in place to really test them.
Disagree! What’s the matter with you man? Pair test, at his desk, with the doc in one hand and the application in front of you. Test a bit, code a bit.
Hi Jamie, and thank you for commenting! I have to admit, not so long ago I could have made this comment on any similar post. But I have gotten some perspective on different contexts in some of the last couple of projects I have been in.
As I replied to Rachels comment, there are certainly some context related information about the project setting that you have to take into account for these things.
I have the possibility to pair test this developers product to a certain extent, but as stated before the extent of testing possible is really limited in contrast to the rest of the test scope. Thereby the pair test at his desk is actually not possible to do with the limited resources for tests.
On our team, we have made it a priority to start early, even working with developers on requirements or user experience planning. It has been really rewarding (on both sides I think) and has given us a better understanding for each other.
http://www.everydayqa.com/2010/agile-development/time-for-qa-to-fully-embrace-agile/
Hi Devon, and thank you for the comment.
As I have replied to the other comments, it is important to state that this is NOT an Agile project setting. The requirements and much of the documentation has already been worked on for some time by BAs and architects. And I have to admit that to some extent it is actually the best written requirements that I have seen. The testers are reviewing this and questioning to fill the gaps now, before the first releases of software is being delivered.
But I do agree that in some other project setting, having the testers doing this BA job is a possibility. I have written about this here:
https://happytesting.wordpress.com/2010/06/15/sast-and-tester-as-business-analyst/
However, considering the work of this projects BAs, I am not so sure any tester would deliver much better requirements. The focus on testable requirements would be a good thing, but missing other parts would probably be a fact.