(This post is from my previous blog, but introduces another blog series that I will be working on around the BBST Foundations book – having blog series help provide some framework to keep me blogging and generating additional ideas)
I just finished the first lesson/chapter in the BBST Foundations book (and more information/background about the book can be found here – http://kaner.com/?p=381). I enjoyed it, especially the reflections at the end. Given that the project (BBST) has been around for a while, there were some questions I had while taking the course that I found the reflections help to clear up, like the reference to the AST dictionary project. I also found the Testing Circus – February 2014 edition (BBST special) to provide some great background about the courses and their evolution. It really helped me understand why I ran into some of the issues in the AST Online courses that I did and the current connection (or lack of connection beyond use of materials) between Dr. Kaner and the AST BBST courses.
As far as the content of the first lesson goes, I found the treatment of the levels of testing to be valuable. It seems pretty fundamental I know, but I can get locked into a particular way of testing from time to time and this was a reminder that there are multiple levels at which an application can (and probably should) be tested, at times with different desired outcomes for those types of testing. One of the definitions that I think could have been edited and improved was around acceptance testing. I believe I understand where the content is coming from in relation to acceptance testing (customer-focused and executed vs. some agreed upon definition or set of tests that can be executed by a test team before the new software is “accepted), however the wide-spread adoption of agile processes, acceptance criteria for user stories and subsequent tests defined to help prove out that acceptance criteria are things that many (I believe most) will run into. I believe that this definition would benefit from some extra treatment that address this.
The issues related to quizzes and instruction were familiar to me (I used to teach in the K-12 space and have a degree in education) and I generally agree with what is explained about quizzes and using them to drive additional learning instead of merely assessment of a user’s progress in the course. Finally, the treatment of the concept of quality is very valuable. I believe many people generally consider that one of the core mission of testing activities are to help contribute to better quality in software, so understanding what quality means is important, as is the realization that the concept of quality might mean something different for someone else (like your manager or the person for whom we are making the software).