CAJ 009-Philip Lew
Meeting Info
Speaker: Philip Lew
Topic: Testing in Agile
Date: 3/27/17
Description:
If you have a scrum coach and a team that can follow instructions, you’re guaranteed success, right? Wrong. Your team might excel at taking orders, but they also might be more dysfunctional than you’re aware. And for all you know, that cookie cutter scrum book isn’t thorough or complete. Without healthy organizational habits and proper planning, your Agile efforts are useless.
If you’re wondering how you can optimize your agile testing process, Phil will share his insights Agile Testing in the trenches. In this talk, Phil will cover some issues such as test plans and test cases. How much documentation is really needed? You’ll learn where testing fits into the Agile process, as well as how to implement integrate into a team to contribute from the beginning. He’ll also share how to take the reigns of your Agile efforts and ensure the long-term success you envision for your team. While walking through agile principles, you’ll learn how they’ve been implemented in the trenches, and how to craft your own version of Agile that best suits your needs.
Bio:
Philip Lew is the CEO at XBOSoft. XBOSoft’s software QA and software testing services help their clients deliver products to market faster and with higher quality; an ever-increasing challenge as software becomes more complex and platforms increase. As a Corporate Executive, Development Manager, Product Manager and Software Engineer, Philip has managed teams to tackle broken processes, develop solutions to difficult problems, and coached others be leaders, managers and experts. He leverages his academic background in operations research, industrial engineering and computer science combined with hands on work experience with programming, predictive modeling and algorithm development to work with clients and colleagues around the world. For his hobbies, he rides a bicycle, and travels the world to quest his thirst for exploration and learning.
Quotes:
Sometimes we talk agile, but we’re not really doing agile
Migrate from handoff concept to actually doing agile
Agile is an adjective, not a noun
Use retrospectives as a way to improve, rather than just going through the motions
You can read books, but really you have to form your on groove
Be-Do-Have – It is about being, not just having
We think about the process and results, but we don’t think about the people we need to be to get the desired results
Team members do what they can do and what is needed
It’s not about roles, but about tasks and the people who have the capability to do those tasks
Overtime is just not sustainable… Overtime leads to mistakes.
Sometimes things fall off the plate, it is better to have them fall off on purpose. Take all these things that aren’t a priority off your plate in the beginning.
Plan out the amount of documentation that is necessary. Take into account how long it will be used and who it will be used by
We don’t write detailed test cases, we write general guidelines for tests and that has to be planned as well
Defects come from requirements, but a lot of time we don’t plan how long it is going to take for a well written user story
Infrastructure takes time and doesn’t happen overnight
Plan out what you are going to test and what environment you are going to test it on
Have environments available beforehand as needed so you can get right into testing when needed
Focus will change sprint by sprint, be agile about being agile
Non-functional testing
Usability
Security
Performance
Static-whitebox
Inspections
There is no longer the functional tester, we as testers have to think about moving up and downstream. Upstream means thinking about skills in automation and performance testing. Also focus on getting closer to the user and understand from a user point of view how they are doing and what they are thinking.
During the sprint, go where you are wanted and needed
We once tested a login workflow and we came up with 50 different options for testing it
Testing improvements:
Where was time wasted
What was not testable
What tasks fell off and why
What tasks were overlooked
Is automation doing what we want
The goal of automation is not to pass, but to help you find defects
Everyone is responsible for quality
Agile doesn’t mean that we have no test plan, but it is a different plan
Follow a plan, but go where you are wanted and needed.
Questions:
In order to do Automation during the sprints don’t we require stable environments? For example : The User Interface type of applications?
API testing is one layer benieth the user interface
Write automated code for the API and regression testing for previously released features
How will the API testing works better when users are concentrate more on GUI?
Won’t help a user for their GUI
Hallway usability testing
If you have no automated testing now, is there a way you would recommend getting started?
How the testing paradigm, with an emphasis on automation, looks in a DevOps environment.
Basically, within each Sprint:
1) How much time is budgeted for manual test case design, manual testing, automated tests (UI and API)?
2) If automating every Sprint’s work within the same Sprint, how would it be done if dev work were to complete towards the end of the Sprint and does not leave much time for automation?
DoD can be passed if tested manually, or automated (coded and tested)
Please elaborate why test cases are not necessary? If not designed, should we use the acceptance criteria as test conditions? Also, if no test cases are created, what do we use as regression test cases for major releases?
What type of tools you suggest for Automation?
What are some other parallels between cycling and agile that you have identified?
Your agile failures/success points are amazing. Have you written anything about those?
You are sharing a lot of great reasons to increase the time in planning. How can teams make a case for additional time for planning quality work?
What role do you see test cases playing in the modern agile team?