After joining CLA as a recent graduate, I joined the Digital Content Store project in November 2015, acting both as a Test Analyst and a Business Analyst. My primary tasks whilst working on this project have been advising the developers on how changes should be implemented, but also testing these changes once they had been completed. These changes include both fixing bugs within the DCS, as well as creating new features or improving on functionality, all of which have their own unique challenges!
A requirement to implement a change often starts with our users of the system encountering an issue or spotting room for improvement. They can also originate internally in order to make administration easier and to integrate the DCS with our other systems. These requests for changes get passed onto the product manager who assesses each one and decides their priority. Changes at the top of the list get developed first, and for this to happen, they are then passed onto me for elaboration of the requirements. The original idea can often already start to shift slightly here, as the analysis I carry out may reveal technical limitations, as well as the possibility of alternative solutions. The types of changes I work on span far and wide, from system integrations, DCS added user functionality and also system functionality that goes unnoticed by users such as security, administration and data structure changes. To cover all this, we need to be able to get information from many different sources, including asking institutions to assist us as development partners, talking with our technology partners, and using a number of secondary sources (technical information on the internet for instance).
Analysis of each change and the impact it could have is really important to carry out before development starts, as mistakes are more costly the later they are caught in the development process. The most common (and biggest) mistakes come from unknown dependencies in the software. A simple example of this could be that updating a book’s total page count could then put the extract over the allowed percentage limit, which would then make the content unsuitable for use. Not catching what would happen in these scenarios before giving users access means that we could create data that will need to be fixed and also means the functionality has to re-go through the change process; analysis, development and testing. Analysis is also essential for improving usability, as creating suitable workflows and formatting with appropriate colours all make the system easier and more pleasant to use. Techniques we use to help us achieve this include creating prototypes to visualize workflows, technical diagrams to visualize backend dependencies, and exhaustive lists of test criteria that cover alternative scenarios as well as the intended outcome.
Testing has to be done for a few reasons; to make sure that there aren’t any bugs, to verify that the implemented change does indeed meet expectations, and lastly to ensure that the rest of the system hasn’t been affected. To achieve this, we create plans for testing that explain all the scenarios that should be working. We also have some automatic testing tools that help test the existing features which need to be kept up to date on a regular basis. Paying close attention to details and making sure that we test everything is important because after approval, users are given access to the new features. This means being a tester carries lots of responsibility, but is also exciting because I’m the first to see the new features, and people usually come to me with questions on how it works.
Our project runs on recurring 3 week sprints. During each sprint, changes for the next sprint have to be decided and analysed, and the changes for the current sprint have to be developed, tested and released to users. This creates a catalyst for continual change so that we can keep our system up to date, our users happy and keep delivering new and improved functionality. It also means that we have to work hard to ensure everything is completed on schedule otherwise the release at the end of the sprint will have to be delayed. Keeping track of the momentum of development and responding to any issues the developers have is important towards keeping the project on track; any setbacks then need to be analysed and a plan should be devised to reduce the risk of a late release, and whether any communications need to be sent out to our users. All in all the DCS has been an interesting first project to work on, helping me to develop my analytical and team skills, and giving me some responsibility in making sure that the product we’re continually developing is meeting all of our customer’s needs and requirements!
Forward this page to a friend
