2. Should I test?

The content here is under the Attribution 4.0 International (CC BY 4.0) license

If we ask 10 people if we should test our work, I believe we would have a majority that will say yes, in reality, what happens in software projects is different. For a given project at hand, the testing strategy varies and often is non-existent. Two groups in the software development chain are delegated with the testing aspect, the first ones are developers and the second are the quality assurance people. The testing is a joint responsibility, however, there is an unfair delegation from developers to QA.

Such behavior makes feedback late in the process and goes against the rapidly responding to change coined by the agile manifesto. This is a problem that business faces daily in the path towards delivering new features for customers. The timeline of the event goes like the following:

developer : developers write codev -> send it to the QA                     -> developer started another task                                    -> developer switch tasks to check the error (switch context)
qa        :                                             -> QA start testing -> something not working as expeted -> QA resports > task is blocked 

This feedback creates two work streams in parallel that generate waste in two different ways, the first one is related to the switch context. A developer has started to look into something else and now they need to come back to verify what the QA found. Secondly, the task at hand is blocked, because it is not working as expected. As a result, we got two tasks one is on hold while the other is being verified again by both.

Research has shown that testing activities consume 75% of the development process [1], as a consequence, we should start thinking that the testing activity is part of the development process and not a separate phase. The movement of shift-left testing is the reaction to that. Shifting left the testing and specifically combining that with TDD brings positive results from a code perspective. Not only at the quality level but also at the perception that developers have with the practice.

In 2012 a study that investigated the influences that TDD plays in class design found the following results [2]:

• Continuous feedback: TDD provides continuous feedback on the code quality, allowing developers to identify and address issues early
• Although TDD is a software testing practice, many developers claim that it directly influences class design, promoting more cohesive and less coupled classes. This point has been a subject that was updated in a more recent work by Tampubolon et al. TDD may not offer substantial assistance in the design phase of software development, posing challenges for design-oriented tasks (missing reference).
• Code quality improvements: Studies demonstrate that TDD can result in higher external quality code.
  • Pedroso et al. made observations regarding external quality and internal quality that are taken into account for this text. The work presented by the authors shows that TDD has empirical evidence regarding external quality, however, the evidence regarding internal quality is inconclusive. External quality refers to defects, whereas internal quality refers to less coupling and more cohesive code [3]. In 2015, Sandro Mancuso supported the idea that TDD is not a design tool, thus, it does not have any effect on internal qualities.
• Increased productivity: Research indicates that TDD can increase developers’ productivity, even if there are no significant differences in code quality
  • Calais and Franzini kick-started an area of research that points to TDD enabling flow state for developers [4]
• Growing adoption in the industry: The practice of TDD has been increasingly adopted by the software development industry, demonstrating its relevance and effectiveness

Subramaniam enforces that automated tests are the path towards failing fast and safely however, developers face challenges in an attempt to write the test first, this thinking comes from the inflection point that TDD poses. If I don’t have a clear picture of the code, how will I write the test first? The solution posed by Subramaniam is split into three phases: take small steps, divide and conquer and spike to learn[5].

We don’t have time fallacy

In the Clean Architecture book, Martin shows in a chart what happens in a software lifespan. Kent Beck shared a post by Pierrick Blons that put at the core of the discussion the fallacy of sacrificing quality to build trust. Kevlin in a talk for Agile elaborated on the subject.

Final thoughts

Software is all about getting the right requirements working through the source code, and accomplishing the customer necessity. Software is also about solving problems. Usually, software projects are divided into a few steps, the waterfall approach is to have the specification upfront, implement the code, test it and deliver the final result to the client. Nowadays we follow the “agile” way, which is focused on delivering value to the customer as soon as possible, dividing the flow in iteration between the team and the client.

Is true that software is powerful, Facebook for example connects billions of people around the world. Google has an amazing search engine that we can use and find anything in seconds. Besides being software what else do they have in common? Both companies are improving their product(software) often, giving the users new features and new possibilities. The only truth is that software changes and always will.

Is not difficult to see teams in different stages, the design team is always closer to the client and this is where the changes start, while the development team is working on version 1.0 the design team is focused on the 2.0 ( even though this can be challenged by developers, is it agile?).

If changes are the only truth, how would you prevent the code from breaking when a change is done? Conventional programmers write code that follows the happy path, which is the correct flow to be used. The exceptions are often found by a QA (quality assurance) team. Think about changing the programming language version, for instance, PHP 5 to PHP 7, how can we guarantee that everything is working correctly? In a scenario without tests, the QA team is responsible for that, there is no way to give a satisfactory answer to that unless we have automated tests.

References

1. [1]Z. Dimitrichka, “The role of unit testing in training,” in Development through research and innovation, 2021, pp. 42–49.
2. [2]M. F. Aniche and M. A. Gerosa, “How the practice of TDD influences class design in object-oriented systems: Patterns of unit tests feedback,” in 2012 26th Brazilian Symposium on Software Engineering, 2012, pp. 1–10.
3. [3]B. Pedroso, R. Jacobi, and M. Pimenta, “TDD Effects: Are We Measuring the Right Things?,” in Agile Processes in Software Engineering and Extreme Programming: 11th International Conference, XP 2010, Trondheim, Norway, June 1-4, 2010. Proceedings 11, 2010, pp. 393–394.
4. [4]P. Calais and L. Franzini, “Test-Driven Development Benefits Beyond Design Quality: Flow State and Developer Experience,” in 2023 IEEE/ACM 45th International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER), 2023, pp. 106–111.
5. [5]V. Subramaniam, “Test-driving JavaScript Applications: Rapid, Confident, Maintainable Code,” Test-Driving JavaScript Applications, pp. 1–364, 2016.