AppFabric and BizTalk

"BizTalk is Dead and Out", on overhearing such a statement I was intrigued to know who the slayer was when a new name surfaced "AppFabric". The ensuing discussion was deadlocked but generated a curiosity in me as to what was the fuss all about. Reading through articles from the BizTalk Gurus I summarize the following:

What is AppFabric?
The simplest way of visualizing AppFabric is that it is an extension of Windows Application Server capabilities supporting the developer in implementing most of the non-functional requirements. Application development is not about just writing code but has certain associated quality of service parameters like scalability, availability, performance etc. In some cases the applications are also required to be transactional with a certain degree of administrative capabilities. Traditionally developers have spent substantial efforts in implementing even one of the above parameters whilst or post application development. What we really need is something out of the box addressing or supporting such QoS requirements on the existing infrastructure.
Look no further as AppFabric provides all of the above and more. And the best part is that it is available on the windows server platform installed on most of the development machines.
Windows Server AppFabric is an extension of IIS (Internet Information Services), WAS (Windows Process Activation Service) and .NET Framework 4.0 providing enhanced hosting, caching and service management facilities.

Does AppFabric replace BizTalk?
Finally I cut back to the discussion which actually triggered off my curiosity. Does Windows Server AppFabric replace BizTalk Server, Microsoft’s widely used application integration tool? Instead of trying to answer the question directly, we shall compare both the products on certain parameters and then try to draw a conclusion. Any form of working experience on BizTalk server would be beneficial in understanding the below table:

Features	BizTalk Server	AppFabric
Server type	* BizTalk is an application integration Server * XLANG based workflow engine	* AppFabric is an extension to windows application server * WF based workflow engine
Purpose	Enterprise level integration mediating various transport and message formats across heterogeneous systems	Extend IIS/ WAS providing advanced hosting capabilities for WCF (+WWF ) services
Architecture	Messaging based system with support for services i.e. schema based system	Services oriented system i.e. uses code contracts
Persistence	* Supports Message Persistence and Instance Persistence with suspend/ resume functionality using SQL server * Use of SQL Server introduces higher latency but advantages of disk persistence	* Supports Instance Persistence with suspend/ resume functionality using SQL server or AppFabric in-memory caching services * Use of in-memory AppFabric caching ensures low latency and improved throughput at the cost of risking disk persistence
Rules Engine	* Business Rules Engine (BRE) providing support for dynamic complex business rules * Rules Composer provides a visual representation of the rules for Business Workers	* Very little support via WF Rules for simple business rules * No visibility to Business Workers as rules are modelled In C#
Adapters	Multiple third party adapters available out of the box supporting heterogeneous system integration	AppFabric Connect allows leveraging BTS adapters but does not have a out of box adapter collection
Publish/ Subscribe	* Workflow engine along with the Message Box provides a publish-subscribe model which auto manages multiple concurrent workflow threads for processing messages * BizTalk host provides auto throttling ensuring load balancing	* With the absence of a message box, AppFabric does not provide a publish-subscribe multi threaded model * However there are WF constructs available for parallel execution which has to be managed by the developer
Monitoring and Recoverability	* BizTalk Admin Hub Page provides an overall view of the system health * Health Activity Tracking (HAT) can be used for viewing and resuming suspended resumable instances	Dashboard provides a view to the overall health of services configured to utilize persistence and event collection
Tracking, Archiving and Purging	* Business Activity Monitoring (BAM) provides a rich set of tools for tracking message data and flow through the engine * Dedicated tracking host for moving tracking data to BAM * SQL Server Agent jobs can be configured for purging and archiving tracking data from time to time	* Provides a set of tools which allows selection of a tracking profile to configure message logging and tracing features * Windows Powershell cmdlets are provided for purging and archiving tracking data from time to time
License Cost	Yes, has to be bought independently from Microsoft	No, Currently free and is already licensed with windows server 2008, Windows 7 and Windows Vista (SP2)

What the comparison brings forth is that AppFabric is best suited for low latency, high performant application server services providing non-functional features of service level tracing, monitoring, distributed caching, hosting capabilities etc. out of the box. Such solution architects might have previously considered BizTalk as an option as most of the mentioned features are in-line with the tools and services it readily provides.
However Windows Server AppFabric still has to reach the comprehensive collection of tools and features that BizTalk provides as an integration server. As highlighted in the above table, BizTalk still has a very unique publish/ subscribe model, strong rules engine, a mix of third party adapters to name a few which are missing in AppFabric and which makes BizTalk server a strong integration tool. All these features at an extra license cost obviously means that solution architects will consider AppFabric as an option before recommending any technology to the client which would fulfill their requirements.
To summarize AppFabric instead of replacing BizTalk server complements it well, each leveraging the features of the other. Future developments in each of the areas will try to bring both the products closer making it seamless and easier to use and configure. As put by the Microsoft pundits “Biztalk vNext will transition to be AppFabric based”.

Would be more than happy to get any suggestions/ corrections/ feedback on the above post @ virus.vinay@gmail.com

Read More

Testing & Programming = Oil & Water

I was watching a science program just now and it occurred to me that Testing is very much science. And then I wondered about Programming.

I started in IT over 22 years ago doing programming.  For me, the process of programming broke down to  three parts: figuring out the algorithm to solve the problem, implementing/coding the solution, and cleaning up the code (for whatever reason - e.g. maintainability, usability of UI, etc.).  It gets more complicated than that of course, but I think that about sums it up the major activities as I saw them. (SIDE NOTE: I didn't write those to mirror TDD's Red-Green-Refactor, but it does align nicely that way.)

When I think back on my experiences in programming, I don't see a lot of overlap with my experiences in Science (~ 8 years studying, researching and doing Physics & Environmental Science + teaching Science on top of that).  Science is about answering questions.  The Scientific Method provides a framework for asking and answering questions.  Programming isn't about that.  Building software isn't about that.  I'm having difficulty at the moment trying to see how testing and programming go together.

It occurs to me that schools and universities don't have any courses that teach students how to build software.  It also occurs to me that schools and universities provide students with the opportunities to learn and develop the skills required to build software well.  The schools just don't know they're doing that and consequently the students don't get that opportunity intentionally.

I'm not talking about learning to program.  That's trivial.  Building software isn't about programming.


Building software starts with an idea - an idea that someone will pay money for.  School courses to watch for here include - Economics, Entrepreneurship.

Building software requires people to work together. School courses that may apply - Business, Math/Finances, Psychology.

Building software requires people to work under constraints. "Project Management" is not really taught in schools, but there are many courses available to the public. I found this really painful to learn by doing. A whole world of insights opened up when I took my first PjM course. Reinventing the wheel really is dumb here.  I believe this should be formally taught in schools - in High School actually (the earlier, the better).

Building software requires people to solve difficult problems creatively.

This one is interesting.  I think there are many opportunities for people to learn this skill in school.  I know that we definitely covered this in Science.  I also know that Engineering programs teach students how to do this.  There are many more faculties and programs that this would apply to and they all have one thing in common - there's some formula or method for solving problems for some purpose.

The thing is, that purpose is different in each case.  See, here's where my mind is doing flip-flops.

In Science, when we solve a problem, the outcome is usually more information.  This information feeds back into the original idea to help us check the validity of our initial premise/hypothesis.  Sure, there are moments of free-form exploratory investigation, but I don't believe that happens a lot.  There are an infinite number of paths that any experiment may go in if you don't have a particular question in mind when you start, so unless you are trying to intentionally waste time and money, you will start with some question in mind before you start your experiment or investigation.

In Engineering, solving a problem is different in that the outcome is usually something real, something tangible, some application or system that fills a need.

The purpose of Science is not to build things but to answer questions.  The purpose of Engineering is to build things - and to do so safely, ethically, within desired parameters for intended purpose, and so on.

So where does that leave us in building software?  *Building* software is definitely an Engineering task... and then some. I am temporarily over-simplifying the process of building software to focus only on the requirements gathering, design, coding and deployment phases.

"Testing" comes from and is an integral part of Science, so how does it fit in with these software engineering/development phases of requirements gathering, design, coding and deployment?  Well, it doesn't.  It has nothing to do with them.  And yet, it has everything to do with them.

That is, from one perspective, at no time do you ever need to test anything to get through any of those phases.

That last statement, while true, kind of goes against everything I ever learned in school.  Whenever I did math problems, I always checked that I got the right answers against the solutions in the back of the textbooks.  Why did I do this? Why did I care?

I did it so that I could tell myself that *how* I solved the problem was correct - it got me the same answer that the textbook and my teacher cared about.  I discovered there were exceptions, of course.  That is, there were times when I got the correct answer but my method was wrong in some way.  Dumb luck does play a role in life and that was when I first discovered the evil twins named Type I and Type II errors.  (Side Note: I wonder if that's where Dr. Seuss got his idea for Thing 1 and Thing 2?  Hmm..)

So, the process of checking answers with the "approved" solutions, and handing in assignments for grading by teachers is a feedback mechanism to tell me that I've learned how to solve certain kinds of problems in ways that provide the desired results.  Let's assume for a moment that's a good thing.

Getting back to building software, you can go through requirements gathering, design, coding and deployment without ever once checking that you are producing the desired solution or results.  In the end, this is a monumental waste of time and money, and is completely incongruous with the initial premise that you are building a product/service/solution that someone will pay money for.  That's bad economics.  That's psychotic.

So how do we fix this?  What's the problem here?

Well, one problem is that we now have a question, we have doubt at the end of each of these phases.  We have a desire to learn if the end result of each stage and for the whole process is meeting [our/someone's] expectations.  The answer at the back of the textbook here will be provided by the people who are choosing to pay you and not your competitor for what you produce/release/ship.

Hey! Wait a minute!  Science helps us answers question!  Testing is a small part of that process.  The bigger process starts with a question that stems from some research or exploration of the initial area of interest.  This hypothesis is the part we really care about.  The "how do we go about gathering enough information to answer this question" part is something different and we should get people who know how to do this to either (a) do it for us, or (b) help us do it for ourselves. Then there is the analysis of that data or observations in context of the initial hypothesis.

But this is a different layer now!  We're adding a layer of "science" on top of "engineering".  That's weird.  That's like trying to mix oil and water together.  That is, they don't mix.  If you shake them up together you only end up with some cloudy mess that eventually will separate out again.

So what does this mean for building software? We need people who are skilled at engineering solutions, and we need people who are skilled at identifying and answering questions about the solutions being engineered.  I believe these are two, very separate skill sets required to be successful.

However, my experience in the Software/IT industry over the last 20 years has been that only one of those skill sets has really been identified as important or relevant -- that of the programmer or engineer in building the solutions.

This is a problem.  There's a huge knowledge gap here.

Schools don't teach you how to "test" in the context of software development.  Every single Testing "certification" agency I have met to date misses the mark. They don't teach you the correct skills. They "teach" you superficial documentation skills that produce information *like* the kind of information that is required.  That would be like me handing out Plumbing certificates to anyone who successfully completes the Mario & Luigi video games because these characters are plumbers in the games.  That's just not right.  Likewise, there is no actual "science" performed by teaching people to create scientific-like reports. (Although it happens sometimes that testers learn testing skills accidentally if they pay attention to what they're really doing.)

So, where are we here? Building software requires layers of intelligent, creative effort and problem-solving abilities.  These layers are complementary and require different skill sets.  Just like you wouldn't hire an accountant to deploy your systems, I don't think it's wise to hire a programmer to provide valuable testing insights into the development process.  It's the wrong skill set.

Oil and water, or oil and vinegar - the analogy holds for me. Testing is something completely different from Programming and building software.  It's a layer on top to help you know that what you are doing is on target for what your paying customers are expecting.  Some might call that value.

Read More

Software Testing "Popcorn" button

I made myself some microwave popcorn for a snack just now.  Placed the popcorn bag in the microwave, pressed the 'popcorn' button and then 'start'. Someone next to me said: "There's a popcorn button?" Um, yes, there is.  In fact, there has been a 'popcorn' button on every microwave oven I've ever seen.

I explained to my colleague that the recommended time on the bag (in this case it was 2 min 30 sec) doesn't work on every oven.  Different ovens have different power output and so the actual cook time may vary.  If I go with the default time, it might burn or be under-done and leave too many unpopped kernels in the bag.  You could figure out the correct time in a few ways.


Method 1: Math
Start by taking a look at the power output of the oven. Full-size ovens deliver 1,000 - 1,600 watts of power, and mid-size ovens yield 800 - 1,000 watts. Higher wattage heats food more quickly.  If it's not explicitly written on the bag, assume the default popcorn popping time is for a 1,000 watt oven.

Use a time/power ratio along the lines of: ( t_your_micro_oven / P_your_micro_oven ) = ( 150 sec / 1000 W)

I converted the 2:30 recommended time on the bag to 150 seconds for convenience.  The power of your microwave oven should be written on the back somewhere, probably close to the plug.  This leaves your popping time as the only unknown variable in the equation, so it should be straightforward to solve.

That might work.

Method 2: Brute Force/Iterative
Put the bag in the oven and follow the instructions exactly.  Make no changes.  When the time is complete, take the bag out and put the contents in a bowl.

If you are happy with the result, congratulations! You are done.  If not, we will need to change the cooking time for the next bag.

On a piece of paper (or in a document on your computer if you prefer), make some observations to capture things like: time settings used, quality of the popcorn output, taste, number of unpopped kernels, and so on.  Keep a note next to the microwave oven or on the container where you keep more popcorn bags -- a note to reference these 'test results' so that you can have something for comparison the next time.

Basically, you know where I'm going with this.  Pop the first bag with the default recommendations and keep varying the subsequent popping times until you are happy with the result.  This will require "n" bags to iterate through until you are happy with the end result.

This should eventually produce high-quality results.  It may take you some time and will be costly to do it this way as you may have to go through many bags until you get it just right.

Method 3: Popcorn button

Put the bag in the oven, press the 'popcorn' button, serve and enjoy.

I'm not certain how this works.  I shall call it "magic" for now.  I can speculate that perhaps the microwave oven manufacturer has a team of engineers dedicated to the "Perfect Popcorn Production" using their equipment and are responsible for programming the correct power and time settings into their ovens.

Maybe they use Method 1 above.  Maybe they use a combination of methods 1 and 2 above.  Maybe it's something else.

The point here is that someone has already done the thinking for me so that I can focus on the quality of experience of using their oven.

Wow.  I have so many comparisons and analogies back to Software Testing running through my head right now.

One that jumps to mind is development & testing terminology/jargon.

• When is a test not a test? When it is a check. When it is an inspection. When it is a question. and so on.
• Are your [agile] development sprints 2 weeks? No? Why not? That's the default value, so it should work for you, right?

What if software organisations were responsible for their own 'popcorn' buttons? That is, where the 'popcorn button' is a way to communicate the methods and models used within their organisations that produce the desired 'quality' result.

As a consultant, one of the first things I do is watch and listen to the development and project team members. I need to understand their terminology and way of doing things.  That helps set a reference frame for me.  If I want to make an improvement or change somewhere, I need to have an understanding of how to do that on their terms, not terms according to some industry standard or certification terminology dictionary that may not apply.

What would be the point?  Well, I think it would be handy if we could abstract out some of the desired practices from the terminology and implementation details that are specific and custom to every organisation, team or project.

Now that I think about it.  Maybe, we as consultants are the "Popcorn Programming Facilitators."  That is, the company wants to implement an automated regression testing activity.  What does that look like? How can that work for us? What kind of output do we get?

Some days we identify the required popcorn buttons (e.g. Regression Testing, Bug Tracking System, Produce Status/Progress Reports). Some days we help program them.

What do you think?

Read More

Fishing for Wisdom

I just came back from a week at the AYE Conference. My head is full with several new ideas swimming around and stirring up half-baked old ideas - which is a good thing.

One of the thoughts causing my head to spin came from a session one evening where we discussed ideas to improve the conference moving forward. Johanna Rothman led the session and at one point she mentioned that the AYE workshop sessions included pure [Virginia] Satir [ideas, models, etc.] and applied Satir. This got me thinking about some of the subtle differences I had noticed about the sessions and what they meant to me.

In particular, some of the ideas and models I learned from the AYE sessions appear to dwell longer in my mind and apply to a broader spectrum of situations while others seem to be more specific - i.e. an application of a model in a particular context. Don't get me wrong, whether you choose to attend a pure Satir or applied Satir workshop at AYE (and the sessions aren't labelled as such because it doesn't really matter), it's a win-win scenario. :) Sure, different hosts have different styles, but each session is different every time so you sometimes see people attend the same session again to see what new insights they get.

So, what's the big deal here? Why did I get stuck on a small point like this? Well, it reminded me of the time when I was in Teacher's College in the mid-90's, preparing to become a High School Science teacher.

I had 2 main professors in Teacher's College - one for each of my 'teachable' subjects of Physics and Chemistry. Their styles were very different. One professor seemed to keep me busy while the other made me think a lot.

I'll be honest, coming from a university environment to Teacher's College, I expected to be told what I needed to do to be a teacher. You know - I expected a lecture-style learning environment like most of my previous undergraduate courses. What I got didn't match that expectation so I was a bit frustrated at first until I discovered the secret that no one clearly explains to you.

What's the secret? Okay, I'll tell you. The secret is that when you go to Teacher's College, *you* are the teacher, not the student. So, by going there acting like a student expecting to be taught, I had the perspective all wrong.

I don't recall when the paradigm shift happened for me but I'm glad it did. After that point, I didn't consider my professors to be the ones teaching me to be a teacher; I saw them as guides to help me learn the things I needed to be a better teacher.

The real teacher here is experience. And that you can't get unless you are doing what you want to be doing, not sitting in a classroom somewhere talking about what you want to be doing. So what did I get from the Teacher's College experience? I got access to many different 'teachers' to help me deconstruct my experiences so that I could learn from them.

I need to pause for a second and think about that last sentence again. That sounds suspiciously a lot like the AYE conference experience to me. Hmm.

So what was different between my two main professor/guides? I think (now) it was something similar to the difference between the 'pure Satir' and 'applied Satir' AYE sessions. One professor offered tips and ideas that applied in a certain situations - the ones we said mattered to us - while the other discussed models and ideas to help us learn from our own experiences in more broader situations. Looking back, those things weren't clearly stated in that way at the time. I think I understand a bit more now about how they were trying to help us, in different ways, to become better teachers. Of course, both professors provided us with lots of opportunities to practice demos and teaching short topics in an environment where we could safely receive feedback from our peers. (hmm, more AYE conference and PSL familiarity here.)

I recall that someone once mentioned the old Chinese proverb while were at Teacher's College:

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

To me, the quote makes me think of the difference between information and knowledge. I think both professors were trying to teach us to fish (i.e. give us knowledge), just in different ways. They both wanted us to leave the college more confident with knowledge that we could use to help ourselves become better teachers moving forward.

Back to AYE and present day. Reflecting upon the learnings from this past week, I learned new models and ideas that I can apply in many ways - some apply at work and some apply to life beyond the workplace. I think I left with a few fish and a few new fishing techniques.

The old proverb bugs me though. I don't think it completely captures the full experience and feeling of what happened. There's something missing, something meta.

And then it came to me today. It's not the fish. It's not learning to fish either. It's the fishing.

If you pay attention to what you are doing while you are fishing, I think that leads to something other than information or knowledge; it leads to wisdom.

Continuing with this proverb as an analogy, if I learn deep-sea fishing while on vacation, I don't think that will help me very much if I decide to go fly-fishing at a local river. There are many different ways to fish - for the different kinds of fish, the environments in which they live, and the purpose of fishing (e.g. food vs sport).  If we pay attention to more than just the types of fish, their environments and techniques to catch them, we can learn something more, something bigger.  I find it hard to think in broad ideas like that sometimes.  I also find those are the most rewarding moments though.

Attending the AYE conference (and PSL this past Spring) was like that for me.  My head doesn't stop thinking about ways to apply the models and ideas we experience at AYE.  Meeting wonderful, intelligent, kind practitioners from all over the world helps enrich the shared experiences in ways that bring us closer together.  We talk about fish (individual experiences) and techniques to help find solutions to problems we think we see.  And then the hosts/speakers go and show us things that help us solve problems we didn't even think about or see!

For me, attending AYE is an opportunity to meet old friends, learn about myself, learn about how to interact better with others (both at work and in personal life), share experiences and knowledge with colleagues, learn some new problem-solving techniques, make new friends, and pause for a moment to reflect upon where I am in life and where I'd like to be.  It's a moment to notice that I'm fishing - I'm learning and growing.  And that others are fishing too.  And while some are fishing for similar things and others for different things, we all recognise that we are fishing so we have that in common.

It's going to take me a bit of time to unpack all of the ideas I was exposed to this past week because learning happened on many different levels.  I could post some notes, and I plan to, but I don't believe the notes alone can convey the experience of learning that happened there.  Much learning happened between conference sessions too.  You meet so many people with similar or related interests and different experiences that once you start talking in the hallways, over dinner or lounging about somewhere, you can't help but continue to learn and think about things in new ways.

If you want, that is.  If you're into that sort of thing.  If learning, growing, and working better with other human beings isn't your cup of tea, then this conference is definitely *not* for you.

To everyone else, I highly recommend the experience.  This conference, and the PSL workshop, are opportunities that shouldn't be passed up.  It might even change the way you think about things.  It has for me.

To the AYE and PSL hosts, Jerry, Don, Esther, Johanna and Steve, to my Teacher's College professors, Peter and Tom, and to my family, friends, and colleagues who have all provided me with helpful feedback and information to help me grow and be a better person, I thank you.

Read More

Using MS Outlook to support SBTM

Okay, to recap, Session-Based Test Management (SBTM) is a test framework to help you manage and measure your Exploratory Testing (ET) effort. There are 4 basic elements that make this work: (1) Charter or mission (the purpose that drives the current testing effort), (2) Time-boxed periods (the 'sessions'), (3) Reviewable result, and (4) Debrief. There are many different ways that you might implement or apply these elements in your team or testing projects.

Let's take a look at tracking the testing effort from strictly a Project Management perspective. Years ago, when I first became a test manager, I was introduced to the idea of the 60% 'productive' work day as a factor to consider when estimating effort applied to project schedules. That is, in a typical 8-hour workday you don't really get 8 complete, full hours of work from someone. I don't believe it's mentally possible to get that. The brain needs a break, as does the body, and there are many natural distractions in the workplace (meetings, email, breaks, support calls, stability of the code or environments, and so on), so the reality is that the number of productive working hours for each employee is actually something less than the total number of hours they're physically present in the workplace.

That 'productivity' factor changes with each person, their role and responsibilities, the number of projects in the queue, and so on. Applying some statistical averaging to my past experiences, I find that 60% seems about right for a tester dedicated to a single project. I have worked with some teams that have been more productive and some much less.

So what does this look like? If we consider an 8-hour day, 60% is 4.8 hours. I'm going to toss in an extra 15 minute break or distraction and say that it works out to about 4.5 hours of productive work from a focussed employee in a typical 8-hour day. Again, it depends on the person and the tasks that they're performing, so this is just an averaging factor.


4.5 hours is an interesting number. In the SBTM framework, the "Time box" length for the test session revolves around a normalised value. The original SBTM presentation ("How to Measure Ad Hoc Testing") suggests that 1 "Normal" session = 90 minutes (+/- 15 minutes). Your "normal" time box session may be 90 minutes, it may be less. Customise it to suit your team's needs and fit.

I'll use 90 minutes for now because it's the default recommended value to have a focussed test effort to get some solid testing done. 90 minutes. That's 1.5 hours. So 3 * Normal = 4.5 hours.

Therefore, from a project management perspective, 3 Normal sessions is an average tester's target productivity level for completed test sessions in an average 8 hour day.

It doesn't seem like a lot, three 90-minute sessions, but you'd be surprised at the number of distractions that happen throughout the day and development sprints/cycles that can prevent a tester from completing 3 sessions in a day.

Recently, I've been working with a tester on an Agile team who has been facing a high distraction level. As a result of all the interruptions for quick checks, reviews, design meetings, and so on, he has been struggling to complete 3 sessions in a day.

I should mention that I *AM NOT* asking him or anyone else on my team to complete 3 sessions in a day. I am not concerned with the numbers or the math of tracking the sessions completed, especially because the development team environment is very integrated and highly collaborative.

What I am concerned about is trying to find ways to block off his time so that he can get some solid testing done, uninterrupted. One of the powerful aspects of the time-boxed session is to reduce or minimise the distractions so that your brain can maintain the focus on the testing problems at hand. The more the distractions and interruptions, the more likely that something important or interesting will be missed.

Enter MS Outlook. When I look at my Outlook calendar it is riddled with meeting requests throughout the week. I have recurring meetings, impromptu meetings, lunch and learns, scheduled debriefs, sprint planning, retrospectives, demos and so on. I'm the Test Manager/Lead, so that's expected. When I look at my tester's calendar, it is fairly blank/open, save for the daily stand-ups and a few other weekly team meetings. It seems counter-intuitive that someone with an open calendar, so much available 'free' time, should be unable to block off time-boxed periods dedicated to testing specific features and charters.

So I've started to schedule his test sessions in MS Outlook by scheduling Appointments. At the start of the day, we'll sit down and come up with 3 important charters that we'd like to cover in the day. We block off one session/appointment in the morning and two in the afternoon. The "Subject" is a summary of the charter and priority. If the session involves another Dev or team member, they can be included in the appointment, which is now a 'meeting request'.

Outlook is a convenient tool since it (a) is available on everyone's desktop, (b) has built-in reminders, and (c) allows the tester to *see* all the free time available between scheduled test sessions. It's a way for him to try and regain control of the *uninterrupted* test sessions.

SBTM isn't intended to be a time-tracking tool. It's a productivity-enhancing tool. By keeping focussed on the charter, you give your mind time to think about the important things -- to learn about the system and the software, to apply the appropriate tools and techniques, to make the best observations you can in the time you have available. Performing good Exploratory Testing is a delicate and complex thought process.

I see my job as doing whatever I can to help provide the best environment possible for good testing to succeed. I never would have thought that Outlook would factor into that. Who knew?

Read More

Test-Driven Development isn't new

I used TDD as an analogy to a tester today to explain how logging bugs in a bug tracking system drives the development. A bug report represents a failing test (when you verify that it's really a bug that is) according to some stakeholder need/want.

In Test-Driven Development, the programmer writes/automates the test first that represents the user story that the customer/user wants. The test fails. The programmer then writes enough code required to pass the test and then moves on. (refactoring code along the way, etc..)

It's much the same with regular system testing (i.e. in the absence of agile/TDD practices) where a tester identifies and logs a bug in the bug tracking system. One difference is that these bug reports/tests aren't always automated. (Okay, I've never seen anyone automate these bug reports/tests before but I like to believe that some companies/dev teams out there actually do do this.) That doesn't change the fact that a bug report is the failing test. Even if it's a manual test, it drives the development change and then the bug report is checked/retested to see that the fix works as expected.

Bug regression testing, then, is a requirement for good testing and system/software development, not an option.

So, while the agile practices of TDD and others may seem new, I see this one as a retelling of a common tester-programmer practice. If anything, I see TDD as an opportunity to tighten/shorten/quicken the loop between testing feedback and development. With practice, TDD helps programmers develop the skills and habits they need to create code and systems with confidence -- to know that as the system grows, the specific needs of the customers are being met every step along the way. No one gets left behind.

How can we, as testers, help? If your programmers don't practice TDD or automate tests, start investigating ways that you can do this. Investigate Open Source scripting languages. Engage your programmers in discussions of testability of the interfaces. There are many articles and presentations on the internet on the topics of test/check automation, frameworks and Domain Specific Languages (DSL).

Start reading. Participate in discussions (in real life and online). Start developing scripting skills (I recommend Ruby, of course, especially to the tester newbie). If you don't feel confident with your programming skills, help hire someone onto your test team that can help all the testers advance their skills, knowledge, and productivity in that area.

Be the Quality Advocate by putting your words into practice. You want your programmers to start practicing TDD? Show them how you can do it. You are already doing it - scripting/automating the checks that demonstrate a bug failure is just the next step.

Start by automating a single bug failure. Take it from there.

Read More

Why New Year's Resolutions Fail

Someone recently said something to me that made me think. He said that all New Year's resolutions fail because they come at the wrong time.

You know what I mean by New Year's resolutions, right? It's those promises you make to yourself, and maybe to others, right around the end of December that you will change or improve yourself in some way in the new year.

The sentiment may not be wrong, but the timing certainly is. The argument made was that January 1st isn't really the start of the new year - September is. You see, here in North America, whether you are in school or not, most businesses revolve around a "school year" structure of September to June, with July and August being the summer holiday months.

So, if September is the start of the year, we can't make promises to change something in January. That's like starting a 2-week sprint (in Agile Development) and saying half-way through that you are going to have completely new objectives. It doesn't work that way. You already committed to delivering certain goals during the Sprint Planning session at the start.

What's that? What if you didn't set any goals at the beginning of the Sprint/Year in September? Doesn't matter. The Sprint/year started anyway and you are in the middle of it. There's no way you are easily going to shift your life in a totally new direction half way through.

So, the moral of the story is: if you want to make New Year's resolutions, make them in August, not in December. That way you are more likely to follow through with them as the year progresses.

Hm, interesting.

Of course, life changing events can happen any time. You don't need to make a resolution of any kind to change yourself and how you get along in the world. You just need to see yourself how you want to be, and live like you've already reached that goal.

Read More