January 2018

Incapable to defend real testing

I am a developer, also a Team Lead. I remember now the moment when I realized that if I’m a better developer is also because of the help of a good testers. Initially it was like a cognitive dissonance: how come a good tester help me be a better developer? Even stranger for me was that when I realised this, I was deep involved (still deep involved) with TDD, unit tests and Automated Acceptance Testing.

There are devs who think that if they do tdd/unit tests everything will be ok and testers will do “some clicks”. Or even worse, the testers, for those devs, should check all the nonsense made by a developer, because that developer will not test. So strange. So a developer should not experiment, learn, explore, investigate, find relevant information from his/her own work.

I am sad. I was unable today to defend the real craft of testing (Rapid Software Testing). In a way, I felt that I was not able to defend those testers who contributed to make me better professional. So strange feeling.

Then I begun to think more. Now is a lot of talk regarding “manual” testing and “automated” testing.

Note: I told to a marketing person that she is doing “manual” marketing. And this sound so strange almost like offending. I told her about testing and “manual” testing and she understood. Still I can’t forget that it almost sound offending.

Why do they say “manual” testing? Maybe because a tester should just verify a specification, no matter the form of that specification – wait, I am wrong, is a user story with acceptance criteria, of course. Since is a clear specification, it is imagined, I think, that they can also write what they will test – some will say they write the test…. Hmmm…So, if they can write it down this means they don’t need a tester with experience – may be temporary – , a junior should be enough because anyway acceptance criteria are done by the Product Owner. But if a junior can do it, then … wait we can automate those steps, yes, yes via UI. So, hmm, why not get rid also of the junior tester, because we have the automation which is the ultimate goal actually. A click of a button and that’s it. For sure that automation code will be developed not by experienced developers like it would be the production code, no, no we have “automation” testers.

So why a tester should matter so much when actually he/she is only doing some of the shallow testing a developer must do? Shallow and clear steps which can be done by anyone.

So, I imagine that’s why – briefly described – some testers are being called manual and automated.

If testers spend time on shallow bugs they will not have time to see for deeper ones. Such deep that neither a dev can’t see it.

But what do those testers that I was not capable to defend? They, although they might not phrase it like this: investigate, doubts, searching for information, pose questions, questions everything, do more than confirm acceptance criteria, they challenge the actual criteria, they make definition of done/ready relative when all the other thinks are clear and absolute, are able to begin testing without specifications if needed, be able to show the multidimensionality of a problem/specification/story, use any tools which can help them (not just selenium or…), they will not answer to different problems with same answer because they are aware of context, support developers, …. please see here for a much longer list: http://www.developsense.com/blog/2017/04/deeper-testing-2-automating-the-testing/

Sorry colleagues testers :(.

Managing technical debt discussion

Shu(1): We found a way to manage technical debt on the projects. I’m curious what you think about it.

Ri: Tell me more. How did this topic arise? Why was your team affected by this?

Shu: Well, it was a top down decision. So we have to manage it somehow. And for doing so we have to see where we are.

Ri: So you don’t know why. The fact that it’s a top down decision doesn’t mean you know the answer to the “why” question. So you are affected because you all have to do it. Hmm…ok. Why do you say “we have to see where we are”?

Shu: By “we have to see where we are” I mean that we need some numbers, like those provided by Sonar.

Ri: Numbers? Don’t you already know how your project stands from a technical point of view?

Shu: Hmm…I don’t understand what you’re trying to say. This is what I was told to do.

Ri: Don’t you participate actively in the day to day work of the project? Aren’t you capable to articulate some aspects?

Shu: Well…yes.

Ri: So why are you acting childishly?

Shu: Childishly?

Ri: Yes. Why do you think complex and complicated stuff can be reduced to numbers? I understand that parents need to make things simple for their kids but you are an adult … you should be able to handle complexity and complicated stuff. (2)

Shu: Why do you think numbers are not ok?

Ri: I didn’t say that. I said that it’s not ok to reduce such an important topic to a simple number.

Shu: Well… then how do you know you are ok from a technical point of view?

Ri: Is technical debt actually a technical problem?

Shu: Ha?

Ri: Ok. Let’s take an example regarding numbers. You have a module 1 which was not modified for years, some of the code is actually generated and it has lots of warnings. What do you do? What do those numbers regarding the module 1 tell you, compared with another module 2 which was modified 5 times in the last 2 sprints? In the end, Sonar tells you that you have 500 days of technical debt. So what will you do about that?

Shu: I will want everything to be cleaned up.

Ri: Why?

Shu: Because clean code matters.

Ri: Don’t deviate. Don’t tell me platitudes. What we are talking about here is how you interpret those numbers and how your actions are guided by them.

Shu: I think that, maybe, we should handle module 2 issues first, and then module 1 issues.

Ri: So what do those 500 days mean?

Shu: I don’t know.

Ri: Why not? It’s a clear number written there….

Shu: It seems that days representing module 2 are more important than days representing module 1.

Ri: Will it always be like this?

Shu: Hmmm….Now that you ask, I am tempted to say: no.

Ri: So, let’s go back to the question: what do those 500 days means?

Shu: I don’t know. At first sight it seemed clear but now it doesn’t anymore.

Ri: Good, you begun to think a little bit. So do you think that by seeing those numbers you can know where you are?

Shu: Nope.

Ri: Why not? At least now you have something. Initially, it seemed, you had nothing.

Shu: Hmmm…actually I did had something….by participating in the work that was done, I saw: the code, automated checks, professionalism of the team members, how prepared the team members are, behaviour of writing code of the team members, bugs, issues, problems, testing. So in a way, tools like Sonar help a little bit by providing a perspective, but to say that they are the key point in managing technical debt is not ok. So tools like Sonar continue the list I mentioned above?

Ri: There is one point I wish you would have mentioned. How do you know, by looking at the code, what problems it had?

Shu: I have to see the history of the code. A lot of information lies in source control. Information which has to be analyzed and interpreted according to context.

Ri: So technical debt is only a technical problem which can be tracked/simplified by some numbers shown to the upper management..numbers which occasionally are stripped out from context?

Shu: Nope… A lot of discussions have to take place, based on the unfolded details.(2)

Ri: Let me come back to the beginning, and ask: why did top management impose this?

Shu: Hmm. I think I know the answer but I can’t articulate it.

Ri: You just mentioned a long list of dimensions when managing technical debt. Are all people managing the projects aware of those dimensions?

Shu: No.

Ri: What should top management do in this case?

Shu: Impose, so things won’t go in the wrong direction.

Ri: Yes, but why?

Shu: Lack of trust? I believe they thought that having Sonar as a common denominator for all projects was a way to at least control the complexity and mediocracy of the people managing the projects. Mediocrity which in the end affects the dynamics of the project a lot, and which creates a space also for technical problems to flourish.

(1) Alistair Cockburn, “Shu Ha Ri”: http://alistair.cockburn.us/Shu+Ha+Ri

(2) James Bach, No KPIs: Use Discussion: http://www.satisfice.com/blog/archives/1440

Regarding Technical Debt Quadrants

I like the way Martin Fowler(1) tried to classify Technical Debt. I think it was a way to show,in a simple not simplistic way, how to grasp the complex nature of what technical debt actually means and how to handle it. I intentionally said complex not complicated.

So, technical debt might appear easier to grasp ( especially due to code analysis tools) but maybe it’s not like that. It seems that we have to rely on the sapience of developers, and I would say testers(2) as well, to take care of the code.

Below are some short thoughts regarding quadrant elements:

– reckless vs prudent for inadvertent: I connected it with the training/qualification of developer(s);

– reckless inadvertent: it seems that (some) basic notions of oop/design/architecture/… are missing;

– prudent inadvertent: we might deal with good developer(s) who had an “aha” moment. In this case, the simple fact that they realized something is a good thing, it’s a sign of progress;

– reckless deliberate: it’s a clear intention for “quick and dirty”. This might be ok in a certain moment because this decision is intentional and fully aware of the context. And it is known that it will be taken care of.

But I usually see this “quick and dirty” solutions from so called senior developers who are unprofessional. For example, these unprofessional devs:

preach that they want clean code and assure their team members that they want to do it, but behind closed doors they are doing actions( technical work) to impede this;
are happy to do some small checks/verifications/investigations which requires no management approval but they ask for time allocation and for the management to agree. And they do this because they know they can sabotage the things so that in the end to do the “quick and dirty” way.

– Prudent deliberate, if applied ok (not by so called seniors mentioned above), might be a sign of holistic thought. It makes me think of the mantra: “First make it work, then make it right, then make it small and fast.”(3)

So, things are not so simple when speaking about technical debt. For those that are interested only in numbers I have a question: How many developers do you know that connect neuroscience, cognitive psychology, complexity theory and forensic psychology with how code is written?

(1) Martin Fowler, Technical Debt Quadrant: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

(2) Context Driven Testing: http://context-driven-testing.com

(3) Robert C. Martin, Test First: http://blog.cleancoder.com/uncle-bob/2013/09/23/Test-first.html