This post is a follow up from “A Kanban focused Test Project – Part 1“. Part 1 was more about the Kanban side of the project where this post should highlight the testing perspective of it.
Because there are no clear requirements we perform test sessions – see Session Based Test Management. Within a Test Session we explore certain areas of the system and learn how it is working etc.
Example of a session report with Microsoft Excel:
The client was already using Jira as Issue Management Tool and we got the Zephyr Plugin for Test Management activated. The Zephyr Plugin allows us to create tests the same way we create a task or bug. Additionally it comes with some extra features for testing like adding execution steps and executing the tests to get a nice report. Because I am not a big fan of doing scripted testing and defining all the execution steps of a test we just created the test areas e.g Teaser Widget, World Time Clock Widget, Responsive Design etc.
For all these test areas we gathered all the information we could get and added them to the test description. This is the basis for our exploratory test sessions. After each test session we feed back the important tests and add them as execution steps. In this case we have a good basis for future regression testing. At some point those regression tests could be automated as well but not within this project as the time constraint is too tight.
Beside the regression tests we still perform additional exploratory test sessions to learn more about the system and explore areas we haven’t thought about yet or were added meanwhile.
I think it is a not so traditional approach to software testing and test management and occasionally it is hard to convince the management what we are doing.
Some of the problems were/are:
- testing at the end of a project is never a good idea – Big Bang
- having no requirements is a challenge – We can perform exploratory testing but who says what is a bug? Different people think differently about the expected behaviour.
- management/project leads asks for test planning althought we have our Kanban prioritization – Too much traditional thinking?
- all the teams are separated from each other – but for our kind of testing we need all the parts of the system working together
All in all it is a challenge and I would prefer a more agile approach where everyone works together towards the final solution and testing is already part of the development cycle.