I received an email recently about an event happening later this month in London, UK. It's the world's first official Testathon (testathon.co). The site describes the event as "like a hackathon but for testers. You’ll be testing apps in teams with some of the best testers in the world." I know some of the judges and think this will be a fantastic opportunity for those who can attend.
When I received this notice my first thought was: this is a really cool thing and I should tell people about it. My second thought was: I don't normally write about conferences so do I blog about this or not? Well, yes, I decided to blog about it.
In the "Context-Driven" Software Testing community, actions speak louder than words. That's one of the reasons that certifications (like those from the ISTQB and QAI) are treated with low regard and even disdain from some people in the testing community. The main issue here is that these paper transactions (certifications) emphasize memory-work over hands-on practice. Here's a Quick Acceptance Test: does the [particular] certification reflect (1) a level of demonstrable competence and ability in the desired field, or (2) the ability to spend money and regurgitate specific knowledge without context?
Showing posts with label certification. Show all posts
Showing posts with label certification. Show all posts
Testing & Programming = Oil & Water
I was watching a science program just now and it occurred to me that Testing is very much science. And then I wondered about Programming.
I started in IT over 22 years ago doing programming. For me, the process of programming broke down to three parts: figuring out the algorithm to solve the problem, implementing/coding the solution, and cleaning up the code (for whatever reason - e.g. maintainability, usability of UI, etc.). It gets more complicated than that of course, but I think that about sums it up the major activities as I saw them. (SIDE NOTE: I didn't write those to mirror TDD's Red-Green-Refactor, but it does align nicely that way.)
When I think back on my experiences in programming, I don't see a lot of overlap with my experiences in Science (~ 8 years studying, researching and doing Physics & Environmental Science + teaching Science on top of that). Science is about answering questions. The Scientific Method provides a framework for asking and answering questions. Programming isn't about that. Building software isn't about that. I'm having difficulty at the moment trying to see how testing and programming go together.
It occurs to me that schools and universities don't have any courses that teach students how to build software. It also occurs to me that schools and universities provide students with the opportunities to learn and develop the skills required to build software well. The schools just don't know they're doing that and consequently the students don't get that opportunity intentionally.
I'm not talking about learning to program. That's trivial. Building software isn't about programming.
I started in IT over 22 years ago doing programming. For me, the process of programming broke down to three parts: figuring out the algorithm to solve the problem, implementing/coding the solution, and cleaning up the code (for whatever reason - e.g. maintainability, usability of UI, etc.). It gets more complicated than that of course, but I think that about sums it up the major activities as I saw them. (SIDE NOTE: I didn't write those to mirror TDD's Red-Green-Refactor, but it does align nicely that way.)
When I think back on my experiences in programming, I don't see a lot of overlap with my experiences in Science (~ 8 years studying, researching and doing Physics & Environmental Science + teaching Science on top of that). Science is about answering questions. The Scientific Method provides a framework for asking and answering questions. Programming isn't about that. Building software isn't about that. I'm having difficulty at the moment trying to see how testing and programming go together.
It occurs to me that schools and universities don't have any courses that teach students how to build software. It also occurs to me that schools and universities provide students with the opportunities to learn and develop the skills required to build software well. The schools just don't know they're doing that and consequently the students don't get that opportunity intentionally.
I'm not talking about learning to program. That's trivial. Building software isn't about programming.
Subscribe to:
Posts (Atom)