Your SlideShare is downloading. ×
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Hunt On The White Rabbit 10 A Eng
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Hunt On The White Rabbit 10 A Eng

423

Published on

Capabilities and benefits of using Silk Central Test Manager within Your organization.

Capabilities and benefits of using Silk Central Test Manager within Your organization.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
423
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Goede middag allemaal! Welkom. Mijn naam is Andrew Issaenko en ik wil graag vandaag jullie uitnodigen voor de avontuur . Wij gaan vandaag iets spannend te doen. Zoals deze twee manen gaan wij vandaag op de jacht. Wij gaan geen platen vandaag schieten , maar wel een jacht op witte konijnen doen . Deze konijntjes kunnen overall zijn..Dus jullie zouden goed blijven zoeken om met goede trofee in de eind te komen. Witte konijnen zijn aparte features of test manager die kunnen aan ons voordelen leveren.
  • Vooraf ga ik beginnen, heb ik een belangrijke vraag aan jullie. Testen wij goed binnen ons projecten? Drie mensen oproepen die antwoord kunnen geven. … Wat is een definitie van “goed”?..
  • Alleen als wie antwoorden op die vragen weten, dan kunnen wij beantwoorden of wij goed testen.
  • Maar hoe weten wij?
  • Dit ZEKER?
  • Willen Wij het
  • Het zeker weten?
  • Als antwoord op die vraag Ja is, dan kunnen wij wel verder. Gebruik van Test Manager is geen zilver bullet, maar het gaat ons betrouwbaar antwoorden op ons vragen over testing bieden.
  • Hoe weten wij de status van de testing? Kwaliteit van oplevering: Hoe goed zijn ons producten? Kwaliteit van project: Is ons test basis/referentie duidelijk is? Gewenst doelen bereiken: Op welke delen van ons product, producten (opleveringen) weten wij zeker dat wij hebben ons doelen volgens ons test basis bereikt? Test Progress : Hoe ver zijn wee in de realisatie van ons test doelstelling tegen oorspronkelijke planning?
  • Natuurlijk, iedereen van ons heeft behoefte om een of andere informatie te weten om ons dagelijkse werkzaamheden uit te voeren.
  • Test Specialist applicatie beheerder.
  • De basis van ons testing is ons verwachtingen over functionaliteit van de product. Test requirements is de manier om die verwachtingen in de structureel manier doorgeven. De structuur is de bom, waarin op elke niveau wordt bepaalde type van de requirements doorgegeven. Hier is een voorbeeld om die bom alvast te bepalen. Voor sommige producten (PZMO) die is wel gedaan. Als wij koppelvaak specificatie pakken, dan kunnen wij deze niveaus daar expliciet vinden. Wat bied je extra hiermee, is prioriteiten stellen op de basis van belang van de bepaalde deel voor de business en risico die je daar verwacht betreffende realisatie. Deze parameters zijn ook gebaseerd op afhankelijkheden tussen requirements en beschikbaar resources.
  • Realisatie van requirements bom binnen verschillende projecten. Daar zitten geen vaste regels qua structuur van de bom omdat elke project uniek is.
  • Waar haal je jou test requirements van?
  • Je kan test requirements in verschillende manieren binnen Test Manager toevoegen.
  • Wij hebben requirements en hoe gaan wij verder naar test definitie? Hoe leggen wij vast een brug tussen ons verwachtende resultaat en hoe gaan wij het bewijzen ? Het kan natuurlijk zijn dat wij geen test requirements maar wel bestande test design hebben. In dit geval hebben wij sort van “reverse enginering””. Maar dan kan. Wij kunnen eerst test cases hebben en daarna op die basis ons test scope bepalen .
  • Deze mooi man is bezig met een creatieve werk zoals test design. Wij kijken ook wat is ons test cases en test situaties kunnen zijn.
  • Een van grootste voordelen van test manager zijn koppeling tussen ons testen en andere informatie gebieden. Als test case is niet goed gespecifierd , dan kan je daar interne issue indienen. Ook als oorspronkelijke requirement niet duidelijk is. Goede manier om elkaars feedback te geven. Issues koppeling: Je weet precies welke test heeft bepaalde issue gevonden en je kan efficiency van jou test cases zien. Issue Manager. Test Data in Star Team makkelijk te benaderen vanaf test cases. Test Data hoeft niet op twee plekken tegelijk staan.
  • Elke gedefinieerde test cases moet vroeg of laat uitgevoerd zijn . De eerste stap is te bepalen wat en door wie.
  • En natuurlijk hoed je rekening met afhankelijkheden zoals met normaal project taken .
  • Je kan test uitvoering beginnen of management van huidige test uitvoering taken.
  • Je kan regelmatige test uitvoering taken plannen, test uitvoering in de toekomst plannen wanneer of overzicht van alle test uitvoerende taken (past, present of future) te zien.
  • Per elke test uitvoering kan je gedetalizeerde uitslag zien Passed – Passed Failed- Failed Unresolved – Kan niet testen maar het moet niet zo zijn. Unsupported – kan niet testen maar het moet zo zijn. Geen reden om alarm bel te trekken.
  • Mogelijkheid om geautomatiseerde test cases direct uit test manager uit te voeren. Rekening houden met verschillende instellingen. Code coverage en interne product analyse tools aansluiten.
  • Niet alle informatie haal je uit Test Manager. Het wordt meestal efficiënt gebruikt in combinatie met andere tools.
  • Transcript

    • 1.
      • Good luck at your hunt!
      Hunt on the white rabbits By Andrew Issaenko ©May, 2010
    • 2.
      • Do We test good?
    • 3.
      • Kan we predict the end quality?
      • Are our test results 100% reliable?
      • Is our test planning 100% reliable?
      • Do we test as efficient as possible?
    • 4.
      • Do We Know
    • 5.
      • For Sure?
    • 6. Do We Want to
    • 7. Know for Sure?
    • 8.
      • Yes!
    • 9. Test Overview
        • Quality of deliverables:
        • Product defects and PCRs
        • Achievement of desired goals:
        • Coverage of the test scope by testing
        • Quality of the project:
        • Issues onthe business goals of the project
        • The real test progress vs planned realization:
        • Realization and spent time of each planned test task
    • 10. Test Manager for You? As Project Management
      • Progress Tracking : Current situation and work left
      • Predictability : Impact on the future test executions by latest test results
      • Test Budget Control: Control over spent test time and test budget
    • 11. Test Manager for You? As Test Engineer/Application Administrator
      • Test-Progress: Always up-to-date info about the test progress
      • Team work facilitation : Distributing manual test execution work between several persons
      • Flexibility: Flexible way of planning test execution
    • 12. Test Requirements (Representation of the test scope) Level Name Priority Risk Dependenties Resources 1 Applications (Domains, Sources) High Medium Low High 2 Services Inherited High Medium Low Inherited High Medium Low 3 Sub-Services 4 Functions 5 Platforms or configurations
    • 13. Test Requirements Realization Experience of LO 3.7 Experience of PZMO Mei 2010 Experience of dKOC Level Description of the category 1 Consists of two items for different products under test. Those products are groups of features. 2 Each feature is the group of user functions. 3 Each sub-feature is one user function. Level Description of the category 1 Test scope is separated between new and existing functionality. 2 Each group of features is a functionality related to a particular domain/application. 3 Each feature is a service offered by application to the end user. 4 Each sub-feature is a function that supports this service. Level Description of the category 1 Each group of features is the type of available business process. 2 Each feature is the business process for the certain type of data.
    • 14.
      • Groups of product/features, certain features or subfeatures
      • ( product specifications )
      • WBS en Project Initiation Document (PID)
      • ( project documents )
      • Business Importance
      • ( define priority )
      • Risk expectations from project management and development team
      • ( define risks )
      Test Requirements Sources
    • 15. Test Requirements Filling Manual Synchronization with external sources In all cases of filling up test requirements, it is possible to select synchronized test scope manually or automatically by using requirements filters.
    • 16. Test Bridge From/To the test scope
      • Automatic generation of test cases for chosen part of Test Scope
      • Test Scope on the basis of existing Test Design
      • Features Based generation of Test Design
      • Sub Features Based generation of Test Design
    • 17. Filling Test Design
      • Predefined Attributes for test steps: Name, Action and Expected Result
      • Custom Attributes for Test Cases/Steps
      • Synchronization with Microsoft sources
      • Manual and automated test cases
      • Planned Test Execution Time per test case
      Manual filling up test case steps Synchronisation with external sources: MS Excel/Word
    • 18. Test Design Linking
      • Internal project issue at a test case
      • PCR en defects of Issue Manager (Star Team) can be linked to a test case(n) en direct entered within Test Manager on the basis of test results
      • Test cases can make use of automated test scripts en test data in Star Team .
    • 19. Planning Test Execution What, by Whom
      • Each Test Execution in Test Manager is a planned task in project planning
      • Planned Test Cases can be defined manually or selected by filter
      • Test Execution work distribution between more persons
      • Manual and automated tests can be combined but only from the same test container
    • 20. Planning Test Execution Dependencies
      • Startup en Cleanup test procedures (also from another test container)
      • Conditional dependencies
      • Test deployment on the basis of dependencies
    • 21. Start Test Execution Adapt Test Planning
      • Executions Management
      • Continue with existing test execution tasks
      • Start Test Execution on de basic of previous test results
    • 22. Test Management Planning and Progress Tracking
      • Automatic e-mail notification of involved persons
      • Auto-measurement of time spent for test execution
      • Manual/planned start of test execution
      • Overview of all test execution activities
    • 23. Test Results Enter and Overview
      • Latest result and the base for test conclusion per each test sep
      • Passed/Failed/Unresolved/Unsupported
      • Overview of the current test results during test execution
      • Attach any file to clarify test results
    • 24. Automatische Test
      • Test Execution Servers define where application(s) under test runs
      • SilkTest AUT define where SilkTest Agent runs
      • Run Analyses define from which host(s) dynamic test execution information is collected
      • Collect Product code coverage information
      Deployment Options Product Code Coverage
    • 25. Trophies Room-10
      • Test Requirements:
        • Borland Caliber Synchronization
        • MS Word/Excel Synchronization
      • Test Design:
        • Automatic generation of test cases
        • MS Word/Excel Synchronization
        • Linking with met internal and external issues
        • Use of test data/scripts in Star Team
      • Test Execution:
        • Work distribution and Team work facilitation
        • Automatic measurement of execution time
        • Control and Overview per each test case and each test step
        • Integration with code coverage tools
    • 26. Overal Test Reports
      • Which information:
      • The quality of deliverables:
      • Conformance of deliverables to the desired goals (feat for business)
      • The latest test progress vs. planned test realization:
      • The quality of project:
      • Where do you get this information from?:
      • Issue Manager: Reports on all deliverables related issues
      • Test Manager: Reports on the latest coverage of test scope by test activities
      • Test Manager & Planning Tool: One test execution is a task of project planning
      • Test Manager: Reports on all project related issues
    • 27. So.. What Now?
      • Use of test manager within LG projects is a goal confirmed and supported by management !
      • Import Test Scope from existing sources
      • Import existing test cases in Test Manager
      • Pink Roccade LG is a learning organization !
    • 28. Camp Fire
      • Questions and Discussion

    ×