7 Key Elements of Agile Software Testing (Part II) Source

Translated

5. Building the Foundations of Core Practice

1) Continuous Integration

Image Source: ZenTao

Every development team needs code management and continuous integration. You cannot test effectively if you do not know what you are testing. If you cannot configure the code, you cannot test. All team members need to import their work at least once a day. Each integration must be validated by an automated build, including testing that provides rapid feedback on software status.

Implementing a continuous integration process should be the highest priority in a software development team. If the team doesn't have a daily build-validated version, the team must stop what they're doing and start building. And it's more challenging if you have a large system to integrate. It's usually not that difficult, and many good tools, such as open-source and commercial ones.

2) Test Environment

You cannot test effectively without a controlled testing environment. You need to know what version is deployed, what database schema is used, whether other people are updating, and whether other processes are running on that machine.

Hardware is always getting cheaper, and open-source software is increasing. Teams must invest in performing automated and manual exploratory testing efficiently. If something goes wrong with the testing environment, you must speak out quickly and let the team fix it together.

3) Manage Technical Debt

Image Source: MELV1N

Even good software development teams neglect refactoring or fixing bugs quickly after feeling time pressure. As the code becomes more cluttered and difficult to maintain, more bugs appear, and soon the team slows down because new features cannot be added until bugs are fixed. Teams must constantly assess the amount of technical debt and strive to reduce and avoid technical debt.

People often say, "Our management won't give us time to do this; there's no time to refactor; the schedule is tight." However, we can easily give a business use case to show how growing technical debt costs a company money. We know what causes technical debt to impact the bottom line by measuring code and defects. It is enough to point out the declining rate simply. Businesses need software development teams to remain consistently productive. They have to reduce the scope of desired functionality to ensure enough time for good, well-tested code design and good practices, such as continuous small-scale refactoring.

Good coverage of automated regression tests is the key to minimizing technical debt. If it's missing, you dedicate time in each iteration to build automated tests, plan a "refactoring iteration" to upgrade or add necessary tools, write tests and refactor. We need to spend time in each iteration guiding code through tests, refactoring necessary code, and adding missing automated tests. We should take this work seriously. Teams can grow faster in the long run.

4) Incremental development

Image Source: Wikipedia

Agile teams can produce high-quality code because they work on a small scale. Stories represent the workload of several days. Each story is decomposed into small increments and constructed step by step. We can test some of the functions and test them incrementally with the function aggregation.

If team members like to develop most of the functions at once, we should encourage them to adopt a step-by-step approach. We should ask: "What is the core business value of this story? What is the basic path of this code? What is the next step?" We suggest you write task cards to code and test small increments, record design concepts and confirm test and test automation strategies.

5) Coding and Testing are Part of the Same Process

Image Source: Slide Share

People unfamiliar with agile thinking often ask agile testers: "What do you do when all the stories are done and can be tested?" Experienced agile practitioners say: "The tester must go through the entire iteration and the entire development process. Otherwise, it will fail".

Testers write tests based on customer examples to help developers understand the story and start programming. Tests and courses provide a common language that enables everyone to participate in software understanding. Testers and developers work closely together when coding, and they work closely with customers as well. Developers show testers the functions they write, and testers show developers the abnormal behaviors they find. Testers write more tests as the coding progresses. Developers pass the tests. Testers conduct more exploratory tests to see whether the correct value has been produced. Each agile iteration includes several continuous, fast, and incremental test—code—test—code—test iterations.

Bad things will happen when this cycle of cooperation and feedback is interrupted, and testing is separated from development. Suppose the story is found in the iteration after coding. In that case, the developers must stop the new story, recall how the code implemented the story of the last iteration, repair it, and wait for others to test it. There are many bugs in software development, but we determine that the sooner we identify bugs, the lower the repair cost.

When coding is always guided by testing, we conduct testing. In contrast, with coding, we are more likely to achieve the behavior expected by our customers and provide the value their customers need. Testing is the responsibility of the team. If the team doesn't have that mindset, then we need to get everyone to raise the focus on quality, expectations for releasing a great product, and what steps to take to ensure the team achieves its goals.

6) Collaboration Between Practices

Image Source: Slingshot

A single agile development practice, such as continuous integration, can play a role, but combining multiple agile practices is larger than the sum of all parts. Test-driven design, shared code ownership, and continuous integration promote rapid feedback, continuous improvement of code design, and rapid generation of business value. Automated testing is good, but we use automated test-driven development, followed by exploratory testing to find defects or weaknesses, so we are better divided into multiple levels.

Certain practices are not good to do alone. Refactoring is impossible without automated testing. Releasing small versions in a mini-waterfall way loses all the benefits of agile development. If your on-site client doesn't have the authority to make decisions, he has limited value to the team.

Agile practices are complementary. It would be best if you took the time to understand the purpose of each practice, think about how to use all the strengths, and make thoughtful decisions about what is useful to the team.

6. Working with Customers

One of the greatest contributions of testers to the agile team is to help customers clarify requirements and set priorities, describe requirements through specific examples of expected behaviors and user scenarios, and convert these examples into executable tests. The testers use the business domain language and the development team's technical language. We act as excellent assistants and translators.

We shouldn't hinder direct communication between developers and customers. We encourage direct communication as much as possible. We should use a "three-party collaboration" approach. When requirements are lost or misunderstood, customers, developers, and testers must work together to solve the problem. We invite customers to discuss issues in front of whiteboards or other virtual tools. If customers come from different regions and countries, we will use any tools we can find to strengthen communication and collaboration. Videoconferencing, instant messaging, and wiki are not perfect substitutes for face-to-face communication, but they are also better than email or doing nothing.

7. Keeping the Vision of the Overall Situation

Image Source: LMA

Testers have a big-picture view and usually think from the customer's perspective. Developers are usually focused on implementing the current story, and while they use testing to guide them, they are also focused on the technical implementation of the requirements.

The big picture contributes a lot to the team. If test-driven development is done well, there are no bugs in the different codes. What if a new feature causes some unrelated parts of the app to crash? Some people have to consider this impact on larger systems and get the team's attention. What if we ignore some details that might annoy the customer? The new UI may be bug-free, but what if the background colour makes the text hard to read? These are all issues that end users will notice.

We should use the Agile Test Quadrant as a guideline to help plan test coverage across all areas. We should use the test pyramid thinking to ensure a good ROI of test automation. Guiding development through testing helps ensure that you haven't lost something important, but it may not be perfect. We should use exploratory testing to understand how the system should work and in which direction the test should point. Making your test environment as similar as possible to the production environment. We should use data that reflect the real world. We should be diligent in rebuilding a scenario similar to the production environment, such as load testing.

It's easy for everyone on the team to focus on just one task or story. This is a disadvantage of doing only one part of the function at a time. You should help your team take a step back and assess how the current story is responsible for the big picture of the business. You should constantly ask yourself how you can better generate real value.

Need more help? Check out the Zentao blog. They have more articles on project management, software management, building cross-functional teams, and so much more.

--

Read more:

• 7 Key Elements of Agile Software Testing (Part I)