OK works - Reflections from an oldimer tester getting back to testing recently

Seeing likes I suppose I got it right, so here we go…

So I got out of my Scandinavian university 1989 having studied computer science, understanding, with some regret, that programming is something I can do but not really my talent. Especially all these “frameworks” and concepts like Object Orientation and programming patterns wasn’t something I understood quickly. But well, I applied for a job as a programmer at The Big Telecom Company that hired engineers in abundance those days.

But coming to work my first workday I got the message “You are going to work as a tester”. WTF?? Well, I could always change later… but starting working I quite quickly discovered it suited me perfectly. You have to understand a system. And both find all the faults and give confidence to customer that it works. So I tested, became quite quickly “team manager”, which in those days was pointing at testers, saying you should to that and you should do this. And I was a decent trouble shooter without being a super one. But I did good stuff, especially talking, to make systems work. I understood the system and what people did to make the system work.

Technically, it was stuff like either running a CLI or using some kind of interface driver to send in stuff and checking text results. And - understand the system. A good deal of automation was done, which was something like Postman automation .

Then… I moved on to other things, mainly managing this and that. First in the telecom business, then in other business. As for many others, the IT crash around 2000 was not the best of times and, well things went up and down after that. And I had to commute for hours. Then - I got the chance two years ago to start working for a governmental facility in my home town doing testing. And thats where I am now.

But lets move back to those turbulent 00´s and 10´s. I wasnt a tester but I saw trends and I had quite close contact with people doing testing from time to time. And AUTOMATION became like the buzzword. Well OK. We did automation back in the 90´s. But now testing managers brought in LISP like languages, very difficult to grasp, and a big challenge for testers. But an enormous effort was made to autmate everything everywhere. And on came the concepts of fast deliverys, daily builds and tests, screens with red and green test runs and so on. I saw it from some distance and thought, well OK, maybe thats a good idea. Maybe.

On came the concept of Lean, Agile, Kanban and Sprints. Of course one could see the advantages, having managed programmers, but well, another one of those maybe good ideas. And how did really Testing fare in such an environment?

Starting my current appointment I was about to find out.
What I test now is a lot of web pages, services, that scientists and people in common can use. To see the result of what is produced in the governmental facility. Very rich guis, that changes all the time. The colleague tester quite quickly made me understand that yeah we use some selenium webdriver, but mainly we test manually. Funding in a governmental unit is somewhat complex and well, there is not money to automate “everything” that once was the plan. So we have some regression test suites that we painstakely update when GUIs change. And well, there aint id tags all over the place… But mainly, we test manually. And to quite a lot of exploratory test.

Azure DevOps is what drives projects and well, for programming its great. But I am not really fond of the way test is supposed to be handled. All tasks and bugs get their tests and you end up with a big, rather unordered bag with test cases. We do make regression suites and so, but well… we test functions. Its really great to test a lot manually, to do exploratory, finding loads of bugs. But in the old days there was a function specification and you wrote a test specification, matching the requirements, and you ended up with a pretty neat test document that you could keep updated. What has bugged me since my university days is that all programming theories and stuff very much focuses on NEW programs, when I during my 30+ years nearly always have been busy updating old ones.

I do understand the rationale about the agile, but it comes with costs. Its not a heavenly sent miracle that takes away whats difficult about keeping large systems updated. The kind of other , old, way around was to have teams of programmers and testers that were experts on some part of the software. That came with problems, it was not an agile way to do stuff. but it had its advantages. For programming as for testing.

I’m looking for good ways to really make testing - especially testing of systems with large, unstable GUI´s, In an Agile development process - as effective as possible. I still do have some rust, and I might not have really understood the agile process advantages test wise and the latest GUI automation possibilities fully. But I know a bit about software development.


Basically the reason Microsoft famously fired all of their testers at one point. Because in an ideal world, developers have to write all of these tests. But we know that they are lazy. It kind of stems from code being written without TDD/BDD strongly in mind. Not having a maintenance plan for every application. Not wanting to commit to long term costs and the extra architecture work that “stable” apps benefit from by being able to change the GUI easily without breaking the testing. But… you have just completed this journey, and you seem to have picked up all of the medals and badges. Or at least you have the scars to prove it now @anders62.

Welcome back to the club. :slight_smile:

I’m not even going to comment on the unstable GUI problem space, that’s an entire love triangle book on it’s own. As for the argument that agile is not working, well, we all know that if agile is just used as a “mini-waterfall”, that you are still just on the same river you were before.


I can relate to a lot of this, its interesting to watch some of the repeated cycles over the decades.