Who’s On Phirst

When designing your own custom WebSphere Portal themes and skins, after initially creating them in the Portal Admin Console and in the file system of your WebSphere Application Server, it is important to update your WebSphere Portal EAR file with your new themes and skins. Otherwise, your new themes and skins can be overwritten or deleted whenever the WebSphere Portal EAR is updated. So, what do we need to do to add our shiny new custom themes and skins to the WebSphere Portal EAR file? Unfortunately, this involves a little bit of scripting with wsadmin and EARExpander. This is all documented in the IBM online help. If you don't want to do this manually every time, you end up with a shell script for Linux or Cygwin (or similar DOS batch file) that looks something like this to update a new skin called qaThinSkin and a new theme called qaIBM:



This can be quite tedious and error-prone (and subsequently, costly) if you are constantly tweaking your skins and themes and need to move them from QA to production. This is where Phurnace WebSphere Portal Deliver can help. After you have initially created your custom skin and theme, Deliver can snapshot your WebSphere Portal configuration. Then we can use the Portal Configuration Packager Wizard to pare down the configuration to just the custom skin and theme.



Then copy your custom theme and skin to your Deliver client, keeping the same directory structure as they would be under the wps.war directory on your WebSphere Application Server:



Next we add the local directory for our themes and skins to the Deliver server profile, in the Portal tab.



Now we can make updates to the JSPs or GIFs on our Deliver client and then do a Portal Install to the WebSphere Portal application server to see the updates. You can even use our Portal Copy feature to transfer your custom themes and skins from your QA environment to your production environment. With no more time spent scripting, you can actually use your time for more important things like designing your custom skins and themes, and let Phurnace WebSphere Portal Deliver do all the deployment work for you.

In WebSphere Portal
Comment (0) Read More...

Installation testing on Windows can be a chore if you don't know what your application under test does to the system. In addition to laying down files in the "Program Files" directory (or a user specified directory), a Windows application will typically put installation files in a temporary directory. It might also install DLLs in the Windows directory, or create or update entries in the registry. Knowing what an application's installation does to your system is especially important when you get to testing the uninstallation. Fortunately for those of us in the software testing profession, there is a handy utility called RegShot.

The first thing we want to do is start with a fresh Windows system that has never had the application installed on it. (This is where Ghost or VMWare is extremely useful in your test lab, by the way.) Install RegShot. I used version 1.8.2. Start RegShot and set your Scan Dir if you want to scan the hard drive in addition to the registry. Now select "1st shot". You will get a context menu with Shot, Shot and Save, and Load. I choose Shot and Save, as this will save a registry hive file that can be loaded at a later time.

When it is finished scanning, you will be prompted to save your hive file. We are done with the first stage.

Now we install our application that we are testing. After installation is complete, select 2nd Shot. When it is finished, save the second shot. Now you can compare the two by selecting compare. You will then be presented with a report that tells you what registry keys and values have been added, modified and deleted. The report will tell you similarly for folders and files if you chose that option.

If you want to test uninstallation, click the Clear button. Then load your second shot with the 1st shot button. Uninstall your application. Then make a third shot with the 2nd shot button, and compare the two.

In Untagged 
Comment (0) Read More...

It seems like everyone is blogging today. Phurnace has a blog. I have a blog. My mother has a blog. All the cool kids are doing it, right? There are many reasons for starting a blog. For some, it is like a personal (or non-personal) diary for the whole world to read. Artistic folks use blogs to showcase their poetry, photographs or art. Businesses (like Phurnace Software) use a blog to show a more conversational and personal side to their company while still generating interest.

So, how can technical people benefit from blogs? When doing work related web searches, a good portion of information that I actually find and use comes from blog postings. There are a lot of tips and tricks out there, as well as some really good tutorials on a variety of topics. Looking for WebSphere related information? You could check out the WebSphere Community Blog as well as the developerWorks blog hosted on IBM. There are also plenty of programming languages blogs as well. Coming to mind are java.blogs and O'Reilly Ruby blog. And there is always my favorite all-around geek blog (and occasional gratuitous timewaster): Lifehacker.

Rather than just being on the receiving end of information, it is important for technical people to contribute to the blogosphere. Are you excited about a new technology? Spread the love. Did you discover a new technique? You should share with the rest of the world. Did you spend hours troubleshooting a problem? You should write it down to save yourself (and others) the pain the next time that occurs. And for these reasons (and there are many more), if you are the type reading this blog, then you should have your own blog or contribute to a team blog.

What makes a good technical blog? One that shares news or technical ideas. For example, you find a provocative news item (e.g., the latest web application server release), and have an opinion or comment on it. Or perhaps there is a specific bug or coding technique you can abstract to a wider audience. And include code samples! We love code samples! Think about this: if you were looking for information, how would you search for it on a search engine like Google. You should include that in your title for your blog entry.

Since writing a good technical blog is like being a mentor or coach, in that you will master your subject the more you do it, you should write, write, write. Hopefully you are now inspired to do so.

In Untagged 
Comment (0) Read More...

Book review: Testing Extreme Programming by Lisa Crispin and Tip House

Testing Extreme Programming is part of the Addison-Wesley XP series of books. The most well known book in this series is probably Extreme Programming Explained: Embrace Change, by Kent Beck. Since one of the frustrating things about being a QA engineer or software tester on an agile or XP project is that there is hardly mention of the role of QA or the place of the tester in most XP literature, I decided to read this book.

If you do not know much about the tenets of XP, this is briefly explained in the beginning of the book, from a tester's point of view. There is no prerequisite to read Extreme Programming Explained. The first part of the book gives an overview of XP: communication, simplicity, feedback, and courage. Then it goes more in depth about the role of the tester in an XP project and why XP projects need testers. In examining unit testing versus acceptance testing, the authors propose that acceptance tests are not as easy for developers to write as it breaks from their natural workflow. Since this book was written in 2002, this obviously predates Fit for Developing Software: Framework for Integrated Tests by Rick Mugridge and Ward Cunningham. But I do think that, in my experience, developers do not have the same testing focus as a dedicated tester, so, in general, I agree with the authors.

The second part of the book takes the reader on a test drive of an XP project. The authors start the road trip with the release planning and iteration planning phases and explain how the tester can facilitate. Giving real-world examples, I believe their ideas and suggestions can be very helpful, especially to the tester who has never worked with XP. The authors then go into great detail describing how acceptance tests should be developed and automated. Using JUnit as an example, the authors show how to quickly automate acceptance tests. Here the authors make the assertion that Java is easy to write. I'm sure this is just to encourage the tester to dive in, but if the tester is technically weak, I'm not sure that the examples would be easily digested. A technically weak tester would need to pair with a developer to overcome this. But overall, the presentation is good.

The last section of the book explains how to use these ideas in less than ideal XP situations. Ideas are given for collaborating and communicating in large or distributed environments that are very helpful. Also, the authors conclude that you can use these ideas to gradually ease a project into XP, or even just for the test organization on a waterfall project.

One slight nag I have about this book is that the example project that is given in the book is a web application called XTrack (similar to XPlanner) at xptester.org. The xptester.org website is now defunct, but it would have been neat to actually view the website while reading the book. Also Brian Marick's old testing.com website is referenced (this is now exampler.com). But such is the danger of print. It would be great if there was a second edition, but it looks like Lisa Crispin has moved on to co-authoring another book.

In reading this book, I have made notes of concepts that I would like to explore in the future and hopefully apply to my day-to-day work. Overall, I'd recommend this book to both new and experienced testers. I rate this book 9 out of 10.

In Untagged 
Comment (0) Read More...