The end of August marked the completion date for Tom our intern. As I wrote about in a previous post we'd offered Tom an internship placement with my team during his summer break. He spent 8 weeks with the company, the first two being spent job shadowing and doing work experience, followed by a 6 week individual test automation project.
Over the first two weeks we spent time introducing Tom to the principles that we followed in developing our software, and the importance of testing to our success. We spent time on both specific development and testing concepts and also developing more general business skills to support these. Watching Tom struggle through the first week trying to keep his eyes open after lunch reminded me of the shock to the system that I had working full time after a student lifestyle. I like to think that it was no reflection on his level of interest in what he was doing.
A critical and often overlooked factor in successful testing is the ability to communicate effectively with the business. This is a skill area that graduates aren't necessarily exposed to through their academic studies so I spent some time with Tom on making presentations, attending meetings and managing emails. Tom practised these skills researching and making a presentation on 'Testing in an Agile Context' to the team.
An Agile Internship
In the subsequent weeks we split Tom's test automation project into a set of user stories, each delivering value to the test team. One of our senior developers helped Tom with creating a set of unit tests and a continuous integration build. The other testers and I helped him with creating his testing charters and reviewing his testing. I introduced him to ideas around exploratory testing, using great articles by Elisabeth Hendrickson and James Bach to introduce essential principles.
I think the style of work and the level of interaction among the team was very new to Tom. He relished the working environment and took to his tasks with enthusiasm and diligence. He completed the initial story well and went on to deliver a second to add additional valuable functionality.
Tom wrapped up his internship with a presentation on his experiences to our VP. He had had a fantastic time and learned a huge amount. Tom's feedback on the team was that, despite the fact that everyone was obviously busy they always had time to help him. This is a really important part of our culture so I'm pleased that in his short time, working on a relatively low priority project, Tom still developed this perception. He felt that we were a great company and just the sort of place that he would like to work in future.
An Educational Gap
Over the summer I hope that Tom has developed a solid understanding of agile methods and the importance of testing in a successful software company. Based on conversations with Tom it was apparent that these were subjects that suffered from limited coverage in his University course. According to Tom on his group development project there were no marks attributed to the error handling or stability of the delivered software. Demonstrating that the final solution had been tested was not a requirement for the project. In my earlier post I lamented the lack of exposure to testing as a career option in universities. The lack of a requirement to demonstrate testing at all is a more fundamental concern. One of the biggest problems I've seen in software that I have tested has been that validation and error handling have been secondary considerations after the initial functionality has been written. Not every graduate programmer will adopt such an approach (just as not every tester measured on their bug counts will focus on raising arbitrary cosmetic issues), however it relies heavily on the integrity of the individual not to slip into bad habits. How can we expect anything other than a trend towards delivery of the happy path functionality alone when it is clear that this is exactly the approach that is promoted in university projects?
Tom returns to his final year with a good understanding of testing and agile approaches, and a copy of Gojko Adzic's 'Specification by Example'. When questioned over whether his experience would assist him in his final year he was unsure, given the lack of exposure to agile in the university CS syllabus. I am more hopeful - I subsequently persuaded him that an agile style approach to his dissertation project on AI modelling, delivering incrementally more complex models, would be an ideal tactic to ensure he did not overrun. This is obviously a small pebble in a large ond, but if more companies offer these placements and expose students to the methods and skills being used in commercial software development, along with the importance of testing, then maybe the quality of our commercial applications will benefit as these students progress into their careers.