Course code: VOL-1
  • Years with company: 3
  • Years programming: 7
  • Primary programming language: C
  • Other programming languages: python
  • Unit test harnesses: CUnit
  • Something else: I've been working in the company for almost three years, started immediately after university. Now I'm Scrum Master for one of the development teams and I try to combine Scrum Mastering and development/testing. Outside of work I hang out with friends, exercise, go to pubquizzes and have a passion for 70s progressive rock.
  • Test practice now: Unit tests, tests on component level after changes are integrated, HIL test in system rig and test in truck.
  • Target system: Instrument cluster, displays to provide driver information
  • Dev tools: Vector Davinci, CANoe, Jenkins, Visual Studio, PN-Tool, SE-Tool
  • Build time: 5-30 minutes
  • Coding standard: Misra C
  • Function too long: Trying to follow the principle that a function should do one thing and one thing only. It is easy to understand the purpose of the function by looking at its name and the code can easily be followed.
  • Code reviews: Mostly handled within the team. We can't merge without approval. Checking that logic looks correct (have we understood the requirements the same way), new Misra warnings aren't introduced, unit tests cover all scenarios, the code looks pretty, etc
  • Code time: 40
  • Test time: 40
  • Debug time: 20
  • Favorite thing about dev: Trying to solve a logic problem or design a simple solution and being able to rather quick test and get feedback on if it works or not. The teamwork.
  • Least favorite thing about dev: Bad tools or processes slowing down the development.
  • Tdd knowledge: I've seen the Clean Code episodes about TDD. Start by writing a simple test, then don't write more code than needed to get the test to pass. Update test case with new scenario so it fails. Code again and repeat this process. Refactor inbetween.
  • Why are you attending: As both Scrum Master and member of the development team I've been pushing for the team to improve quality. Coming from more of a implementation background myself, I look forward to get inspiration for how to improve the team's test methods.
  • Back