| || |
After almost two years out of work I finally landed a job as a QA Engineer at a company in the IT support department. I've been doing testing for years and am familiar with the SDLC and QA process improvement. I'm the first official tester in the department. After being there 3 weeks now I had a talk with my boss to find out how I was progressing. I found out that she had to talk her boss, a former programmer, into creating this position - Quality Engineer. She needs to show that the position has improved the department in 3 months time. Their documentation is sorely lacking, they don't do code reviews, design reviews, requirements reviews, test case reviews or any other early defect detection. The real kicker is that she thinks that a new format of a test plan can be created that can be used for any project, any environment, any programming language, and there won't be a need for detailed test cases on each project. You just plug some scenarios into this new format of a document and the people doing the testing, the Tech support people, will catch defects from the slimmed down version of a testplan/testcase document. She said when she interviewed the different prospects, the recurring theme was that this was possible. I've never heard of such a thing. But I have a feeling that if I can't do this, she's planning on letting me go. She doesn't want me spending time writing detailed test cases for every project from the requirements and she doesn't want her support analysts to spend time writing detailed test cases either.
I think the problem is that she thinks QA and testing synonymous. If she used the term QA when meaning testing, then sure, everyone she talked to would say yes, a QA plan can be put in place that could be applied to any project, regardless of the application or coding language. But I'm at a loss to understand how test plans could be so generalized that they could apply across the board and you'd just add scenarios without rigorous, detailed test cases. I don't see how it would be possible without giving up thoroughness. She's expecting me to develop this so she can show it to her boss and justify the position - or I could be out of there at the end of 3 months.
Has anyone ever heard of such a thing?
Re: Testing shortcuts
The 'projects' which she mentions, are they similar in nature ?
It is very difficult to imagine such a generic test plan which can work across different versions let alone different applications.
A lot if companies with immature/non-existent QA processes have the notion that QA and testing are one and the same.
I am assuming you are a contractor: the expectation is you create a magical document which can be used by less skilled people to catch defects. I would think you would be let go even if you do create this magical document which she expects.
I feel sorry for your situation. If i were you, i would do as much as possible to create a super generic test plan like test printing, certain reports, logging into the application (security) etc. Keep looking for other jobs my friend.
Re: Testing shortcuts
I agree to qasleuth. What She is looking for is to create Document, which can work for any project..
Well, I will suggest you to not loose the ground. Create a document which covers issues like, open , Save, print, sharing, sercurity, web releated issues, legacy doc support, Import and export (this can we the wide area..)
You should do hard to make such thing.. It could be innovative doc.. But without keeping expectation keep looking for new job.
Re: Testing shortcuts
From my view, the documents that you guys are talking about are test cases. They deal with the functionality that is being tested.
If you are talking a true test plan (or maybe you call it a test strategy), yes, that can be a very generic document that can apply to all projects. However, a test plan or test strategy by itself is not useful for catching defects. You need the next level document that you guys are talking about - test cases - and really, that is not enough either. You need the detailed test scripts to really catch the defects.
The test plan or strategy will contain the basic idea of who, what, where, when and why, but not the how.
"Purpose of testing is to catch defects as early in the development cycle as possible, so as to minimize cost of rework. We need 3 testers. We will do unit testing, followed by integration and functional testing. Then performance testing followed by user acceptance testing. Follow-on tests will not be conducted until previous tests have met defined exit criteria for that phase."
This type of document can be generic for any development project.
I don't think that is the document that the manager has in mind, but it IS what she asked for. This is a case of her not knowing what it is she really asked for.
Re: Testing shortcuts
A test plan can be a generic document. The terminology varies from company to company, but test plans normally contain information regarding the infrastructure of the project, such as defect tracking, severity levels, completion criteria, etc., with links to the "meat" of the test effort (test cases, test data, etc.). Infrastructure often doesn't change much from project to project.
You can also develop a minimal-level test case template (this may be what she's looking for) with examples. You can, if your environment is lacking in structure, also perform testing from structured outlines. This works well in dynamic, iterative, or XP type of environments and uses a modified form of exploratory testing technique. The structured outline contains a descriptive, organized, hierarchical "list" of each test to be run. The actual test cases and tests run can be fleshed out during the tests themselves, or the outlines can be left as is.
Several test tools lend themselves nicely to this kind of effort, if you're in a position to either have them or acquire them. Compuware, Mercury, and Rational all include a "Director" type of tool that will store outlines in nice, organized repositories. They also include defect management tools. You don't have to have automated tools, but it will make your life easier; otherwise, you'll have to come up with repsitories, templates, defect management processes, naming conventions, etc. yourself.
In my experience, particularly since they've had nothing in the past, there are a few things you can do that will prove improvement within a short timeframe.
First, organize the tests and centrally locate them somewhere using some kind of intelligent organization scheme. It doesn't matter what format the tests are in, as long as whatever you use is consistent.
Second, set up a defect management process to use during the testing. Organize and report on problems in whatever way is of most benefit to both development and management staff.
Third, figure out a non-emotional, standard way to report testing progress.
If you appear organized, in control, and provide information the staff has not had in the past, you are going to be regarded as a "star". As they've had nothing previously, you just need to tell yourself that everything you provide will be better than what they've had - and that will be true. Chances are that everything you do is going to look better than what they've had.
I think you can be successful with this - you have the experience - best of luck!