Research through functional testing

Foreword

Very often, the developer meets with tasks that imply a change in the existing functionality of the system, or the addition of a new one that re-uses the existing functionality. In this article I want to discuss some approaches to determining the amount of work that a developer will need to do in order to plan tasks correctly.

Why plan

Regardless of the environment in which you work, be it a flexible development environment (agile) or traditional approaches, for example waterfall, there are deadlines during which it is desirable to finish the work. In Scrum, for example, a deadline will be a sprint. In any case, the team or developer provides obligations to the customer, and these obligations must be fulfilled, otherwise penalties on the part of the customer cannot be avoided.

Technical task planning

In this article, I will omit task scheduling techniques for systems that are written from scratch, and focus on the changes that need to be made in existing applications.

All the approaches that I am going to describe, I used myself in one way or another.



So:

1. Investigation of code that hypothetically needs to be modified.
   
   This approach can be used if you are very well oriented in implementation, and you can tell with almost absolute certainty which parts of the system will be subject to change.
2. Examination of system logs.
   
   If you are not sure about your knowledge of the system implementation and its behavior, you can refer to the logs. You can first ask the user to enter input data and see what trace the system has left in the logs. After that, you can say with confidence what part of the implementation of a particular business algorithm and estimate the labor costs for implementing the new logic
3. Write tests
   
   There is no user who can be accessed to reproduce the behavior of the system. And if there is, then contact each time is a thankless task, and you yourself do not want to repeat everything manually. Why not write an automated test, before implementing the algorithm?
   
   ')
   
   Yes, it is about ATDD (Acceptance Test Driven Development) and functional tests.
   
   This type of test must be taken care of immediately after the start of the project. The framework for writing and executing such tests should evolve with the project. It should be easy to expand and scale. In addition, the run of such tests must be supported on Continuous Integration.
   
   If you have a test that reproduces the current behavior of the system and you know what the result should be, then half the work has already been done. It remains to evaluate the very delta that needs to be implemented so that: a) the existing tests did not get, and b) the new test with the new expected output also passed.
   
   
   
   There is quite a political question. Is it really necessary to write such tests before scheduling a task? The answer may be the fact how quickly your functional testing framework allows you to write such tests. If this is a question a couple of hours of time, the answer is yes, it is better to write, if not, then you should think about Technical Dept and fix the situation in the near future.
   
   
   
   If you use the iterative development methodology, make sure that before the next iteration the User Story is clear enough in terms of requirements. Requirements could easily be converted to Acceptance Tests, specification by example (SBE) to help you. SBE by the way is well integrated into Testing Tools such as Fitnees, BDD implementations such as Spock, Easyb, etc.
   
   
   
   

   Morality

   
   
   Before burrowing into implementation details, consider how you will test all this. Maybe there are still not enough requirements to implement a particular feature, and then it should be postponed to a later time (sprint). Lay the time to write functional tests, watch the regression on the Continious Integration. Green functional tests are proof that you have done your job correctly, in the way that the customer wanted, and you will know about this immediately after the next commit in Source Control (early feedback). And write intelligible logs.
   
   Good luck to you.