A new teams encounter with DET/TET as a framework for testing – Part 1-Context
Over the last year I have been asked many times about how to implement DET/TET at a new company. Since most of my experiences have been within Jayway where the concept is accepted, I have not been able to answer that question in a good way. This is my story of implementing DET in a company which had not been using it before or very much any other formal testing. Since i got the question, this company is not Atlassian, but my last assignment before my move.
In this first post I want to give some context about the assignment, the company and product and what we ended up doing. In the following posts I will highlight specific aspects that were relevant for this implementation in the new company.
I was brought in as an Agile testing mentor to this company, which actually has no dedicated testers. There were a couple of reasons for bringing me in, examples include the workload of support people and embarrassing bugs found by customers. In short, you could say that they have grown out of their product in terms of overview and need for better ways of working than before. Since it shows as a quality drop, they figured they needed some better testing.
It consists of three main groups of people; developers, support group and business consultants. Developers work on a big backlog of both new functionality and maintenance releases. This is run in a pretty good Agile fashion by the PO and development manager. The business consultants are the ones that best know the product domain, helping customers with configurations and business development using the product. The support group also includes operations, which helps installing new customer environments. They are actually the ones that mostly carry out tasks similar to testing when reproducing customer issues and solving them.
The company is distributed across two main locations, but with people working at all customer sites as well. This was an interesting challenge all along for me, although everyone were very used to this way of working. Main tools for collaboration included Skype, teamviewer and the whole Atlassian suite.
Most people were in very positive spirit towards what I was doing all the way from the start. They all appreciated the efforts and were very willing to invest themselves into the process. This helped me very much when introducing new ways of working.
The product is an enterprise java based application that consists of plenty of modules, services and add-ons which has been developed for many years. This was a challenge in itself when testing because of the needs for test environments, data and preparations. Test isolation also became an issue when the whole team tested at the same time.
Like many projects I have seen, the reason for poor quality is as obvious as you might think; lack of testing and/or the acting on test results. To improve the situation, the solution is quite simple, simply put the testing up on the agenda in some form. As a start, we took on two different forms, targeting development team and business consultants respectively.
Development team had heard about DET and read the original articles. Meeting with a colleague of mine made them want to try it out, but they needed some guidance and focus to make it happen. Another thing to notice is that they had already tried to introduce the DET column in their greenhopper board, but did not have any formal way of working with it. Since I have mostly worked with it outside of the story scope, this is what we went with. And that is just as easy as it sounds. Some coaching on formalising time for everyone to test together.
The other thing that I did was to introduce scenario based testing to the business consultants. With some freedom to explore, they were introduced to a framework for specifying and executing scenarios mainly targeted at release testing. That might be a subject for later posts.
With these two things, I we achieved a company wide attention to quality and put testing up on the agenda integrated with day to day work.
If you want more context than this to follow the next posts, please ask me to clarify. If not, please continue:
A new teams encounter with DET/TET as a framework for testing – Part 2-Intro workshop