Our group of fellow testers gets together once in a while to discuss our profession of testing and quality assurance. This time we discussed some remarkable examples of our own experience that perceptive testers (who are aware of the specific situation they’re in) adapt their approach to fit the specific needs.
Leo van der Aalst starts with this anecdote:
Currently more and more IT projects are done in an agile way. It was just a matter of time I, being a tester, would be involved in an agile project. So it happened that in the beginning of this year I was member of a scrum team. In a traditional development lifecycle I would have to read comprehensive documents like requirements and functional designs. And then write a report whether these documents were consistent, complete and testable (TMap NEXT calls this ‘intake of the test basis’).
But of course, when you are dealing with sprints of three weeks, this approach doesn’t work. So instead of reading documents, I had talks with the designer, developer and product owner about the features they would deliver in the current sprint. I asked them questions and when I got all the answers I needed, the intake of the test basis was done and I could start creating test cases. So, no time was lost with reading comprehensive documents, writing a report about the findings and then lose some more time because I would have to wait for these findings to be solved before I could start writing the actual test cases.
Rob Baarda shares his recent experience:
When I was writing the book “End-to-End testing with TMap Next” the expertise group started off finding the best practices from many E2E testing projects. Being an End-to-End-test manager in an E2E test project myself I immediately noticed that some of these practices were certainly good practices but did not apply in my situation. Other practices fitted perfectly and applying them helped me speed up my testing. So these collected practices are great to inspire test managers to adapt the way of working to their specific situation.
Ewald Roodenrijs enters the role of people into the story:
A few years ago, when I started in a new project, I found the project consisted of some loose ends in people that didn’t cohere with each other; we needed to bring them together and focus on the same result. I knew I needed to get the people involved in testing, we all needed to work together to get to a well-tested software product.
We started the project by getting all together as stakeholders of the project and perform a product risk analysis. This helped us all to get an understanding of what everybody wanted in the information system and the issues that existed between people and departments. During the project we found, as often happens, that the requirements and circumstances changed. So while involving all people we adapted the test strategy. In the end the information system went live as a great success, thanks to the effort of all people involved in the project, not because of the process, but because of all of us working together towards the same goal.
Bart Vrenegoor experienced that circumstances often change:
Some years ago, I worked for a large bank that was in the process of merging with another bank. I was the test coordinator working on a project that was responsible for automatically sending letters to millions of clients who were affected by the merger.
The image of the bank was at stake, the quality of the letters had to be high and we simply couldn’t afford to have major defects. Based on the outcome of the product risk analysis, we decided to do a considerable amount of testing to cover the risks identified. Most of these tests were done by external consultants like myself.
During the project circumstances changed radically. The financial crisis emerged and struck the bank hard. As a result, most external consultants had to leave to reduce cost. The project had always been driven by quality, but now had to make a huge shift to cost driven. It is obvious that this impacted our test approach as well. We simply didn’t have the manpower to do all the work we initially planned to do.
Eventually everything worked out fine. The remaining consultants focused their testing on high-risk areas and additional acceptance tests were planned to cover other areas. We couldn’t do all tests we planned, but this was accepted by our stakeholders. The letters were eventually sent without any major disturbances. I believe this is a great example on how to adapt to changing situations.
Ben Visser expands on change and the fact that a system should solve some problem:
Recently I entered a very large migration program that was running for over two years already and the final acceptance stage was about to start. Some diehard process tigers had implemented a rigid test process, based on TMap NEXT but ‘ameliorated’ to their own ideas: they had picked some TMap elements they thought were useful but had forgotten to involve the end user perspective. All in all, the test process had become ‘test centric’ instead of ‘solution centric’. We were just in time to transform the test approach to fit the actual context and do justice to all involved in testing and accepting the solution. We facilitated cooperation between end users, developers and testers by organizing test goal workshops, risk workshops and test design workshops. Furthermore, reporting – based on test goals and risks – was placed in context and adapted to the needs of the relevant stakeholders which contributed greatly to actually implement a system that was a solution to the needs of the stakeholders.
Thomas Veltman tells about the challenges a test team has to overcome:
One of my most inspiring experiences as a test manager was at a startup energy company that was on the market for only a short period and was focused on low pricing. They always had a sharp focus on winning clients and less on the quality of their internal systems. This approach was very successful: the company had grown rapidly. Because of this, everyone in this company always had too little time for everything and especially for testing. This asked a lot from the testers, who were pushed to the limits of their abilities to be able to test efficiently and effectively. They had to devote a lot of time and energy to understand their surroundings and the drivers for the business which of course is a prerequisite for a successful test. Besides that this project was favored with good testers that were able and willing to look outside their profession, this was made possible by templates and techniques from TMap that could be adapted in short time to be leveraged effectively in this environment. Testers did not lose time by reinventing the wheel so they could use their intellectual powers to solve the problems they encountered.
Rik Marselis concludes that collaboration is the only real way to successful systems:
Over the years I learned that testing is no activity on its own but is an important part of quality assurance as a whole. It supplies valuable input for status – and progress reporting. The quality gate is often introduced for the decision to go from one stage to another. In recent discussions with clients and colleagues we concluded that this often doesn’t work properly. We need to have a “Quality Collaboration Point”. At the handover from one stage in the project to the next the people involved need to use their combined skills to make the right decisions that lead to doing the testing and quality assurance activities that are suited to the situation at hand and to make sure we deliver the right information system to solve the business challenge, within the bounds of time and cost.
Together we concluded that although TMap NEXT was introduced some six years ago it still is a solid foundation for any testing project since the essence of adaptiveness makes sure that any perceptive tester can collaborate in doing the right things at the right moment in any project and thus ensure that the proper quality is delivered to solve the problem of the stakeholders.
