What I learned in my career so far (part 1)

I am in interesting point in my career. I have recently resigned on my position in company I have been with for 6 years and accepted an offer from another company.

It was very difficult decision, because I like my job, the people and the team. And I am also one of those people who get very personally attached to their work - the product is "my product". However, I felt like I have to do it. I have learned some very valuable lessons here, but I felt that if I want to continue growing, changing jobs would be a good step. I also didn't want to not give new experiences and potentials a chance just because I am comfortable in my job right now. I decided to take the leap and see. As I am transferring to my new job right now, it gave me some time to reflect on the past 6 years. I will try to list some of them here.

QA guardians won't save it

When I started, I was in organization where there was a big, organization-wide QA / Development structure. QA turnover was normal practice and the software was ridden with bugs. So naturally, I started to feel like the guardian and gatekeeper of quality.

Nowadays, I understand that quality comes from writing the software, not testing it, and the role of a tester is to be present and help prevent problems throughout the development. I learned to work closely with programmers and we developed mutual trust. We leaned together to think about testing first, then coding. I actually do more coaching than testing these days, yet I still feel I contribute to the quality more. The programmers I work with do a lot of testing, and I fully trust them to do a good job. They feel the same amount of responsibility for quality that I feel.

Testing is a craft, requires skill and experience and continuous learning 

I used to think testing is about talent. You either have this special gift to stumble across those bugs, or you don't.

As with many crafts and arts, testing is largely about experience. As a craftsmen, you have to practice and exercise your skills, but also vary your work in order to keep improving - try new things, experiment. Don't do the same thing over and over again, because that is the way you always did it, and it always worked.

Btw, testing is not inferior to programming, nor it is less demanding

Formal test management is mostly a huge waste

There were times on this project where we could not cope with the amount of testing during development combined with all the need for regression testing and hardening before the release. At one point, we thought to solve this by better and more rigid test management. Any guesses what happened? It was such a pain that we of course abandoned it pretty quickly.

Now what we do is exploratory testing, charters, heuristics - lean stuff. I also believe in using techniques such as ATDD and BDD, which provide you with living documentation of the most important business use cases that you product must satisfy (and they are automated, how nice).

Don't automate for sake of automation

I am always terrified when I see a company goal of 100% test automation. What a stupid idea. I learned this lesson the hard way. Never automate to achieve automated test coverage.

I already mentioned I believe in use of ATDD and BDD. That is because those practices do much more than automate tests. They provide executable examples of the most important business logic of the product.

Good team is more than star individuals

A team of good, if average, people who work together and communicate will do much better work than one coding or testing super star who works alone. Good communication in the team is absolutely crucial, as is trust.

Testers need to understand the technology and domain

At some point in my career, I may have though of my work as "whatever you will give me, I will test." The problem with that is it leads to a belief, that testers just execute tests. Over the years I learned that is no way enough. 

As a tester, I need to have deep domain knowledge of the product I work with if I hope to uncover anything more than the surface annoyance. Along with that, I also need very good knowledge of the environment where the software exists or potentially could exist.

As a tester, I also I need a very good knowledge of the technologies the product consists of, or interacts with. This includes the programming languages the product is written in. I do believe testers benefit form knowing how to code. Especially, knowing how to code in the language their product is written in.

Testers need to have full access

Testers should always have access to the source code, all development environment and resources, build machines and so on. Testers should always be able to get latest code changes, build it, run it and test the product - at any given time. Having this available allows testers to provide feedback very early, early enough to influence the ongoing development and prevent many problems.

I called this post "part 1". That is because as I embark on the my new journey I expect to evolve and and learn more, or change my opinions.