'Test script-free validation in a regulated environment: Kanban Style' with Andy glover webinar
•Télécharger en tant que PPTX, PDF•
1 j'aime•683 vues
view webinar: http://www.eurostarconferences.com/community/member/webinar-archive/webinar-74-test-script-free-validation-in-a-regulated-environment-kanban-style Software development and testing practices have gone through a revolution since Agile came into the scene. Buzz words such as scrum, user stories, Kanban, lean and test driven development are all the rage now. Many of these Agile practices have shown to improve the overall quality of the software yet it can be very hard to implement them in a heavily regulated environment. This presentation will discuss an experience in applying a lean and just in time test approach while working in the Pharmaceutical Industry where detailed test documentation and providing evidence of the testing are mandatory requirements from clients. By taking principles from Acceptance Test Driven Development and Kanban techniques, the presentation will show how producing a detailed requirement specification can drive the test execution without the need for detailed test scripts. By automatically generating traceable test evidence using video recording tools, the tester can save time on documentation and invest the time saved on performing further testing.
Recommandé
Contenu connexe
Plus de TEST Huddle
Plus de TEST Huddle (20)
Dernier
Dernier (20)
'Test script-free validation in a regulated environment: Kanban Style' with Andy glover webinar
- 1. www.excointouch.com Andy Glover EuroSTAR 2013 KANBAN STYLE TEST SCRIPT-FREE VALIDATION IN A REGULATED ENVIRONMENT:
- 3. @esconfs #esconfs Go to Jail
- 4. @esconfs #esconfs Do you expect better testing practices in a heavily regulated environment? Question for the audience
- 5. @esconfs #esconfs Different Test Phases A formal process V. An informal process • Formal test process near the end of the project. Highly detailed and rigid process. • Informal test process throughout project. Flexible, low detail.
- 6. @esconfs #esconfs Reality: Informal Test Process Hard to describe Not managed Seems random at times
- 7. @esconfs #esconfs Reality: Formal Test Process • Test Plan – Test Scripts • Traceability Matrix – Test Report – Issue Logs • Screen Shots • Review, Review, Review • Sign and date
- 9. @esconfs #esconfs What’s the problem Testers mind-set: Pass an audit!
- 10. @esconfs #esconfs Tester’s Mind Set
- 11. @esconfs #esconfs Ideas, Suggestions History Mentality Ideas Case Study History Pitfalls Ideas Freedom
- 12. @esconfs #esconfs Every project is different FDA do not mandate a test approach or techniques Every software development project is different Testing starts from day one Request testability requirements
- 13. @esconfs #esconfs Manage all the testing Manage the informal testing Manage the testing in sessions Add Variety Not just Requirements based testing
- 14. @esconfs #esconfs Don’t settle down • Good testing is hard • Software Development (and testing) is new(ish)
- 15. @esconfs #esconfs Learn Learning doesn’t stop at the end of conferences [or webinars] Learn from other testers in the same industry as well as other industries Books, magazines/articles, blogs, forums, exercises/group sessions
- 16. @esconfs #esconfs It’s all about the evidence Highly detailed test scripts are common in the industry
- 17. @esconfs #esconfs It’s all about the evidence “Abundant, quality evidence mitigates your other problems” - Griffin Jones 2012 Video shows software working in specific scenarios
- 19. @esconfs #esconfs Merge the [testing] phases Agile Working software over comprehensive documentation
- 20. @esconfs #esconfs Automation • Automate as you go within the sprint • Automate only what needs automating – Focus on checking the software • Add to the automated regression suite • Work with the developers as one team • Use the automation to validate product: – Build reviews/checks around the automation – Produce screenshots & reports from the automation
- 21. @esconfs #esconfs Kanban… or is it ATDD? History Mentality Ideas Case Study History Pitfalls Ideas Freedom
- 22. @esconfs #esconfs Put your hands up Admit you do Requirements Based Testing - i.e. Checking every specification item From a Requirements or Specification doc: Req ID Requirement Test Result 1 Valid User can login to the system Pass 2 Invalid passwords will be rejected Pass 3 User will be locked out following 5 invalid passwords Pass
- 24. @esconfs #esconfs NEW AND AMAZINGLY AWESOME PROCESS
- 25. @esconfs #esconfs NEW AND AMAZINGLY AWESOME PROCESS
- 26. @esconfs #esconfs WHO OWNS QUALITY?
- 27. @esconfs #esconfs SOAP OPERA TESTING
- 28. @esconfs #esconfs SOAP OPERA TESTING
- 29. @esconfs #esconfs Summary Highly regulated environments can develop and learn from other industries Suggestions on new processes/tools Testers must keep learning and developing skills Case Study
- 30. THANK YOU www.excointouch.com Andy Glover Head of Testing at Exco InTouch Andy.glover@excointouch.com Software Testing community: Blog: http://cartoontester.blogspot.com Twitter: @cartoontester I regularly contribute on STC’s The Testing Planet
- 31. www.excointouch.com EXCO INTOUCH Our mission is to improve clinical and healthcare outcomes through simple, effective and engaging patient communication Exco InTouch is a privately owned & managed company, established in 2004 Operational offices in UK, USA and Canada Studies conducted in 85 countries with over 750,000 patients
Notes de l'éditeur
- Highly Regulated EnvironmentsThere’s a reasonIt’s Safety Critical
- Test Plan & Test Scripts & Traceability Matrix Review documents and sign offExecute testsSign & DateRecord screenshots of testingTest Report & Issue LogsReview documents & test evidence and sign offIssue Management
- Pass all tests (if possible)Reluctant to try new processesReluctant to try new toolsFunctional testingRequirements based testingInvolved late in the development processExpected Results must be knownOnly testing the expected outcome and nothing else
- Help with test evidence recording and loggingReview user requirementsConsider developing test automation
- Focus testers on testing (mind set)Focus on learningFinding issues quicklyDocument as you goDiscover where testing happens. Does it add value?Can it be improved or shared with other testers?If beneficial, document itConsider group testing sessionsCollaborate with developers on unit testingUse ChecklistsSwap projects between team members
- Ability to understand testing Ability to communicate testingFocus on testing skills:Able to learn quicklyThinking Skills (critical, lateral)Technical knowhow and/or programming skills
- To prove the testing was performed
- Less need for detailed test scriptsArgument tests need to be self explanatory are no longer validReviewing sessions and video evidence requires skill and timeThe tests are more powerful (re-use, variable inputs).
- Currently for projects, either for core products or ePRO projects, we have a spec (RDS) we then, as testers, write a test plan and a long set of test scripts/cases. There are good reasons for that but generally speaking it’s a pain because of a number of issues mainly the fact that the requirements often change, at the last minute, which requires the tests to be updated… lots of times in some projects.What if we could still do the testing but without the test scripts, because in fact, we do that already, we call it informal testing and we tend to find the majority of the bugs during that face. But of course we have regulations to follow! Having said the process we are going to apply doesn’t require any tests to be written (bar 4 or 5 simple ones!) – By the way – Mark has reviewed this process and he is happy so from a regulatory point of view we’re good to go.This new approach does have some requirements to be in place. But I’ll walk through the approach first and then I’ll talk about what as testers we need of you as the PMs in the project.
- Now, there are a few risks in this process. And I don’t want to go into detail of what those might be. The important thing is that as development team and I include the test team is that we release software that is good enough in terms of quality for the end users, for clients for regulators. As a test team we don’t own Quality, do we are not quality gatekeepers, Quality is everyone’s responsibility, that’s why PMs do certain Quality checks, that’s why you guys do unit testing, code reviews, etc.Our key role as a tester is to find relevant information about the application by asking lots of questions. Like does it work, does it have defects in this area or this other area, is it usable, does it perform well.Now the new process is all really just functional based testing. We are looking at the functionality specified in the RDS and we are checking that the app behaves as expected. but as a tester I want to make sure this new process we’re introducing is no worse than the current one. Since we are saving time, it’s worth doing more testing, what ever testing that means to find more info about the application. Whether to give us confidence that the app is good to go or to raise defects as we find them. And that extra testing we are going to try is called Soap Opera Testing. Hopefully through this we can improve the overall quality of the software we ship…
- Now, there are a few risks in this process. And I don’t want to go into detail of what those might be. The important thing is that as development team and I include the test team is that we release software that is good enough in terms of quality for the end users, for clients for regulators. As a test team we don’t own Quality, do we are not quality gatekeepers, Quality is everyone’s responsibility, that’s why PMs do certain Quality checks, that’s why you guys do unit testing, code reviews, etc.Our key role as a tester is to find relevant information about the application by asking lots of questions. Like does it work, does it have defects in this area or this other area, is it usable, does it perform well.Now the new process is all really just functional based testing. We are looking at the functionality specified in the RDS and we are checking that the app behaves as expected. but as a tester I want to make sure this new process we’re introducing is no worse than the current one. Since we are saving time, it’s worth doing more testing, what ever testing that means to find more info about the application. Whether to give us confidence that the app is good to go or to raise defects as we find them. And that extra testing we are going to try is called Soap Opera Testing. Hopefully through this we can improve the overall quality of the software we ship…
- We have operational offices in UK, USA and Canada, supported by a third party partnership Trialfacts across Asia-pacific time zones (enabling 24/7 support)Based on 43 members of staff our experience as of July 2012 …Total: 479yrs of relevant pharma & healthcare operational experience!!Average: 11.14 yrsMedian: 11 yrsRange: 0-32 yrs-------------------------------------------------------------Future idea - Can we highlight the 67 countries???