So what's your priority?

In the fast paced world of software development, sooner or later you or someone on your team will find a situation where they are faced with multiple tasks, and competing priorities.   So what does a person do when an urgent list of changes to a software under development is received?   Then what do you do when the expected time to deliver these features appears to be something rather aggressive?

Let's take a step back for a second to discuss the requirement process.  Often requirements are not as detailed as necessary to begin to design or codify.   Sometimes requirements may be in a list form, they may be rather obvious, but more likely they are obscure, cryptic, or down right confusing.   Because of this, very often there is a necessary feedback loop between the team and the client just trying to make sure they understand the change, and the impact it may have on the system.

This back and forth, haggling over specifics, and gaining enough understanding to model the process necessary to be implemented can be very time consuming, and often the hardest part of the software process. Customers do not always have the computer knowledge to give sufficient feedback about what they write, and as a developer it is our jobs to not just verify that we are building the software correctly, but even more critical, we must validate that which are building actually meets the needs expressed in the requirements.

Often the understanding of a requirement will morph over time, but for simplicity's sake let's assume for a moment that the haggling over the requirements has already taken place.  So your team is called into a rushed meeting to discuss a list of changes.  The manager describes the ten items that need to be implemented, and expresses the hope that it can be done in a short amount of time.  For sake of argument lets say its a week.

Immediately the issue of time and priority may come to the forefront.  If there are ten changes to a system, ten changes that do not necessarily 'interact' with another or depend on another, then how do you prioritize them?  Depending upon what model your process is based upon the answer could vary.  It may be the Project Manager who sets these priorities, or in a more agile environment it could be the customer, or the person designated as the 'product owner' within the team.

So the team after a little debate comes to the decision, much as they might like to pick and choose which pieces to do in what order, they need one more layer of feedback about the requirements, what is the order of priority for these changes.  Given that the team is taking some measure of risk trying to rush these ten features into the system in a week's time, they believe that this risk would be easier to stomach if they could impose some logical order to implement the features, so that if the time should prove insufficient, they could at least be sure to have the  most critical features done and deployed.

So what do you think the response would be?  Hopefully you'll get a list of points itemized from one to ten giving a clear order of development and importance to the customer.  That would be the ideal, but what if the list comes back with six of the ten items listed as priority number one, and the other four as priority number two?  I posed this question on Twitter.

I received a few different responses two of the more interesting ones were from Stephan (@S_2K) "Everything is most important. " Morgan Ahlström (@Morgsterious)  replied with the understanding words "That noting is REALLY important."  These were very much my same sentiments when I pondered this question.  If someone cannot distinguish a hierarchy between two things, let alone ten things, how then can you know which items are of most importance and tackle those ares of the software first?  Even if you have multiple team members, it is only natural that some components may still have higher precedence.  


So what do you do when you have this sort of situation?  My hope would be that enough time would exist to push back for further definition of the structure of the requirements.  However, given that the customer might not be as eager to be asked the question a second time, or might not be as readily available, the team is then left to its own deductive skills to try and figure out the proper order to do them in.   This is where knowing a bit about potential dependencies within the requirements could lend aid into determining an order of construction. 


Nevertheless, it is still highly probable that there can be no clear prioritization gleamed from this answer.  With time being ever more tight then the team is left to its wits, and knowledge of prior conversations to try and 'best guess' the order they should tackle the changes.   In the end the team might complete all ten, or they might completely only a handful of the tasks.   In the later situation, the customer might then push back and ask why they completed one task but not another.  The team then can remember that it didn't get the accurate feedback it requested on prioritization, and could provide this as reasoning for the order they had chosen.


The customer might not like that sort of response, but sincerely in the absence of information, it becomes better to complete at least some of the work, even if you do not know how much, or what order it should be done in. This may not be an ideal solution, but it should be evident from this how important communication with the customer must be to ensure accurate building of the software and the timeliness and sequence of delivery.

Some thoughts about Version Control

In my time as a software professional I have seen many systems for maintaining and tracking changes to code in progress.  Whether this is the archaic and I hope no one ever really uses this on a real project practice of passing along zip files of changed code with comment mark-up to indicate where changes were made, or to full featured source control solutions, like subversion, team foundation server, or git, every project at some point or another will have to make a decision on how to handle these files.

I could spend time dealing with the importance of choosing any source control solution, but that's not what this post is about.  Instead I'd like to take a moment to describe some of my experience with source control solutions.

In general there are two sorts of source control mechanisms, one is like that used with Microsoft's Team Foundation system (and before it Visual Source safe an incremental check out/check in system, and the other is a check out the code base, and commit/update to get/add the latest changes to the current working version.    There are pluses and minuses to both schemes.  The incremental check out/check in system really feels like a pull system.  While you can download the latest tree from a base directory, to make changes, and have them be saved with out the IDE screaming about read only or protected files, you have to make a point to check out in essence pulling on TFS to make the file ready for editing.   Team Foundation Server (TFS) allows you to do this in an exclusive mode, essentially locking out any other attempts to check out and change the file by other users, or a less prohibitive more shared lock.  

I've only had the privilege of working on a single project with TFS thus far, and that project relies on the exclusive kind of check out system most of the time.   This means that if a developer needs to make a small change to a file that you are working on, he will have to communicate that need to you, so that you can then do a hand shake of releasing the locked edit, so that the change can be checked in.  It can be a real pain at times when you want to try a quick fix and the IDE prevents you at times from trying something simply because it's marked as 'read-only'.  It provides a benefit in that it limits the number of files you might accidentally touch which can be a blessing at times.  It also means that anyone trying to check in another fix may not be able to do so while it is held checked out, and as has happened to me a few times, sometimes files in a project may get checked out by the IDE automatically even if you did not intend it so.

The other form of version control management is the style for which Subversion has become known. It is in essence a more push style of architecture, where by, you can check out an entire source control tree (much like getting latest for any particular folder), and then have significant freedom to make changes, erase a file and refresh/revert it from the last commit, or even make a series of changes and check them in one after another.  The draw back of this system, is that because anyone can edit, there is the possibility of files getting more and more out of sync from the base or trunk as it is called in subversion.  This can present problems when during a commit a major conflict arises trying to reconcile differences between the two files.    In my experience though, if used judiciously and kept up to date and committed as often as necessary, these conflicts can be minimized fairly easily.   Subversion also has the bonus in that it is portable to other operating system types, and is not dependent on the windows/.Net stack as much to function.

There may be other tools that fit your needs better, Wiki's can be edited inline from a browser and keep good version tracking of each meta page, content management systems like Share Point can allow you to track updates to your requirements, contacts, or serve as a portal for storing key documentation for a production.  Whichever tool your team chooses for source control, it is critical that your entire team is on board with its function, and regular use to help avoid major headaches between builds.   The value of source control is manifest in how it allows teams to track branches of in progress development code, tag certain releases for easy comparison later, and giving a history with comments about the update and logs of the files that have changed.  This logging function can be of great value when trying to track down how a particular strain of bad code may have made its way into your product.

Then some source control systems allow you to track the progress of development from requirement, to deployment.  Team Foundation Server has these features out of the box, while open source tools like Subversion require other components, for example TRAC, to help track the progress of development.  I hope that whatever your team chooses to use, that you will find the source control to be a great asset, that helps facilitate your development needs.

Some thoughts on the Programmer vs Tester Argument

Shrini Kulkarni wrote an interesting blog about arguments related to the programmer vs tester who is better at testing and why (Programmers make Excellent Testers - Arguments and Counter Arguments).  The idea comes up now and then in development circles, and whether you are a programmer, a developer, a manager, or a student of Software Development, sooner or later a question like this may enter the picture.

Shrini does a pretty good job of illustrating some of the reasons why at any given snap shot moment, why a programmer or tester may be better for a particular task of testing.  I've hard some of these arguments before, and I find that the context of the situation, and sometimes the budget of the team often dictate just how much a programmer or tester is asked to do.  One thing that I find interesting, is why things end up being the way they are.  Each of us if you will may start off as a blank slate at birth, and we learn many, many different tasks.  When we enter the Software field, we even at that point have different ideas, philosophies and hopes and dreams of what a life and career in software might be.  Whether that is to be an Engineer, Programmer, Designer, Architect, Manager, Lead, Tester, each of us started off with an idea of what we might get from this rewarding field.  How many of us though stay on the path we initially pointed our ships bow of learning and experiences towards?  I'm not sure a survey could even give a good idea for why people choose one career path from another.  People are as varied and individual as grains of sand or rocks on any given beach. 

So when I reflect back on my career in the software profession.  I can't help feel the irony to have basically come full circle, and reminded of at least one of Shrini's points. When I Started, all I wanted to do was write Code. I had aspirations of being a "Software Engineer" and thought I had a pretty good idea of what that entailed.  Though I lacked experience I had not thought beyond that little view point.  So when it came time to start my first professional job, it didn't take long before the ideal, and reality clashed.

Learning is often seen as climbing a pyramid between four points.  Along one Axis is technology and the closer to it the more experienced with technology, particularly specific technological contexts represents your learning and experience.  At the other end of that Axis  is the Second point of our Pyramid, that of working with people.  The closer you get to it, the better you work with people, but perhaps you end up spending more time with people then the technology.   Then off on the opposing axes would lie the other two points, in one direction is that of being more of a specialist.  The closer to it, the better and more specialized you are in your context.  You might call someone at that point an 'expert' of sorts, while at the other end is the generalist.  They may be better at one thing than another, but their broad base of experience helps give them a larger context to evaluate their problem set. 

As you move from the Technologist point of extreme towards the  specialist you are really moving around the base of the Pyramid.  Or if you move to generalize you may be moving back the other way along that face.  However, since Computer and technological problems are inevitably people problems, noone stays on the base very long, they begin to grow upward, and toward being able to deal with people. 

I recall being taught taught this 'myth' that programmers code, and testers test, and neither the twain shall meet. Thus fresh out of college there was this propensity among some of us, myself included to see testing as beneath them and not worth their time.  This may have been vocalized by professors, or it may simply have been a matter that Testing was not a focal point of CS or Engineering coursework in college.  The absence of a tester point of view from my Academic experience, clearly colored my early thinking about software.

I had a desire to crank out quality code, usable code, and I saw Software Engineering as a tool to get there.  Just one problem.  In the first shop I worked, Software Engineering principles were not necessarily being practiced.  Even if they had been, I'm not convinced it would have solved the host of problems I encountered early in my time there.  I came to realize very quickly that programming alone didn't insure the code was ready and met the customer expectations. Heck sometimes even other programmers don't meet other programmers expectations. Now almost 8 years later, I'm a full time tester, and now I see the other end of the equation, where some developers seem to see the majority of testing related tasks as 'not their job' or beneath their position or station.

I'm sure, I am not alone in seeing this, and I find it both sad, but in some ways understandable. After all in the technical realm you have generalists and you have specialists, to be good at one thing requires many hours of study and honing of that skill, often at the expense of others.  Thinking back to that Pyramid, and admittedly, this is a very rough model or metaphor in need of tweaking and polishing, We may walk around a level of that Pyramid closer to one skill or another, We may move up it at an angle as we learn multiple skills practically at the same time, and sometimes we may move straight up.

I see the technical Specialists close on the face between the top of the Pyramid (the metaphorical pinnacle of learning success),   and the Specialist and Technology points.  The more specialized the developer, the closer to the specialist point they may be, and likely further up the pyramid to its zenith.  For generalists, the same could be said between the Technology and generalist point to the peak.   The more a person pours into one technology or into technology in particular the less time they've spent gaining other experiences.  So it should come as little surprise when a twenty or thirty year experienced developer who has poured his life into coding has gotten so far away from knowledge about testing as to see it as a foreign country.


Even among programmers there are generalists and specialists in particular ideas or platforms, and each type of developer brings their own unique viewpoint to the problem at hand. What does that have to do with testing? Well we have something a bit similar do we not? We have people who focus on particular schools of thought, we have people who pour everything into automation, or pour everything into exploratory style testing. We even have some who are trying to learn as much as they can from every category, not knowing what tool they'll need next.




Now Imagine that there were two more points, a high and a low along the Z Axis the top would be Programmer and the bottom Tester.   I can see from adding those points, and removing the metaphorical pinnacle and replacing it with a point for programming and testing.  A person who is a good programmer and continues on that path, may learn at the expense of learning things related to testing.  Just like a programmer who chooses to learn more about testing, will have less time to focus on the craft of programming.    Each of us then may move upward or downward toward being more programmer or tester.  Forward or backward at being more involved in the technology vs the people, or more a specialist in one area vs a Generalist in others.

So when I look at the tree of development with Development as the grand daddy of all the other nodes, and programming, and testing each on separate branches, I can't help see that there are so many varieties of testers and developers out there. Making each of us unique, or different as our experienced build upon one another.  The real question I think we should be asking, is where do we fit in these areas.  Are we more technical or more people oriented?  Are we more specialists or generalists?  More programmer or more tester?

So who is better?  I'm not sure the question matters.  I think the context of program budgets, team size, and backgrounds often weigh into who does what, and as a team on a project we must each do what we feel we can do that will help the project effectively.  Maybe that Senior level developer with twenty years experience would be wasting his time testing, its not his strength, or area of study, so a specialist tester would be better.  However, I would hesitate to ever rule out a particular individual from testing or other development tasks simply because of lack of experience.  The software profession, like so many is one where dedication to life long learning is paramount.  So we should bear that in mind as we forge ahead, no matter which direction we point our bow of learning to on the next course we may set.

One question, many responses.

I have been going through something of a transition phase in my life.   The project I was on, has effectively run its course, and so the uncertainty of where I would end up next began to pop up.   It has been a stressful time, and I know that there may be more stress in the future. Change seems to require quick study, a measure of patience, and the eagerness to take it by the horns and honk till the cows start moving. 

As I have begun preparing for this next assignment, anticipating that Testing will once again be a primary role that I will fill, I began thinking of how I could be better prepared to meet my new project team, and how I can be ready to give an answer to some of the things that may come up as a direct result of statements I might make, statements that are greatly influenced by a large measure of reading, and collaborating with other Test Pros online, through the blog o sphere, or twitter.  I find I am on edge, not in a bad way, but the Eagle Scout in me likes to be prepared.

Up till now, I've been something a lone gun tester, going where ever the current test ideas, or recent releases seem to point as areas of risk.   Sure, the previous project I worked with a pair of testers, but so much of the work I was doing, was different than theirs, that in essence, I brought something unique to the table something that provided value for those teams.   I want to continue to provide value on my next task.  There will be a lot of new faces, new ideas, and new challenges to overcome, but I'm ready, and eager to mount up and go chasing over and after what lies at that horizon.

As I have been preparing myself mentally for this scenario, a thought occurred to me late last night.  It was a thought that gave me pause.  The thought was this:

If you as a tester on an existing project, were allowed only one question on your first day about the project, what question would you ask?

 
 I regret that I had to hit the hay before I could see some of the fantastic responses from the twitterverse.  Some of the responses were similar to the ideas ruminating in my own head. Reid Sheppard asked: "What's the URL to the SUT?" Lanette Creamer asked: "1 question to who? Very important to know."

Truthfully, Lanette's question was really asking for clarity to the context of the above question I asked.  Since it was framed with out any context for where, or who was available to ask, it was very much an open ended question.  I intended it to be a little open ended, but as I slept on it I realized something.  Not only was it lacking in context, but it begged the question.  For any given project X, how much might you as a tester know before officially being on the Team?  

Every test effort begins a bit differently, but I imagine many of them where a new person is brought into an existing team (the specific context of which I was mulling), would begin by some kind of interview, or screening.  Unless the tester and hiring authority had some familiarity with the particular tester they are hiring, The tester could be just as much an unknown to the hiring manager, as the hiring manager, the test team, and product under test is at the start for the newly hired tester.

I find myself coming into a team that to my understanding has already been through several bug/fix and release cycles.  So to me, the context in this case actually includes a few things that are not clear in my statement. The Customer is an entity with which many people might have some experience, or at least preconceived notions regarding how this entity helps them leverage what their service provides. 

Stepping back from the specific instance in my mind, to a more general case, which is really where this question began.  How much does the average tester know about a project before going in?  It might depend upon how their interview and contact with the team began.  Maybe you know who the Customer is, but maybe that information is sensitive information that is only given once a person is a part of the team and agreed to sign on.  Maybe, you do not even have an idea of the scope or mission of the subject under test before agreeing to act as a tester.  Sure there may be cases were that information is available in that screening process, but if it isn't, that's context most testers would hope to grasp early in their testing role. 

Others responded with questions about why the limit of only one question? 

Ajay Balamurugadas asked: "How can I get information without getting restricted by number of questions? #there is a better question :)"

In fact, the limit of one was not meant in my formulation as a hard limit.  My thought was what is the first, question, the first one you'd ask so you can begin pondering all the who's and whats, whens, wheres, whys and hows of testing the application.  Perhaps I can give more idea why my thinking was 'limited' in this context.

When I first came on board here, I remember days of reading that I had to go through.  Much of it wasn't even related to the tasks I would be doing day to day.  time sheet training, ethics rules, benefit packages, taxes, I-9, so much paperwork.  So for someone who is coming in brand new, to be a full part of a team as a tester, the thought occurs to me that they might spend most of their first hours doing a lot of untester things.  So what if at the end of the day, you have an hour left, your tired from all of the tedious paperwork you've had to file, you've signed your life away with a non disclosure agreement, or perhaps signed a contract for term to serve.  Whatever the case is, the thought was this: 

What if in the span of that one remaining hour, in the process of being greeted by the team after you emerged from where HR had you sequestered,  what if one of those team members, not a customer, probably not even the manager, it could be another tester, a developer, a business analyst, whoever it may be, what if they turned to you and asked that question, "Hey, we are glad to have you with us.  Just ask us any question and we'll try to answer it."  However, the new colleague, then adds that they only have a few minutes to spare before they will be leaving for the end of the day.  It's possible you might only have enough time that first day for a single question to ask.  There are so many questions you could ask, and maybe there would be time for more than one question, but depending on the answer you receive it could take up the rest of the time to complete.  This was the frame of mind I was in when pondering this question.

In reality, that first question could be very important, or it could be just the first of a series of questions.  That first question might be forgotten, and left in the dust bin never to be remembered.  The thought would be not so much what is the one question you might ask, but rather what is the first question you would ask? Would it be the same question in a different context? Perhaps it would be different.

Truthfully this does not really matter, there are many questions that will need to be asked to successfully test any product.  Some of these will be obvious, and some will have to be unearthed after peeling back a few layers of the onion.  So I come back to Lanette's question, who is there to ask?  

If it is a tester, perhaps you might ask what areas they've had difficulty testing?  Or maybe you could ask them how the team documents the defects encountered.  If it was a programmer, you might ask them where they think the code is weak, or as Lanette suggested: 'I like to ask developers, "What was the hardest part of X to design? What was the hardest to code so far? What worries you?'  Sometimes the developer will know where their code is weak, or what areas were harder to code, or what areas they've had particular difficulty with.  These kinds of questions would help to identify areas of risk.

In actuality, it may not matter what our first question might be, in fact the thing that sticks out to me is that the issue really shouldn't be what the first question is.  The first question could have a myriad of answers, and in turn a number of counter, or clarifying questions could come up in the course of understanding that answer.   I found this an interesting puzzle to consider.  Just like I do not believe there is a such thing as 'best practices' in testing, there is testing that is good, and techniques, or approaches that are good in some contexts, but perhaps dangerous in others.  So perhaps the best response would be to ask the developer or tester that has opened this door, to simply explain their experience while testing the product.  As such an open ended question, the ideas that might be unearthed could be true gems that lead to effective testing down the road.

From the dark ages, to test automation

Some days inspiration comes so thick that all your ideas begin to stick together in one melding like pancakes with butter, maple syrup, and strawberries.  What follows is a second post, that begin inside my earlier posting: Where in the world are all the software testers?  So if some ideas from that post are also found mixed in here, that is why, but I did my best to refactor my initially 2,500 some odd words from the initial post to create what I feel are two very distinct posts.  While the first one is my thinking about Alan Pages blog on forward thinking, this one is a bit of an experience report, all be it a bit of a history about my first experience in software, and a bit about some of my more recent challenges.  I describe the trial of working with out a source code repository, and even describe some of my frustrations at having to build using clearly out dated technology.  Sometimes it is hard to realize how valuable any given tool is, unless you have ever had to try to work on a project without that tool.  This is where I began, and to forget how I first tread foot into the industry, would be to forget how far I've come, how much I've learned, and how much more there is to learn and do...


When I first started in Software, testing was seen as something I did when the time and necessity called for it.  Though initially I was hired as an integration developer, focusing on piecing module code from one place into another in the stable product line, testing was something that seemed as if it was just part of the job, but not necessarily the most important.  Maybe its the way software engineering is glamorized in the courses I took at WVU, I'm really not sure; nevertheless, as I began to grow understanding around the product, its structure, and purpose, It was not long before I found myself in a "Test First, Test Often" mindset.  

The reality of my first professional Job seems almost barbaric compared to recent projects I worked on.  There was no source code repository, no Visual Source Safe, Subversion, or CVS in general use, so this meant that when new modules were being developed they were always in what was deemed as the last stable development build.  Many times the build that the features were added to comprised a number of new features and bug fixes, so the porting of that code had to be done laboriously by hand.  If I had not been so green as a Developer at the time, and had scene the value of source code repositories before my professional time, maybe we could have changed how things worked.

In any case, it was my job to kick the tires on these features by porting them into the latest and greatest build, and then seeing what the new additions actually did.  Suffice it to say, I highly recommend a source code repository for projects, especially when you have people working remotely or on different sites.  However, this was the situation I found myself in as a young software practitioner.   Finding all the right bits of code, initially was not easy.  Sometimes I would get complete source, and have to scour every class for changes (And really, with little background on the project before, It is quite possible some of those changes had been changed not by that module, but in previous bug fixes in the new build.)  So I began pushing back to have some way of seeing and marking what areas they had changed, so I could focus there, and not on other parts of the code.  The wrap around comment with tags for each module became the first thing I searched for when integrating.

That's how the process was initially described to me, so that's how I went about my tasks early in that assignment.  This turned out to be a harder more time consuming method though.  With developers deployed overseas, sometimes on different operating system setups, even the code they wrote that worked on their systems did not always work correctly on hours.  Were these Regression errors that crept in as features kept being added?  Or were these simply the result of the different platforms we were using?  To this day I am still not certain, but the obvious solution came that we began requiring a demonstration build of each feature.  First it would allow us to see if the build actually worked on our production systems which were perhaps closer to what our customers actually used, and secondly it would also allow us to see whether the feature worked as expected before putting the time consuming 'monkey work' of copying code A to class B.    So I found myself doing about 50% more testing than actual clerical/coding work on our project, and found a lot of bugs in the process.  Suffice it to say, I look back on those first steps as very raw, hard ones in my development professionally, and am thankful that I have learned and moved beyond such outdated techniques.

So it has been just over five years that I have been on this latest assignment, and one area that I have found myself thrust into has been testing.  What others on our team realized, though I couldn't see it from my eagerness to help out the team in any way, was that I was actually a pretty good tester.  I'm not sure where this skill, or perceived confidence in me as a tester came from, but as a Colleague said to me just this past week, "He's a testing Wiz."  I smiled and accepted the compliment graciously, but deep down, while others think I have it all figured out, I know that I have a long way to go before I consider myself to be any kind of expert, at Testing or Software Development.   Truthfully I wonder if it is even possible to be an expert in anything software related given how fast the state of the art moves in some areas.

So what does this have to do about forward thinking?  Before the last year I had not seen myself as a tester, just a software developer, eager of doing whatever the team required to succeed on our projects.  I stepped up to an offering of a different role as a developer of test automation, and also testing in general, and I embraced the chance to learn and do something new.  I did so not enter this assignment knowing how long I would be kept on the project, and I did so, having done perhaps more coding work than actual testing on recent assignments, but I didn't let that stop me.  As I had recently learned from the classic book from Spencer Johnson, M.D. "Who Moved My Cheese?" to not only anticipate change, but to embrace it, and relish it, I plunged into what initially seemed like a rather dull engagement, and not to mention highly time consuming, but I could see why they needed someone to focus on test automation, it just frankly took too much time to have the regular testers doing it.  

So I embraced the change, challenge, and at times boredom of test automation, and learned how to string together tests in a version of the test tool we used.  While I looked for and anticipated change, I had set my mind to get 'comfortable' in performing these tasks the way they were demonstrated to me.  I didn't know at that time that anyone else had tried and given up on the effort in the past, nor did I have any prior experience or research to back me up in finding a better way, but it was a start.

As I pushed forward through these challenges, I took time when I could to research the certain unique problems I encountered along the way, and at some point I stumbled onto a blog.  I don't recall which blog it was that I first read, but I began reading this blog and using the challenges to learn more about testing in general.  Then one blog linked to another, Google Reader began suggest some other similar blogs, and suddenly a new world of testing was open to me, and as I learned, read, and absorbed new ideas, and techniques, and it transformed my understanding and view of the field.

Now I am engaged on a new project, one where I am not constrained to a particular tool set, rather constrained to doing the best job I can in testing the application to find bugs, to learn, and to apply as never before new found technology.  Some of my tasks have afforded me the chance and need to develop a test harness, utilizing both C# and Selenium.  Perhaps later I shall try to bring some examples of the generic process  I went through to create and build a test harness for some of the automation tasks that make sense for this project.  For now, it feels good to no longer be back in the dark ages, but to be in the present ever living moment, applying new ideas as I encounter them, learning and building both my knowledge, as well as wisdom on when and where to use certain testing ideas.