What a tester can do when implementation is going on, for example when he/she is waiting for the build/feature to test?
Below are some of the activities that a tester can do in the time when he or she is waiting for the build/feature to test. These are only few examples and these vary depending on the project or company etc.
Read and refine requirements:
Complete and clear requirements are very important. Lack of clear requirements can take a project to a path of failure. A tester can read all (or some of the important) requirements, depending on the available time, till he/she is able to completely understand these. A tester can review the requirements, ask questions if something is not clear, discuss those requirements with peers, system analysts etc., can put forward his/her views and in one way or the other can help to improve the requirements. Believe me that complete/correct requirements go a long way in improving the application stability and saves lots of time at later stages, which in turn is like saving dollars.
Prepare test cases:
A tester can prepare test cases, if possible. If you have written each and every possible scenario (for a feature for example) with probably its expected results, it will then help you to free your mind from that feature and continue with next/ another one which may be diametrically opposite from the earlier and requires completely different thinking. So in a way you prepare some awesome scenarios (both positive and negative) for a given feature, forget about it for the time being till you get it for testing and continue with the next one. This is just one way of working. When you get the feature for testing then you can refer the test cases written earlier without any delay.
Map test cases to requirements:
At regular intervals you can map test cases to requirements to make sure that all the requirements are covered. Some teams take this very lightly, but believe me, if this is well maintained and regularly updated then you are going in the right direction and it also instills a kind of confidence and security in you. You can use some Traceability matrix or any automation tool like Quality Center for example.
Mapping test cases to requirements not only helps you to verify that all the requirements are covered, but it also helps you to see that one or more test cases are correctly mapped to the needed requirement, which in a way tells you that you have tested a given requirement completely.
Create test data:
If you are a good tester then you never underestimate the importance of test data. If you are planning to use any of the old test data which you think will work well according to your needs then you can modify it or increase/decrease it as per the latest scenarios or you can create a completely new set of test data. Due to lack of proper test data there is a chance that you may miss one or more important test cases.
Prepare valid, invalid, boundary conditions data or may be other data related to load/stress testing depending on your needs. You can use excel or other automated tools.
Create test environment:
Setting up test environment is also an important part of testing process but may be time consuming (sometimes). Spending time early on test environment may save you from the bottlenecks at later stages of testing, when build is ready, for example. If test environment is poorly configured or is unavailable, the quality of test process will suffer. In a nutshell, in order to ensure confidence in the successful release of the application, test environments play a vital role.
Poor test environment configuration, downtime, and the unavailability of test environments can impact the quality of the testing process as well as the code itself. This is caused primarily by the lack of ownership and management of test environments.
In fact try to understand the complete application in depth:
The better you understand the AUT, the more accurate test cases you will be able to write and in turn be able to test the application in a better way (read domain knowledge here, leave the case of Exploratory testing at the moment). Of course you can test the application in case you don't have in-depth understanding of it, but that testing will be limited in one way or the other. In my experience as a tester, I believe if you have end to end knowledge of the AUT you feel confident from within and you will always be able to deliver much better and faster then otherwise.
Tasks leftover from the previous sprint (in case you work in sprints for example):
In my case, sometimes, because localization files are not available in time to complete the localization testing, so we have to leave localization testing in current sprint and take it as a separate task in next sprint. So this is another example of such an activity that you can do before latest build is available for testing because you have the old build and new localization files (probably) now.