Date: Sunday 19th February 2017
Time: 3.30pm – 5.30pm GMT
Facilitator: Neil Studd
Attendees: Dan Billing, Gem Hill, Erik Hörömpöli, Nasimul Huq, Srinivas Kadiyala, Emma Keaveny, Christian Kram, Christian Legget, Maja, Gita Malinovska, Vijaykumar Nadeshan, Bhagya Perera, Ram, Kinga Surányi, Dolores Zurdo
There are very few degree-level computing courses which are testing-focused, or which contain testing elements. So it’s hardly surprising that (as we discovered from this session’s attendees) many people feel as if they “fell into testing”, as there was no clear career path which led them into the industry. There are various professional testing certifications available, but these are often aimed at existing testers who want to demonstrate a particular skill level (and the certifications are often very poor at meeting that need).
In this month’s session, we imagined that we’d been granted permission to present a testing module within a university Computer Science course for a single semester (12 weeks of 1-hour classes). Within each group, we considered what skills or techniques would you like to teach, in order to make students interested in testing, and to help them discover whether they have the ability (and passion) to pursue testing as a career.
After an hour, the three groups reported back on what they’d sketched out:
- Group A framed their course around something practical, starting to review an application in Week 1 and building upon knowledge in future weeks using the same application. This would give students a tangible sense of progress as they discover new theories and techniques which they can apply each week.
- Group C focused their plan around skills (e.g. questioning and communication) rather than test techniques, and were also keen on a “learning by doing” approach. They were keen to keep students engaged and passionate by allowing them to be hands-on, which sounded like a very positive experience for students, although I suggested that it might frighten university heads who expect a more traditional curriculum!
- Group D took a more high-level approach, but in doing so they managed to sketch-out a full 12-week plan with assignments and reading material – a heroic achievement within an hour! They focused on providing a diverse selection of viewpoints, rather than presenting “one way” of doing testing, and introducing students to the wider testing community.
Between the groups, we brainstormed a wide range of resources (books, blogs, applications and videos) which we would use to aid in educating new testers. There’s far too many to list here – if you open each of the syllabi in the Resources section, you’ll find a whole host to choose from!
We finished by looking at the syllabus for a real-world university module: Aston University’s “Testing and Reliable Software Engineering” module (linked below). Their approach seems very traditional (focusing on name-chcecking a range of core testing-related concepts), and the final examination (80% based on an exam and the ability to write a test plan) appears to be quite narrow. But it’s still more than many other courses are offering, and we concluded by agreeing that we wish that more of our ideas could be represented in educational courses.
Resources:
- Session Transcript (including group chats)
- Group A’s syllabus
- We didn’t have a group B 🙂
- Group C’s syllabus
- Group D’s syllabus
- Aston University’s syllabus
Neil is a tester from the United Kingdom who has been testing desktop, mobile and web applications for the past ten years, working in a range of agile roles for organisations as varied as Oracle and Last.fm. In his spare time, he participates in freelance and beta testing projects, as a way of learning and developing new approaches to testing.
Interesting to read this. As someone who teaches software testing at a University it’s useful to see what other people think and compare with what we do. As university faculty, in developing syllabi, on any topic, we are faced with a number of additional challenges prior to a module being adopted on a programme:
1. What is the thrust of the programme(s) in which the module resides? – e.g. maybe the programme is aimed at producing software engineers in which case more emphasis may be required to be placed on development/unit testing in any software testing module.
2. In what year should the module reside? – most undergraduate honours Computing programmes are 4 years, so at what point should testing formally be introduced as a module(s)?
3. How many hours per week are available for the module. In your case you had 12 hours available across a semester for such a module. This doesn’t leave a lot of time to cover many topics in any detail which may be where potential testers find their passion by getting to know how to do something rather than just be aware of something.
4. Typically, each module will have an assessment component and a final exam. What format will these take and what sort of questions are you going to ask based on the syllabus content?
In developing real syllabi to deliver to students we have to cater for all of the above. I think it’s great that people are even considering how software testing could be incorporated into University programmes, but rather than just ask “why are universities not doing this”, we need to be aware of some of the constraints and challenges that may exist and which need to be overcome if this mission is to succeed.