Functional testing of incomplete features

Question

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?

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.