Almost two months ago ago was my last day at RSA, and I wrote a bit about it in Hebrew. I intended to publish The English version at the same day, but barely managed to get the Hebrew version out, and as it turned to be, I was a bit occupied in the past couple of months, part of it was preparing my workshop for Nordic Testing Days. Now, when I'm at the airport, waiting for a long connection, I have some time to catch on this gap.
After seven years and a bit, following an opportunity that jumped into my hands, I decided to move on. What can I say? It's not an easy decision to make after so much time, especially since RSA was my first "grown-up" job where I've learned a lot and where my entire professional persona has evolved. Such turn points are a good opportunity to look back and reflect, so here I am, reflecting.
The easiest thing is to drown thoughts with numbers, and thus I'll start with it:
- Seven years
- 41 team members
- 8 managers (two of which were team members before)
- One product, two versions (of a sort)
- ~25 major releases
- 13 conferences in which I've participated, in 4 of which I attended as a speaker
- two certification diplomas, one is completely useless, and the other one is not much more so.
Naturally, those numbers are not telling any significant story, and tell nothing about how my professional approach has changed alongside with my role.
Officially, my role in the team has not changed. I was hired as a (junior) tester, promoted to a (senior) tester and even to a (principal) tester. Each promotion came with the expectation "please continue to do what you are doing". In practice, what I did changed drastically.
I started my way in RSA fresh out of the university after a friend who worked there referred me, and since all I knew about testing was what I've learned in one introductory course to software testing, I thought that the job of a software tester is to test software (spoiler - it is not). I started with almost decent programming skills, and with knowledge about testing that was just a bit over the required knowledge to pass the ISTQB CTFL test (The professor passing this course was a member of ITCB - the Israeli chapter of ISTQB, but we had some extra material in to fill a semester-worth of course for CS students that don't need to waste time on "what's a loop"). This meant I came prepared to write mountains of documents and to deeply analyze the software I was about to work on. Frankly, my initial experience was pretty close to that: I came to what soon became six regression cycles running back to back due to some major changes that incorporated a lot of risk - we upgraded the OS and then upgraded some central components in our system, so we had to go over most of the system just to see that nothing was very broken. We worked with tests that were written some time ago in Quality-Center, and with rudimentary automation that wasn't that great, and in most cases - simply wasn't there. In fact, one of the test scripts was so poor that I asked for, and got, some time to re-write it using the framework we've started building so that it will be easy to understand what's going on and in case of failure, understand what were the symptoms of the failure. All in all, my focus was on learning the product and while doing so, learn also how to test software. Oh, and bugs, what fun was it to find bugs.
After about a year I got to a point of unease - I was a bit more familiar with the product, and I thought I did a decent job, but I felt that my theoretical knowledge on testing wasn't improving and I looked with my then manager (The third one, after maternity leave and a wave of layoffs) and we came to a conclusion that a course could be a good thing. But what courses are available on testing? We didn't find anything we thought was relevant or useful, but there was a CTFL certification course, so what the heck - company's paying and we're out of ideas. Now's probably the time to say: Despite what I have against this lousy certification, the preparation course can be used to learn a thing or two about testing if the instructor is experienced, you have some knowledge about how real software projects look like and you are prepared to ask a lot of "why" questions each time you hear a recommendation that does not align with reality (which is about 90% of the material). I got out of the course with some ideas for improving our process, which, unsurprisingly, included more paperwork. I think this was a point where I can mark a changing point - about the same time I decided to act upon a rumour I heard back at the university that said professional hi-tech workers should real to always stay current. I probably started doing some reading a bit before the course, but it takes some time for knowledge and impact to accumulate. That second phase came when I've encountered James Bach's &Co. ideas, out of which the most representative example is probably this video. Another idea that I found very helpful was the concept of the "testing schools" which I found convenient, as it connected well with what I learned at the university about different literary schools and, more importantly, different paradigms 1.
The concept of different testing paradigms seemed very sensible to me, and the division to five schools was convenient. The factory school, which is represented very clearly in the ISTQB syllabi (mostly in the CTFL, but it was in the others I skimmed through), is focused on managing the testing process, and treats software creation like an assembly line - where consistency and predictability are the main focus, as well as cost saving. The analytical school focuses on scientific and formal methods of measuring and improving testing, and it provides tools to practitioners of the other schools that are busy with the real world of software delivery. The agile school is focused on the developer's perspective - unit testing, TDD, fast feedback and freeing bottlenecks are the bread and butter of the agile tester, and this school provides language to engage non-testers in testing, which is mission-critical in most software projects. The control school (or, in Pettichord's terminology - "quality assurance school" tries to understand how to prevent mistakes from getting to production, on setting standards and regulations and deploying measurements to deal with bug escapes). The line between this one and the factory school is a bit blurry, but I think that having two focal points is important enough to have those two schools separate. The final school, which has assumed the title "Context Driven school" (To be honest, only people within the CDT communities are using the notion of testing schools. Others, such as Rex Black, are opposed to it) and is focused on the skills of the individual tester and treats testing as performance - In the balance between personal skills and methodology, the former has much more influence on how effective will the testing process be.
The message carried by the CDT community appealed to me very much - It said that *my* skills are the most important to do a good job, and I found there encouragement to think on how I test software and to notice the language I was using. My focus shifted gradually from processes and bug finding to improving as a software tester.
Roughly at the same time, by the end of 2013, I connected, almost by mistake, to the local testing community. A colleague of mine told me of a testing meetup in Jerusalem and I thought it could be a good way to connect with people working in the city and maybe find my next position (I don't know if I mentioned it before, but when I first started in RSA I had full intentions of staying there for a year or two and then return to Jerusalem. A blink of an eye later and seven years have passed, me still living in a self imposed exile) I got there, met some people, and someone managed to convince me to participate in an online forum (Facebook wasn't as dominant as it is today in the testing community in Israel, or rather - the forum wasn't yet as dormant as it is today). This is how I began chatting with other testers and going to meetups.
In the meantime, things progressed at a slow and comfy pace at work - my coding skills improved, I learned the product, people and processes and there even were parts of the product I was the expert on, having been the one working on them. In addition, my team was maturing as a scrum team: We've learned to work closer and minimize gaps between functions in the team and the pace was speeding up nicely. As time passed, I noticed that most of my contribution was not while I was "working" with the software but rather when I chatted around with other team members, offering some advice, passing on rumors and asking questions, and then Brendan Connolly wrote this post, which connected well with what I was experiencing and it helped me define my role as a nexus of information and not as "someone who comes to check that everything's ok"
Time passed, and some of the faces around me changed, when I started noticing that not enough testers at work are showing interest in professional development, and unsurprisingly, things had some place for improvement. It wasn't only that information didn't really pass between teams working on similar products, but the standards were different as well: People who worked for years in one team didn't have the skills to even pass a basic interview for junior position in another, let alone function in that team. Once I noticed this phenomenon, it was impossible to un-notice it, so I looked for ways to help resolve this (I was sadly unsuccessful in that). Completely unrelated to this but about the same time I saw a post in Maaret's blog I was (and still am) following that published an experiment - half price tickets for a testing conference, based solely on the reputation of the organisers. Well, cool. I was wondering about professional conferences, but they were quite expensive to try out and pay for myself, and this one was not that expensive, and being in Romania it was a cheap enough flight and the extra expenses were also cheap enough for me to decide on taking a vacation and attend the conference. What can I say? The European Testing conference was a great conference to start with - I met awesome people, learned a bunch, and came back home with some ideas I wanted to try out. It was also the point where I met the European testing community2 and started disconnecting from the American CDT ideas (mainly because I connected more to an inclusive discussion instead of the debate oriented one).
I was also influenced by the changes in my team - when one of of our developers left, I found myself in a position where I was the only one in the team who was familiar with the bureaucracy around software security (or rather, the only one who was familiar with it and wasn't already swamped with back-to-back meetings) I had the opportunity to develop my understanding in software security and became the team's expert. On a side note, being an expert does not require any specific knowledge, just declaring "I'm an expert", and whenever anyone comes to you with a question, respond with "I don't know, but let's figure this out together". Another such event was when after 5 years at RSA my manager for 3 years, who was a technical leader in the team when I joined, left to work at another place and I had to help my new manager to figure out what was going over, and in the meanwhile to shield the rest of the team from external pressures. I was thus exposed to just enough of the process of managing people to know that this is not something I want to do at the moment.
All of those processes, alongside the progress we made in combining the test and dev parts of the team, and listening to the ABTesting podcast helped me grow to the paradigm that currently appeals the most to me, which is phrased quite eloquently under the modern testing principles, which despite the name, is not a testing paradigm but rather a software production (or however you would call the process of defining, developing, testing and deploying an application) one. There is one point on which I disagree with those principles, and this is the exaggerated focus on the "customer". I wrote about this before, so I won't go into it again, I'll just mention that for me - the business comes first. I work for my employer, and in the cases where my employer interests are not aligned with the customer, I'll choose my employer.
After all this time, when I'm looking back, what I see is mostly people. Those who were there when I arrived and those who stayed there when I moved on. There were good and difficult times, and each person added their own unique something into this cauldron. I think I learned at least a bit from everyone I worked with (even if some people taught me patience by testing it over and over), I've learned that every software out is a matter of compromise, how to work as part of a team and how to write better code and talk about the principles that guide me. I learned a thing or two about software security and bureaucracy and how to both ask and receive help. Most of all, I've learned that the most important thing are the people you work with.
So, thank you for everything, and we'll probably meet again.
The concept of different testing paradigms seemed very sensible to me, and the division to five schools was convenient. The factory school, which is represented very clearly in the ISTQB syllabi (mostly in the CTFL, but it was in the others I skimmed through), is focused on managing the testing process, and treats software creation like an assembly line - where consistency and predictability are the main focus, as well as cost saving. The analytical school focuses on scientific and formal methods of measuring and improving testing, and it provides tools to practitioners of the other schools that are busy with the real world of software delivery. The agile school is focused on the developer's perspective - unit testing, TDD, fast feedback and freeing bottlenecks are the bread and butter of the agile tester, and this school provides language to engage non-testers in testing, which is mission-critical in most software projects. The control school (or, in Pettichord's terminology - "quality assurance school" tries to understand how to prevent mistakes from getting to production, on setting standards and regulations and deploying measurements to deal with bug escapes). The line between this one and the factory school is a bit blurry, but I think that having two focal points is important enough to have those two schools separate. The final school, which has assumed the title "Context Driven school" (To be honest, only people within the CDT communities are using the notion of testing schools. Others, such as Rex Black, are opposed to it) and is focused on the skills of the individual tester and treats testing as performance - In the balance between personal skills and methodology, the former has much more influence on how effective will the testing process be.
The message carried by the CDT community appealed to me very much - It said that *my* skills are the most important to do a good job, and I found there encouragement to think on how I test software and to notice the language I was using. My focus shifted gradually from processes and bug finding to improving as a software tester.
Roughly at the same time, by the end of 2013, I connected, almost by mistake, to the local testing community. A colleague of mine told me of a testing meetup in Jerusalem and I thought it could be a good way to connect with people working in the city and maybe find my next position (I don't know if I mentioned it before, but when I first started in RSA I had full intentions of staying there for a year or two and then return to Jerusalem. A blink of an eye later and seven years have passed, me still living in a self imposed exile) I got there, met some people, and someone managed to convince me to participate in an online forum (Facebook wasn't as dominant as it is today in the testing community in Israel, or rather - the forum wasn't yet as dormant as it is today). This is how I began chatting with other testers and going to meetups.
In the meantime, things progressed at a slow and comfy pace at work - my coding skills improved, I learned the product, people and processes and there even were parts of the product I was the expert on, having been the one working on them. In addition, my team was maturing as a scrum team: We've learned to work closer and minimize gaps between functions in the team and the pace was speeding up nicely. As time passed, I noticed that most of my contribution was not while I was "working" with the software but rather when I chatted around with other team members, offering some advice, passing on rumors and asking questions, and then Brendan Connolly wrote this post, which connected well with what I was experiencing and it helped me define my role as a nexus of information and not as "someone who comes to check that everything's ok"
Time passed, and some of the faces around me changed, when I started noticing that not enough testers at work are showing interest in professional development, and unsurprisingly, things had some place for improvement. It wasn't only that information didn't really pass between teams working on similar products, but the standards were different as well: People who worked for years in one team didn't have the skills to even pass a basic interview for junior position in another, let alone function in that team. Once I noticed this phenomenon, it was impossible to un-notice it, so I looked for ways to help resolve this (I was sadly unsuccessful in that). Completely unrelated to this but about the same time I saw a post in Maaret's blog I was (and still am) following that published an experiment - half price tickets for a testing conference, based solely on the reputation of the organisers. Well, cool. I was wondering about professional conferences, but they were quite expensive to try out and pay for myself, and this one was not that expensive, and being in Romania it was a cheap enough flight and the extra expenses were also cheap enough for me to decide on taking a vacation and attend the conference. What can I say? The European Testing conference was a great conference to start with - I met awesome people, learned a bunch, and came back home with some ideas I wanted to try out. It was also the point where I met the European testing community2 and started disconnecting from the American CDT ideas (mainly because I connected more to an inclusive discussion instead of the debate oriented one).
I was also influenced by the changes in my team - when one of of our developers left, I found myself in a position where I was the only one in the team who was familiar with the bureaucracy around software security (or rather, the only one who was familiar with it and wasn't already swamped with back-to-back meetings) I had the opportunity to develop my understanding in software security and became the team's expert. On a side note, being an expert does not require any specific knowledge, just declaring "I'm an expert", and whenever anyone comes to you with a question, respond with "I don't know, but let's figure this out together". Another such event was when after 5 years at RSA my manager for 3 years, who was a technical leader in the team when I joined, left to work at another place and I had to help my new manager to figure out what was going over, and in the meanwhile to shield the rest of the team from external pressures. I was thus exposed to just enough of the process of managing people to know that this is not something I want to do at the moment.
All of those processes, alongside the progress we made in combining the test and dev parts of the team, and listening to the ABTesting podcast helped me grow to the paradigm that currently appeals the most to me, which is phrased quite eloquently under the modern testing principles, which despite the name, is not a testing paradigm but rather a software production (or however you would call the process of defining, developing, testing and deploying an application) one. There is one point on which I disagree with those principles, and this is the exaggerated focus on the "customer". I wrote about this before, so I won't go into it again, I'll just mention that for me - the business comes first. I work for my employer, and in the cases where my employer interests are not aligned with the customer, I'll choose my employer.
After all this time, when I'm looking back, what I see is mostly people. Those who were there when I arrived and those who stayed there when I moved on. There were good and difficult times, and each person added their own unique something into this cauldron. I think I learned at least a bit from everyone I worked with (even if some people taught me patience by testing it over and over), I've learned that every software out is a matter of compromise, how to work as part of a team and how to write better code and talk about the principles that guide me. I learned a thing or two about software security and bureaucracy and how to both ask and receive help. Most of all, I've learned that the most important thing are the people you work with.
So, thank you for everything, and we'll probably meet again.
1 In short, a school is a group of professionals that share a common paradigm (maybe more than one?), and a paradigm is an angle to look on and define the problem space in a field. It's a set of questions that are interesting and some tools to answer them.
For example, the "reader's response" school is focused on answering the question "how is a text processed by a reader and what are the mechanisms through which a text is having its effect on us" (So, The Iliad would be a very different thing for contemporary readers and ancient Greeks). Questions such as "what was the writer's intentions" are mostly irrelevant and secondary to the perception of the act of reading as a dialog between the reader and the text) ↩
2 I use the term "European testing community" from my own personal perspective, There are multiple testing communities in Europe, with varying amounts of overlapping. I use this term to note the people I met through ETC (not necessarily at ETC, though) ↩
No comments:
Post a Comment