You know the feeling, you’ve been working as a testing manager for several years, you and your team have established a testing process, and then worked on improving and refining it, but you’ve reached the point where you can’t achieve any more. It is not that your processes are perfect, they aren’t, but you realise that to make further improvements in the testing process you have to change the way development works, and that is a far harder task.
So how do you go about changing the development lifecycle? Key areas to address to make progress with testing are; documentation, volume of change, design for testing, quality assurance/quality control and project management. Then you have the traditional problems of the relationship between the developers and the testers, organisational priorities assigned to testing, and the commercial realities of a software house.
This presentation uses as a case study the work carried out by Graham over the last year, starting with identification of the problems, kicking-off a change program, and then details the initiatives that have resulted, including the definition of a test friendly development lifecycle. To add to the complexity the development group have been investigating agile methodologies such as XP.
1. BCS SIGiST, London – May 2002
2. EuroSTAR, Edinburgh – Dec 2002
An introduction (by Graham, in his role as Secretary) to the BCS SIGiST Standards Working Party, giving the history of the group and details of the current work (2001) on non-functional testing techniques.
This is followed by a two interactive exercises looking at standards options for non-functional testing techniques in the areas of Procedure Testing and Performance Testing.
1. EuroSTAR, Stockholm – Dec 2001
Several times over the last few years of working as a tester, I have found myself making compromises on the way that I have been testing, and generally felt very uncomfortable about doing so. Everyone will tell you that compromise in testing is inevitable, but that never makes it any easier. It is never possible to get the perfect mix of resources, skilled testers, equipment to test upon, enough time to plan and prepare for testing, or even to run all of the test scripts, let alone re-test all of the software fixes.
Managers are forever telling you that when they used to write and test software they did it this way, or that way, someone else will suggest that you aren’t using the right toolset, and even your own testing team may disagree with the general direction or method. Notwithstanding all of that, and the fact that developers don’t make mistakes do they, the users will then blame you personally for every bug that they find!
This talk does not offer a silver bullet solution, but will take you through the testing lifecycle, identifying the areas where compromise is most commonly called for, and show you the techniques that I have found successful in managing and controlling that compromise without losing integrity. And also a few of the pitfalls!
1. BCS SIGiST, London – Sep 2000
2. EuroSTAR, Copenhagen – Dec 2000