Challenges in Test–Ensuring Testability/Influencing Design
Products are primarily designed for customers, yet a test team must test these products. Who is thinking about how you might test the product? If you are a tester, you better be thinking about it and providing feedback to your developers about their design. Your feedback should both be for the customer and how to better enable you to test the product effectively.
For some of technologies there may be tools you can use such as the IAccessible interface for many windows forms or the tools that we ship as part of Visual Studio Test. Yet you may be on a product for which there are no other people testing that technology & therefore less existing items you can leverage. A tester needs to know what technologies are out there & be willing to dig in and implement similar technologies if they do not exist for their environment.
For example how can you do UI automation on an Xbox console? The console does not have public interfaces for manipulating UI elements & is completely different than a traditional WinForm. Additionally, it uses a different processor architecture (PowerPC) than what many Microsoft products use (x86, x64, & more recently ARM), so some tools & libraries won’t work on it. What does it’s UI need to support for you to be able to have reliable automation? What would you ask the developer to do for you to get better automation? Below are a couple items that you could use when designing your product to improve testability. As always with test, there is no one magic bullet but instead they are tools that we can leverage where it makes sense for our development.
Model View Controller (MVC)
Design plays a large role in how you can test a product. It influences how devs write their code & how you can then write your test code. There are many concepts out there to help improve the testability of a product design. One example is Model View Controller (MVC). The idea with this design pattern is that you minimize the logic that is in your UI (aka View) and push your business logic into the model. The controller then manages the interaction between the two. With most of your business logic pushed into the model, this means you can now manipulate the model directly possibly via APIs and do a large amount of testing that way instead of relying on the UI. Traditionally API testing is much more reliable & robust than UI testing as UI changes more often and has timing issues with regards to knowing when you click on something when the next screen of the UI is ready for input. This design also has the added benefit of allowing the developers to quickly add additional views with out much effort.
A newer pattern which is similar and targeted at several of the latest Microsoft UI development platforms (Windows Presentation Foundation & Silverlight) is Model View ViewModel (MVVM). This adds a ViewModel which is an abstraction of the view used in data binding of the model to the view.
Mock Objects
How are you going to test error conditions in your code? What if components you require are still under development? Are you testing a UI component which requires a service? Mock objects are a useful way to tackle these types of problems. If you design your code to allow for the ability to use mock objects, you can simulate them. In order to do this your product needs to be written clean enough that you can swap mock objects & the real objects.
Take for example a product that relies on a SQL database. You likely have a data layer that handles your calls out to SQL. When implementing this data layer, you can implement a mock object to simulate the SQL server. This would allow you to do things such as simulate the results of the database or if the network is down. Mock objects are also useful at the unit testing level as the developer can isolate their component to only rely on these mock objects. This is especially useful if they depend on another component also under
development which may not be ready for consumption yet. If you are following test-driven development (TDD) then it is also useful for being able to write tests prior to implementing the product code.
Conclusion
Similar to developers, testers need to stay abreast with the various design patterns that can be used in development. As products continue to grow in complexity gone are the days of a tester being able to strictly white box test and black box test an application after development is code complete. Doing so will likely result in a product that is highly difficult to test and result in automation that is less robust and reliable. Instead we expect and involve our testers from the earliest stages of design both as a sounding board for designing a solution to a problem and as a source of input to ensure the product we develop is highly testable.