Don’t criticize what I did!

As in all areas of life, if there is one thing that is personally disliked by most people in the world of software development, it is negative criticism of something you produce or contribute to the production of, or showing its unworkable or faulty aspects. Unfortunately, this is a protection instinct that started with our transition to speech1 about 150-200,000 years ago, and has been worked into the corners of our “reptilian brain”, which has been developing since then. In general, I think that we are not the type that can tolerate criticism or falsification of what we want to do, the ways we choose to realize our wishes, or what we do after reaching the result, and can meet them with maturity. I believe that people who can do this and who can handle negative criticism with maturity are more successful in both their professional and personal lives.

When society or someone in our team tells us that we did something wrong, not as desired, or – to put it more seriously – badly, our first reaction is to build a defensive wall against that person, albeit involuntarily. People who do not build this defensive wall, on the other hand, can get rid of the society or team they are in, as people who are open to negative criticism and self-development. It is unfair to describe a production or work as “bad”, as if it is “destructive”, “destroying”, “unjust”, “creating unhappiness”. I think it’s an insult to people.

Definitions and Parties

In the “Dark Side of Software” articles, which I intend to write as a series of four articles, I will refer to the concepts of “dark side / light side” in the Star Wars universe, from which I inspired the title of the article. The views in the article(s) will be based on my personal observations and opinions rather than the inferences of rational methods based on experiment or data. I will also assume that the definition of negative criticism that will be discussed in the article(s) is data-based criticism with logical explanations. I see all criticisms of “it didn’t happen” or “x has already done better” made just for the sake of talking about any production that is created, only as “disgrace”.

The party that is seen as the “light” is the party that strives for the production of the software, the progress of the project or application ‘whatever’; The side that is seen as “dark” will be the side that draws attention to the deficiencies, setbacks or mistakes in the project or application and is not liked very much. If we write it in technical language we can understand, the “light side” will represent the software developer, project manager and management staff, while the “dark side” will represent the test engineers and testers who test the software and try to prevent / find bugs.

I have enough experience to know that the best way to produce a quality product is by testing it at the optimum level, taking the test results seriously and making corrections accordingly. I have a definite place in testing expertise, which is seen as the “dark side” and bad boys of the software world.

Aydınlık taraf ne istiyor?

 

 

 

 

 

 

 

 

We can understand whether there is sufficient maturity in testing within the team or company running a software project by observing the following situations:

  1. Testing of the product or application begins very close to the delivery of the project,
  2. The project manager and / or senior management does not create a project calendar considering test times,
  3. All tests are expected to be done by the developer,
  4. There is no expert test engineer dedicated to the test work within the team,
  5. Software testing means only “unit testing” or “end user testing”
  6. If any, every “bug” found by the tester, if any, is reported directly to the developer instead of being recorded,
  7. The requests of the application to be tested are not clearly understood,
  8. There is no separation of development, test and live environment,
  9. The data and datasets to be used for testing are not parsed,
  10. In the performance criteria that determine the salaries of the developers, there are also the number of “bugs” in the modules or applications they write,
  11. In the first error notification from the customer or user after the product or application is released, the guilty person or unit is selected as “testers”.

Maybe it will be like the personality tests of a content compilation and copying site that is known by social media users in Turkey and that attracts a lot of visitors, but if you answered “yes” to at least two of the eleven items that came to my mind at first glance, you will be in your team or It means that your company does not give the necessary importance to testing and software quality.

The bright side (i.e. programmers, developers, project managers and senior management) complains that all of the suggestions in these articles are not applicable at the same time and are incompatible with market realities, simply because they are concerned about their long-standing habits and generally disturbed comfort. While project managers complain about “time”, company management draws attention to the “budget” issue, while developers resist the “uncritique” I tried to point out in the first introduction, or the “performance goal” mentioned later.

Think back to the “light side” of the Star Wars universe. Remember Master Yoda, Obi-Wan Kenobi, and the Jedi council. Because of their conservatism, which turned into bigotry, they could not see the progress as it was, and they ruled for a long time with the aim of silencing every opinion that questioned their discourse. The bright side is afraid and afraid of being criticized and disturbed. Being tested, being put to the test, is a brutal process that makes it uncomfortable. That’s why it’s seen as dark. A person is afraid of the darkness, which he thinks is hiding what he does not know, and tries to stay away.

What does the dark side want?

Test engineers, who have long been seen as the dark side in the software world, have determined the main target of the application as “quality“. Software test engineers who do their job well, instead of being the builder, developer, and person who puts the brick in the building, are responsible for checking to the millimeter how much each brick placed complies with the standards and the request of the home owner, reporting the problematic parts and pursuing the work until this problem is fixed. Everywhere the subject of software is mentioned, they are the people who defend the quality first and foremost. If you have a test engineer on your team with the following qualifications, he is one of the best soldiers of the aforementioned and constantly vilified dark side:

  1. Ability to categorize the errors or deficiencies encountered in accordance with customer needs and in-application balances,
  2. Ability to base and justify the mistakes he/she notices on objective data,
  3. Able to make commitments and fulfill these promises,
  4. Very good in human relations and can explain the problems and listen to the other side objectively,
  5. Able to plan the necessary resources and time well to carry out the tests,
  6. Able to report each error in detail,
  7. Persistent to participate in the production process of a software from the very beginning,
  8. Being aware of the distinction between “internal quality” and “external quality” of a product in terms of software quality and able to plan the tests accordingly,
  9. Being able to follow the literature in software quality, internalize and apply the standards,
  10. Knowing the software product quality model2 very well and able to put pressure on the team to implement a test process within the framework of these standards,
  11. Fully open to negative or positive, data-based objective criticism, not involving emotions.

In the next parts of the series, I will try to write why those who serve the dark side we fear and know badly are well suited for those tasks. I hope I can keep my promise and complete it in the future.

References:

1: Mcneill, David. (2010). How Language Began: Gesture and Speech in Human Evolution. 81-82. 10.1017/CBO9781139108669.

2: ISO/IEC 25010:2011 / Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models

Software Testing