Day 1: Testing Process
The first day of our Process week has been interesting and somewhat productive. We started off by taking over one of the conference rooms. We setup my laptop in front of the white board and recorded our conversation. We talked for about 4 hours. Here is a summary of this conversation.
First of all, we need to change how we implement projects because the process that we have right now causes too many revision cycles. From our experience, revision cycles are very distracting and time consuming. Sometimes each revision cycles takes from 2 days to 1 week.
Here is what a typical revision cycle looks like:
- We implement all of the features in the spec and pass the site back to client advisor
- Client Advisor either does testing himself or passes on to the Client to do testing and find bugs
- Client or Client Advisor (depending on who is doing the testing) creates a list of bugs
- Client Advisor passes the bugs to us
- We fix the bugs and go back to step 1
The real problem is that we leave it up to the Client or Client Advisor to find bugs in the website. This adds work to Client Advisor and creates a perception of a faulty product. We would like to eliminate this as much as possible.
I think one way to do it, is to take a more proactive approach to testing. I think instead of testing at the end, we should plan testing at the beginning. What this means is that we would actually create tests for features before the feature even goes to the developer. These tests should be provided to the developer with the tickets for the feature.
This is good for several reasons:
- It gives a developer better understanding of how the feature is going to be used.
- It allows to predict issues that might come up doing the development process.
So how would we actually do this?
Let’s take a Standard Art Gallery site as an example (these are the kind of sites that Artgal sells).
A Standard Art Gallery Site has the following features:
Frontend
- Home Page – usually some text, a featured artwork, list of categories
- Artists Page – alphabetical list of all artists
- Artwork Page – list of all artwork sorted by last name of the author then by title of the artwork
- Category View – to display artwork in specific category
- About Us – static content page
- Contact Us – contact form
Frontend Admin
- Edit Text on Home Page
- Add/Edit/Delete Artwork
- Add/Edit/Delete Artist
- Edit description on Category view
- Edit About Us Page
- Edit Contact Us Page
Now, let’s take a look at how we might actually build tests for some of these features.
First of all our goal is to make the implementation of the site as simple as possible. To do this, we have to make sure that we have predefined wireframes for this kind of site. Doing this will show the developer how the views should be setup. What we don’t want is for the developer to waste time creating the user interface.
Let’s assume that the developer has good detailed tickets that allow him/her to implement the feature according to spec. What should the test look like?
Let’s take “Exit Text on Home Page” as an example. Here is what a test might look like.
- Go to Home Page
- Client login at the bottom right
- Enter “admin” username & password
- You should now be redirected back to home page
- Click on edit beside the main text on home page
- You should see a form that allows you to edit that text.
- Change the text to “this is a very long text …. “
- Click save
- You should get “Your Text has been changed”
Each step has to be completed as per description for the test to pass.
For the developer, this allows to follow step by step and know exactly what’s going to be expected of his implementation and how it should be implemented.
For the tester, it gives instruction on how to test this features.
This can also be used as documentation for the client.
So it’s a win-win-win for everyone. And should potentially allow us to catch most of the bugs before the site goes to the client.
Next step is to see what technology we can use to automate this process.
I would love to hear your feedback,
Let me know what you think.
This is the common problem, and you found common solution. But i think using term “test” here is not right, developers think of test as of a piece of code or software which tests their code.
I think the best way to organize development is to use UML specifications (and maybe tools). UML has “use case” diagram which describes software usage in abstract terms and views. “Use case” diagram should be best tool of communication between developers,architects,managers,clients and others.
http://en.wikipedia.org/wiki/Use_case_diagram
For even more control developers can use “activity diagram”, which are used for deeper program flow visualisation.
http://en.wikipedia.org/wiki/Activity_diagram
The bad things are – clients should be smart enough to undesrtand UML diagrams, developers have to waste time for drawing diagrams.
UML is a very good tool if you use it right.