There are many programming methodologies teams adopt.
One of them is extreme programming.
In this article, we’ll look at the purpose of acceptance and how to do them.
Also, we look at how to do estimates.
Acceptance Tests
Tests are important in any system si that we can find out whether it works or not.
We should create tests as soon as possible so that we can test our system.
If we don’t, then it’ll lead to pain later on.
We definitely got to test before we ship.
Putting off overall testing until release if probably not a good idea.
If we fall behind, then testing time will be decreased.
Programmers forget what they did, so we should have tested as soon as we can.
If we test now, then we find defects now and fix them earlier.
If we find issues later, then we probably forgot what we did from earlier, so we would have to dig up what we did from memory and investigation, which may take a long time.
Extreme programming values feedback.
There are no better things than early feedback that’ll steer us in the right direction.
If there’s a way that can let programmers find mistakes earlier, then there would be a lot fewer mistakes.
There are many ways to implement acceptance testing in our project.
It’s up to the programmer to pick one.
Each programmer tests the thing they work on.
If a system is built to replace a legacy system, then they can bring over the test cases from the legacy system.
We can also use spreadsheets to keep track of what’s needed.
The values from them can be extracted and be used in our tests.
Some customers give input numbers to programmers and check the outputs by reading it.
This is a bad idea since checking outputs of a computer is an error-prone process.
It’s far better to have the correct values upfront so we can check against them.
We should have repeatable tests so that we can run them and check if our work is correct.
Automating the Tests
The tests must be automated.
This reduces of the burden of testing significantly.
However, there are many ways to do this.
We can write tests to read inputs and produce of puts.
Also, we can write unit tests to test small parts like functions an classes by running them one by one and checking the results.
We can also set up tests from a spreadsheet and run them.
GUI tests can also be done to simulate user actions.
We should build them so that they are automatic so we can run them again and again.
Timeliness
Tests need to be available in the same iteration as the story is included.
This way, we won’t forget about them.
Customers can also use automated tests to see them in action.
Estimation
Stories need to be estimated on size.
This way, we know how many of them we can do in each iteration.
Also, we can see how fast we’re going after each sprint so that we can do better planning in the next iteration.
It’s not easy to know how fast we go at first, but it’s easy to observe our pace after a few iterations.
Estimate by Comparison
We can estimate by comparing our project to similar projects.
Then we have a reference point of how fast it can be done.
If the scope and work are similar, then we can see how fast we can go according to that.
We estimate our stories in points, with each point based on 1 day of work for a perfect engineering day.
This means that we have the whole day free to work and everything foes well.
In the beginning, we can start with intuitive time estimates.
First, we begin with a spike solution, which is an experiment where we do enough work to get a feeling of how to implement the story.
If we don’t know how to do it, then we can chat with our teammates.
Then we should get an idea of how to implement the story.
Coming up with the estimate would be easy.
For each perfect engineering day of work, we give it one point.
If we feel that it takes more, then we give it more points.
If it’s more than 2, then we may ask the customer to split the story into 2 or more.
Conclusion
We should have automated acceptance tests as soon as we write our code.
This way, we can check against them as soon as we can.
Also, we can estimate our stories with points by comparing them against related work.