Hmm. The live your product is right on. I am very dubious of the "really focus on your test plan" -- I would actually put "really focus on integrating the testers with the development team" -- go Agile! Having an integrated test group help to drive a fully functional team that will have ownership of the features they develop. Having a fosters an us versus them mentality.
I'd be interested in seeing what you consider a useful test plan. Most examples I've read on the web (aka the first few pages of search results) consist of what I would consider heavy, even bloated, process documents.For a small agile team (~10 devs) and 1-3 testers, a plan like this would be more hindrance than help. What would you consider the most important aspects of a test plan that would be applicable for a small team?
What is being testedWhat is not being testedRisksGaps
What would you consider examples of Risks and Gaps, if you are not sure the developers disclosed all of the details of a new feature?
Excellent posting... as a Test Manager, I am always advocating understanding the purpose of the end deliverable. WHY you are building what you are building, and then testing whatever it may be. For many in conventional test roles, this approach seems a challenge to grasp, more are concerned with unit type testing versus a full understanding of what a piece of code is intended to accomplish. Product awareness is important no matter the role, or the product. In a previous life I was employed in a financial capacity for a Tier 1 auto supplier. Leadership mandated all employees attend a product awareness training event. Not only to give thanks for the product your company builds (said tongue in cheek), but also to understand how everyone's daily work activity contributes to the end product.great post, looking forward to more...
Get your Communication methods and channels going immediately. As a manager you will interact with many different people from all parts of the company, including your own staff. Get to know your audience and how best to communicate with them. Also, work on being a better 'listener' and when and when not to voice your response/opinion.A management position is a lot of "business" and "politics" so get used to being in that mindset. Don't be a "political player", but understand that you will be dealing with this everyday.
"understand it's competitive advantages" -> "understand its competitive advantages""IT'S" ALWAYS MEANS "IT IS"
First, it's great that you are asking for help. That shows that you want to learn from others and that's something you want to model for the people who now report to you.James is right - definitely learn and live the product. But for my money, two other Ps are just as important: people and process. Yours is a company of people. They make the enterprise tick. They come to the table with strengths and weaknesses; competencies and doubts. Work to help everyone you contact (your customers, contributors, C-types, contractors). We test mgrs are uniquely positioned to influence the nature and direction of our companys' culture. Have fun, expect the best, listen, and be supportive.On the process front: Examine/Witness how things work - where value is created and where time seems to disappear. But don't try to fix everything a) at once or b) alone. Attempting to change too much results in process shock and regression. On the other hand, you do want to do something positive and visible in the first couple weeks. That will set the tone for your process improvement efforts. Engage others, forge alliances, and remain positive and calm.Note: This is only one person's opinion but it comes from several years as a QA mgr and three decades in the software biz.Good luck. Enjoy the ride.Regards, Ian Savage
Two months back I wrote a blog post on Key practices for test managers here: http://blog.shino.de/2009/10/27/key-practices-for-software-test-managers/I quite can't agree to some of the statements you made regarding test cases, test plans and design documents. The Swedish Army has a saying:"If the map and the territory disagree, always trust the territory."This means that the code is the final design of the software, and should really not be confused with the design document, which describe the state of thought at maybe a different time. The same goes with requirements, and all the other documentation we have.
What's about the testing team and their competence ? I think this is an important factor to consider too.
Leverage your people - look for opportunities and techniques to make one person-day worth five or more. Automated testing is the canonical example. It can be expensive to construct automated tests, and lots of QA testers don't have the skills to do so. But they are an excellent "force multiplier" if it becomes possible to run the test more often or if the test can be run for at least three QA cycles without change.Unattended testing is usually harder than automated testing, but the payoff is even greater. Take the nightly build that your development team does and that passes their unit tests and subject it to your user- and functionality-focused automated tests. I guarantee you'll occasionally find important failures, and you'll find them while the code in question is still fresh in the developers' minds.
Bug clusters are your friend. Get more bug for your management's buck.See my Google tech talk "Building Software Smarter" for morehttp://www.tinyurl.com/80-20-rulescheers,Erik Petersen
Hi, My name is Gil Zilberfld. We’ve discussed your post on our webcast “This week in testing”. We’ll be happy if you can comment, and if you like the discussion and content, let us know. And everyone else. Thanks, Gil Zilberfeld Typemock
Awesome, thanks Mr.Whittaker. I think we unconsciously realise that these are the bits to focus on, but never really focus in putting those thoughts to paper, so it's great to see this documented.
Network with other test professionals! I wrote an essay about this titled From Zero to Hero - Networking for QA Expertise: http://www.yvettefrancino.com/networking-for-qa-expertise.html
Besides living with your product and being passionate, how about "live" with your team. As a new manager I tried to understand my team, leverage what each person brings, grow, and evolve the team. Processes, products, tools, and techniques are necessary, but software is intellectual creation and testing software is even harder intellectually, so I had know the team and my customers/users as part of my "test team".
Test plan is only as good as the paper it's printed on. I've worked with some managers who were unable to deviate beyond their test plan or spent their entire work day updating test plans that no one ever used.Test plans are the final refuge of the incapable.
Lovely blog. I've just been nominate "QA Manager By Default," and my first step was to put my money where my mouth is: I started with communication and organization among the QA team, because those were the biggest complaints I had before landing here. A large part of that communication involves my "real" job - updating the existing technical and UA documents and creating the new ones made necessary by the enormous development effort over the last year.@Ian -Our QA team wants to know very basic information: Who will perform the tests, What needs to be tested, How to report results, and Where can they find the necessary resources. That forms the framework for our test plan, and the details (the pass/fail criteria of the features tested) are filled in as we go. As the Business Analyst/Technical writer in our small, attempting-to-be agile shop, I work closely with the entire development group and borrow resources from technical support for the QA effort. Current test assignments are based on the work items and change requests in the build to be tested. Development is also doing their part by implementing Unit testing as part of the development process and updating their work item descriptions as they go (best thing ever! for making my documentation duties easier).
nice blog i have an advice too be innovative to prove your self worth full in organization and bring some thing called innovation in organization time to time . I mean to say present new ideas new practices that are not followed in your organization under previous manager like lets automation , Load performance test you will find so many things that you can introduce this would increase your team importance.
The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.