Skip to main content

Live and learn


In spring I wrote about a big change on my career, continuing to work as a tester but changing almost all other aspects of the working context, the aspects being:

From
- Customer acceptance testing role into Developing our own products
- Waterfallish into Agilish project models
- Business oriented & simple into Mission critical & complex domain
- 8000km from developers into a Few meters from developers
- Consultant into Employee
- Non-technical into Technical

So how has it been?

Comparing my new job between the jobs in the organizations I've previously worked for isn't really possible, or fair, due to the many contextual differences (trust me, I worked on a blog post comparing the differences for a long time until eventually scrapping it). But still there are huge changes that have happened to me as a tester, which I'll briefly discuss here.

Information over-flow
The biggest change has happened regarding getting information on the contents of the changes I am testing. I had got used to spending a lot of time digging through different communication layers in order to get some rational data about what, why, and how the changes were done. Now it's almost the opposite: very approachable developers eager to help me and extremely dedicated product owner sitting behind me. Mandatory descriptions on how changes are done and how those should (at least) be tested are documented and available. Full access to code repository to see the specific code changes done per a change. All kinds of documentation regarding the many aspects of the system we are working on. Now my problem is to try to solve which sources of information to use and when, and to understand the information I get.

Testability
Was previously just a word for me. I had gotten used to having testability built in through the user interfaces, and having little or no need for any "test features" (now that I am thinking, I would have had a need for these many times...). Now after working on algorithm development where there is initially little or no control to the inputs, and little or no visibility for the outputs they produce, the situation is really different. I have to be active in asking and suggesting ways how these variables can be modified dynamically during testing, and in trying to convince (myself and others) that those are worth the development effort needed. Today, test interfaces are my trustworthy friends, and logs are my lovers.

Authority
As a consultant, I had started to think that I am a software testing expert. I had started to think I knew the secrets of the software testing business. I had started to think, that I am to software testing what Neo was to the Matrix. Awakening from the day dream was pretty rough (actually it also kind of felt like Neo's awakening in Matrix looks like :) ). So currently, I think, I'm looking at the world of testing with a bit more open eyes, and open ears. (though I think it is already passing and my ego is starting to rise again, alas this blog post).


Agile testing
Hey, not that much has changed there. Of course there are differences due to the changes in the context, but testing is still testing: exploring, learning, and experimenting. Huib Schoots said it beautifully and I agree:

there is no Agile testing, but instead testing in agile context.

 Live and learn.
Labels:

Comments

Post a Comment

Popular posts from this blog

Periodical retrospectives are lame

  "You got nothing, not a single thing?! Well lets just end this here then." I remember well when I said this, being very frustrated. About ten years ago I had been working as a Scrum master for a team some months, and putting quite a lot of effort into planning our scrum teams sprint retrospectives. Lot of work also because I felt we were not getting too much out from them; not very good discussions, very few actions, and even the few actions we did come up with did not stick.  And then it happened: a retro where none of the participants came up with anything to say about the sprint. Regardless of the retro topic boxes, reading of books on retrospectives, getting inspiration from tools like retromat.org, having them in different places, using all kinds of different formats and rainbow coloured post-it notes. Not a single thing. Blank.  So then I said the words, out of frustration, mainly to myself. Why couldn't I get this thing everyone is so hyped about to work? After t
Post a Comment
Read more

I don't report bugs

I don't report bugs . Bug is such a loaded word that people understand very differently, that instead of using it and explaining what I mean by it I rather just use other words. Like observations, thoughts, surprises, ideas, alternatives, or something similar. (And no I don't use fault, defect, or error either). Bug has also quite a negative connotation. "Reporting a bug" is kind of like telling someone that they've been served. And as we are actually giving away the gift of information, why wrap it in such a nasty package? And maybe more importantly it is very likely that whatever you might have to say is wrong. If not plain wrong, then at least incomplete. So I like to approach the kind of situations with the assumption that I am probably wrong. Cutting off anything that might sound arrogant makes stuff quite a lot easier. Especially after you realise later on that you have been wrong. I leave plenty of observations unreported . I don't want to waste
Post a Comment
Read more

Testing drunk

(My first blog writing ever.) I've been thinking a long time that it's funny how many bugs I find by accident. Try to do something, make a mistake and boom - a bug is found.  Making the mistakes intentionally doesn't quite work - that's why they are called accidents I guess.. So I've thought of ways to make myself more prone to accidents, coming up with an apparent one; testing drunk. TUI (testing under the influence). So this I gotta try. More to come on that later.
3 comments
Read more