Our applications are growing larger and more complex in business functionality, and they are available on multiple platforms. Our business partners expect more functionality with better quality delivered in a timely fashion while our technical leaders attempt to simplify designs and make it all possible.
The ability to deliver value in an application AND making it simple to use challenges experience designers, developers, analysts, and especially testers. An expectation to evaluate application behaviors in depth through just the user interface has not only become a fallacy, it has become insufficient and risky.
High profile projects in your organization must be delivered quickly and as a tester, you cannot wait for completed code to begin testing, and you cannot assure quality merely by testing through a UI. The definition of testing must extend beyond exercising code to evaluate requirements and risks. To expect high quality products at a good pace, you must foster and nourish quality as a team sport. Your time is now and project teams are ready to hear you!
Testing now begins when work is assigned. You are the Question Asker and you scrutinize acceptance criteria.
Soon after the assignment of a story card (or your method of work conveyance upon your team), the Three Amigos is your first opportunity to foster team quality, your first opportunity to “test”. Your tests include
- A check for acceptance criteria clarity
- Does everyone have the same, deep understanding of WHAT is being built?
- Have those understandings been verbally explored and vetted?
- Have you vocalized your assumptions and had them clarified?
- A check for validity
- Is this product being constructed at the right time?
- Are there dependencies that could prevent its timely completion?
- A check for value
- Some products are defined at some time in the past – does the present context of the project still support the work defined by this card?
- Will the completed work still be valuable to the project and the product?
Testing continues as products are designed. You are the Quality Advocate for testability in designs and implementations.
Most products require some thought before their construction. The project team explores possibilities for implementation during design meetings. Your testing continues at these meetings. While you could also attend design reviews, a design review may imply that the design has been decided – this is too late.
When the design of a product is discussed, your primary goal is the testability of the product. If the design addresses just the business intent of the product, then it is not testable. As a tester, advocate for testability. Make a request for error logging, for transaction transparency, and for data transparency. An introspective product is a testable product.
During implementation, paired programming becomes paired collaboration. You are the Quality Accomplice with simple tests at the ready and encouraging reflection on how the product in front of you will interact with the system.
Quality must be built into a product: the product is defined in a manner that is clear to everyone, the product is designed so that inspection is simple, and the product is constructed and checked multiple times during its implementation. As a tester, you are the Quality Accomplice by having tests ready for execution at any time, and by working with the developer to help them create a quality product that meets the business intent. To work effectively with a developer, you must understand the system and its components, and how the components interact to provide value. With that understanding, you can ask questions how the code in component A will interact with the code in component B under multiple scenarios. This collaboration helps everyone reflect on the integration of small parts defined in story card and their contribution to a product that operates correctly in multiple scenarios.
I encourage you to go forth and experiment with these ideas.