Agile software development is probably the most common methodology used by organizations today, as such; many people have started to ask more and more questions about this methodology that sometimes based on wrong assumptions.
In this presentation, I will review the most common Myths and Misconceptions that I encounter during agile training courses, hopefully, to help people to divide the truth from the assumptions.
Using JIRA for Risk Based Testing - QASymphony WebinarQASymphony
Learn how to leverage risk based testing with JIRA to prioritize the testing of features and functions based on risk of failure, function of importance and likelihood or impact of failure.
You want to integrate skilled testing and development work. But how do you accomplish this without developers accidentally subverting the testing process or testers becoming an obstruction? Efficient, deep testing requires “critical distance” from the development process, commitment and planning to build a testable product, dedication to uncovering the truth, responsiveness among team members, and often a skill set that developers alone—or testers alone—do not ordinarily possess. James Bach presents a model—a redesign of the famous Agile Testing Quadrants that distinguished between business vs. technical facing tests and supporting vs. critiquing―that frames these dynamics and helps teams think through the nature of development and testing roles and how they might blend, conflict, or support each other on an Agile project. James includes a brief discussion of the original Agile Testing Quadrants model, which the presenters believe has created much confusion about the role of testing in Agile.
Agile software development is probably the most common methodology used by organizations today, as such; many people have started to ask more and more questions about this methodology that sometimes based on wrong assumptions.
In this presentation, I will review the most common Myths and Misconceptions that I encounter during agile training courses, hopefully, to help people to divide the truth from the assumptions.
Using JIRA for Risk Based Testing - QASymphony WebinarQASymphony
Learn how to leverage risk based testing with JIRA to prioritize the testing of features and functions based on risk of failure, function of importance and likelihood or impact of failure.
You want to integrate skilled testing and development work. But how do you accomplish this without developers accidentally subverting the testing process or testers becoming an obstruction? Efficient, deep testing requires “critical distance” from the development process, commitment and planning to build a testable product, dedication to uncovering the truth, responsiveness among team members, and often a skill set that developers alone—or testers alone—do not ordinarily possess. James Bach presents a model—a redesign of the famous Agile Testing Quadrants that distinguished between business vs. technical facing tests and supporting vs. critiquing―that frames these dynamics and helps teams think through the nature of development and testing roles and how they might blend, conflict, or support each other on an Agile project. James includes a brief discussion of the original Agile Testing Quadrants model, which the presenters believe has created much confusion about the role of testing in Agile.
Join Stacey Brown, President of MindLink Resources, for a webinar that will examine the top 10 qualities of a quality assurance (QA) tester. Learn how to bring out these traits in your current QA staff and how to watch for these soft skills when screening new candidates.
When localizing products, the QA step is essential in confirming the translation and making sure the product was successfully prepared for the target market. Managers trust the QA staff to catch translation and engineering errors and ensure product readiness to avoid quality issues caught by the end customer. Many managers make the mistake of assigning this critical role to a linguist who may not have the right characteristics of a good tester. When selecting QA staff, it is important to consider skills beyond just linguistic and technical. There are many “soft skills” to watch for in a candidate that will give localization managers the confidence that even small errors will be reported by their tester.
In this webinar, Stacey will discuss the top 10 qualities of a quality assurance (QA) tester, how to bring out these traits in current QA staff, and how to watch for these soft skills when screening new candidates.
About the presenter
Stacey Brown is the Talent Management Specialist and President of Mindlink Resources, LLC.. She has a passion for surrounding herself with talented people. For the past 15 years she has successfully built teams of contractors providing a variety of services at large fortune 500 companies in the Pacific Northwest. She specifically has over 12 years of experience recruiting, training and managing QA specialists. Stacey has a degree in Communications and an MBA in Technology Management.
Talk for the Project Quality Day at Eclipse Conference Europe 2015. A presentation on how to perform risk based testing, using Jira, Jubula and Mylyn (and Spago4Q), appplied to a real-world use case, the SpagoWorld Shop
Evolve or Die: Healthcare IT Testing | QASymphony WebinarQASymphony
Modern software testing for Healthcare Organizations. Learn about best practices for software testing in the healthcare industry featuring Mike Cooper, Chief Quality Officer of Healthcare IT Leaders and Kevin Dunne, VP of Business Development at QASymphony
Digital Transformation, Testing and AutomationTEST Huddle
The Digital Transformation is real. It is having a profound effect on how business is done and the nature of the systems required to deliver productive customer experiences and consequent business benefits.
Key Takeaways:
- What is the Digital Transformation and how does it affect testing?
- Some key findings from a recent and an ancient survey
- How to achieve testing and automation success.
To view the webinar, visit - http://testhuddle.com/resource/digital-transformation-testing-and-automation/
Test Metrics in Agile: A Powerful Tool to Demonstrate ValueTechWell
Most understand that an agile development and testing approach improves quality and reduces risks in our projects. In some companies and culture however, there are skeptics. Is the move to agile—and therefore agile testing—really beneficial? Join Iuliia Zavertailo for a closer look at a Scandinavian insurance company that started with one manual tester and within three years moved toward opening a large test center in the Baltic. Behind this story were many small steps of demonstrating testing's value to the client through a well-defined set of agile metrics which quantitatively supported the importance and value of testing. Iullia gives examples of key performance indicators—test coverage, defect open and close rates, issues reported by customers, and regression test suite duration—and provides a roadmap for building a test metrics framework. She then discusses tools that support the agile test framework, provides guidance on how to analyze test statistics, and offers ways to present the facts that interest clients most.
ATDD And BDD The Great Beat Down…or…DebateTEST Huddle
Key Takeaway’s
1. - A solid overview of the intent behind the User Story as a requirement artefact.
2. - A solid overview of Acceptance Test Driven Development, including Behavior-Driven Development.
3. - An understanding of the intent behind Acceptance Criteria.
4. - An understanding of the balance required in the User Story and the Acceptance Criteria/tests.
View the webinar here - https://testhuddle.com/atdd-and-bdd-the-great-beat-down-or-debate/
We’ve all been there. We work incredibly hard to develop a feature and design tests based on written requirements. We build a detailed test plan that aligns the tests with the software and the documented business needs. And when we put the tests to the software, it all falls apart because the requirements were changed without informing everyone. Mary Thorn says help is at hand. Enter behavior-driven development (BDD), and Cucumber and SpecFlow, tools for running automated acceptance tests and facilitating BDD. Mary explores the nuances of Cucumber and SpecFlow, and shows you how to implement BDD and agile acceptance testing. By fostering collaboration for implementing active requirements via a common language and format, Cucumber and SpecFlow bridge the communication gap between business stakeholders and implementation teams. In this workshop, practice writing feature files with the best practices Mary has discovered over numerous implementations. If you experience developers not coding to requirements, testers not getting requirements updates, or customers who feel out of the loop and don’t get what they ask for, Mary has answers for you.
The Test Automation Pyramid is a useful model to help us understand and discuss automated testing efforts. Generally speaking it is a good practice to have lots of unit tests, fewer component integration tests, fewer API tests, and even fewer UI tests.
In this webinar, Hans goes through a number of solutions a team can do to diminish this problem, and what actions to take when it happens. Hans discussed the following solutions on how one can apply better test design to drive better automation, a number of technical strategies, what developers and product owners can do to help, and how to handle the testing and automation work that is still left after a sprint has finished. A key item in handling the test automation work that is left over is that QA’s need to own the testing from the beginning, and should not get stuck in the work of previous sprints, since that will inhibit good cooperation with other team members, making matters worse.
Key Takeaways:
- Get more tests created and automated.
- Make automation manageable and maintainable.
- Keep the QA people in sync with their fellow team members.
View webinar recording - https://testhuddle.com/resource/how-to-get-automated-testing-done/
Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.
Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.
By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.
More details: https://confengine.com/last-conference-canberra-2018/proposal/7294/improving-the-quality-of-incoming-code
Conference Link: https://2019.agileindia.org
Join Stacey Brown, President of MindLink Resources, for a webinar that will examine the top 10 qualities of a quality assurance (QA) tester. Learn how to bring out these traits in your current QA staff and how to watch for these soft skills when screening new candidates.
When localizing products, the QA step is essential in confirming the translation and making sure the product was successfully prepared for the target market. Managers trust the QA staff to catch translation and engineering errors and ensure product readiness to avoid quality issues caught by the end customer. Many managers make the mistake of assigning this critical role to a linguist who may not have the right characteristics of a good tester. When selecting QA staff, it is important to consider skills beyond just linguistic and technical. There are many “soft skills” to watch for in a candidate that will give localization managers the confidence that even small errors will be reported by their tester.
In this webinar, Stacey will discuss the top 10 qualities of a quality assurance (QA) tester, how to bring out these traits in current QA staff, and how to watch for these soft skills when screening new candidates.
About the presenter
Stacey Brown is the Talent Management Specialist and President of Mindlink Resources, LLC.. She has a passion for surrounding herself with talented people. For the past 15 years she has successfully built teams of contractors providing a variety of services at large fortune 500 companies in the Pacific Northwest. She specifically has over 12 years of experience recruiting, training and managing QA specialists. Stacey has a degree in Communications and an MBA in Technology Management.
Talk for the Project Quality Day at Eclipse Conference Europe 2015. A presentation on how to perform risk based testing, using Jira, Jubula and Mylyn (and Spago4Q), appplied to a real-world use case, the SpagoWorld Shop
Evolve or Die: Healthcare IT Testing | QASymphony WebinarQASymphony
Modern software testing for Healthcare Organizations. Learn about best practices for software testing in the healthcare industry featuring Mike Cooper, Chief Quality Officer of Healthcare IT Leaders and Kevin Dunne, VP of Business Development at QASymphony
Digital Transformation, Testing and AutomationTEST Huddle
The Digital Transformation is real. It is having a profound effect on how business is done and the nature of the systems required to deliver productive customer experiences and consequent business benefits.
Key Takeaways:
- What is the Digital Transformation and how does it affect testing?
- Some key findings from a recent and an ancient survey
- How to achieve testing and automation success.
To view the webinar, visit - http://testhuddle.com/resource/digital-transformation-testing-and-automation/
Test Metrics in Agile: A Powerful Tool to Demonstrate ValueTechWell
Most understand that an agile development and testing approach improves quality and reduces risks in our projects. In some companies and culture however, there are skeptics. Is the move to agile—and therefore agile testing—really beneficial? Join Iuliia Zavertailo for a closer look at a Scandinavian insurance company that started with one manual tester and within three years moved toward opening a large test center in the Baltic. Behind this story were many small steps of demonstrating testing's value to the client through a well-defined set of agile metrics which quantitatively supported the importance and value of testing. Iullia gives examples of key performance indicators—test coverage, defect open and close rates, issues reported by customers, and regression test suite duration—and provides a roadmap for building a test metrics framework. She then discusses tools that support the agile test framework, provides guidance on how to analyze test statistics, and offers ways to present the facts that interest clients most.
ATDD And BDD The Great Beat Down…or…DebateTEST Huddle
Key Takeaway’s
1. - A solid overview of the intent behind the User Story as a requirement artefact.
2. - A solid overview of Acceptance Test Driven Development, including Behavior-Driven Development.
3. - An understanding of the intent behind Acceptance Criteria.
4. - An understanding of the balance required in the User Story and the Acceptance Criteria/tests.
View the webinar here - https://testhuddle.com/atdd-and-bdd-the-great-beat-down-or-debate/
We’ve all been there. We work incredibly hard to develop a feature and design tests based on written requirements. We build a detailed test plan that aligns the tests with the software and the documented business needs. And when we put the tests to the software, it all falls apart because the requirements were changed without informing everyone. Mary Thorn says help is at hand. Enter behavior-driven development (BDD), and Cucumber and SpecFlow, tools for running automated acceptance tests and facilitating BDD. Mary explores the nuances of Cucumber and SpecFlow, and shows you how to implement BDD and agile acceptance testing. By fostering collaboration for implementing active requirements via a common language and format, Cucumber and SpecFlow bridge the communication gap between business stakeholders and implementation teams. In this workshop, practice writing feature files with the best practices Mary has discovered over numerous implementations. If you experience developers not coding to requirements, testers not getting requirements updates, or customers who feel out of the loop and don’t get what they ask for, Mary has answers for you.
The Test Automation Pyramid is a useful model to help us understand and discuss automated testing efforts. Generally speaking it is a good practice to have lots of unit tests, fewer component integration tests, fewer API tests, and even fewer UI tests.
In this webinar, Hans goes through a number of solutions a team can do to diminish this problem, and what actions to take when it happens. Hans discussed the following solutions on how one can apply better test design to drive better automation, a number of technical strategies, what developers and product owners can do to help, and how to handle the testing and automation work that is still left after a sprint has finished. A key item in handling the test automation work that is left over is that QA’s need to own the testing from the beginning, and should not get stuck in the work of previous sprints, since that will inhibit good cooperation with other team members, making matters worse.
Key Takeaways:
- Get more tests created and automated.
- Make automation manageable and maintainable.
- Keep the QA people in sync with their fellow team members.
View webinar recording - https://testhuddle.com/resource/how-to-get-automated-testing-done/
Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.
Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.
By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.
More details: https://confengine.com/last-conference-canberra-2018/proposal/7294/improving-the-quality-of-incoming-code
Conference Link: https://2019.agileindia.org
UNESCO World Report : Investing in Cultural Diversity and Intercultural DialogueDavid Vicent
Culture plays a very special role within UNESCO’s mandate. Not only does it represent a specifi c fi eld of activities, encompassing the safeguarding
and promoting of heritage in all its forms (both tangible and intangible), encouraging creativity (particularly in the cultural industries), and facilitating
mutual understanding through intercultural dialogue, it also permeates all UNESCO’s fi elds of competence. It is therefore a source of satisfaction
that this cross-cutting relevance of culture should be underlined with the publication of this second volume in the series of UNESCO intersectoral
world reports, devoted to cultural diversity. 2009
Matthew 6, Prayer, What is Prayer and What's It For, ss, 3 Nines for Prayer...Valley Bible Fellowship
Matthew 6, Prayer, What is Prayer and What's It For, 3 Nines for Prayer, What is Prayer and What's It For?, The Lord’s Prayer, What Access To God? What Should We Be Praying For? What is Prayer? NT Words For Prayer, A.C.T.S., Why Pray?
CEE and Seventhwave lead a rapid-fire discussion of innovative tech and program approaches, and the most meaningful recent research findings for utility representatives, efficiency program implementers, and both residential and commercial field experts.
Testing for agile teams . What's the difference between this and other testing ? What are the goals for such testing ?
Is agile testing needed at all ? Why ?
You will find some answers inside and mist likely will be directed to the right way.
Learn how to establish a greater sense of confidence in your release cycle, along with the practices and processes to create a high-performing engineering culture within your team.
Tune Agile Test Strategies to Project and Product MaturityTechWell
For optimum results, you need to tune agile project's test strategies to fit the different stages of project and product maturity. Testing tasks and activities should be lean enough to avoid unnecessary bottlenecks and robust enough to meet your testing goals. Exploring what "quality" means for various stakeholder groups, Anna Royzman describes testing methods and styles that fit best along the maturity continuum. Anna shares her insights on strategic ways to use test automation, when and how to leverage exploratory testing as a team activity, ways to prepare for live pilots and demos of the real product, approaches to refine test coverage based on customer feedback, and techniques for designing a production "safety net" suite of automated tests. Leave with a better understanding of how to satisfy your stakeholders’ needs for quality-and a roadmap for tuning your agile test strategies.
The Tester’s Role: Balancing Technical Acumen and User AdvocacyTechWell
Ten years ago, many of us started our careers in testing, generally moving from a different internal role. It was common for people who were product users to be hired to jump start their technical career. Now, we see the growth of tester positions that require coding experience or a computer science degree. Melissa Tondi discusses the changing landscape of the role of testers, the challenges when hiring developers with no previous testing experience, and a way to shift the pendulum back to balance technical acumen with a user advocacy role. Melissa leads a thoughtful discussion on what makes a good tester, how we can continue to promote our profession, and how to accentuate the value testers bring to organizations. She identifies factors that caused the test/QA role to become mainstream and how it shifted to become more technically focused. Melissa helps fill in the gaps with a test strategy that balances time for the test team to continue supporting the development efforts while equally emphasizing user advocacy tests. She presents recommendations you can take back to your team to achieve the right balance for your organization.
Transitions to Agile software development always seems complicated when it comes to QA. There are a lot of DOs and DON'Ts but it always seems that 2-3 weeks is not enough for all. In this presentation I cover how a change your mindset and on how you look at the typical problems you can address your challenges with ease and create a mindful process for your organization
These slides mark the goals that we'd like to accomplish defining a QA team which eliminates the frictions with development teams. How much is achieved? Well, it's on our plans to follow it. But we do not know if we'll be able to make it possible
Some notions of continuous testing (CT) have been applied in software development methodologies for a while but it was never called by that term. Another term sometimes used for CT is parallel testing. While some have mastered CT, most of us struggle with how to transform our current testing approaches to CT approaches and align them with evolving development methodologies. Join Tom Wissink as he discusses current examples of CT implementations across different software development methodologies (agile, waterfall, incremental) and describes where parallel or CT type testing yields the best benefits. Arguably the most challenging methodology that demands CT testing is DevOps. DevOps requires all phases of testing to be done quickly and in parallel with the development process and some contend that testing continues into actual operations. Leave this session with a better understanding of CT, and how this approach can be best leveraged in your development environment.
Implementing QA testing seems straightforward. However, implementing a comprehensive QA strategy can be a complex process. To ensure that your product, app, or website is bug free when it hits production, here are 7 QA tests you should be running.
Reaching for Your Quality Stretch Goals: Testing at Realtor.comKlaus Salchner
A/B Testing
If you are not familiar yet, an introduction to A/B testing and how you can leverage this approach to truly measure customer impact before and after a change. It's a practice highly leveraged in the e-commerce and cloud space to truly measure the impact of a change and be able to iterate through it till you see the desired outcome.
Where in your stack to invest in test automation
This short talk will explain in which layer to invest in test automation and the pros and cons. Too many teams still invest heavily in automated UI testing which then results in large test automation suites once the platform grows while still not being able to catch critical quality issues before they reach customers.
Testing for reliability, resilience and recovery
Your customer experience is also impacted by how reliable your application is. How do you test for reliability. But also how do you build and test for resilience, as guaranteed reliability is unachievable and the closer you get the costlier it becomes. Lastly how do you test for recovery, so once an outage or partial outage happened how to you recover, and how do you prepare for that recovery.
Despite the belief that a shared context and collaboration drives quality, too often, software testers and quality professionals struggle to find their place within today's integrated agile teams. This session is a practitioner’s view of testing and testing practices within an iterative/incremental development environment. We will begin with a discussion of some of the challenges of testing within an agile environment and delve into the guiding principles of Agile Testing and key enabling practices. Agile Testing necessitates a change in mindset, and it is as much, if not more, about behavior, as it is about skills and tooling, all of which will be explored.
2. AGENDA
Quality Assurance vs. Quality Analyst
Welcome & Introduction
Where Does QA fit in for Agile and Waterfall Methods
Business Benefits of Quality Assurance & Quality Analyst
Tricks & Demo
What Should You Look for in a Quality Analyst?
3. A LITTLE ABOUT ME
I began as an embedded Quality Assurance Tester on Friday, November 3, 2006
2 QA certifications
Worked on over 20 games and web/client based applications.
Responsible for approximately 10k bugs
One day I logged 93 bugs with pictures (all menu art related)
All iOS devices & Mac, Game Consoles, Windows-XP up
…I love shooting pool, fishing, and playing video games too!
3
4. A LITTLE MORE ABOUT ME
Overall, I love what I do and I try to advocate for QA with the mentality:
“After having been devoted to a project and a team, would I buy or use this
application/tool/”thing” knowing how well it works, feels, and how easy it is to
learn?”
“Would I be proud to sell or use this?”
4
6. THE DICTIONARY SAYS…
The definition of Quality is:
“The standard of something as measured against other things of a similar kind;
the degree of excellence of something”
The definition of Assurance is:
“A positive declaration intended to give confidence; a promise”
6
8. THE DICTIONARY SAYS…
Again, the definition of Quality is:
“The standard of something as measured against other things of a similar
kind; the degree of excellence of something”
The definition of Analyst is:
“A person who conducts analysis”
8
9. TO CLEAR UP THE CONFUSING ACRONYM: “QA”
QA – Quality Analyst
• This is the person
responsible for doing
the work (testing for
quality) on the
application
QA – Quality Assurance
• This refers to the
promises that an
analyst will assess and
scrutinize the level of
quality throughout the
SDLC.
9
So, QA means the person(s) and the promises of quality while
maintaining quality throughout the lifespan of development.
…We should be called QAA’s
10. AN ANALYST’S GENERAL FUNCTION
QA is primarily a person or group of people working
either remotely or along-side developers,
programmers, designers, or business analysts as they
design, document, update, implement, and build an
application; hardware or software.
We, QA, manage and help maintain an expected level
of quality and risk associated with the application.
10
11. ANALYST GENERAL FUNCTION
QA ensures installation, uninstallation, functionality, product stability,
usability, possible legality and consistency between what the customer
needs and expects vs. what’s developed using various testing methods
and some tricks here and there.
In a nutshell
QA finds bugs, issues or risks before the application is put into production.
11
12. 12
WHY INVEST IN QUALITY ASSURANCE /
QUALITY ANALYSTS?
QUESTIONS YOU MIGHT HAVE
13. WHY INVEST IN QA OR A QA TEAM?
Investing in QA is similar to having a safety
net under a tight-rope walker.
Quality Assurance is your safety net –
ensuring that you not only get to live and try
again, you can continue to “try again” to help
accomplish your goals.
13
14. WHY INVEST IN QA OR A QA TEAM?
QA is used to help mitigate risks from an application by finding issues as
early in the Software Development Life Cycle (SDLC) as possible.
We continue throughout the life of the project to ensure that there is
as little risk as possible for the end-user.
14
15. WHAT COULD MY TEAM LOOK LIKE?
Key Stakeholder (Client)
User Acceptance Testers (UAT)
Project Manager/Scrum Master and-or Business Analyst
Developers
Quality Analyst(s)
15
18. WHEN DO WE START USING QA FOR WATERFALL?
QA should become involved
near the Planning phase. Why?
To learn the schedule and plan
ahead
Research or Assess any
competition (if
applicable)/marketing trends (if
applicable)
18
20. WHEN DO WE START USING QA FOR AGILE?
In the Agile method, QA needs to
become involved in Sprint Zero.
This is the requirement-gathering (user
story)/product backlog planning time.
QA can begin assessing effort levels, getting an
idea or plan to assess the upcoming work, and
helping make user stories.
20
21. START USING QA - AGILE
In the Agile method, the whole team is responsible
for quality, not just QA. Quality must be addressed
every sprint to demonstrate that part of the
application.
21
22. WHEN DOES QA BECOME INVOLVED?
Waterfall Methods:
Planning and Design discrepancies
prior to Coding
Consistent data flow across the QA
team to avoid duplicating efforts
Agile Methods:
User Stories, Requirements and/or
Product Backlog Items in sprint 0
Communicate with the team to
ensure QA as a whole.
22
23. WHEN DOES QA BECOME INVOLVED?
Waterfall Methods:
Test cases built from the Design, Test
Plans, Checklists, Metrics (where
applicable), etc.
Agile Methods:
Testing based around requirements
per sprint.
23
1 2 3 4 5 Tracking Information
Red FAIL X Tested 9 PASS 2
Yellow PASS PASS BLOCKED Remaining 16 FAIL 3
Blue X BLOCKED BLOCKED 2
Green FAIL FAIL Total Checks 25 X 2
Black Pass % 8.00% Fail % 12.00%
24. WHEN DOES QA BECOME INVOLVED?
Waterfall Methods
Milestone reports for area
completions
Testing that design documents
match the application and visa versa
Agile Methods
Sprint-release demos to
stakeholders, clients and team
Agile- Ensuring any changes made
from sprint-to-sprint still “work”
with the rest of the application
(Regression Testing and Integration
Testing)
24
25. WATERFALL – MAINTENANCE PHASE
• The project is sent to production at this phase
• UAT can be done at this phase also (User acceptance testing)
• If the customer needs adjustments, “tweaks” or change requests, QA
assesses these changes per. Like a new mini-project
25
26. AGILE – MAINTENANCE PHASE
• UAT is performed throughout a specified time by the PO/Client (usually last quarter
of the project but can exist throughout the entire project *best case*)
• The closer the project gets to the final sprint, the more concise testing is
done to the project as a whole by the development team and UAT
• Upkeep is done as-needed on a case-by-case basis from the customer after
the application is in development (similar to Waterfall)
Depending on the size, budget and overall needs of a project, maintenance isn’t
a required “Phase” for either Waterfall or Agile
26
27. SO, WHEN TO INVOLVE QA? EARLY,
VERY EARLY.
Waterfall – Not long after planning has begun OR
just before Design phase depending on the Plan
Agile – During Sprint 0
27
28. TRICKS
1. Use Hamlet to test max bounds for textbox fields. Look for “shot off”
2. See if the application gracefully handles symbols like ഃ ഇ
3. Take note that entries like “<!” can easily break javascript
4. Wrap text around braces or quotes, “test” could show @#$test@#$
5. The magic SQL date that breaks is 1752. Anything above 1753 works
6. Quick and easy way to spellcheck, copy-paste into MS Word
7. Attempt website addresses to see if the link works in textbox fields
8. Invert the From-To fields for dates
9. Build shortcut keys for commonly used tools (pictures and snip-its)
10. If a sequence of numbers is expected like 1-9, test 0,-1, and 10
11. If the application is an .exe, make sure only 1 .exe can run at once
12. Try to force yourself into URL locations by entering text in the address bar
28
30. Excellent verbal and written communication skills
The ability to recall and demonstrate issues found in a reliable manner
The ability to think outside the box (Edge-cases = bugs live)
The ability to write test cases, test plans and bug reports
Able to test product requirements and around them
Knowledgeable of computer hardware and software
Able to type
Planning and time management skills
Being tech-savvy is a big plus
Any other company-specific need or requirement of QA
Examples: SQL Experience, Automation Experience, Jira, TFS, etc.
30
HIRING ANALYST SKILLSETS
31. RESOURCES
The site for Early defect detection:
http://www.isixsigma.com/industries/software-it/defect-prevention-
reducing-costs-and-enhancing-quality/
Impact on the economy:
http://www.rti.org/newsroom/news.cfm?obj=DA7FBFE6-4A4F-4BFD-
B77E0FA3C04D9E22
31
32. MY CONTACT INFO
Lyle Huston, Quality Analyst
Lyle.hutson@sparkhound.com
Sparkhound.com/pages/blogs
LinkedIn: Search Lyle Hutson OR:
https://www.linkedin.com/pub/lyle-hutson/1b/856/25b
Editor's Notes
The CTFL-AT means Certified Tester on the Foundation Level with the Agile Testing certification addition.
Speaker: Lyle
When I started QA, I really had no idea what I was getting into. I just knew I loved technology, knew how to type, loved games and loved to learn. I figured, since there was a game company in town, that I’d give it a shot by starting anywhere on the ladder that I could. QA, as they call a gateway job into games, is where most people start; so did I. After only 6 months, I had to give a milestone report to our CEO and all of the management in the company. I was extremely nervous but the more I talked, the easier it got. I became more confident in the messages I was trying to convey to the team.
As time and experience went on, my responsibilities grew and the more I began to appreciate the position I held as being the center of attention when things were broken and how to break it. I was “that guy” that was like “what’s this and is this supposed to happen?” Everyone knew I could be counted on to really give my best effort when I tested something.
As I’ve grown in QA as a profession, I’ve begun feeling like this is information I would like to start sharing with other people to inform them of just how important QA really is and what bugs, when found early, can do for a company as far as lower cost and help improve quality early on.
The 2 certifications are from ISTQB – International Software Testing Qualifications Board. One is basically Waterfall Methodologies (the standard SDLC) and an Agile Certification
with #3 right around the corner
One of the games took over 3 years
Some years, 5-6 games were tested
A lot of people used to ask me “did you have problems testing games then playing them later on?”
I’m fairly
If you say “yes” to these, then you’re going to have a successful product in regards to presenting it to the client as a working, and stable product or tool
So, I’ve spoken a little about myself, now I want to ask you a couple of questions … (lead to next slide)
Poll the audience
Poll the audience
The Analyst, or the “QA”, analyzes the quality of the application to promise Version 2 is at least no worse than version 1, but also better than Version 1
The Quality Assurance is the Promise the Quality will be better, the Analyst is the person that does the work that ensures the promise
(mention before slide 1)
I went over the specific definitions to help describe and explain this point…
I was talking to our marketing team the other day about QA this and QA that, and they asked me a really good question…What exactly is QA? Is it a process you follow or is it just another word for “tester”?...what is it?
I hope this will help make what “QA” means, a little easier to understand.
Questions?
I’ve described the meaning of QA. Now, I’m going to talk about what a QA is and what a QA does.
While working with the previously mentioned group of people (dev’s, designers, BA’s)… (first line)
Various Testing Methods:
To keep a long story short and a lot of QA Jargon to a minimum, I’ll explain something of a buzzword; Accuracy Testing
Accuracy testing is primarily the testing methods used to prove all of the numbers you use vs what you expect to see are “accurate”. So, if you enter 2+3, you expect “5” not 6 etc
Tricks..I’ll show some of those near the end of the presentation
A Risk is anything note-worthy that a consumer or end-user would find problematic ( anything from data loss, unexpected software “glitches” to physical injury). The higher the risk, the more severe the issue.
Before listing the questions, tell the audience that I’m open for any and all questions you may have for your company (big or small project) and to ask at the end of the demo
Sure, it’s possible to make it across with the tools at your disposal (in this case a good sense of balance and a balance beam); but if even one of those “messes up” or “fails” you’ve bet your life on it.
What I mean by “try again” is finding critical bugs, fixing them, then “getting back on the tight-rope and trying again”
((Before clicking through the slide…)) Not that I’m suggesting that your lives are at stake by any means; it’s just, initially, some companies just don’t tend to think of exactly what kind of insurance having QA actually is and what we can actually do for you. (now read the slide)
((Read after the slide)):
An analyst works with the mindset of the end-user to the best of his ability based on his/her knowledge of the application to assess the app as the end user would.
I’ll discuss the “timing” of when to invest in QA later on
Also, “I did a little research and found that the US economy suffers almost 60b dollars annually due to bugs in production.”That’s why I mention (here) fix bugs early and throughout development
Waterfall is a form of sequential methodology that most companies use that is a heavily documented and uses formal process.
If you’re in the testing phase but then realize something is wrong with the design, you must stop testing and coding to fix the design, then start designing over again, then testing. It’s very “expensive” to back-track in Waterfall
A project that doesn’t need software maintenance would be something like a ball-bearing company
One that would need maintenance would be something like any tax-based software, banking, or oil “industry-type” projects
If you can, try and assess the competition if there’s competition out there. See what the team can do and try to help come up with ways “we” can do It better, more efficient, and/or cheaper (have the competitive advantage). As QA, if there is absolutely no advantageous reasoning to be a part of the planning phase, then QA can begin by making test case templates, getting tools in order and making sure all preparation steps are in-place if new QA ever need to be on-boarded before design begins
Tech research:See if the “best thing ever” is about to be outdated with the newest operating system upgrade and plan for that with your first versions of the product
Or, plan ahead by working with the next-best OS, while also being compatible with the most commonly used (found through research)
Good examples of this would be Windows Vista or Windows 7 and min specs for either machine, then having your application being compatible with everything up-to windows 10 – IE/Chrome/Safari
Agile is a very quick turnover type of methodology/process where there is very little documentation and work is done in chunks of time called “Sprints”; sometimes called “Iterations”. Agile incorporates the primary phases from waterfall, but uses them in 1-2 week cycles. Agile plans, designs, codes and tests all within 2 weeks in each little section (see above)
Agile plans don’t require QA to have test plans or test cases due to the time constraints within sprints. With proper time management, however, it’s very possible to incorporate having TC’s and plans in your project.
User Story – Basically a scenario based on some form of user type “As a _ user, I want to be able to….”
In Agile, even though it’s s small team, QA is not alone..
For Waterfall, this is when QA begins flushing out design issues as the design is being written and well before any code is written
Since Sprint – 0 is basically the planning phase for Agile client requirements, begin getting prioritized and somewhat categorized in difficulty-ranges and managed as a series backlog items or user stories
For both methods, communication must happen across the team to help mitigate duplicating efforts and maximizing productivity
During Waterfall, it’s heavily documented and there will be time to write test cases and plans per milestone. Testing is based around the design
Because Agile is very document-light, test cases, and test plans aren’t necessarily used for an agile project. Testing is based around and directly around requirements. Being able to edge-case, run regression checks and integration checks, then think outside the box in Agile is always a really good skillset to have.
Personally, regardless of method, I always prefer to build some form of checklist, especially if there is a little extra time in a given sprint before testing is required. This way, using the picture above, you can get a quick idea of how many spots or checkpoints there could be to test if you ran all of the permutations. (given a 1-on-1 type of check)
This slide is basically the “testing” sector
(bullet row 1) In waterfall, when you give a milestone report on all of the functions that should be working up-to that point on a case-by-case basis. In the same vain of thought, Agile will demonstrate the functionality to a client or stakeholder.
(bullet row 2) In Waterfall, QA makes sure the design matches the application and visa versa. When there are discrepancies, they are given to the BA and Devs (depending on where the concern lies) If the issue is in the Documentation, the BA is consulted, and Dev if the app isn’t like the design
For Agile, a client can make changes from sprint-to-sprint. Upon this happening, QA needs to ensure these changes don’t “break” the previous installments (sprints) and that the new functions work as intended
Integration testing = (grouping new functionality to old and testing them together) making sure no new implementations have broken any old functionality where the group(s) of efforts of work (sprint/milestones) still work correctly.
Regression testing = (comparing fixed bugs to current build making sure no new issues have arisen) making sure no fixes to existing work have broken anything else. Basically, re-running a completed test that once passed, that is now failing
QA basically helps with the up-keep of the application. For very large maintenance jobs, this could be an on-going phase for a long time if you’re supposed to support that application, tool, or product over the span of time (think commercial and industrial) (bank/oil/gas/etc)
Regardless of the method used, the sooner QA can begin working with their team, the sooner critical issues can be found and resolved giving more time to find and address other issues.
I did some research on this type of timeframe. On average, if you find issues during:
Design: it’s a 1-to-1 defect and fix cost comparison (best case scenario)
Coding: it’s a 6.5-1 defect and fix cost comparison (due to the time to find, fix, and re-test)
Testing Phase: It’s a 15 – 1 defect and fix cost comparison (due to time to find the bug, then fix, and re-test and regression)
Maintenance Phase: It’s a 100-1 cost if issues or bugs are found while the application is live or in production (worst case)
The phrase “death by a thousand cuts” could be as powerful as a single critical issue.
Again, by the end of a project, QA wants to confidently say “We’ve tested and verified this “thing” works to the best of our knowledge and ability. We’ve done our best job and we’re confident in its Quality”
All of these tricks are extremely easy to execute regardless of your technical skillset or job role.
Trick 1: You can cause “submission” forms to take a very long time, even timeout if you paste enough text into certain fields. Basically, from a quality perspective, it’s best to limit all textbox entries to a min and max value.
For trick #2, I’ve done this before and after the data was processed, the returned text would look like “?? ?? ? ???” because the syntax couldn’t be found. (Basically, from a Quality point of view, to disable charmap characters or ALT + Numpad
Trick 3, I’ve caused a great deal of null reference exceptions and just general page-load failures or timeouts
Awesome tools to use: Snagit, WinMerge, Allpairs, Excel, Solenium
UPON STARTING: to sign in it’s test@test.com / Guest1! OR: sql@today.com/Guest1! (use for the Multiple Admin bug… Bug #3)
Begin the demo stating, “I’m first going to go through this application as expected by the end-user and use the application for what it’s used for (like requirements would show). I’m going to book a conference room and save it under my username.” This is the ultimate goal of what this site is supposed to be able to do, and from what I can tell, it appears to work as expected; however, what I’m going to show you very soon is just how fragile the site is if you do anything outside of the expected functionality of the site.
As you start, login, click Conf Rooms > Book > Reserve This Room (today) > Select 8:00 – 9:00 > Click Book time (Observe the site appears to work)
Change the Date field and Click Search and observe the availability is open (showing the date you used is working)
Change the date back to (today) and observe the room is still booked
Click Home > Reset all data (seed data) and log off
Begin below
If you make any errors trying to make a new sign-in, you’re locked from making a new account (there’s an error)
There’s no requirements on the create a new user page
After signing in and being on the home page, click manage users and show the current roles, then go back to the HOME screen > make the current user admin (click the button several times), click manage users and notice each time you click the “make current admin” the “Admin” is shown in the list
If you click Conference Rooms > “Add new conference room” the app will crash
If you edit a conf room and enter “-1” is allowed while “a” is invalidated
If you edit a conf room and you enter “1.8” the app returns “0”
In the conf room and you click delete, there's no confirmation of destructive action
Conf room > edit > entering a very long name returns a non-friendly error message
Conf room > book > you can book a room in the past (this could be an issue depending on the type of site you may have/use/ require)
Conf room > book > 8am to 8am returns an array is too long
Conf Room > Book > 8am to 9:15am returns an error too
Conf room > book > the hour dropdown doesn’t show “7” when “7” shows in the listed times below
Conf Room > Book > attempts to book during times that aren’t listed; the user isn’t told they’re invalid times.
Edge case example (your series of checks is a list of numbers between 1-9.. Edge cases are 0 and 10
(when the page is done) Yep, it looks like a resume or job requirement.
I used to always tell people “I’m joined at the hip of the designer or BA during the design phase because I want to know everything about everything
Once this phase is approaching its end, there is sometimes an informal approval of the design document saying “its’ ready for coding to begin”
LOE – Levels of effort are assessed. This can actually be very challenging because you can easily misappropriate difficulty both too high and too low. This is “evolved” during your sprint-by-sprint efforts
Each “slice” or sprint is usually comprised of 2 weeks of time. At the end of that 2 weeks, QA Is capable of presenting the sprint’s functionality. This can be done to the team, product owners, stakeholders or anyone vested in the application.
By sprint 2, you’re already testing new implimentations and functionality. QA tests functionality in S2 doesn’t conflict with S1 (integration testing) and doing Regression testing, making sure no bugs found in sprint 2 will affect sprint 1.
This process gets more and more regression-heavy as the lifecycle progresses
By the end of 2-sprints, this is usually when a demo is presented to the client/customer (this is approximately 1month of dev)