:: HOME :: GET EMAIL UPDATES :: The Story Board :: susurration :: Reenie :: randomthoughts :: outtamyhead :: Electric Grandmother :: heyelsa :: rhubarb :: Brownie :: Scout :: Starting Over :: Recent JS Users Entries :: Scan :: Twitter-Stalk Me :: ">Meebo Me :: LiveJournal Me :: WordPress me :: FaceBook Me :: EMAIL :: | |
2007-07-24 1:00 AM Thankye Read/Post Comments (3) |
Thank you all very much for the hugs and encouragement. Today was worse, much worse. I was ready to tear someones head off. No one in particular, just stressed in general. Too much stuff to do, not enough time to do it. The usual, just like everyone else.
Testing is an interesting art form. It's more than just, 'Let's see what breaks.' That's a key component, but not the only one. Like just about everything else with computers, it takes a good deal of planning before you start doing. (Or, you can dive right in, but you'll likely end up redoing it.) For me, for this part, I define who my customer is. It may or may not be the non-technical user of the software. For this product, my area is more sys-administration-like, so my primary customer will be the people who have to maintain the system and support the non-technical users. Secondly, I have to define what is in my 'problem domain' and what is not. I cannot test the whole software from every angle. I lack the expertise, the time, the tools, the resources. I'm just a single person, with a single feature or function to test. Now, the job of the test manager is to make sure every part of the software is tested enough. "Enough" is a tricky word. It's all about RoI, return on investment. If a piece of software hasn't changed, then it should work as before. However, if it takes input from a new or changed component, then ... At any rate, my third step would be to list the specific areas I'll test. This component. That action. A given scenario. A list of things not covered. Some may be obvious, so much so they're not listed. Hardware, for example. Mine is a software product, so hardware is out of scope. (Problem domain, again.) However, mine is a system administration feature, so if hardware fails, it may need to notify or log the failure. Specific area. Other steps include writing a test plan, then having other stakeholders review the plan. This includes the developers, the program managers, the security gurus, etc. We should all agree on what's subject to test, why and who thoroughly. After all this, then I get to devise the specific tests. That's where I am now, in this cycle. Unfortunately, that's where I should have been a fortnight ago. Yes, I'm tired. I'm off to bed now. Thank you all for reading and posting comments. Read/Post Comments (3) Previous Entry :: Next Entry Back to Top |
:: HOME :: GET EMAIL UPDATES :: The Story Board :: susurration :: Reenie :: randomthoughts :: outtamyhead :: Electric Grandmother :: heyelsa :: rhubarb :: Brownie :: Scout :: Starting Over :: Recent JS Users Entries :: Scan :: Twitter-Stalk Me :: ">Meebo Me :: LiveJournal Me :: WordPress me :: FaceBook Me :: EMAIL :: |
© 2001-2010 JournalScape.com. All rights reserved. All content rights reserved by the author. custsupport@journalscape.com |