Archives

On the Value of "Running for the Board" and "Being on the Board" (TESTHEAD)

On July 31, 2015, in Syndicated, by Association for Software Testing
0

I sit here now in Grand Rapids, Michigan, after what has been a rather “eventful” day.  It started with a very early morning flight, which was delayed due to mechanical trouble, which turned my 90 minute layover in Dallas into a 13 minute layover …

Why this Tester Learned to Code (Assert.This)

On July 31, 2015, in Syndicated, by Association for Software Testing
0

Where I first started testing, it was essentially all “manual testers”. Much of the work fell into what James Bach and Michael Bolton would refer to as checks rather than tests. 1 The team was the quality guardian. The last line of defense before software could be released onto the world. The relationship between QA … [Read more…]

From Test Cases to Context-Driven Testing (software test kitchen)

On July 30, 2015, in Syndicated, by Association for Software Testing
0

On Tuesday August 4, 2015, I presented my experience report on moving from test cases to context-driven testing at the 10th annual Conference for the Association for Software Testing 2015 in Grand Rapids Michigan.  This was my inaugural speaking enga…

Let’s Make BBST Courses More Accessible (Testing Bites)

On July 30, 2015, in Syndicated, by Association for Software Testing
0

Are time and financial worries keeping students away?Second in a series.In my previous post, I wrote about enhancing the student and instructor experience in the AST’s BBST courses by focusing on updating the Fieldstones. Today, I’m talking about ano…

Let’s Make BBST Courses More Accessible (Testing Bites)

On July 30, 2015, in Syndicated, by Association for Software Testing
0

Are time and financial worries keeping students away?

Second in a series.

In my previous post, I wrote about enhancing the student and instructor experience in the AST’s BBST courses by focusing on updating the Fieldstones. Today, I’m talking about another area I would like to concentrate on if elected to the Board of Directors: finding ways to make the BBST courses accessible to more people.

When I say “make the BBST courses accessible to more people,” I’m not implying that the courses are in any way exclusive (other than requiring students to be members of the AST) or elitist. What I do mean is there are many reasons people are unable to take the BBST courses, and I think it would benefit the AST, and better help it to achieve its objectives, if we were to look into what those reasons are and find ways to resolve them.

One of the more common obstacles I see involves the time commitment required to succeed in the courses. One of our guiding principles is that we view software testing as a cognitively complex activity that requires critical thinking, effective communication, and rapid self-directed learning. To me, that means the BBST student needs to go beyond merely remembering or understanding the material the course presents. Using the language of Bloom’s Taxonomy, I believe the goal is for the student to not only apply what they learn in the course, but use it to create something new, critically examine information and make judgments, and take information apart and explore relationships. That, admittedly, takes time, and the general guideline for the AST’s BBST courses is to allow roughly 10 to 12 hours per week for study.

But I think many people who have taken a BBST course can agree the study guideline is really the minimum suggested time allotment, and students can, and often do, spend much more time on the course to get the most out of it. This can be a problem because everyone has limited time (BBST students are no exception!) and other commitments, such as work and family or community and charitable involvement, are all vying for that limited time. 

Another common obstacle is financial. Although the courses are reasonably priced, especially when compared to similar training options, there are those for which it can be a bit costly. Do we want to adjust the price of the course, award scholarships, or give a student discount as we do with membership fees? There are many ways that this can be addressed, each with its own intricacies and issues. 

So, what do we do?

I believe we need to initially spend time to identify some of the more common obstacles to BBST participation, and then work collectively to find ways to lower or remove those obstacles. 

Because, the BBST courses are an essential and integral part of what the AST brings to the community, and changes of this nature can have wide-ranging and unanticipated consequences, I think this effort needs to involve more than just the Board of Directors and the Education Committee, and should include involvement by the general AST membership as well.

CAST 2015: Count Down to webCAST 2015

On July 29, 2015, in Events, News, Newsletter, by marketing
1

The webCAST is only days away and we are making final preparations for the trip to Grand Rapids. For this year’s livestream we are using Youtube Live to avoid some of the annoying commercials and so we can broadcast in HD. Three ways to watch: AST Website Session “Watch Live” Button Youtube Channel Like last […]

Ingredients for well-designed OWIN middleware components – Part 7 (The Continuous Improver)

On July 29, 2015, in Syndicated, by Association for Software Testing
0

In the sixth post of this series I talked about how you can use Swagger to create real useful documentation for your API. In this seventh and probably last post, I’d like to present some spices to make that OWIN middleware component extr…

Ingredients for well-designed OWIN middleware components – Part 7 (The Continuous Improver)

On July 29, 2015, in Syndicated, by Association for Software Testing
0
In the sixth post of this series I talked about how you can use Swagger to create real useful documentation for your API. In this seventh and probably last post, I’d like to present some spices to make that OWIN middleware component extra special.
Spice 1: Automate your entire build process using PSake
So you’ve completed the first version of your component and you’re ready to ship it as a NuGet package. Manually creating that .nuspec file, running nuget.exe and publishing it to nuget.org is not that difficult to do. But now what? Are you going to do it like that forever? Of course not. That’s why we have the power of PowerShell to our disposal, something that I already demonstrated with ingredient 6.
Spice 2: Choose the right release strategy
Now that you have your first release out of the door, you’ll have to start thinking about when and how you’re going to release feature versions of your component. Is any change you make that good that you can ship right away? Or do you first want to stabilize upcoming releases by shipping alpha or beta packages to be tested by your consumers. Within the git open-source world, two strategies have become kind of ad-hoc standards. There’s a lot of documentation available, but the gist of it is that you should GitHubFlowif every change you do is production ready and GitFlowif you work on multiple features in parallel and get released after a period of testing. In both scenarios, GitVersionwill help you automatically generate version numbers, just like I do in Piercer.
Spice 3: Decoupling through delegates
In ingredient 6 I talked about the example of having your component support an extension point in the form of the IPlugin interface. I suggested to put that interface in a separate NuGet package so that your extension point doesn’t need to take a dependency on the middleware component package. An alternative approach for using an interface is to define the contract in the form of a delegate. So instead of taking the (simplified) interface definition…
public interface IPlugin
{
  bool IsMatch(Assembly assembly);
}
…you can have the middleware component also take a delegate like this:
public delegate bool AssemblyMatcher(Assembly assemby);
By doing so, any method that matches that signature can be passed in place of the delegate, thereby removing the need for the plugin to implement an interface or taking a dependency at all. Delegates exist since .NET 1.0, but somehow they didn’t get the love they deserved.
Spice 4: Logging like a master
Now suppose your middleware component needs some kind of logging feature to help diagnosing production issues. You could take a dependency on Log4Net, Serilog or any other popular logging library. But then you have to think of a way to expose its configuration to consumers. But what if the host is hosting multiple components, all using different logging libraries? How would it manage to get all that logging to the same log file?
This is where LibLog by Damian Hickey comes into play. It’s a sophisticated little NuGet package that just adds a single source file (so no public dependencies!) and auto-detects the logging library loaded in the AppDomain at run-time. It supports NLog, Log4Net, Enterprise Library, Serilog and Loupe. So from inside your component, you just use the logging API provided by LibLog. As long as the host uses one of the supported libraries, your logging statements will automatically forwarded. Personally, I prefer the structured logging magic provided by Serilog.
Spice 5: Dependency injection without dependencies
Just like you don’t want to have an extra dependency for that logging library, you don’t want to expose your prefered dependency injection container to leak into your public API. Fortunately, my favorite DI container Autofacdoes not rely on any static state and can be used within your container perfectly fine. However, we’ve observed lots of problems internalizing Autofac within your main assembly with both ILRepackas well as ILMerge. So if you can live with a thinner feature set, I can highly recommend TinyIoc. Just like LibLog, its NuGet package will just add a single source file to your solution, which means no dependencies, nada, niente.

Well, that’s all folks. After seven posts I think I’ve completed my recipe for building professional middleware components. What do you think? Does this all make sense? Comment below or tweet me at @ddoomen.

Ingredients for well-designed OWIN middleware components – Part 7 (The Continuous Improver)

On July 29, 2015, in Syndicated, by Association for Software Testing
0
In the sixth post of this series I talked about how you can use Swagger to create real useful documentation for your API. In this seventh and probably last post, I’d like to present some spices to make that OWIN middleware component extra special.
Spice 1: Automate your entire build process using PSake
So you’ve completed the first version of your component and you’re ready to ship it as a NuGet package. Manually creating that .nuspec file, running nuget.exe and publishing it to nuget.org is not that difficult to do. But now what? Are you going to do it like that forever? Of course not. That’s why we have the power of PowerShell to our disposal, something that I already demonstrated with ingredient 6.
Spice 2: Choose the right release strategy
Now that you have your first release out of the door, you’ll have to start thinking about when and how you’re going to release feature versions of your component. Is any change you make that good that you can ship right away? Or do you first want to stabilize upcoming releases by shipping alpha or beta packages to be tested by your consumers. Within the git open-source world, two strategies have become kind of ad-hoc standards. There’s a lot of documentation available, but the gist of it is that you should GitHubFlowif every change you do is production ready and GitFlowif you work on multiple features in parallel and get released after a period of testing. In both scenarios, GitVersionwill help you automatically generate version numbers, just like I do in Piercer.
Spice 3: Decoupling through delegates
In ingredient 6 I talked about the example of having your component support an extension point in the form of the IPlugin interface. I suggested to put that interface in a separate NuGet package so that your extension point doesn’t need to take a dependency on the middleware component package. An alternative approach for using an interface is to define the contract in the form of a delegate. So instead of taking the (simplified) interface definition…
public interface IPlugin
{
  bool IsMatch(Assembly assembly);
}
…you can have the middleware component also take a delegate like this:
public delegate bool AssemblyMatcher(Assembly assemby);
By doing so, any method that matches that signature can be passed in place of the delegate, thereby removing the need for the plugin to implement an interface or taking a dependency at all. Delegates exist since .NET 1.0, but somehow they didn’t get the love they deserved.
Spice 4: Logging like a master
Now suppose your middleware component needs some kind of logging feature to help diagnosing production issues. You could take a dependency on Log4Net, Serilog or any other popular logging library. But then you have to think of a way to expose its configuration to consumers. But what if the host is hosting multiple components, all using different logging libraries? How would it manage to get all that logging to the same log file?
This is where LibLog by Damian Hickey comes into play. It’s a sophisticated little NuGet package that just adds a single source file (so no public dependencies!) and auto-detects the logging library loaded in the AppDomain at run-time. It supports NLog, Log4Net, Enterprise Library, Serilog and Loupe. So from inside your component, you just use the logging API provided by LibLog. As long as the host uses one of the supported libraries, your logging statements will automatically forwarded. Personally, I prefer the structured logging magic provided by Serilog.
Spice 5: Dependency injection without dependencies
Just like you don’t want to have an extra dependency for that logging library, you don’t want to expose your prefered dependency injection container to leak into your public API. Fortunately, my favorite DI container Autofacdoes not rely on any static state and can be used within your container perfectly fine. However, we’ve observed lots of problems internalizing Autofac within your main assembly with both ILRepackas well as ILMerge. So if you can live with a thinner feature set, I can highly recommend TinyIoc. Just like LibLog, its NuGet package will just add a single source file to your solution, which means no dependencies, nada, niente.

Well, that’s all folks. After seven posts I think I’ve completed my recipe for building professional middleware components. What do you think? Does this all make sense? Comment below or tweet me at @ddoomen.

Let’s Enhance the Student and Instructor Experience (Testing Bites)

On July 28, 2015, in Syndicated, by Association for Software Testing
0

Honing Instructor Materials is First StepFirst in a series.The Association for Software Testing (AST) is holding elections for its Board of Directors starting August 2nd at 12:00 a.m. (GMT) and running through August 4th at 12:00 a.m. (GMT). I’ve bee…

Page 1 of 712345...Last »

Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!