What do you do when development is not complete?

Home Forums Software Testing Discussions What do you do when development is not complete?

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #10926
    Ronan Healy

    So development is not complete but you or your team have the test cases written?

    What do you do during this time?

    Would you advise to work on learning about the product more if that is something you can do? What other tasks could a tester do at this time or is it something that doesn’t happen that often?


    Assuming that you have a version you can work on. We would start trying to break it soon as possible!

    Ronan Healy

    @ben9 That makes complete sense! Would there be any other tasks that your time might usually do?


    @ronan I sat down with a Dev during the week and tried to get a better idea of exactly where the Dev team are with their own Unit Tests. I don’t think they have been very proactive with keeping a record of what’s been done. It’s been difficult to get a clear answer from them. There’s not much of a strategy on their part and not much in the way of metrics to analyse coverage. The Dev I chatted too has made a kind of automated unit test program of his own and I’ve been familiarising myself with that in between early Functional Testing against Requirements. We will be dipping our toes in the realm of Automation soon too and researching what would be best for us to carry out our Automated tests.

    Ronan Healy

    @ben9 That seems really practical and a great use of your time. Did you start doing this yourself or is it recommended by your test manager?

    Devanathan Ram

    Well, in a typical Agile environment there is always a task for you waiting on the wall to pick. In agile, when the development is not complete there would be discussions on the requirements analysis with the entire scrum team to see what are the dependencies and to decide on the efforts and delivery dates.
    But when it comes to testing teams, apart from participating in the current sprint activities (including estimation, test plan and test case preparations), we will also have previous sprint’s spillover items. Like,
    1. Defect retests
    2. A sudden high priority adhoc deployment during the last phase of previous sprint
    3. Could be some piece were not delivered in the scheduled hand off date due to development environment issues. They come with various caveats tagged.
    4. And a typical scenario would also include testing teams buy in some extra days for previous sprint testing in current sprint timeline due to various factors starting from resource absence to code delivered beyond the last Hand off date with justifications.

    These are unavoidable when the Biz does not want a sprint item to be moved to another sprint. They would be fine completing it with some extra days from next sprint but not moving the task to next sprint. Tasks are always there in AGILE.


    Tasks that we normally do in such cases is:

    – Test Environment setup: Make sure the machines in the test environment are ready, install the necessary software, get the automation tools / test management tools set up, create the necessary logins / accounts for all testers and so on

    – Documentation: Make sure all documents are complete along with the review and rework of the documents

    – Requirements: Work alongside with the BA / developers to keep a track of all the change requests that come through during the development phase and incorporate the same in the test cases

    – Test data creation


    There are many things that can be done.

    1. Looking out the automation scripts ,any new libraries to be built which were pending

    2. Pick any tasks from the backlog

    3. If nothing is there for you , you can anytime start exploratory testing. A great value add and never a waste.



    – Catch up with developers frequently to learn more about the development.

    – Create more test cases that target real end user scenarios.

    – Test the available modules already created (if possible) and provide early inputs to development team.

    – Asses the risks to not deliver the product in the planned schedule.

    – etc.


    Do something that you usually do not have time to..

    LEARN new things, read blogs, forums.

    LEAVE and take some time off. Drill down overtime hours, lessen hours billed.

    WRITE blog post, conference call for papers, forum posts 😉


Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.