A few months ago I started work on a Perl version of a protocol test app, the original one was written in C and while we have the source code my network C was never very good, but I can handle Perl and protocols so I changed it. Basically there are two scripts, one that sets up a dummyServer (listener) and another that is a dummyClient (sender). The sender connects to the listener, sends a few lines of data and disconnects. Short and simple because all we are doing is checking that the connections are detected, and where the connections come from, because that is what the product does. Now this worked fine for awhile, but now we are detecting connections over IPv6, and that necessitated something else, and since I couldn't work in C (yet) I did this in Perl and it was a good experience. I got to learn alot more about networks and protocols, and how DNS will work on our lab network, which I had no idea was limited.
Now that the scripts are done I then discover our product likes to ignore a lot of Perl scripts, good for testing but not good in this case, so rather than try to hack the product to make it recognize these scripts I am looking at changing the scipts into executables. This has been more fun. Since initially my work is done on Windows, so I can use SlickEdit, I tried buildind the various Perl Package Utilities on my Windows 2003 machine, what I encountered is noted here.
Perl2EXE, while nice, does not give me what I want, and sadly also does not install properly on my machine. Giving me all kinds of weird Mac::InternetConfiguration errors, that seemingly a lot of people get, but somehow get past by installing older versions of certain Perl libraries or somehow ignoring them. I can't seem to ignore them, and honestly, if I need to go through these weird kinds of hoops to get this working on a Windows machine, I'd rather do it on Unix.
PAR is a good alternative, but I want these to be executables not PAR files that I need to run individually, so while it was fine many versions ago with the recent split to have PAR and the Perl Packager (pp) in different distributions I have to install it and the PAR:Dist that gets me the Perl Packager I need. On Windows I get loader errors with the PAR::Dist, which many have gotten but somehow gotten past awhile ago, there are some sites that list instructions on how to install the Packager, but some are woefully out of date or had steps which did not work for me.
pp - the Perl Packager is the one I am in the midst of using, but as I am now in the middle of adding this to one of my Unix machines (I have AIX, HPUS, Linux and Solaris available) once I get it working then I will know how things are going.
Perl is always fun, and I am always getting into something new. Never a dull moment.
Wednesday, July 16, 2008
Friday, June 13, 2008
What do I want to be?
After working in various positions and companies I can pretty much say I have done all the pathways to progress I ever considered at one time or another. starting from single person to Manager of QA, building up the groups overtime, or as individual contributer working on setting up processes, expanding existing testing or even automation I have done all the different aspects of what I have encountered. Not that this is all of them but in many posts through the SQA Forums, most people ask about progressing towards Automation or Management or stay where they are. Well here is what I have found.
As a Manager you will get away from the day to day testing, unless you are able to finagle some testing work into your schedule, and I always tried to do so for various reasons but its a good thing to do. Most importantly to keep your skills up, sure management skills are important but within QA its good to also be technically proficient, because you will deal with Developers at times its good to have the technical backing to either keep down a snowjob or to back up what you are saying when you just know something that you are being told will work, just won't. It's also good professionally, because you may end up leaving your job at some point, and if like me you enjoy the environment of start-ups, you will need to begin again and test so don't let the skills lack! I know someone who used to be an IT Manager and worked his way up to there, but then spent so much time managing that when he ended up looking for another job he was so far out of the current environment technically he felt he needed to take a lower level job to catch up. I say avoid that at all costs!
If you want to do Automation, then make sure you enjoy programming, know how to do it and want to make it your life. When every day is either spent debugging a test program so that it will work correctly, because the interfaces you want to test have changed in subtle ways, and are not well documented, then you have to enjoy that sort of life style. Knowing how to generate good frameworks that are well documented, easy for others to use and most importantly give clear and concise results is important. When you are the toolsmith, your goal should not be just to make any tool, but make one that is easy for others to use and implement in various ways, so you can move on to making the next and greatest tool, don't just think you can make something then let it go. See that its doing what you thought it was. In the case you leave one day, don't leave a bunch of tools lying around that not many people know how to use, and can't figure out because the code is not commented well because "it was only a test tool".
My preferred area is a nice middle ground, at least for now, I have done managing, and some automation work (makes me realize that I don't really like getting into coding too deep, I'll never be a hacked I know it but I can get by), but what I like is being the person that gets a project and runs with it. With my skills as a manager I can lead a project from the QA side, knowing how to diplomatically work with people, because I learned lots from some good HR people in the past, and I know enough about programming to be dangerous and take the time to work out the issues I find. Some developers love that, especially when you are eager to learn, and I find that is the most important thing for me, I like to keep learning and working on new stuff as well as learn more about what I am working on. There is so much out there, its almost inexhaustable, but its all good.
As a Manager you will get away from the day to day testing, unless you are able to finagle some testing work into your schedule, and I always tried to do so for various reasons but its a good thing to do. Most importantly to keep your skills up, sure management skills are important but within QA its good to also be technically proficient, because you will deal with Developers at times its good to have the technical backing to either keep down a snowjob or to back up what you are saying when you just know something that you are being told will work, just won't. It's also good professionally, because you may end up leaving your job at some point, and if like me you enjoy the environment of start-ups, you will need to begin again and test so don't let the skills lack! I know someone who used to be an IT Manager and worked his way up to there, but then spent so much time managing that when he ended up looking for another job he was so far out of the current environment technically he felt he needed to take a lower level job to catch up. I say avoid that at all costs!
If you want to do Automation, then make sure you enjoy programming, know how to do it and want to make it your life. When every day is either spent debugging a test program so that it will work correctly, because the interfaces you want to test have changed in subtle ways, and are not well documented, then you have to enjoy that sort of life style. Knowing how to generate good frameworks that are well documented, easy for others to use and most importantly give clear and concise results is important. When you are the toolsmith, your goal should not be just to make any tool, but make one that is easy for others to use and implement in various ways, so you can move on to making the next and greatest tool, don't just think you can make something then let it go. See that its doing what you thought it was. In the case you leave one day, don't leave a bunch of tools lying around that not many people know how to use, and can't figure out because the code is not commented well because "it was only a test tool".
My preferred area is a nice middle ground, at least for now, I have done managing, and some automation work (makes me realize that I don't really like getting into coding too deep, I'll never be a hacked I know it but I can get by), but what I like is being the person that gets a project and runs with it. With my skills as a manager I can lead a project from the QA side, knowing how to diplomatically work with people, because I learned lots from some good HR people in the past, and I know enough about programming to be dangerous and take the time to work out the issues I find. Some developers love that, especially when you are eager to learn, and I find that is the most important thing for me, I like to keep learning and working on new stuff as well as learn more about what I am working on. There is so much out there, its almost inexhaustable, but its all good.
Monday, May 19, 2008
Nightly Builds - Just Good Sense
Occasionally in some discussions on Agile the topic of Nightly Builds comes up, and while I will agree that its something that should be done during a sprint, and while its mentioned in a couple of newer editions on the methodology I just see it as something that needs to be done. You don't need to be on a Scrum Team or on an Agile Sprint to see the value in a nightly build, if your code is building every night then it means people are doing their work and verifying that things work properly, nothing more special than that. Methodologies are great to build a framework around, and often give high level management some way to say they are doing something that is hot and on topic, or allow them to utilize yet another buzzword. Outside of that nightly builds are good for everyone.
The gains are immense, not only knowing that any day someone can check out the source tree and get the code to build in their environment but once you have taken the step of having a build happen then you can go onto the next step of automated testing. Whether its a suite of Unit Tests or an automated Smoke Test, unless code is building you are not taking that next step, adding those steps allows one to have a good deal of confidence against the code checked in. Having tests run every night allows you to know that your code is good in the source tree not only because it builds but that its passing a set of tests deemed necessary for the code to always pass. Confidence assured.
Of course if you don't have the coding to back this up, say check ins are only occurring every couple of days then this won't work for you. In larger, or mature, products you have code being checked in all the time, and that's where the gain is. You need to determine the best output for your team.
So before worrying about whether or not you are following a specific methodology get some basics in place first, Nightly Builds is one of the most important.
The gains are immense, not only knowing that any day someone can check out the source tree and get the code to build in their environment but once you have taken the step of having a build happen then you can go onto the next step of automated testing. Whether its a suite of Unit Tests or an automated Smoke Test, unless code is building you are not taking that next step, adding those steps allows one to have a good deal of confidence against the code checked in. Having tests run every night allows you to know that your code is good in the source tree not only because it builds but that its passing a set of tests deemed necessary for the code to always pass. Confidence assured.
Of course if you don't have the coding to back this up, say check ins are only occurring every couple of days then this won't work for you. In larger, or mature, products you have code being checked in all the time, and that's where the gain is. You need to determine the best output for your team.
So before worrying about whether or not you are following a specific methodology get some basics in place first, Nightly Builds is one of the most important.
Monday, May 5, 2008
Software is NOT Manufacturing
I've seen it alot whenever discussions on methodologies come up, especially the ISO and CMMI ones, but it usually comes down to the whole mechanism of why software is different than making widgets. Thinking about this off and on, I came to the conclusion for myself, that there are some major differences here and it all comes down to the fact that widgets ARE different than software. Beyond the physical there are some major differences between generating a product that people use, utilize or somehow adapt to their life and software which can also have the same implications is very different. I came up with what I consider 3 major points, makes it easy because no one really has a top 3 and a half reasons list, in which they are very different and thats design, implementation and release. Yes, they are similar but that's about where it all ends to me. So let's take something amorphous called "software" or "the programme" and compare it to "Plastic Shovel Red No.2".
Mind you this is all my opinion, if you feel different go ahead and comment or stop reading now.
Design. When you create software there are lots of meetings and specifications and documents that tell you how it is going to be and what it is going to be, unless its a personal or open source project (or even Agile!) where this may change. Input is gathered, perhaps some market research, after all you want to know what it is you are building before you go ahead and do it. Someone has to know before starting to even think about it that the particular software is going to be useful, or will be, in some niche that will create an entry point for its particular functionality - if its not going to be useful no one will want it or probably not want to work on it either. So that need is part of the design and helps shape what the software will be, there is an idea and a goal to reach then, so the work on the design and any associated research is all about what will help the software become that need. Now the Plastic Shovel is fairly simple, it has some uses (more if you consider the imagination of the typical 4 year old) that are known ahead of time and a shape that needs to be made. It's considered from multiple angles and multiple measurements (how long should it be? how wide? how thick? when we make the handle should it have an O shape at the top or another shape?) all of this is considered at the beginning. Once run through a couple of times, perhaps a meeting or two just as might be had for the programme, a decision is made that this is the way we want it. A prototype is made, for either one, and that is then presented and demo'ed to someone or a group and input is solicited. Now this is the important part. Once that input is given software can go through more rounds of feedback and use while Plastic Shovel is decided upon and then you know what....decision made and go make it!
This is what I call the Feedback Divergence. For software you can continually elcit feedback, because its complex and evolves, almost as if its a living thing made of many living things and what you end up with is often not what you started with. A plastic shovel, on the other hand, once decided upon has its specs sent to the factory floor with orders to make X numbers of them, software basically has one thing made - the source code. Sure someone can come back and say that Plastic Shovel was horrible and broke when too much sand was put on it, but that just means we start the process again with Plastic Shovel and make a completely different version of it for the factory to press out later. That feedback does not go back into the design and create a different one, because its already been made! Software, because it can be built at any point of the process can elicit input at any time and be made different at that time.
Implementation. Part of putting the design down on the factory floor for the Plastic Shovel is that a mold is made, and machines are set for creating thousands of cheap Plastic Shovel Red No.2. Once that is done the Shovel is committed (now I know that's an Agile term but its also true) the Shovel will now be made by the thousands. It's now being implemented by the workers on the floor whose only job at this point is to make thousands of nice, bright plastic shovels in Red No.2. Not Red No.3 because little Suzie wants that color to go with her polka dotted suit, or Green No.5 because Jimmy thinks its cool, its all Red No.2. If you want another color you are buying another product because once that shovel is stamped out on the factory floor its done, been implemented as designed and is not going to be personalized at the factory at all. Not in the plan. Software can do that, because its able to be adjusted because its not a physical object.
This is what I call the Hand Divergence. If I can hold it in my hand there are a limited number of mechanisms by which this object can be adjusted, personalized and or changed. With a significantly smaller number of those changes actually provided by the manufacturer. Once its done its done. Software in some essences is never done, because you are making a new version off an old set of source and code which together comprises the whole, and because its malleable you can infinitely change it. You can't do that with a plastic shovel, at some point you will come to an end of possibilities to change it, software does not work that way.
Release. When software is "done" by a project sense its given to the Customer, perhaps on a CD or a download, and there is probably a release party somewhere with beer, food and hula girls. Well not everyone gets the hula girls, heck some people don't even get the beer. The point is, you can take your checklist and look at it versus your software and say you have X% functionality done, which will be acceptable to the Customer at this time, with other improvements in queue, or soon to be in queue once they install the programme and use it. But is it really done? Not at all. You've hit a milestone where you can say that the functionality that was originally designed for was satisfied to a degree, the closer to 100% you get the better off your project was managed. Now that plastic shovel, once its off the factory floor its either on its way to some discount retailer near you to get a price tag, or its going to be bundled with the "Super Special Summer Sand Spectacular" where it takes its place in a bucket with a bunch of other cheaply made plastic items that are all COMPLETE!
I have no divergence with this one, unless you want to call it the Profit Divergence. Part of what makes the Plastic Shovel Red No.2 special is that once it was sent to the factory floor we knew exactly how many needed to be made and sold to generate a profit for the company. For software we are either paid for the work up front, where we probably went over budget because of circumstances beyond our control, or it will be sold and people will go out and driver desire for the programme so we can continually make money off it and get people in line for the improvements that come later. At this point the story for Plastic Shovel Red No.2 is done, it may go back for a redesign but maybe not, software is just beginning and still has a long road ahead.
So there you go, my rationale as to why software is not manufacturing.
Mind you this is all my opinion, if you feel different go ahead and comment or stop reading now.
Design. When you create software there are lots of meetings and specifications and documents that tell you how it is going to be and what it is going to be, unless its a personal or open source project (or even Agile!) where this may change. Input is gathered, perhaps some market research, after all you want to know what it is you are building before you go ahead and do it. Someone has to know before starting to even think about it that the particular software is going to be useful, or will be, in some niche that will create an entry point for its particular functionality - if its not going to be useful no one will want it or probably not want to work on it either. So that need is part of the design and helps shape what the software will be, there is an idea and a goal to reach then, so the work on the design and any associated research is all about what will help the software become that need. Now the Plastic Shovel is fairly simple, it has some uses (more if you consider the imagination of the typical 4 year old) that are known ahead of time and a shape that needs to be made. It's considered from multiple angles and multiple measurements (how long should it be? how wide? how thick? when we make the handle should it have an O shape at the top or another shape?) all of this is considered at the beginning. Once run through a couple of times, perhaps a meeting or two just as might be had for the programme, a decision is made that this is the way we want it. A prototype is made, for either one, and that is then presented and demo'ed to someone or a group and input is solicited. Now this is the important part. Once that input is given software can go through more rounds of feedback and use while Plastic Shovel is decided upon and then you know what....decision made and go make it!
This is what I call the Feedback Divergence. For software you can continually elcit feedback, because its complex and evolves, almost as if its a living thing made of many living things and what you end up with is often not what you started with. A plastic shovel, on the other hand, once decided upon has its specs sent to the factory floor with orders to make X numbers of them, software basically has one thing made - the source code. Sure someone can come back and say that Plastic Shovel was horrible and broke when too much sand was put on it, but that just means we start the process again with Plastic Shovel and make a completely different version of it for the factory to press out later. That feedback does not go back into the design and create a different one, because its already been made! Software, because it can be built at any point of the process can elicit input at any time and be made different at that time.
Implementation. Part of putting the design down on the factory floor for the Plastic Shovel is that a mold is made, and machines are set for creating thousands of cheap Plastic Shovel Red No.2. Once that is done the Shovel is committed (now I know that's an Agile term but its also true) the Shovel will now be made by the thousands. It's now being implemented by the workers on the floor whose only job at this point is to make thousands of nice, bright plastic shovels in Red No.2. Not Red No.3 because little Suzie wants that color to go with her polka dotted suit, or Green No.5 because Jimmy thinks its cool, its all Red No.2. If you want another color you are buying another product because once that shovel is stamped out on the factory floor its done, been implemented as designed and is not going to be personalized at the factory at all. Not in the plan. Software can do that, because its able to be adjusted because its not a physical object.
This is what I call the Hand Divergence. If I can hold it in my hand there are a limited number of mechanisms by which this object can be adjusted, personalized and or changed. With a significantly smaller number of those changes actually provided by the manufacturer. Once its done its done. Software in some essences is never done, because you are making a new version off an old set of source and code which together comprises the whole, and because its malleable you can infinitely change it. You can't do that with a plastic shovel, at some point you will come to an end of possibilities to change it, software does not work that way.
Release. When software is "done" by a project sense its given to the Customer, perhaps on a CD or a download, and there is probably a release party somewhere with beer, food and hula girls. Well not everyone gets the hula girls, heck some people don't even get the beer. The point is, you can take your checklist and look at it versus your software and say you have X% functionality done, which will be acceptable to the Customer at this time, with other improvements in queue, or soon to be in queue once they install the programme and use it. But is it really done? Not at all. You've hit a milestone where you can say that the functionality that was originally designed for was satisfied to a degree, the closer to 100% you get the better off your project was managed. Now that plastic shovel, once its off the factory floor its either on its way to some discount retailer near you to get a price tag, or its going to be bundled with the "Super Special Summer Sand Spectacular" where it takes its place in a bucket with a bunch of other cheaply made plastic items that are all COMPLETE!
I have no divergence with this one, unless you want to call it the Profit Divergence. Part of what makes the Plastic Shovel Red No.2 special is that once it was sent to the factory floor we knew exactly how many needed to be made and sold to generate a profit for the company. For software we are either paid for the work up front, where we probably went over budget because of circumstances beyond our control, or it will be sold and people will go out and driver desire for the programme so we can continually make money off it and get people in line for the improvements that come later. At this point the story for Plastic Shovel Red No.2 is done, it may go back for a redesign but maybe not, software is just beginning and still has a long road ahead.
So there you go, my rationale as to why software is not manufacturing.
Wednesday, April 23, 2008
A Developer went Ka-Choo
(My apologies to Dr. Seuss)
You may not believe it, but here's how it happened.
One fine spring day....a Developer sneezed and went KA-CHOO!!
Because of that sneeze, a task dropped.
Because that task dropped, a Manager got assigned.
Because that Manager got assigned, he had to delegate.
Because he needed to delegate, and Architect got work.
Because that Achitect got work, some brainstorming happened.
Because of the brainstorming, some fingers got pointed.
Because of the fingerpointing, around that table
Someone got more work than they were able.
Because of that work more talking was done.
Because there was talking, a document got made.
Because a document got made people had to read it.
Because of that reading comments were made.
Because comments were made, they were sent around.
Because they went around people got to read them,
And when they read them more comments were made.
Because of the comments more people got involved.
Because of more people more comments were made.
And so comments were sent around one more time.
Because there were opinions no review was made.
Because there was no review more comments got added.
Because of more comments and no review the document got stale.
Because it got stale it was ignored by QA
Because it was ignored more tempers were flared
Because tempers got flared more comments were made
Because more comments were made someone asked why
Because someone asked why they looked at the task
And because they looked at the task, it’s true I’m afraid – they
Ran into a spectacle
And that started something they’ll never forget, and far as I know its going on yet.
You may not believe it, but here's how it happened.
One fine spring day....a Developer sneezed and went KA-CHOO!!
Because of that sneeze, a task dropped.
Because that task dropped, a Manager got assigned.
Because that Manager got assigned, he had to delegate.
Because he needed to delegate, and Architect got work.
Because that Achitect got work, some brainstorming happened.
Because of the brainstorming, some fingers got pointed.
Because of the fingerpointing, around that table
Someone got more work than they were able.
Because of that work more talking was done.
Because there was talking, a document got made.
Because a document got made people had to read it.
Because of that reading comments were made.
Because comments were made, they were sent around.
Because they went around people got to read them,
And when they read them more comments were made.
Because of the comments more people got involved.
Because of more people more comments were made.
And so comments were sent around one more time.
Because there were opinions no review was made.
Because there was no review more comments got added.
Because of more comments and no review the document got stale.
Because it got stale it was ignored by QA
Because it was ignored more tempers were flared
Because tempers got flared more comments were made
Because more comments were made someone asked why
Because someone asked why they looked at the task
And because they looked at the task, it’s true I’m afraid – they
Ran into a spectacle
And that started something they’ll never forget, and far as I know its going on yet.
Wednesday, March 12, 2008
Who is Testing the Tests?
When Developer's write code who looks at it?
Usually another Developer, at least for a review, and more importantly someone who is testing it.
When Tester's write a test who looks at it?
Uhm....I sometimes find that hard to answer.
Sure, we occasionally send out test plans and cases for review, but does it happen all the time? No. Are you sure everyone looks at it? No. Will comments come back? Not always. I do try to look at test plans that my group generates, I review it even if I think I will have no comments, though I can at least spot a grammar error or two if I look hard. But that's not really a technical review is it? That's kind of the point, where is the technical review?
I've seen this come up on occasion in blogs or posts, that someone writes a test tool and uses it, fixes it and makes sure that it does what its supposed to do then what? Maybe suggest to others that they use it when checking certain code or functionality, but has it been as strenuously reviewed as code for Production? I can honestly say for myself, that has not always been the case. But in a way to catch up and practice what I preach, I am spending more time getting reviews and following up with people, having reviews of tools we use in house done by other people, including Developers. Not only to make sure that things work right, and I can explain what is going on, but I can maybe find a better method of doing what I want by someone who spends more time coding than I do.
When was the last time you wrote out a spec for a tool you wrote? If it was complex enough, that is...I can honestly say 1 for all the tools I have made.
Let's face it, we sometimes take shortcuts as in the test environment its not perceived to be as necessary to have strenuous reviews of what we use because what we are using is not going into Production. What we are testing is! So why not have the same standards for the tools we use and write? Be just as critical as if you were going to buy such a tool from someone, and make sure you know what its doing and how. The more you understand and can talk about the tool you are using, the more secure you can be in that the tool is doing what its doing.
And yes, I say reviews are for QA as well as Development, because in the end, its all code.
Usually another Developer, at least for a review, and more importantly someone who is testing it.
When Tester's write a test who looks at it?
Uhm....I sometimes find that hard to answer.
Sure, we occasionally send out test plans and cases for review, but does it happen all the time? No. Are you sure everyone looks at it? No. Will comments come back? Not always. I do try to look at test plans that my group generates, I review it even if I think I will have no comments, though I can at least spot a grammar error or two if I look hard. But that's not really a technical review is it? That's kind of the point, where is the technical review?
I've seen this come up on occasion in blogs or posts, that someone writes a test tool and uses it, fixes it and makes sure that it does what its supposed to do then what? Maybe suggest to others that they use it when checking certain code or functionality, but has it been as strenuously reviewed as code for Production? I can honestly say for myself, that has not always been the case. But in a way to catch up and practice what I preach, I am spending more time getting reviews and following up with people, having reviews of tools we use in house done by other people, including Developers. Not only to make sure that things work right, and I can explain what is going on, but I can maybe find a better method of doing what I want by someone who spends more time coding than I do.
When was the last time you wrote out a spec for a tool you wrote? If it was complex enough, that is...I can honestly say 1 for all the tools I have made.
Let's face it, we sometimes take shortcuts as in the test environment its not perceived to be as necessary to have strenuous reviews of what we use because what we are using is not going into Production. What we are testing is! So why not have the same standards for the tools we use and write? Be just as critical as if you were going to buy such a tool from someone, and make sure you know what its doing and how. The more you understand and can talk about the tool you are using, the more secure you can be in that the tool is doing what its doing.
And yes, I say reviews are for QA as well as Development, because in the end, its all code.
Wednesday, February 13, 2008
Clearing the Junk
I recently got a book from my sister-in-law, my wife's family comes from Taiwan and they are Buddhist so I occasionally end up going with them to the Buddhist temple and meet some of the monks there. One I have had the pleasure or meeting, and discussing things with, is the Venerable Yifa, a very smart, funny person and prolific writer. More can be found out about her here Yifa, I'm also pretty happy to know someone with their own wikipedia entry, pretty cool.
In reading Authenticity: Clearing the Junk, which focuses more on the junk cluttering our lives, I inevitably had to start working on something for test plans and started thinking - do I have junk here? Is there stuff that is cluttering up my testing and making my work harder and more difficult than it needs to be? While I can be prolific when I want to be, I can also feel that I don't want to waste time on something because its a point or discussion I feel can be done in a relatively short amount of time, my test plans are not padded in any way. I don't write more than I have to, probably from advanced laziness where I don't want to have to update any more than I have to in the future if things change, but also because I know things may change in the future so why get set into something that may not be the same in 6 months?
So if my test plans don't have much junk in them what about those test cases? I took a look and one of the benefits of using Excel is that you only have a limited amount of space to write in, so I am actually boxed in to be junk free there. Not a bad way to leave myself. So I decided to look at the Test Harness we use, and yes, lots of junk there. Not all mine, but I certainly contributed at some point. So I need to clean that up.
But why stop there? If I look at my calendar I have a lot of meetings, some of them go far longer than they should, do I contribute junk there? Probably. I better start cleaning that up. Of course sooner or later I am going to get back to looking at my life and seeing how much junk I have there as well, there have been cuts in many things over the past year just to provide a healthy home for my son. No soda in the house anymore, I do miss that, not as many cookies and snacks, I eat way more fruit than I used to, and baking our own bread has been nice and gives the place a rustic, homey feel.
I guess I've been keeping an eye on this stuff for awhile now, so I guess I am going to a good place in life, and work.
Those Buddhists, pretty smart.
In reading Authenticity: Clearing the Junk, which focuses more on the junk cluttering our lives, I inevitably had to start working on something for test plans and started thinking - do I have junk here? Is there stuff that is cluttering up my testing and making my work harder and more difficult than it needs to be? While I can be prolific when I want to be, I can also feel that I don't want to waste time on something because its a point or discussion I feel can be done in a relatively short amount of time, my test plans are not padded in any way. I don't write more than I have to, probably from advanced laziness where I don't want to have to update any more than I have to in the future if things change, but also because I know things may change in the future so why get set into something that may not be the same in 6 months?
So if my test plans don't have much junk in them what about those test cases? I took a look and one of the benefits of using Excel is that you only have a limited amount of space to write in, so I am actually boxed in to be junk free there. Not a bad way to leave myself. So I decided to look at the Test Harness we use, and yes, lots of junk there. Not all mine, but I certainly contributed at some point. So I need to clean that up.
But why stop there? If I look at my calendar I have a lot of meetings, some of them go far longer than they should, do I contribute junk there? Probably. I better start cleaning that up. Of course sooner or later I am going to get back to looking at my life and seeing how much junk I have there as well, there have been cuts in many things over the past year just to provide a healthy home for my son. No soda in the house anymore, I do miss that, not as many cookies and snacks, I eat way more fruit than I used to, and baking our own bread has been nice and gives the place a rustic, homey feel.
I guess I've been keeping an eye on this stuff for awhile now, so I guess I am going to a good place in life, and work.
Those Buddhists, pretty smart.
Subscribe to:
Posts (Atom)