I wrote a blog post giving an introduction to the 30 days of testing challenge that I am doing. When I first read this task my first reaction was. I don’t do exploratory testing. But after thinking about it a little bit I concluded that I do it without thinking. I do it all-the-time.
Here is a diagram of that models how I write code.
Before I explain what the paths are through this network of feedback loops. Let me define the steps above.
- Code – Writing application code, not test code
- Developer Test – Automated tests that are not from the perspective of the end user. Non UI tests, if you will.
- Acceptance Test – Automated Tests that exercise the application like a user. Think Selenium or Protractor tests
- Manual Test – Manually testing the application as if I were a real user.
So where do I start? Sometimes I start by writing code and sometimes I start by writing developer tests. It depends on what I am doing and how I am feeling that day. Either way, I write a little code, stop, and write some developer tests. I try not to go too long without writing tests.
I alternate between coding and developer testing until I have something that I can use. Then I add manual testing to the loop. The first few rounds of manual testing help me answer the following questions:
- Does it work?
- Is it easy to use?
- Does it look good?
After I get it to work and look good, in at least one browser, then I move on to more exploratory testing:
- Think of edge cases that are not described in the acceptance criteria and test for it. Usually, this gets discussed during development but a few can fall through the cracks
- Test the entire experience the user would have when using the feature. Some usability defects don’t get fleshed out until a human uses the software (funny how that works). Developers are the first users of the software so this is an opportunity to give that feedback to the designer.
- Test other areas of the application that depends on the code I changed.
- If we identified risks of a feature or story such as, if there is a large amount of data, then the page will not open quickly. Then I make sure I test those cases.
When all of my Developer Tests and Manual Tests pass, then I write the automated Acceptance test(s). These are usually a happy path tests that exercise the critical paths through a feature. Why not write them in the beginning? Some people do. It would be awesome to become one of those people one day. Acceptance tests are brittle. If the UI design may change then writing a test up front may cause rework of the tests.
Task 4: Read the Agile Manifesto and reflect on the implications of your role
