I've had several tasks where I'm to do functional testing (and to be writing automated test scripts) on features that are not actually complete.

For example, CRUD testing on a project to make sure the user can create, read, update, and delete items. As I begin the create process, I type in all of the fields and hit a button that says 'Next'. On the mock-up and wireframe, there is a specific page that is supposed to follow as a result of clicking the 'Next' button. Expecting this page to appear, the page I used for creating said item is instead refreshed- but the item does get added to the list as expected (though it's data is incomplete because there is supposed to be more information to add after clicking 'Next').

I've had several tasks like this, where I'm functionally testing and attempting to write automated scripts for features on projects that aren't complete. To me, unit testing (testing the code itself) during this stage of development makes sense; functional testing does not. I am new to SQA and a fresh professional in the software world so I don't know if my inexperience is getting in the way. I then get confused because I'm being told to test a feature that I expect to be "done" but, by referencing documentation, really isn't complete. I then scratch my head thinking I've got something wrong, which is shortly followed by me interrupting a developer to ask him/her if I am missing something; this seems to be an inefficient use of time.

Is this the proper way to do testing? Should the features of a project be complete first?

  • By the way: your question is not off-topic here, but it is also on-topic on a different site (it is perfectly possible and normal for a question to be on-topic on more than one site, which site you post to depends on what kinds of answers you are interested in). In this case, that other site is Software Quality Assurance & Testing. Please make sure you don't cross-post, i.e. either delete this question, or make sure to tailor your question to the different target audiences in such a way as to eliminate potential overlap in answers and thus knowledge fragmentation. Sep 2, 2016 at 19:33
  • I actually see two questions. "How do I test an incomplete feature?" at Software Quality Assurance & Testing, and "How do I build a large feature so it's easily testable in phases?" here at Programmers. Sep 3, 2016 at 12:31

1 Answer 1


Unfortunately, if you wait that everything is finished to to the tests, you might discover too much wrong things at once, and it will be a stressful nightmare to clean the mess up. Maybe only then -- too late -- will you discover that fundamental assumptions were flawed (sometimes with catastrophic consequences).

Software quality is something that you have to ensure from the start to the end of the development process. And one aspect of quality is to ensure that developed parts work as intended, as soon as possible and if possible before to assemble them in more complex parts.

The more unitary your test, the easier it will be to find bugs: if you wait for two interelated parts to be finished before testing a feature, and the test fails, you first have to find out in which part the problem is.

There is even a Test Driven Development approach, claiming that you should first write the test and then the code in order to achieve higher reliability.

So yes, it's normal to test before everything is finished !

Now to the techniques: you may be interested in using test doubles. Without entering in all the details, you could use test stubs, mocks and fake objects, so that your unit test can focus on what is already there and simulate assumptions on chat's still in the pipe.

  • It could be the real problem is the organization is not set up to work this way. Your answer is right on. Sep 6, 2016 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.