Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Lesson 3

Working with Requirements
by

Artem Vasiuk

on 9 January 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Lesson 3

Thank You!
artem.vasiuk@gmail.com
arty.vasyuk
Summary
1. Don't panic - evaluate situation
2. Gather info about product
3. Work with development peers
4. Build & Own a Testware
TesterBootCamp
What is SDLC
Testing goals on each stage
Skills expected from Tester
Profit from Tester
Lesson 1
No requirements reality
Test Techniques
Survival plan
Acting responsible
Lesson 3
*past
Testing types
The right one, The right time
Differences in platforms
Type per phase of a SDLC
Lesson 2
*past
'No time to explain - just Test'
- No Documentation
- No Testing process
- No Time to test everything
Define reality
Reasons
- no Resources (time, HR)
- no Knowledge about system
- no Interest in system/skills
Result
- Testing only obvious things
- Iceberg effect:
Groundless confidence
Guessing about the rest
Uncertainty on Release

Apply Test Techniques!
Wanna survive?
Error guessing
Equivalence Partitioning
Boundary values
State-transition
Decision tables
Requirements
No Documents
No Time
Error guessing
AdHoc testing
Exploratory testing
Experience based
Structure based testing
.
Use-case based
.
Equivalence Partitioning
Boundary values
State-transition diagram
Decision tables
Much Time
Enough
1. Start Exploratory testing
2. Learn the product
3. Document steps/flows
4. Use High-level checklist
Follow Basic Plan
1. Exploratory testing
QA lead
PM
Customer
- Who is responsible for test output?
- Ask him to validate your testware
Test Scenarios
Test Cases
Defects
- Use Risk-based testing
Release Critical features
Primary functionality
High-risk failures
Discover system behavior
Plan regression testing
Knowledge sharing source
- Log your test scenarios
2. Learn the product
- In Focus
users
objects
workflows
product properties
Notes
Chats
Emails
Tasks/Defects
Product vision
- Info Source:
- Also
Competitors
Subjective experience
Code
- Interview with peers
Ask precise questions
Ask proper questions
- Input> Process> Output
1. what will get (Output)
2. what will use (Input)
3. what's inside (Process)
Use case diagrams
Flow charts
Screenflow charts (mobile)
3. Create documentation
- Visualize the info
- Build a map of workflows
- Update structure of new tests

- Use common tools
- enough for testing
- checklists format
- add details 'on the fly'
- use bottom-up / top-down approach
4. Document on high level
Some advices:
Always inform people about risks
You cannot test everything - follow priorities
'Not a bug - feature' situation
'Stay alert - stay alive' rule
Follow-up discussion with written notes
Full transcript