Are you an aspiring Test Lead or Test Manager? Are you ready for transition from test engineer to lead or Lear to a Manager? Here we explain how to set up good testing step by step. You will not find a lot of theory here, only a practical introduction on how to perform good functional testing. You can consider it as a Checklist or Guidelines set. These are the points to take care while planning the test project.
Planning
We are now at the very beginning of the software project. Someone has decided this project has to be started, so why should you wait to get started? Because you’re a tester, you still have lots of time? If you start at the end of the software life cycle, you’ll be in trouble. There’s a lot you can do. Start now!
Method
Make a decision on what testing method you are going to use
Tools
– What test management tool?
– Which Defect tracking tool are you going to use?
– What performance tool?
– Do you need more study on these tools, contact people?
– How and when will performance testing be performed?
– Need to customize the tools?
– Authorizations for these tools?
Test room/ Materials
– Test room?
– PC’s available?
– What software is needed on the testers PC’s?
Test environment
– Is there a separate environment for testing purposes only?
– Who can give authorization on it for your testers?
– Are all parts of the production environment available in the test environment? If not, how to resolve?
– Set up a directory per project for testing and define who has read/write rights / read only rights
Prepare demo’s
– Explain the basics of software testing to project players and testers
– Explain Project View (helicopter view) and other test level views
– Explain why you want the testers to do test preparation sessions before development
– Explain the Golden Rules for Bug reporting
– Explain for every level of testing what you want from the testers
– Explain IT why you want them to perform good testing
– Explain how testers are going to report to you? (Word document? Bring in defects in the bug tracking tool – make sure they have authorization for this)
Testers
– Look for good testing profiles
– End users (super users with the right attitude?)
– System testers (in house? outsourcing?)
– Performance testing, who?
– Do you need consultancy?
Arrangements with IT department
– Make arrangements with IT department on how they are going to test
– Talk about exit and entry criteria (when is software good enough to deliver to test team)
– Ask about organization of the Component and Component integration testing
– How are the builds going to be done? Once a week? Every day?
– Will there be time for smoke tests between the build and the start of your testing?
– Propose a demo for the developers on testing
– Ask about the IT organization of automated component testing
Acceptance test preparation
Okay, the analysts start to talk to key users to define what they need.
Don’t sit and wait till they are finished. Get your acceptance test preparation started!
Organize test preparation sessions with end users (and i mean, do this at the very beginning of the project)
– Ask end users what they really want
– Ask them to give examples of real live cases
– Go with the end users trough the current application or manual method they use now to perform what the application will have to do later
– Ask for details and keep on asking
– Make a list of the cases they mention
– Use a tool, excel.
- These are the test cases you are going to use at test execution
- Make a second list of the questions they might have
– Hand over these lists to analyst team (helps to find the bug early)
Create (and maintain) an helicopter view on your project
– Decide for each project part what is the
- ‘Impact’ of a bug when it goes wrong (Business van tell you that)
- ‘Change’ of anything going wrong (IT can tell you this)
System test preparation
– Take each analysis document and break it down into tests that can have a ‘pass’ or ‘fail’ answer
– This will get you a certain number of test cases
– make a list, one per project part analysis
– Use a tool, excel.
– These are the test cases you are going to use at test execution
– Don’t put anything in these tests that is not in the analysis documents – You can structure the list by using these divisions :
– check fields:
– Is the field there?
– correct type (checkbox, input field, dropdown)
– check buttons/links:
– Is the button/link there?
– does it do what it has to do
– validation of fields:
– e.g. is website name correct / incorrect
– cross check fields:
– if one field has a certain value this might have implications on another field
– Processes:
– make tests on the working of background processes
– on a given input, what is the expected output
– here you might ask more input from specialists to get good test cases
– Database actions:
– make tests for database fields that will change but are not on screen
– check IT on how to make these visible
– Navigation
– If you have questions about the analysis, talk to the analysts! If you find a bug here, no harm is done (just changing the text will do).
– Look for incomplete info in the analysis (not enough detail, e.g. no defaults, dropdowns without detail, processes that are not clearly described, errors in navigation plan, etc). Make sure to report this information to the analysts.
– When ‘impact’ and ‘chance’ are high for this part of your application, make sure to make a very detailed test preparation. If both are low, don’t spend too much time on it.
This is how your project might look like at the end of the test preparation phase:
Project_view_after_preparation_example.xls (password of file: osst)
Recent Comments