|
Recently I finished a three days training course on Rapid Software Testing with Michael Bolton in London UK. This course was very effective and had elements related to learning, questioning and thinking all along. It reinforced my belief that testing is not a 'phase' performed towards the end or a '100% automated suite' as claimed by many Agile shops. Software testing is much more than that and it is extremely important for the successful delivery of any project.
This was my first training course related to software testing and I was extremely happy with the outcome of this course. I have tried to capture my experience of this course in the following paragraphs.
Day -1
Training started with the discussion on a seemingly simple concept i.e. understanding of 'problem'. One thing that is bound to happen in Michael's class is lots and lots of questions. These questions are really important because they trigger something in our brain and make us think. For a simple word 'problem' that we use everyday, there could be so many questions. For example - What is the meaning of problem and how it is related to testing? Why problems are important and to whom they are important? How do you report a problem? How it is related to your credibility and what is the psychology behind it. Problems, I know for sure will never be same again for me.
There were many interesting things that we discussed on the first day. For example, how many times we ignore our emotions while testing and how important it is to have awareness about these emotions. If as a tester you feel shocked, puzzled, frustrated, amused and so on, chances are that the user will feel the same. When you feel these emotions, probably its time to explore and ask question. I also liked discussion on the epic questions like � "Why testing is taking long?", "No user will ever do that!!" and different interpretations of these.
Key take away from the first day for me was discussion on cognitive bias, heuristic, general system thinking, Importance of inference, conference & reference. During the course, when these things were discussed, I could relate many times how these things are related to what I do everyday. This realization or understanding gave me plenty of 'aha' moment on the first day.
Day � 2
Theme of heuristic was continued on the second day and Michael explained importance of guideword heuristics and triggers. What made this training very interesting were the numerous interesting exercises, magic tricks and discussions around them. These discussions were extremely helpful in understanding concepts like oracle problem, eye-brain law, binary fallacies and concomitant variables among many other things.
In my opinion, one of the most interesting take away from this course was increased understanding and awareness about the things we probably do but without understanding reasons behind it. For example, things like focussing / defocusing to improve efficiency, modelling, chartering, observing, manipulating, questioning etc., we are probably doing some of these, but having awareness about what we are doing and why we are doing will certainly increase our effectiveness.
On the theme of testing software rapidly, Michael introduced us to the quality criteria � CRUSSPIC STMPL which translates to (Capability, Reliability, Usability�. And so on. ). Probably for every project we start with considering what is important, but having a list similar to this mnemonic will make identification of quality criteria much faster and ensure that nothing is missed.
Day - 3
Michael has many exercises and tricks to ensure that grey cells are working through out the training. On the third day, after a challenging exercise, he made us realize the concept of "Pesticide Paradox". In a nutshell it shows that repeating same (or similar) tests over and over again will rarely yield good results. It also showed us that varying many things at once is not a good idea and varying one factor at a time and observing its effect might be a better thing to do. As a concept, it probably looks simple, but challenge is in identifying whether a given test case is revealing any new information or not. When Steve and me were pairing to solve an exercise, Steve made me explain every combination I was proposing. That was extremely helpful and it ensured that problem is solved rapidly and only combinations which were revealing new information were used.
One thing that this training does really well is changing perception many people have in their mind that testing is a mundane / simple activity. For example many people take a very simplistic view on what is boundary value analysis, but if you think hard, you will be amazed to know how many boundaries any system can have.
Towards the end of last day we had discussion on blink testing and its usage, coverage model and many interesting mnemonics to remember them easily, for example, SF DEPOT, CID TESTED and so on.
Overall this training and all the discussions we had during the course was an amazing experience. I would highly recommend this training to anyone interested in learning rapid software testing.
Another important part of this training was its location and other logistic arrangements. This training was organized by Stephen Alloty from ElectroMind.
|
