An approach to Agile and Scrum - Part 3
05 December 2016
This is the final entry of our three part blog series relating to Argenta’s adoption of Agile and Scrum. In this post we are going to cover how we integrate one of the most important aspects of a project, testing, into our approach.
Testing comes in to our projects at three points, design, developer testing and third party testing. We start thinking about testing during the design phase of a project, where we define all the requirements for the software based on the specification. This approach is known as Test Driven Design. The principle behind this is that you design a test to prove the functionality of a particular requirement.
So if we look at a simple example, imagine a requirement to log data to file and the file name must take the format ‘Test Data DD_MM_YY’. The test for this is very simple; when the system is logging data, check that the file name of the files saved match the requirement. The test approach we would adopt here is very much a manual operation. This is not always the case, Unit Testing also plays a part in our approach to testing, but it must be for the right scenario. It’s not appropriate to try and develop a unit test for each requirement as this would take a huge amount of time and not return the value of the time invested. However, in some situations unit tests are invaluable, for example if you want to test part of a complex algorithm.
A simple example of unit testing can be explained if we have a requirement for being able to switch between two parts of an algorithm based on a trigger. We can configure a set of data that simulates the trigger and then develop a unit test to read in that data, pass it through the algorithm and check that the trigger is a) registered and b) registered at the correct point.
When the developer completes a task, they refer to the documented requirements and associated tests. They may need to determine the requirements that have been addressed with this part of the development and perform the tests linked to those requirements. Once these tests have been completed satisfactorily, that task would be signed off by the developer and passed on for third party testing.
Third party testing is performed by somebody that hasn’t been involved in the development. Their role is to review the requirements document and check that the solution meets all requirements. This will involve an element of repeating the defined tests, but also operating the tool as if they were a user.
We think one of the most important things to remember with any project management/software development approach is to evolve. You must constantly review and refine the way things are being done, with the minimum disruption to the delivery of the project.
To view our previous blogs covering the first two steps in our approach to Agile and Scrum please vist Agile and Scrum 1or Agile and Scrum 2.
Back to Blog listings