Software Quality without Testing - Part 2

In Part 1 of this three-part series, we learned about the importance of a quality mindset or better said, a quality-first mindset. Also, we looked into our building block to create long-lasting software quality and defined that each individual has the responsibility to form their own, as well as others' mindset. As everybody is equally responsible for generating and delivering as much quality as possible, today, we go a bit deeper into the associated roles and responsibilities.

Quality depends on teamwork: The Quality Hopper

The team enables quality – the whole team is responsible for delivering quality. Quality management or assurance is exactly that, an insurance or the last safety net to make sure that quality is as expected. There is no QA team in the world that could provide the team with better quality. All QA can do, is to show that quality is missing, which most of the developers are painfully aware of.

So, the real question is, how everybody in a team could enable software quality without allowing the QA an opportunity to throw your carefully implemented feature back at you.

The problem with feedback and criticism is that people tend to take it personally, which is tough in a development life cycle (since we need fast-paced feedback to deliver better software). To prevent that kind of social friction, we need a good team spirit and better communication. No one likes the feeling of getting back the task which has already been implemented, without so much as a comment or with a mean comment like "fix it".

Sometimes, it's easier to invest five minutes and talk to your teammate about the issue you found while code reviewing or testing the implementation. If you have the technical expertise or even if you don't, sit down with your teammate and fix the error together, pair programming style. This may also be a good learning experience. Pair programming seems slow on the outside, but it's not. There are a lot of studies that say that pair programming is a very effective way to implement high-quality software at a faster pace. Since there is a continuous back and forth of ideas for possible solutions, this makes absolute sense. The nice side-effect these practices do have is lifting team-spirit, motivation, and achieving goals more easily. Plus, you get to know your teammate.

Before we delve into other roles, apart from developers and QA engineers, we want to introduce you to the 'quality hopper'. This is merely a visual aid of what we think is essential to build a framework for our quality mindset. As you can see in the following diagram, the quality hopper comprises of coding guidelines, clean code principles, architecture, and tooling, and is a representation of components in a software life cycle. Not the technical implementation, but all the moving parts which are responsible to create a high-quality software.

The Quality Hopper framework

For this chapter, we have highlighted 'The Team' and 'Team Spirit,' and we already talked about how important it is to have a good team spirit. We will now talk about the typical roles of a team and their responsibilities regarding a quality mindset.

Stakeholder

A stakeholder needs to have a vision for the product to be implemented. It will be optimal if the stakeholder has the skillset to communicate it to the project manager or the team, depending on the organization. We encounter situations where the vision and the requirements change almost daily, and the development team makes changes to current implementation accordingly.

Yes, you may be working in an agile environment, but this behavior is far from agile, it is chaotic. If you encounter such a scenario, as a team you need to enlighten the stakeholder with knowledge about agile development and agile mindset, hold workshops with the stakeholder to form a clear vision, a roadmap and plan of action as well as a way to communicate with the team. Also, the stakeholder is responsible for:

• Project frame: How and where is the team located (remote vs. local vs. near-/off-shore) and providing the team with infrastructure, hardware, licenses.
• Time: A realistic deadline based on an estimation coming from the whole team (not only the business roles).
• Market: Knowing the market and adapting the vision and the requirements accordingly.
• Steady communication: Communicating with the team and to the end-user (over PR or marketing).

Project manager, Product Owner and Business Analyst (Business roles or BRs)

As the link between the business and the technical implementation, the BRs have the responsibility to translate the stakeholder’s requirements into manageable but also implementable packages. Therefore, people in these roles need the skill set to communicate with both sides of the development process.

This role has the challenging task of managing expectations, and also communicating realistic timelines and deadline delays to the stakeholder. The BR also needs to work closely with the dev team by translating requirements from a visionary view or idea (stakeholder) to implementable epics, user-stories, and acceptance criteria.

These roles must not talk about a technical detail, but about the feature’s behavior. BRs should only explain what a feature should do in certain situations. Based on that, BRs should work with the development team on epics and user-stories and define the acceptance criteria accordingly. So, the responsibilities of these roles could include:

• Steady communication: Should make sure that a steady stream of communication is assured.
• Technical details: Should clearly communicate 'What to implement'.
• Accuracy: Should provide clear distinctions to a story. Also, the acceptance criteria formulated should be clear, accurate, and meaningful.
• Market: Should know the market well and be in a position to even challenge the stakeholder‘s requirements to come up with a more market relevant product.

Developer

A developer is the primary source for ensuring quality, especially when implementing the right software. Since people in this role implement and develop the vision and ideas of a stakeholder, they need to understand the requirements perfectly well.

In our experience, this is often the root cause of failing projects. When communication lacks clarity, the features implemented don't deliver the expected output. A developer must ask questions and must use sync up meetings for grooming, refining, and planning to get on the same page as the stakeholder and BRs. Only if the development team has a full set of acceptance criteria and complete understanding of the business aspect of a story, a full commitment to implement the story can be given.

However, the reality is many-a-times different. The development team is pushed to an early commitment, acceptance criteria are often not well formulated and stories don't have a clear purpose, obviously making it difficult to implement the right feature. In other words, the idea and the vision of the stakeholder do not take shape.

The developer faces other challenges as well (we will talk about this in detail in part three) such as versioning, automation of build-, deploy- and delivery-systems, framework selection, code guideline, coaching junior staff in the art of clean coding and clean architecture, selecting the right architecture for the product and the right patterns to implement new features. Finally, how to implement proper unit tests during the development of features. So, these roles are responsible for:

• In-depth technical knowledge: Expertise in understanding the environment and the software in development (depending on the role and seniority level).
• Domain knowledge: Expertise on the branch in which the developer is working.
• Team coordination: The days of nerdy hackers who sit in a dark cellar and don't talk to anybody are over. Software development is a team sport, and developers should be team players.
• Steady communication: Communicating on expected or unexpected issues, status of the product, resource problems, technical debt, medium to big refactoring needs particularly, if the team works with legacy code.
• Applying coding and architectural guidelines by:
  • Reviewing code.
  • Practicing clean code.
  • Applying SOLID principals.
  • Using pair-programming as a tool to transfer knowledge and work on critical and high-risk changes and additions.
• Challenging requirements of user stories: Not accepting requirements as they are, and challenging the same in order to implement acceptance criteria of user stories successfully.
• Implementing unit and integration tests: Using a test-first approach to implement a feature (e.g. TDD). However, if the team is not committed to such an approach, implementing unit and integration tests incrementally with the feature. Conducting unit test days or even weeks after implementing the feature is hard and very time consuming.

(Test) Automation Engineer, Quality Engineer

A well-trained quality engineer (whether manual or automation) should bring a well-established quality mindset into the team. Planning, designing, execution, and implementation of automated tests are part of the daily routine of a person working in QA. However, the experience of a QA engineer should also be taken into consideration to set up a quality-friendly organisation.

Challenging requirements and coordinating with stakeholders and BRs while defining user stories and acceptance criteria (and checking for flaws in behavioral design during the early stages of a software life cycle) are important skills which a QA engineer should use in a way to help the whole team learn.

The QA engineer (manual testing) supports the team with:

• Finding bugs (technical and conceptional).
• Explorative testing of new features.
• Designing the test.
• Planning test execution for releases as well as user acceptance testing.

The test automation engineer supports the team with:

• Implementing regressions tests on different levels such as UI, DB, API, Integration, and end-to-end, and creating, therefore, a safety net.
• Automating and managing environments.
• Managing test data for QA engineer and developer for executing all sorts of tests (including automated tests).
• Unit testing (not necessarily how these tests are implemented but what the tests cover) and if they have any value.
• Implementing the technical part of DevOps.

Both support the team with:

• Steady communication for underlining the current state of the software, findings and issues and performance changes (for e.g. the application takes too long to load that leads to failure of UI test automation)
• Challenging requirements and user stories such as working with the stakeholder and BRs as early as possible to create meaningful and valuable requirements, epics, and stories, and thus ensuring software quality.

Requirements, user stories, and acceptance criteria

During the description of the individual roles we mentioned requirements, user stories, and acceptance criteria. Therefore, we will be giving you an overview of our take on these aspects.

Imagine the following scenario. You work in an agile team; it's the beginning of week two in your iteration. The daily stand-up meeting has just started when the stakeholder joins in. The stand-up shows that you are on the right track and if nothing unexpected happens, you could reach all goals for that iteration.

However, before the meeting ends, the stakeholder says, "Guys, we need a digital whiteboard, by the end of the next iteration!" Silence. Finally, one of your team members asks the important questions. "A what? What for? Why don't we use one of the hundredth solutions out there?"

Vaguely, the stakeholder starts to explain what he needs but doesn't get into the details. Assuming you have all the information needed, the stakeholder leaves, saying, "We are agile, this should be no problem".

The essence of the story – we need more detailed requirements and a better picture of the stakeholder's expectations. Without clearly defined requirements, we cannot hope to create well-designed user-stories or build the right software.

Requirements should describe the general idea. It can be very detailed but doesn’t have to. To describe a requirement in more details, you could use epics.

Epics can be a breakdown of a requirement into estimable and plannable units. An epic should go more into details. Since it is a part of a requirement, it is possible to define very clearly what should be implemented, what should not be, and when is the epic successfully completed.

User stories should be the most detailed part of the whole process. Requirements and epics are important to understand where we want to go. However, user-stories tell us how to go there. User stories should tell us what the goal is and why it is needed in a clearly defined way:

As [a specific user], I want [some goal], so that [some reason]

A user story should only explain the behavior of a feature. We don't want to describe technical details since a user story can and should be used as reference and documentation for a feature. A big part of user stories are acceptance criteria.

Acceptance Criteria helps to distinguish the goal of a story. They give us behavior for different situations and edge cases. Behavior Driven Development (BDD), or better said, the idea of describing acceptance criteria not technically but with behavior, has proven to work very well. We could use the Gherkin syntax to unify communication and use it as a "building pattern" to write acceptance criteria which only describe behavior. The Gherkin syntax is simple; it is structured and natural language-based and uses only a couple of keywords.

Given there is a precondition, when something is done, then the feature has to behave in a specific way.

Also, this keyword can be used to combine and create more complex given/when/then statements.

Tasks give us a way to break down user-stories even more and go into technical details of the implementation. Some teams will go as far as defining APIs, classes or even methods during the planning so that the feature team can work on that story even if a single, necessary part of the feature requires implementation.

Summary

Quality needs people who can communicate, take, and give feedback without taking things personally. To form a quality mindset means to understand that every person in a team has his or her own responsibility regarding the software quality, which only ends if the project is terminated. Quality also needs clarity of vision, ideas, requirements, and expectations.

In Part 3, we will discuss how to set up a quality friendly technical environment to help deliver quality before moving into software testing.