Today's Big Picture


November 15, 2010  8:04 PM

Facebook Email

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

Facebook email – its out today. I listened to the live web cast. As a person who is involved in emerging technology I am very very curious and interested to see how it does.

What do I think about it? I don’t know I have an open mind to change and this is a change that was inevitable. Facebook started small and expanded to limits that no one would have guess a decade ago. SecondMarket(an online trading marketplace) published a report stating that Facebook is currently worth $41 billion. So it was just matter of time before they tapped into the email market which is what made google really big (193.3 million users).

Email (unnamed service – which is a very smart move to begin with) well its a term they want to redefine – one stop shop for email/messaging/chat. The founder Mark Zuckerberg calls this the “convergent modern messaging system.” Will this replace emails completely. No I don’t think so. People might be spectacle to move here completelybut am sure there are some who will jump into the wagon sooner than the others. Will this replace my yahoo, hotmail or GMail emails… well GMail replaced my yahoo and hotmail already. So it will have to be pretty big to make me completely change from GMail to facemail.

Anyone out there who has an invite, would love to hear from you and also wont mind getting an invite.

November 11, 2010  2:39 PM

The IT Files – Lisa Crispin – Part II

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

Part I

Name your favorite book on Agile?
I can’t pick one favorite agile book. I suppose I could say _XP Explained_ since that started it all for me. But there have been many great books since then.

Who is your hero?
Oh, this is an interesting question too! I have many heroes. But maybe my biggest heroes are my current team. Mike Cohn took over this team in 2003 and brought me in as a tester. I have learned so much working on this team for most of the past seven years, and I have been able to pass those experiences along to others. I have been on some other rockin’ teams in the past as well. My coworkers are my favorite heroes.

What do you do when you are not working?
My normal job is working as a tester on a really cool team. I spend a lot of my spare time writing, presenting and coaching, helping other people be successful with agile testing. But I still have time left for my avocations, such as driving my miniature donkeys, hiking with my husband and our dogs, gardening, and enjoying our travels.

What is a skill or strength that sets you apart from others?
I work in a ‘real job’ on a ‘real team’. We have successes and failures. I find ways to share those success (and failure) stories with other people, so they can make faster progress in their journey.

What (or who) inspires you?
My biggest inspirations come from the people I meet at conferences, and via Twitter. Every day someone tweets at least one link to a blog post that really makes me think, that inspires me to try something new or different. I’ve been able to take a lot of great ideas back to my team and we’ve implemented some of them to good effect.

Question from our reader Tom

“…agile teams…” — Should the “team” itself be ‘agile’? How do you know who should be on a team? How does having a pool of developers from which a team can be constructed differ from just having a fixed set of developers? How do those two scenarios change any relationships with testers being made part of the “team”?
I’m struggling with the context for this question. In my experience, it works best to have a team together for at least the life of a project or epic. The team needs to include whomever it needs for that project or product – programmers, testers, BAs, DBAs, sys admins, visual designers, UX experts, performance test experts, whatever. The self-organizing team frequently does retrospectives to see how they are doing and whether they might be missing a particular role or skill set, and decide how to solve that – with more training, with hiring someone else, whatever.

I prefer to have testers integrated into development team (by the way, we are all ‘developers’, not only the programmers). There are cases where it makes sense to have a separate test team, such as for testing embedded software, but the testers should still collaborate closely with the development team throughout each iteration and release.


November 11, 2010  11:01 AM

The IT Files – Lisa Crispin – Part I

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

An agile testing coach and practitioner, Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), and a
contributor to Beautiful Testing (O’Reilly, 2009) and Testen in der Finanzwelt (2009). She also co-wrote Testing Extreme Programming (Addison-Wesley, 2002) with Tip House. Lisa specializes in
showing agile teams how testers can add value and guide development with business-facing tests. For the past ten years, Lisa has worked as a tester on agile teams developing web applications in
Java and .Net. She teaches Agile Testing courses and tutorials worldwide. Lisa regularly contributes articles to publications such as Better Software magazine, Software Test &
Performance Maazine, IEEE Software Magazine, Methods & Tools, Agile Journal, Agile Record, She enjoys sharing her experiences at conferences and user group meetings around the world. Lisa
was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisa’s work, visit
www.lisacrispin.com.

What is your definition of Agile (how would you explain it to someone who doesn’t know what agile is)?
I like Elisabeth Hendrickson’s definition of agile. I’m paraphrasing here, but it goes like this: Delivering value to the business frequently (production-ready code delivered at least once a month) while maintaining a sustainable pace. The sustainable pace won’t happen without good practices such as TDD, ATDD, refactoring, pairing, feedback, all the things that keep technical debt at a manageable level. Software projects succeed when they are done by good people who are allowed to do their best work.

Any advice for new agile adopters?
The company needs to decide what their commitment to quality is, and what it means. If management wants the development team to deliver the highest possible quality code, they will have to make an investment. They will have to get the right people, give them time to learn and experiment, and tolerate mistakes – we can’t improve if we’re afraid of making mistakes. Understand that this is mostly a cultural change: everyone has to learn to work in a new way and get out of their comfort zone. It’s easy to teach a new process, but really tough to teach a new culture.

Quality – what is your definition or understanding?
In XP Explained (1999), Kent Beck talked about two kinds of quality: Internal and external. Internal quality belongs to the development team. We do test-driven development and use refactoring and other clean code practices to produce robust, maintainable code and keep technical debt low. The business cannot interfere with that. External quality belongs to the customers. They decide what business value they want from each feature or user story, and articulate that with examples that can be turned into tests that help the development team understand their quality needs. The business may decide to trade off some quality for other business priorities, such as speed. This means reducing focus or removing functionality – not hacking quick fixes unsupported by tests into the code.
 
Both kinds of quality depend on a real business commitment to quality. The business must value quality over speed and quantity, and make investments that may slow team velocity in the short term, but allow it to succeed over the long term. If the business is not on board, the development organization will not be able to deliver a quality product.

What are some lessons you have learned about agile that you wish you had known long ago or you wish someone had told you about?
Number one is the importance of learning the business, even the parts of the business that are outside of what is automated by the software. When my current team had been doing agile development successfully for three years, we felt we had good code architecture and design, a team commitment to quality that really meant something, mastery of practices such as TDD and ATDD. Yet there were still issues in production – not technically bugs, but problems that required attention. We divided up the business and each of us took a different part to learn well and teach to the rest of the team. Understanding all aspects of the business at a deeper level helped us help our customers and cut down significantly on “production support requests”.

Did you adopt agile or did agile adopt you?
Nice question! In the web start-up era, I was frustrated that no matter how disciplined we were with our waterfall process, we couldn’t get features out fast enough to stay ahead of the competition. Some coworkers who went to found their own startup gave me Kent Beck’s _XP Explained_ to read. It was a revelation – all about quality! What if the whole development team cared about quality, and testing were not a separate phase? I had to join this XP team and try it.

Link to Part II


November 8, 2010  3:25 PM

All Hands on Deck

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

something that you say when everyone’s help is needed, especially to do a lot of work in a short amount of time

Every once in a while in our company.. we get everyone to come test for us. We include developers, business analysts, other product testers, support and marketing people, etc. We call it our party day, set up a training room, get lots of food, have lucky draws and prizes. Its a party day for testing. You come in, test any area of the products and log defects.

This helps with

  1. Getting everyone in the organization an opportunity to know the product.
  2. Get people involved in doing things that are not planned or scripted. We give them description of the role they want to use and let them free. They can explore and create their own tests. When they find a defect they have to document the steps to recreate it.
  3. Give other team members an opportunity to understand what we testers do on a day to day basis.
  4. Helps with cross training other team members on our product so when there is a crisis and we want all hands on deck we can approach these team members.
  5. Give support line, marketing, help desk people to try things they hear customers are having issues with and help them log those issues, so testing can keep an eye on those features or areas when doing regular testing.
  6. Able to log defects in areas that testers may not usually get a lot of time testing or play with.
  7. Give testers a chance to observe and learn from other team members.
  8. Helps with team building.
  9. Everyone has fun and it really helps to take a break once in a while.

So for us all hands on deck is really a fun day to experiment and innovate.

What do you do in your organization that is different and has helped your test team?


November 8, 2010  8:55 AM

Make Testing Fun Again

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

I recently read a twitter update from Marcus Buckingham “Sure, we need rules, but remember that every rule removes a choice, & choice is the fuel for learning“.

This really made me think of the testing state in a lot of organizations, especially big ones. Test leads and testers have to work within the processes, expectation and reporting hierarchy that they loose the essence of true testing. They spend more time documenting and following processes (covering their back) than they spend on testing, testing innovation or even learning new things. Yes its true we have to have some forms of processes to adhere to but for some testers to perform to their full capacity there has to be freedom to learn, experiment, to adapt, to change, etc.

Some issues that prevent this growth

  1. Lack of time – testers don’t get a lot of time to experiment, learn, even play with their products per say. 
  2. Focus of testing status – how many test cases, how much did you do, where are you? These questions cannot be answered if you take a day to explore or experiment. I think testers get caught in the I have to keep up with things we have to do.
  3. Contracting/consultants – Its hard when you are not part of the organization and have no input in processes. You work hourly and are forced to perform within the job description. Its harder to get your inputs into testing processes and decisions.

What can you do?

  1. Never loose an opportunity to learn, always seek knowledge be it by learning on your own, reading books or working with more experienced team members.
  2. Collaboration – team up with other team members like SEs or BSA and learn their processes. Understand their view of the project and ask them for suggestions to improve testing.
  3. Fun “testing” time – take a few hours every month (say an hr every Friday or come in early once a week) and use this time for applying new processes to testing, do ad-hoc testing, explore.
  4. Switch Roles – Once a month ask your team members if they would switch roles with you for an hour or two and ask each other questions using the role that you are playing.
  5. Have fun – dont make your job a routine. Mix things up once in a while.


November 3, 2010  2:27 PM

The IT Files – Lisa Crispin

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

I will be talking to Lisa Crispin in the next couple of days. Please post any questions you have for her at the following link

http://itknowledgeexchange.techtarget.com/itanswers/what-questions-do-you-have-for-agile-expert-lisa-crispin-100-point-bounty/

Here is some information about Lisa

An agile testing coach and practitioner, Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), and a contributor to Beautiful Testing (O’Reilly, 2009) and Testen in der Finanzwelt (2009). She also co-wrote Testing Extreme Programming (Addison-Wesley, 2002) with Tip House. Lisa specializes in showing agile teams how testers can add value and guide development with business-facing tests. For the past ten years, Lisa has worked as a tester on agile teams developing web applications in Java and .Net. She teaches Agile Testing courses and tutorials worldwide. Lisa regularly contributes articles to publications such as Better Software magazine, Software Test & Performance Magazine, IEEE Software Magazine, Methods & Tools, Agile Journal, Agile Record, She enjoys sharing her experiences at conferences and user group meetings around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisa’s work, visit www.lisacrispin.com.


October 29, 2010  12:24 PM

The IT Files – James Christie – Part II

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

Part I

 

What are some lessons you have learned about testing that you wish you had known long ago or you wish someone had told you about?
That’s a very interesting question. I was reflecting on that point a few months ago.
I think the big two are about scripted testing and the requirements.
I was young and inexperienced I was sceptical about the amount of effort that scripted testing required, and whether it was the best use of testers’ time. I was also concerned about the length of time that it took to document the requirements for large, complex applications. So much time and effort went into documenting everything in precise detail that there seemed an obvious danger that the business would change faster than we could build applications.
However, I was happy to defer to the experience of the grizzled professionals. I suppressed my doubts and got on with it. Only much later did I realise that my doubts had been valid.
I wrote about this very subject on my blog a few months ago; “I wish I’d known I was right”. This is all related to what I was saying in part 1 of this interview about Agile being much more in tune with the natural, default way to develop software than the heavyweight traditional methodologies, which cut against the grain.
http://clarotesting.wordpress.com/2010/05/13/i-wish-id-known-i-was-right/

What are some tools you have used for test management? Which one is your favorite?
Ugh! My favourite test management tool? That’s like asking me what my favourite headache has been.
I’ve used Quality Center (Test Director) and Trac Notes (the Lotus Notes tool that we had to use in IBM). Frankly, I didn’t care much for either of them, and didn’t feel they helped me manage the testing. They helped me produce reports that I didn’t need, but which my managers and the stakeholders required. I suspect that these reports were only demanded because they were available, and I hated the way we could be forced to structure the testing to suit the reporting.
If the tools hadn’t been available I’d have quite happily used spreadsheets (Excel, 123, Open Office Calc or whatever). On balance I’ve found test management tools more of a nuisance than an aid.

Automate or not – which side do you lean towards?
That’s like asking which side of the road I lean towards when I’m driving! In the UK, it’s the left hand side – no question. In the rest of Europe, I always go for the right hand side.
That’s a bit flippant, but there’s some truth in it. It all depends what the problem is, and what the environment is. If there’s an advantage to automation then I’m in favour. I’m wary of people who’re too enthusiastic. They remind me of Maslow’s hammer; “it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Perhaps this variant is even more relevant; if you give a little boy a hammer he’ll find that everything he sees needs pounding.
Having said all that, I do like automated routines which can detect problems in testing and production. You can get all philosophical about this and debate whether these are test routines, automated controls, or just part of the core application. However, I did once take part in a very heated debate about whether we should put these into an application. I was over-ruled on the twin grounds that I was a tester, and shouldn’t be telling the developers what to do, and secondly no-one should write any code that didn’t flow from the requirements.
I thought that stance was really a bit dumb. On the first day we went live there was a problem with a batch job that would have been detected if I’d won the argument. A customer’s insurance policy had dropped into a black hole. It had been input, but not output. It had effectively been deleted from the master file. Instead of the problem being quickly fixed before it affected the customer, the company found out only when the customer complained. It was embarrassing, predictable and easily avoidable. But the users hadn’t specified the requirement; “whatever you do, don’t do anything as utterly stupid as losing a customer’s policy”. That went without saying, so it wasn’t said, so it wasn’t implemented.

What do you do when you are not testing?
I write football (soccer) reports for the Dundee FC website. I go to all of the home games, and most of the away matches. I then write up the report straight afterwards and get it online, mainly for the supporters who couldn’t get to the game, but also for people who were there and want to read and talk about it. I really enjoy that. It’s good fun, and it’s great to be able to write something and get immediate feedback. Normally if I write an article it’s weeks before I get feedback, so I like being able to start and finish something, then get feedback, all within a few hours.
I’m also very involved with my wife, Mary, in our church. I’m quite lucky because there’s no end of things I enjoy doing or reading about. I love travelling, cycling, walking and being in the country. I can’t remember the last time I was bored because I didn’t have anything interesting to do. When was the last time I was frustrated because there’s not enough time to do everything I want? That was today – same as every day!
If I stopped being a tester tomorrow I’d be able to fill my time quite easily. I want to write a book, but it’s not about testing. It would be about football.

What or who inspires you the most?
The quick and easy answer is my faith, which underpins much of what I do and what I am. I know I’m nowhere near perfect, but believe I’m better than I would have been without it. Also, my wife is a constant, quiet inspiration to me to do and to be better. She’s so much more patient and understanding than I deserve, and that helps spur me on. I’m also inspired by the previous generations who worked so hard and sacrificed so much to give me and my generation the freedom and prosperity that they dreamed of. In particular, that applies to my parents.

From our readers
a.      I would like to know if there are any open source tools for automated testing of desktop applications (not web). I manage a small group of developers and we are not doing automated testing by now, so any recommendation is welcome.
b.      Are there any good automated testing tools for the AS300? Especially something for regression testing of batch jobs.
Sorry, this is an area I’m weak in. Maybe you should try starting a discussion on the Software Testing Club, http://www.softwaretestingclub.com/?


October 28, 2010  2:00 PM

The IT Files – James Christie – Part I

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

The first person to be interviewed for “The IT Files” is James Christie from Scotland. He is a freelance Software Tester and has more than 24 years of commercial experience ranging from test management, information security management, project management, IT audits, systems analysis to programming. To know more about him and his work please visit http://clarotesting.com/index.htm.
James is currently working as a freelance consultant through his own limited company, Claro Testing Ltd. In 2007 he successfully completed a full-time MSc in IT at the University of Abertay. His master’s project and dissertation, for which he received an A grade, was “Integrating usability testing with formal software testing models”. He is particularly interested in how the quality of applications can be improved by incorporating usability engineering and testing techniques.

What were some differences you found between consulting (freelance) and working for other companies?
There are so many, though perhaps the biggest difference is between different types of freelance work. I don’t think freelance is a synonym for consulting.
I’ve worked as a freelance test manager, and that’s not much different from being a permanent test manager. Sure, the money is better and there’s no security, but the work itself is very similar. One significant difference is that a freelancer has less influence. They are brought in to do a specific job, on a certain project, and there’s little interest in hearing their ideas about how the world could be a better place.
A permanent employee will probably be around for the next few years. Their career and their future are hitched to the company. They’ve got skin in the game, and they will be listened to. A freelancer might offer ideas that others will pick up on, but if any action is taken it would be an entirely different project, and contract, and it’s quite likely that it will be others who get the work, particularly a specialist consultancy.
The freelance test manager has been hired simply because there are not enough internal bodies to do the work. The company already knows what they want, and how they want to do it.
However, permanent employees can also get frustrated at their lack of influence. Sometimes companies underestimate the talent and initiative of their employees. They don’t have enough confidence in them.
Often companies take on board criticisms and recommendation from expensive consultants, unaware that their staff have been saying the same things. Consultants know that. Part of the job is going round speaking to people trying to spot the ones that have had the crucial insights about what’s going wrong. Cynics say that this is just plundering the bright ideas that the company could have had for free – but the point is that the client has missed the opportunities, and the consultant is forcing them to focus on what was in full view, but invisible to them.
So the best place to have influence is to be a genuine consultant, not just a freelancer. I enjoy that. The money’s not nearly as good as freelancing. The rates might be great, but the work is almost inevitably patchy. You have to be prepared to go for uncomfortably long spells without being able to bill anyone, and you have to accept that sometimes you’re going to have a great idea ,and your client will decide to implement it themselves, on the cheap, rather than give you the work. Don’t go for consultancy just for the money!

What is one of your favorite books on Software Development or Software Testing?
I’m going to mention three books that I’ve found very helpful. Weinberg’s book is a great introduction, and refresher, to help ensure people “get” testing. The Poppendieck’s book provides a very readable analysis of what’s gone wrong over the years with software development, and Cooper helped me to look at software and the development process in a different way. I’m not sure about all of his detailed recommendations, and some of his criticisms were a bit emotive, but basically he was on the money.

Gerald Weinberg, “Perfect Software and Other Illusions”.
http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692/ref=sr_1_1?ie=UTF8&qid=1288276662&sr=1-1
Mary and Tom Poppendieck, “Leading Lean Software Development: Results are not the Point”.
http://www.amazon.co.uk/Leading-Lean-Software-Development-Addison-Wesley/dp/0321620704/ref=sr_1_4?ie=UTF8&qid=1288276524&sr=8-4
Alan Cooper, “The Inmates are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity”.
http://www.amazon.co.uk/Inmates-are-Running-Asylum-High-tech/dp/0672326140/ref=tmm_pap_title_0?ie=UTF8&qid=1288276560&sr=1-1

What is a skill or strength that sets you apart from other testers?
That’s the sort of question I find hard to answer. It’s easiest to refer to what other people have said about me. When I worked for IBM, I was chatting to the programme manager over a beer at the end of a project about what the future held in store for us. He said that I was a rebel, an iconoclast and that I was prepared to challenge existing practices, sometimes forcefully. We got on very well, and in the context of the successful project we’d been working on it was clearly a compliment. However, he wasn’t sure it was a quality that would give me a happy long term future in a big corporation.
More recently another consultant with whom I’ve been working said he liked working with me because I’m “an ideas man”. He thinks I come up with bright ideas that wouldn’t have occurred to others.
Being a bit of a rebel, and having the reputation for being an ideas man are great assets for a consultant, so I guess these are the strengths I need to emphasise when I’m trying to sell myself.

Cloud is the buzz word in the software development industry. Are you in the cloud yet?
No, definitely not, but it’s a fascinating development. To be honest, I’ve not seen any evidence yet of it taking off, but I’ve probably just been mixing in the wrong circles. I’m sure it will be huge.

For people who don’t know Agile, how would you define it for them?
This isn’t a definition, just a helpful way of understanding what Agile means.
Agile is a return to the natural way for developers to build systems. It’s a way that works, because it fits the inclinations and abilities of developers, and it fits the technology. If developers haven’t been indoctrinated in traditional techniques and heavyweight, document-driven methodologies, then their instinctive approach will be multiple, relatively small scale iterations.
It was a tragedy for the software development profession that they headed down the Waterfall, structured techniques route, assuming that building an application was essentially the same as building a bridge. if it wasn’t, then it had to be mutated into a form more like construction engineering.
Recently I had an informal chat about Agile with a senior development manager with a large IT services company. He said that most of the big clients he came across were still wedded to the Waterfall. I said, “it’s easier to manage the contractual relationship, isn’t it?”. He said “that’s it exactly”.
Basically, the whole profession went down a route for decades that was dictated by the needs of lawyers, accountants and contract managers. They’ve all got important inputs, but it was an appalling, fundamental mistake to pay attention only to them and ignore the realities of software development.
Quality was sacrificed on the altar of predictability. I believe strongly that compromises and trade-offs are often necessary. You don’t always get what you want, and smart managers have to be able to manage those trade-offs intelligently. You have to be honest and objective in admitting that you’re making these compromises. The great sin of software development for a generation was to pretend that these compromises weren’t there. As a result, they usually got neither quality nor predictability. For far too long the answer was to assume that they’d been unlucky, or (worst of all) people had just screwed up, and it would be ok next time. It’s a pity it took 30 plus years for the penny to drop.

Part II


October 27, 2010  7:10 PM

Marching Towards Crunch Time

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

Every tester has had to deal with crunch time during the test phase. Testing is always towards the end of the development cycle and invariably something goes wrong upstream that causes the testing crunch at the end. There could be various reasons for this crunch time: Budget cuts, scope creep, hitting the dates, uphill deliverable dates slipped, etc.

It is important to be prepared when marching towards this crunch time.

  1. When you have down time in the beginning, take it as down time. No matter how fast testers get their analysis done, test cases written there are chances things will change again. So don’t feel guilty in taking the down time. But the other side to this is that when its crunch you have to give it all. You will have to make up the time to get the work done. Its give and take policy that you can discuss with your project manager or team manager. What counts the most is getting what needs to be done to get the product out the door. We can sit and complain but if the product does not go out the door, then we have failed as a team including the testers. So we can complain about it or plan it ahead to balance work.
  2.  When estimating, plan some buffer time that can be used in the end when there is time crunch. You can do this hidden (don’t share with your project team – beef up estimates 10%) or you can let the team know what you are doing. This is not the best way but if you have been burned in the past then this could be something that you can discuss with your manager or department head and get a buy in from them.
  3. Cross train people in different projects. So if you have tester colleagues who are working on other projects, you can train them on your project and you can get trained in theirs. So during crunch time you can use their help and vice verse.
  4. Constantly go over the list of changes that are being planned in the release. See if there are areas/features that are being heavily affected. Plan more testing in those areas. During your downtime clean up regression test cases for those areas so you can have good test cases that anyone from your project can execute. You can use your cross trained colleagues or other resources (BSA or SE) from your project to help with testing those areas. This way you know your test cases well (since you reviewed and updated them) and you know exactly what they are doing when testing.
  5. Risk Ranking everything including regression test cases will help. Communicate this to your team and let them know as the time is crunched, you will be taking things out of the list that have lower priorities (less risky areas). Use different colors to show things that will absolutely have to be executed and things you can compromise on. Get a buy in early on from the team and management.

Its easy to stress about crunch time since we know its coming or we can go into the war fully prepared.


October 25, 2010  10:36 AM

The IT Files – Chat with James Christie

Shilpa Venkateshwaran Shilpa Venkateshwaran Profile: Shilpa Venkateshwaran

The IT Files
 
I will be starting The IT Files series which will present one-on-one conversations and interviews with Information Technology Professionals. These conversations will be informal chats on topics ranging from industry practices, job market, career development, skills to emerging trends. We would like to extend an opportunity to our readers to ask questions in the forum here that we can use for the interview. Please post your questions here and a chance to get points.
The first person to be interviewed for “The IT Files” is James Christie from Scotland. He is a freelance Software Tester and has more than 24 years of commercial experience ranging from test management, information security management, project management, IT audits, systems analysis to programming. To know more about him and his work please visit http://clarotesting.com/index.htm.
James is currently working as a freelance consultant through his own limited company, Claro Testing Ltd. In 2007 he successfully completed a full-time MSc in IT at the University of Abertay. His master’s project and dissertation, for which he received an A grade, was “Integrating usability testing with formal software testing models”. He is particularly interested in how the quality of applications can be improved by incorporating usability engineering and testing techniques.
James has 25 years commercial IT experience, covering test management (the full life-cycle from agreeing the strategy and budget, writing the test plans, supervising execution, through to implementation) and test consultancy (writing and reviewing testing processes). His experience also covers information security management, project management, IT audit, systems analysis and programming. This has been largely in financial services, mainly with General Accident and IBM (working with a range of blue-chip clients).
James is keen to use testing models that move beyond the traditional V Model. See his website (www.clarotesting.com/page7.htm) for more information.
James left IBM when he had the chance to take voluntary redundancy which allowed him to pursue his ambition to take a Masters degree.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: