Testing foundations

As we’ve discussed, testing refers to the process of assessing a software program to verify its behavior matches the program requirements defined. Many types of testing activities may be performed as testing foundations to validate this. These are the principles, concepts, and best practices that form the basis of software testing. These include things such as the importance of having clear and well-defined requirements, the need for thorough planning and coordination, and the importance of using appropriate tools and techniques to ensure the effectiveness of testing efforts. Let’s start with the different activities and roles.

Activities and roles

Testing activities are the specific tasks and processes that are carried out as part of a software testing effort. These may include planning and controlling testing objectives and goals, analyzing and designing test cases, understanding the tools and services needed, and test implementation and execution. These activities help ensure that your low-code solutions are of high quality and meet the needs of the business. These activities may be carried out by different roles within an organization, such as software developers, testers, and quality assurance (QA) engineers. Testing roles are the different positions or jobs within an organization that are responsible for carrying out various testing activities, such as test leads and test engineers. As a citizen developer, you may also be involved in testing activities throughout the life cycle of your app. Each of these roles may have different responsibilities and expertise and may work together to ensure the success of the testing effort.

Once you are aware of the importance of adding testing to your app, one of the challenges is what to test and how to add tests. If you already have an application without any tests, how do you begin? Each app is unique, but you should consider the following guidelines to start with.

Prioritized and end-to-end flows, or the critical path

Focus on the top activities of your application. You want to check and validate that it is working as expected while you evolve and add new features for users, and on the other hand, that you find any issues users could face with the app. As part of the design stage, select the different parts that are the most valuable to the users. In our expense report app, think about the whole flow a user must go through to complete a job. Start creating test cases, following the flow from start to finish — from the main page, where you check the complete list of expense reports in our fictitious app — to the detailed information and the creation of one report — until you edit it and submit the expense.

Validate new features, one part at a time

As part of the new features you add to the app, review the main goal for the user, and break it down into steps so that you can, on the one hand, validate the expected result for the user, and, on the other hand, check whether future changes you may make will break the experience of the user.

From a best practice perspective, you should think of scenarios (you will map this to a test suite later) where specific features are validated as test cases to keep test cases small but group those tests with the same purpose.

In our expense report app, you may consider a test suite new expense report, where the user will follow several features and steps (test cases) to fulfill their objective – from report creation, expense creation, and editing to image receipts and expense report submission. This must also be done to validate that old functionality works as expected. An example of this includes submitting a special type of report for public sector companies.

Make it simple and fix it later, or the Boy Scout rule

The best part of the testing process is anticipating issues before your users face them. But once you or your users find an unexpected behavior, the best next step is to fix it and add tests around the bug to validate that it is working nicely.

When a new bug appears, it helps you understand why you didn’t prioritize its flow or didn’t add a test case specifically. In the design process, sometimes, you expect your users to use your app one way, but they end up using it in another way. Monitoring and feedback may give you important data from your app, such as a mismatch in expectations during development.

Finally, to fix a bug that one of your tests has detected, keep it simple and describe the expected outcome. The simpler and more assertive the test is about its expected result, the faster you will identify the coding issue. You will learn more about this when we cover the concepts of test expressions and test assertions in the next chapter.

Testing responsibilities

We may be the only one responsible for the app at the departmental level, or it may be part of an organizational-level app, and you could be part of a team involved in developing the app and expanding low-code and pro-code. Either way, testing is everyone’s responsibility. However, the larger the scope of complexity of the app, the larger the team and roles’ responsibilities. In these two scenarios, you could find the following:

• Dedicated roles in the scope of the whole organization or specifically for a project, including employees and/or external companies. In those teams, the maker/developer will be responsible for implementing the app and validating its behavior. You will find two levels in a software testing team:
  • Test lead: This person will be responsible for test planning, test governance, and coordinating with test engineers or testers
  • Test engineers: This person will be responsible for understanding what needs to be tested, developing and executing test cases, and test reporting
• Having a single person in personal development, departmental applications, or small businesses is usually the norm. The maker/developer is responsible for writing the code and ensuring that it works as expected. Having said that, all people involved should participate in the testing process through some of the mentioned activities.

Now that we have reviewed the activities and roles that help us identify what to test and who should be responsible for testing, let’s drill down into the mindset of the tester.

The mindset of a tester

Among the various factors that contribute to successful testing, the psychological aspect holds a significant position as it can influence the way we approach testing without our conscious awareness. This can be attributed to several reasons:

• A solution-oriented mindset versus a problem-oriented approach tends to be less effective when it comes to testing code
• It can be challenging to identify defects in something that has been created by yourself
• It can be difficult to consider potential issues when the focus is on what the system should do

Testers do not typically need to have a deep understanding of how the system under test works. Instead, they need to adopt the perspective of the end user and consider potential scenarios from the user’s point of view. In this context, your knowledge of how the system works can prevent you from identifying alternative scenarios that may lead to unexpected behavior.

Therefore, to be an effective tester, you need to focus on identifying ways to break software. A software tester’s job entails not only finding bugs but also preventing them. This includes analyzing the requirements, process optimization, and implementing a continuous testing strategy. In this sense, a tester’s mindset entails being concerned with quality at all stages of the SDLC. Because quality is the responsibility of the entire team in agile development, the primary focus of agile testing is shifted toward the initiative and controlling activities that prevent the occurrence of defects.

This connects us to the following three key areas of agile development, in which it’s acknowledged that testing is not an isolated stage but an essential component of software development, together with coding, thereby summarizing a consolidated view of many of the capabilities for testing:

• Mindset: This is where everyone is responsible for ensuring quality and running tests as a cross-process and not just a phase through customer collaboration and thinking in terms of requirements elicitation
• Skill set: In the role of tester, as a low-code developer, think of adopting skills to do different types of testing through automation and effective communication and collaboration
• Toolset: Use development and build tools for the best performance and use examples and requirements as guidance and support (visual examples, mockups), as well as simplification (recording, multi-level test automation in fusion teams, and so on)

Agile testers must depart from the guiding concepts and operational procedures of conventional software development. Success as an agile tester requires the appropriate mentality. Twelve principles can be used to summarize the agile testing mindset, as shown in Figure 1.5:

Figure 1.5 – Agile testing principles

Let’s take a closer look at them:

1. Quality assistance over quality assurance: Quality assurance is the process of ensuring that the software meets certain quality standards before it is released to the customer. Quality assistance, on the other hand, is the process of helping the customer achieve their quality goals by providing guidance and support throughout the development process.
2. Continuous testing over testing at the end: Continuous testing is the process of testing software throughout the development process, while testing at the end is the process of testing the software only once it is completed. Continuous testing allows for the early detection of defects and allows for faster delivery of the software to the customer.
3. Team responsibility for quality over the tester’s responsibility: In traditional testing approaches, the responsibility for quality lies solely with the tester. However, in a whole-team approach, the responsibility for quality is shared among the entire team, including developers, testers, and other stakeholders.
4. Whole team approach over testing departments and independent testing: A whole team approach is a process that involves all members of the team in the testing process, including developers, testers, and other stakeholders. This approach allows for better communication and collaboration among the team members and leads to a more efficient and effective testing process.
5. Automated checking over manual regression testing: Automated checking is the process of using automation tools to test software, while manual regression testing is the process of testing software manually. Automated checking is faster and less prone to errors than manual regression testing.
6. Technical and API testing over just UI testing: Technical and API testing is the process of testing the underlying technical aspects of the software, such as the code and the APIs. UI testing is the process of testing the user interface (UI) of the software.
7. Exploratory testing over scripted testing: Exploratory testing is the process of testing software by exploring it, without a preconceived test plan. Scripted testing is the process of testing software by following a predefined test plan. Exploratory testing allows for a more flexible and creative approach to testing and can lead to the discovery of defects that may not have been found through scripted testing.
8. User stories and customer needs over requirement specifications: User stories and customer needs are the processes in testing software that consider the needs and wants of the customer, while requirement specifications test software by following a predefined set of requirements. User stories and customer needs allow for a more customer-focused approach to testing and can lead to a better test to satisfy the purpose of the feature developed.
9. Building the best software over breaking the software: Building the best software is the process of creating software that meets the needs of the customer and is of the highest quality, while breaking the software is the process of finding defects in the software. Building the best software allows for a more customer-focused approach to testing and can lead to a better understanding of the customer’s needs.
10. Early involvement over late involvement: Early involvement is the process of involving all members of the team, including testers, early in the development process, while late involvement is the process of involving testers only at the end of the development process. Early involvement allows for better communication and collaboration among the team members and leads to a more efficient and effective testing process.
11. Short feedback loop over delayed feedback: Having a short feedback loop is the process of providing feedback to the team members promptly, while delayed feedback is the process of providing feedback to the team members only after a significant amount of time has passed.
12. Preventing defects over finding defects: Preventing defects is the process of identifying and addressing potential issues before they occur, while finding defects is the process of identifying issues after they have occurred. Preventing defects allows for a proactive approach to testing and can help minimize the number of defects that are found in the software.

Finally, it is important to understand the different types of testing and how they apply to development.

Types of testing

Some common types of testing in development include performance testing, unit testing, integration testing, system testing, acceptance testing, and UI testing. Using the principles of inclusive design, we should consider accessibility or localization testing as well. Unit testing focuses on testing individual components or units of your low-code solution, while integration testing focuses on testing how the components work together. System testing focuses on testing the end-to-end functionality of your solution, and acceptance testing focuses on verifying that your solution meets the needs of the business. By understanding these different types of testing, you can develop a test-driven mindset and ensure that the low-code solutions you develop are of high quality. Let’s discuss each type in more detail.

Unit testing

The goal of unit testing is to identify and fix any issues with individual units of the application before they affect the overall functionality of the system. This can help ensure that the application works correctly and meets the specified requirements. You should consider it when you develop Power Apps code components.

Integration testing

This is a type of software testing that is used to evaluate the interfaces between the different components of an application or system. This type of testing is performed to ensure that the different components of the application are working together properly and meeting the specified requirements. You perform this when you use third-party connectors or when you build a custom connector and want to validate the integration.

System testing

The goal of system testing is to identify any issues or defects that may affect the overall functioning of the app from a feature perspective (functional) and a performance, security, or scalability perspective (non-functional). This may involve creating a specific Power Platform environment with your solution test data and the needed integrations or connectors in a test environment.

Acceptance testing

This type of testing is typically performed by the end user or a representative of the end user and focuses on evaluating the overall functionality and performance of the application from the user’s perspective. We will explore this in detail in Part 3, Planning a Power Apps Project.

Exploratory testing

Exploratory testing is an approach to software testing that emphasizes creativity, learning, and adaptability. It involves testing a software product without a formal test plan or script and relies on the tester’s intuition, experience, and skills to discover issues and opportunities for improvement. It may involve using your app while running Power Apps Monitor watching out for errors, app performance issues, accessibility or design problems, and unexpected error messages.

UI testing

This is a type of software testing that focuses on the visual aspects of an application, such as its layout, design, and UI. UI testing may be performed manually, by having a tester visually inspect the application and compare it to the visual specifications, or it may be automated, using specialized tools such as Test Engine or Power Apps Test Studio to compare the actual behavior of the application to the expected behavior.

Overall, each of these testing processes is important in its own way, and they all play a crucial role in ensuring the quality and success of a software application. By performing these tests at different stages of the development process, it is possible to identify and resolve any issues with the application before it is released, which can help improve the user experience and ensure the success of the app and the happiness of your users.

Now, it is time to start the final section of this chapter and review how all the previous content comes together.