10th of March: Security (testing) & Personal developement

Friday the 10th of March our SIG (Special Interest Group) met again and this time we had a guest. Sander Nieuwenhuis, our company Security expert, came to visit and explain what his daily work consists of. After his presentation, we discussed how we can bring Security and Testing closer together. After that, everyone did a presentation in which we told the others about our personal development goals for this year. To finish the day with some fun, we went bughunting on each others projects. During our pair-testing session we’ve found some interesting new bugs on our own projects.

Security testing

Sander did a presentation about which security scans the Ops-team on a regular basis do for our clients. Some of the manual security scans are on a yearly basis, some of them are done just before a release to production is made.

The risk of doing a security scan just before a release to production is made, is the late stage in development where issues can be detected. Issues at this stage in your development cycle means you have to go back to the drawing board, and fix the security issues. Because the scans are manual, it’s not possible to do these scans more often and still stay within budget. The option to do these more often is to automate the scans. By automating them, they can be run when needed. For example, when a minor release to a test-environment is done.

As testers, we can also test for security issues. The most obvious test you can do is for cross side scripting in input fields in a website. Sander gave us a couple of hints to look for in a website how to spot possibilities for cross side scripting.

By hand, you could check what result the search-string below will give:

  • “><script >alert(‘xss’)</script>

If you are more into automation, the script below may help to find some security issues.

Personal development

The next thing on our agenda was to give a presentation of our personal development goals this year. Because the set-up of our personal development plan is agile, our goals aren’t set in stone. It’s possible (or highly likely) that the goals we have set today aren’t the goals we’ve set aren’t the ones we finish at the end of the year. During the presentation of our plan for this year, the rest of the team criticized the goals on the following points:

  • Are they challenging enough?
  • Are they doable?
  • What is missing?
  • When is this goal done?

Especially the last question was hard to answer, since we all had some development-skills on our list. But with a little polishing and rephrasing everyone had a nice start for our agile personal development plan.


Finally some time to relax. We paired up and one of the testers would test the app or website of the other colleague. With no experience of the project or product, we went testing. And we did find some nice bugs. It seems that if you let someone else test your work sometimes, you’ll probably find a blind spot in your testing.