Two Different Schools of Testing?

🗄️ Archive
1

I’m sure many of you have read the LinkedIn article recently whose title was recently updated to Stop hiring software checkers. I’ve been pondering the post for a while trying to figure out how I felt about it. I think the updates helped to clarify the original intent about the post.

I saw another blog post that followed this one called Two new…schools? and I think between the two blogs posts there are a lot of things that could help to generate some discussion.

When I read the second blog post I felt quite lucky on my team. We don’t release often or always but the developers on my team do their bit with testing and checking. They do some integration checks before merging code, they have started security testing, there are benchmarks for code performance on a basic level. For my part I regularly write/edit user stories, take part in story boarding, help the developers think about how our customers will experience the product and discuss the end to end experience. I’ve never felt like this was getting me into the quality assurance business but I knew that it was different to “traditional” testing.

Are there perhaps more than two “schools” of testing?

4 Likes
2

What stuck with me about Alan’s post was the getting into the quality assurance business. So many of us have been saying for years that we are not ‘QA’, we don’t assure quality and what not. And sure, we don’t, but are we doing ourselves as a community/profession harm but trying to disassociate ourselves with the term ‘QA’?

It’s certainly made me ponder :slight_smile:

On the schools of testing, I’ve never really aligned myself with any of that. I kind of feel alot of it is about the ‘state’ of testing. We are changing, constantly, and that’s ok/good. How important is it that we label it? I’m not convinced it helps. Much like trying to label kids in schools, often it does more harm than good.

4 Likes
3

I feel that the trouble that development has in general is that we tend to borrow ideas and wording from other industries. QA in manufacturing is a fairly straightforward role wherein you follow the process of a product being made looking to improve either the product or the way its being manufactured. QC is where you check that output meets requirements in a fairly linear way. (Lean, kanban, six sigma and a whole host of other terms also filter through). This means that the understanding people have for testing is limited by these reference points.

The Phoenix Project, in my mind at least, was at least able to explain the role of DevOps to non-technical people and how there is a process to software in a loose sense. It heavily borrowed from manufacturing as the metaphor but kept it as a metaphor which is useful in pointing to the distinctions therein. I guess here its clear demarkation in job role of the CTO and the factory Overseer and how there are parallels worked.

For testing, I guess a ‘Chimera Project’ style book might be needed, though what it’d be about and framed would be interesting…

4

Both blog posts are misleading and incorrect (not intentionally). I have commented on Janna’s and replied to Alan there as well.

In Janna’s post, she has changed the title to ‘checkers’. However, the issue is that engineers who exclusively focus on automation or developers who have no understanding of testing are the same as checkers. If you want to be fair, you should call out the ignorance of testing equally.

Janna advocates that developers should do testing, just like Alan. However, there is not a single blog post, book, conference talk from developers which demonstrates an understanding of testing.

I don’t like Alan’s cheap digs at testers. From my point of view I know that I have a lot to learn in automation from Alan. I know that Ron Jeffries, Mike Cohn are giants in agile. I completely disagree with their views (lack of) on testing. However, I see my respect for their skills as one-sided. Good testers have embraced automation (for a specific purpose). However, developers and SDET types have not given any consideration to kaner-bach-ast testing.

Checkers are an easy target. It is very difficult to speak against developers or SDET types. I wish more testers would speak out against the lack of understanding of testing in the development community and the test automation community, not just against checkers.

2 Likes
5

There are many schools. And really as Alan points out, “school” is a wrong word. It’s his way of giving his observation a name/label. These 2 articles resonates well with the shift-left/shift-right/devops approach to testing that many large software development shops use. But remember now - it’s a viewpoint, not the world.

There are plenty of other contexts. People do UAT, and people do testing is based on test cases. There are places that cannot transform to automation as fast as the articles would like. change is hard. I agree that the field is changing (in many directions). I probably do more QA than testing when I introduce Definition of Done to a team, or when I sent up controls to confirm that technicians have tested the operational changes…

Testing is not about the testers anymore, it’s about the testing.

2 Likes
6

Ok, I usually don’t write. Mainly due to the fear of being rejected or ridiculed by others who pride themselves in knowing better or for being “leaders” in the testing industry. But I must push past my fears and share.

I do not fully understand when or why we transition from QA engineers to software test engineers. I always felt that testing was simply a part of QA. So as I read Janna’s article, I was not surprised. In fact, I agree with most of it… except with the statement that devs and business can be responsible for validating the product (this rarely can happen due to the pressure to release first and release quickly). But even in this declaration, I think I understand what she was trying to say. She is not eliminating the need for testing but rather expanding it. Many times titles condition us. A lot of us know what is meant when we are given the title of software testers, but others do not know, and therefore by just accepting that title we have limited our boundaries and become part of an assembly line. This assembly line concept is often focused on how to become quicker at spitting out a product rather than on how to spit out a better quality product. And in that assembly line, everything must be questioned for the improvement of the efficiency of that line.

When I started my career in technology, I went from being a tester (checker) to a developer because as a “tester” I was bored and I wanted to have more impact in the product overall. Shortly after I started developing, I learned that I was not happy just writing code, so I returned to testing where I saw the opportunity for me to test and to program and to have a larger impact on the product. From then on, I made it a point to be involved in every aspect of the SDLC and to inject the value of quality at every stage. So what she describes as a quality expert is what I have aspired to be, and this approach has allowed me to have more impact in the product as a whole. These days, I review and question written and unwritten requirements; I review and question processes; I perform testing on product utilizing my experience, the experience of others, automation tools and performance tools; I oversee deployment and look for ways to make it more efficient using CI tools; I review support feedback and influence future iterations by staying close to the voice of the end users.

In conclusion, I see testing as a way to help impact the quality of a product and in my humble opinion, discussing different schools of testing simply boxes us in and keeps us from talking about how to continue to have an impact on the quality of a product as businesses, technology, and people evolve.

Anyways, this is just my humble opinion. I’m sure there are reasons to discuss this topic that I am not considering. I’ll leave it to the experts to rip it apart. In the meantime, I will continue to do my best to learn from them and to utilize what I learn to impact in a greater scope the quality of the products I am testing. :slight_smile:

18 Likes
7

@Alex I don’t think there is anything to be worried about. I have not yet read the article you are referring to, however your thoughts mimic mine.

I call myself a tester to most as they understand this title and then move to the term quality advocate. I enjoy doing testing and engineering.

After talking to Bob Jones at our MoT - Philly meetup recently I was discussing how I liked to be involved in the creation and discussions for User Stories. Reason being I can help eliminate bugs from ever happening. This lead to stating that being part of the designing process makes you an engineer. This makes the term Quality Engineer make sense for me.

Keep putting out your thoughts, the lack of doing so keeps the QA field “stale and outdated”.

4 Likes
8

Titles like “Stop hiring software testers”, which was later changed to “Stop hiring software checkers”, is just being sensationalistic. If the title to the article what “Stop hiring people who add no value” we would all think, “Duh, that makes sense.” We all have an understanding of “people who add no value.” No one wants to hire someone who adds no value. This does not challenge my definition of “adds no value.” No one is going to say, “Yep, that is me! I add no value.”

Even if you add no value, you don’t identify with that description. However, many people identify with the title “software tester” or “software checker.” Janna has already put people on the defensive just from the title. There are also going to be people who believe what you, a software tester, adds no value. Do those people agree with Janna’s definition of “software checker?” Maybe, maybe not.

Do I get a list of requirements after the developers have implemented a feature and I check that those requirements have been met? Sure. Is that all I do? Absolutely not. Do I automate tests? Sometimes. Do I test the requirements during story writing? Do I do exploratory testing? Absolutely. Do I pair with developers and challenge the type of tests they are writing? Sure. I think differently than a lot of software developers. I can role-play and ‘become’ the customer. There are ways I can approach testing a piece of software that I have rarely seen a developer do. There are things I enjoy doing that developers have told me they find tedious or boring. So I always seem to add value on a software team.

Does QA, tester, checker mean the same thing to everyone? Nope. Will we ever get everyone to agree to what these terms mean? Or at least in my life time? Probably not. Are there two different schools of testing? Why aren’t there three different schools of testing? Or maybe there is 17 different schools of software testing. Binary systems are easier to understand. As a small child the world was very black and white (binary). As I got older I learned the world is more complex than that.

When people write articles with absolutes or try to break things down to a binary system, I think they are trying to understand a complex system by making it ‘simple’. There is a hint of truth to articles like this. People who want to believe it can believe it. They will read into it what they believe.

In my experience I have worked with people who check the requirements are being met. If they miss something but it was not in the requirements then it was not their fault. If they see something they think is going to be an issue but they don’t want to bring it up because they are afraid the product owner will shoot the messenger.

Does a company want to hire people who keep their head down and fly under the radar? Not really. Is this the sort of person Janna and Alan are hinting at? Maybe. If this is the case, do I think these people’s days are number. Nope. Bet you were expecting me to say yes. I want to say yes. Even though I know no one wants to hire these people, they will still find work. They will still get hired as QA, software tester, etc.

Janna talks about how the software industry is changing and people like this are not getting hired. Is this true? I don’t see any evidence for this in her article. My experience has been to meet more and more people who would fit her definition of software checker. I remember working at companies who had HORRIBLE development practices. I quit before they went out of business. I gave them 3 to 5 years to change or go under. This is how I thought 30 years ago. I don’t know one company which I thought would go out of business and actually went out of business.

I don’t think someone who matches Janna’s definition of software checker has to worry they won’t be able to find a job. It might be hard at times to find a company who will hire them but my gut tells me they will still be around 20 years from now. I have no hard evidence of this.

Realistically, I add value to a software development project. My title is “software tester” or “QA”. When I apply for a job, my resume says, “This is what I did for my past employers. This is what I will do for you.” If they focus on my title and skip the body, no big loss. Someone will read what I can do for their company and I’ll get a job.

Darrell

5 Likes
9

Thank you for sharing. Remember the leaders in the test industry will not reject you for sharing your ideas and opinions, so long as you respect theirs. The ones who will reject you wouldn’t be very worthy of the term “leader”, eh?

Now there are as many different “schools” of testing as there are testers. And not all are contradictory.

For example, I believe that all testing should be thought driven and based on the context. Thus I might be in the CDT school of testing, but my context is that I work in a factory (literally, we make things more than programs), so my context is that I have to automate everything, make test cases, etc. My tests are perfomed on thousands of products by people who do not (necessarily) understand testing. Thus I am also in the factory school of testing (note, “factory school” is a term used by some preachers of context driven testing in an attempt to be derogatory. In my case, their description is a simple truth of what I do…)

I design tests to be reused on products to ensure that the hardware is good. Thus I am in the “quality assurance” school as described.
I question my designs and am involved in the design process (mostly hardware these days), thus… “quality assistance?”

There are things to be learned from most practices who call themselves schools. But in labelling the different practices, we can talk about them and their differences.

4 Likes
10

I am one that has been ripped apart and ridiculed by the thought leaders, I write. I have a voice, you have a voice and I will fight for your right to express your opinions, whether I agree or not.

5 Likes
11

I’ve recently been reading How Google Tests Software and found myself vigorously agreeing with many things in it. It’s reminded me that I often do view software testing differently to much of the industry.

My day job is a consultant, and I do spend a considerable amount of time going to clients, and my role being misunderstood. They tend to think of me coming late in the project, do a quick check/rubberstamp it in the lead up to their big release.

That’s not really what I do. Which is why I kinda get the ‘two schools’ argument. There is definitely a prevailing attitude towards how testing is done - as defined by both management and culture - which I have to fight against.

The point is to get me in early so I can set up good processes. Set up a pipeline and automation early, so we can continue delivering at speed. It’s as much for the developers - to help them know when they’ve broken stuff early - as it is for the business to know what on earth it is they’re developing. Grooming backlogs and getting clear requirements are part of my job too.

6 Likes
12

+1 for “Get testing in early”. Perhaps even before the SDLC? Like during bid and release planning.

2 Likes
13

The ideas in How Google Tests as well as automation proponents like Alan are useful. The problem is that is pushed as a better alternative. It isn’t an alternative. You can do both early testing as well as late testing. Good testers have embraced these techniques. However, it is rare to see any developer blog/book (including HGTS) have any mention of testing techniques, viz., the Kaner, Bach, AST type testing.

1 Like
14

When it comes to “Schools,” I like Rex Black’s take (https://rbcs-us.com/blog/strategies-of-software-testing-not-schools/). The post has a link to one of his many fine videos. (Yes, Rex is a friend of mine. So? Still good info!)

1 Like