Let’s take a look how the process of quality assurance has evolved in Cognifide. I would like to take you on a journey through the transformation of quality assurance process in our company from the dinosaurs to the electrically driven car sent into space. The short history from script approach to exploratory testing, from Testers to Quality Assurance Engineers, from manual to automated approach, from Quality Assurance to Quality Assistance, from Continuous Integration to Continuous Delivery and many other elements of our software quality path. Have we found an ideal and bulletproof Quality Assurance process? Has the evolution finished? If not, what’s next?
Adam Makarowicz – Principal Quality Assurance Engineer in Cognifide. 8 years of experience in software testing. A highly motivated person who always tries to find the most effective solution in any situation. Working closely with clients to overcome their difficulties and help them to reach their business goals. Swiftly changing hats of QA Lead, Technical Lead, Business Analyst to learn, share and accommodate project and company needs.
PTAQ L - Adam Makarowicz - The quality, or there and back againAdam Makarowicz
Let’s take a look how the process of quality assurance has evolved in Cognifide. I would like to take you on a journey through the transformation of quality assurance process in our company from the dinosaurs to the electrically driven car sent into space. The short history from script approach to exploratory testing, from Testers to Quality Assurance Engineers, from manual to automated approach, from Quality Assurance to Quality Assistance, from Continuous Integration to Continuous Delivery and many other elements of our software quality path. Have we found an ideal and bulletproof Quality Assurance process? Has the evolution finished? If not, what’s next?
Product QA - A test engineering perspectiveImaginea
Imaginea's time test product qa methodology. Our hawkeye methodology helps products get released to maker more efficiently and in lesser time. Products have to be tested with a gotomarket testing approach and thats what we specialize at.
Introduction to Software Testing - Part 2Sachin-QA
In this session you will learn:
Defect/Bugs in Software Testing
Quality Team Roles and Responsibilities
Career options available for a Test Engineer
Testing documentation
Testing Fundamentals
Testing Certification
For more information: https://www.mindsmapped.com/courses/quality-assurance/qa-software-testing-training-for-beginners/
In this session you will learn:
Agile Approach
What is ‘Agile’?
What does the Agile Manifesto Mean?
12 Principles of Agile (1)
12 Principles of Agile (2)
Central: Incremental and Iterative Development
Agile Methods
Scrum Lifecycle
Agile Methods – Scrum (1)
Agile Methods – Scrum (2)
Scrum Values
In this session you will learn:
SDLC and Quality Standard
What is SDLC and Stages?
Phases of SDLC
Design Types
SDLC Models
Waterfall Model
Spiral Model
V-Model
Big Bang Model
A guide for adopting Agile Testing. Gives the overall framework, principles and practices. Starts with Introduction to Agile Testing and then moves on to cover technical practices, HR and training needs which need focus during implementation of Agile Testing.
PTAQ L - Adam Makarowicz - The quality, or there and back againAdam Makarowicz
Let’s take a look how the process of quality assurance has evolved in Cognifide. I would like to take you on a journey through the transformation of quality assurance process in our company from the dinosaurs to the electrically driven car sent into space. The short history from script approach to exploratory testing, from Testers to Quality Assurance Engineers, from manual to automated approach, from Quality Assurance to Quality Assistance, from Continuous Integration to Continuous Delivery and many other elements of our software quality path. Have we found an ideal and bulletproof Quality Assurance process? Has the evolution finished? If not, what’s next?
Product QA - A test engineering perspectiveImaginea
Imaginea's time test product qa methodology. Our hawkeye methodology helps products get released to maker more efficiently and in lesser time. Products have to be tested with a gotomarket testing approach and thats what we specialize at.
Introduction to Software Testing - Part 2Sachin-QA
In this session you will learn:
Defect/Bugs in Software Testing
Quality Team Roles and Responsibilities
Career options available for a Test Engineer
Testing documentation
Testing Fundamentals
Testing Certification
For more information: https://www.mindsmapped.com/courses/quality-assurance/qa-software-testing-training-for-beginners/
In this session you will learn:
Agile Approach
What is ‘Agile’?
What does the Agile Manifesto Mean?
12 Principles of Agile (1)
12 Principles of Agile (2)
Central: Incremental and Iterative Development
Agile Methods
Scrum Lifecycle
Agile Methods – Scrum (1)
Agile Methods – Scrum (2)
Scrum Values
In this session you will learn:
SDLC and Quality Standard
What is SDLC and Stages?
Phases of SDLC
Design Types
SDLC Models
Waterfall Model
Spiral Model
V-Model
Big Bang Model
A guide for adopting Agile Testing. Gives the overall framework, principles and practices. Starts with Introduction to Agile Testing and then moves on to cover technical practices, HR and training needs which need focus during implementation of Agile Testing.
In this session you will learn:
Defect/Bugs in Software Testing
Quality Team Roles and Responsibilities
Career options available for a Test Engineer
Testing Documentation
Testing Fundamentals
Testing Certification
In this quality assurance training, you will learn basics of software testing. Topics covered in this session are:
• Course Overview
• Introduction to Software Testing
• Is Testing a Technical role
• Project And Product
• Quality Assurance Vs Quality Control
• QC VS QA
• Verification and Validation
For more information, visit this link: https://www.mindsmapped.com/courses/quality-assurance/software-testing-training-beginners-and-intermediate-level/
In this session you will learn:
Course Overview
Introduction to Software Testing
Is Testing a Technical role
Project And Product
Quality Assurance Vs Quality Control
QC VS QA
Verification and Validation
For more information: https://www.mindsmapped.com/courses/quality-assurance/qa-software-testing-training-for-beginners/
In this session you will learn:
Testing Concepts and Manual Testing
Overview of Testing Life Cycle
Testing Methodologies
Dynamic Testing
Black Box Testing
White Box Testing
Gray Box Testing
Unit Testing
Integration Testing
System Testing
Regression Testing
User Acceptance Testing (UAT)
Where does a Software Tester fit in the Software Development Life Cycle? What are the responsibilities of a Software Tester? What are the competencies of a Software Tester?
YouTube channel : https://www.youtube.com/c/prelrik
This course of slides are very useful for beginners or less experienced testers. The course focuses to teach how actually testers work in LIVE environment.
Aginext 2021: Built-in Quality - How agile coaches can contributeDerk-Jan de Grood
Built-in Quality is key when you want to achieve Business Agility. Yesterday I spoke at the AgiNext Conference in London. In my presentation I explained the importance of Built-in Quality, what is actually is and introduced an approach to implement it. The presentation explains how we can take a validated learning approach to eliminate waste and learn how to improve our development life cycle. I share the suggestions that SAFe makes and give a prioritised overview of quality measures. Throughout the presentation I share my thought on how Agile Coaches can contribute to built quality in.
In this session you will learn:
Defect/Bugs in Software Testing
Quality Team Roles and Responsibilities
Career options available for a Test Engineer
Testing Documentation
Testing Fundamentals
Testing Certification
In this quality assurance training, you will learn basics of software testing. Topics covered in this session are:
• Course Overview
• Introduction to Software Testing
• Is Testing a Technical role
• Project And Product
• Quality Assurance Vs Quality Control
• QC VS QA
• Verification and Validation
For more information, visit this link: https://www.mindsmapped.com/courses/quality-assurance/software-testing-training-beginners-and-intermediate-level/
In this session you will learn:
Course Overview
Introduction to Software Testing
Is Testing a Technical role
Project And Product
Quality Assurance Vs Quality Control
QC VS QA
Verification and Validation
For more information: https://www.mindsmapped.com/courses/quality-assurance/qa-software-testing-training-for-beginners/
In this session you will learn:
Testing Concepts and Manual Testing
Overview of Testing Life Cycle
Testing Methodologies
Dynamic Testing
Black Box Testing
White Box Testing
Gray Box Testing
Unit Testing
Integration Testing
System Testing
Regression Testing
User Acceptance Testing (UAT)
Where does a Software Tester fit in the Software Development Life Cycle? What are the responsibilities of a Software Tester? What are the competencies of a Software Tester?
YouTube channel : https://www.youtube.com/c/prelrik
This course of slides are very useful for beginners or less experienced testers. The course focuses to teach how actually testers work in LIVE environment.
Aginext 2021: Built-in Quality - How agile coaches can contributeDerk-Jan de Grood
Built-in Quality is key when you want to achieve Business Agility. Yesterday I spoke at the AgiNext Conference in London. In my presentation I explained the importance of Built-in Quality, what is actually is and introduced an approach to implement it. The presentation explains how we can take a validated learning approach to eliminate waste and learn how to improve our development life cycle. I share the suggestions that SAFe makes and give a prioritised overview of quality measures. Throughout the presentation I share my thought on how Agile Coaches can contribute to built quality in.
End-to-End Quality Approach: 14 Levels of TestingJosiah Renaudin
In 2015, the Standard & Poor’s Ratings IT team set out an ambitious objective—to tighten the process and controls around the quality of code deployed to production. Based on internal cost of quality assessments, and supporting agile and waterfall internal engineering processes, distinct testing levels were identified to help push quality left and root out the underlying causes of defects as early as possible. The ‘14 Levels of Testing’ were defined to collaboratively span organizational functions, establish quality expectations, and help track towards the goal of eliminating defects. Adrian Thibodeau and Chintan Pandya review their 14 Levels of Testing and focus specifically on sharing the processes and tools employed to help govern the delivery of quality. Adrian and Chintan discuss metrics and dashboards, defect lifecycle management, their home-grown QA Workflow Portal, testing vendor SLAs and contracts, and facilitating UAT best-practices.
In this quality assurance training session, you will learn introduction to software testing. Topics covered in this course are:
• Course Overview
• Introduction to Software Testing
• Is Testing a Technical role
• Project And Product
• Quality Assurance Vs Quality Control
• QC VS QA
• Verification and Validation
TO know more, visit this link: https://www.mindsmapped.com/courses/quality-assurance/get-practical-training-on-software-testing-quality-assurance-qa/
ISTQB eğitiminde yazılım testi ile ilgili önemli konulara ve örneklere değinilmiştir. "Test Nedir?", "Testin Prensipleri", "Test Teknikleri", "Yazılım Metodolojileri" ve daha birçok önemli başlık hakkında detaylı ve teknik bilgiler yaşanmış örneklerle verilmiştir. Bu sunumda, bahsedilen konu başlıkları ve daha fazlası genel haliyle anlatılmıştır.
Imaginea's Test engineering shares its process guideliness, best practices and recommedations for effective Product testing. Ensures software products behave the way they are supposed to.
Profile of QA professional having 6+ years of experience in software testing. Exhaustive knowledge of SDLC and STLC, all testing activities, processes and services. Having exposure to Automation Testing.
Similar to The quality, or there and back again (20)
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Essentials of Automations: Optimizing FME Workflows with Parameters
The quality, or there and back again
1. The Quality, or There and
Back Again
Adam Makarowicz
March 13, 2018
1
2. Adam Makarowicz
Principal Quality Assurance Engineer
8 years of experience in software testing
QA Lead, Technical Lead, Business Analyst, Product Owner
2
About me
10. 10
Exploratory testing
Exploratory approach
QA designs and executes tests simultaneously
relies on empirical knowledge
of the tested application
supports creativity
emphasizes personal freedom
and responsibility
continuously optimizes the quality
of tested work
Learn
Test
Design
Test
Execution
Analysis
11. 11
Standard checklist
A pre-scripted standard checklist:
list of standard aspects of the application that
must be checked
avoid situation when core features are not
tested
each project defines its own standard
checklist based on its platform requirements
13. 13
Session based approach, charters
Plan, execute and report the results of the exploratory session using the session based
approach.
charter – goal or agenda for the test session
follow the mission of the session
take notes during the session
report your findings
use tests session templates
14. 14
Cross testing
No duplication
Based on session notes
Great to learn how to test
21. 21
Automation
21
End to end
tests
Author feature
tests
Visual comparison
HTML comparison
JS errors
Design responsiveness
3rd party integrations
API / micro services tests
Unit tests
Code quality validation
22. 22
Definition of Done
Definition of Done
Task developed
– tests executed (acceptance and exploratory)
– regression tests done
– non-functional tests done
Maintainability achieved
– automated tests implemented
– documentation done
39. 39
Continuous delivery + Progressive UAT
Feature 1 Feature 2 … Feature N
UAT for Feature 1
UAT for Feature 2
…
…
Deployment of
Feature 1
Deployment of
Feature 2
F1
Sign-
off
F1
done
F2
Sign-
off
F2
done
…Sig
n-off
…don
e
Feature1Feature2Feature…
47. 47
Bug hunting
How?
all QA practice members in one room
we test and explore any application
we take a 2-hour timebox to find defects
and improvements
we log all things in one place
rules & scope are defined by the project
When?
in the middle of a project timeline
before the UAT phase
Since 2012 in Cognifide
Many roles to get wider spectrum
Recently I’ve become Product owner
Worked on QA Process across company, changing the way how we sell, verify, deliver the quality.
Whats is behind the title?
One step forward two steps back
Experiments
Success fails
As you will see we were experimenting a lot with different ways of working.
Not always it was end up with a success. We were changing one or multiple things and then validated if this is a good change. Sometimes we drop an idea after a short period of time. Sometimes it takes few years to understand to get a results.
Our journey is still in progress, we are still changing.
I would like to talk you through our path.
How the first process looks like?
I need to warn you, you can expect something really complicated, so stay focused
Are you ready for that?
Around 2004, beginning of the company, using JIRA
No quality activity presented.
Simplest possible workflow.
Testers exists
Standalone bugs
No clear status
That doesn’t mean that we have no testers back then
Testers were in company from the beginning but not visible in process
Tasks status checked via jira filters, very painful
Bugs raised as a stanalone tasks
Noone knows what is a status of the feature, a lot of reading in comments
Code, test, close.
First change in the process,
Highlighted testing in JIRA
After resolved – problem with clients.
Changed Resolved – means implemented and tested
Added Implemented
Additionaly Sub-bugsrestrictiion on unclosed subtasks
JIRA boards
Clear view on sprint
Clients starts understand that Resolved means implemented and tested.
Not only Testing in progress added,
Added Sub-bugs, now we were able to match bugs with feature, we know in what state is feature
Then
Added JIRA dashboards, team were able to get status just from one screen
Only when all sub-tasks are closed you are allowed to move task to QA Queue
We decided to leave simple workflow for sub-tasks. We don’t need to have same extended process then for them.
Na poczatku byly filtry
Pojawily sie boardy
Status calego taska na boardzie
Przesunac mozesz dopiero jak sa zamknięte
First just a cr – not in all projects
Then by TL – bottleneck
Then by min 2 devs with one Senior at least
Crucible, then Stash – better to present status in JIRA, create a branch from task etc.
Apart from jira, changes behind the scene
No test cases upfront
QA responsible to design end execute tests
Based on story description
Not only the jira workflow was changed, we introduced mamy more behind the scenes
Tested was involved after implementation,
We were siting together, but not designing the solution.
No test case upfront, we were never company like that.
Based on description of the story,
Full responsibility on QA to figured out what to test
Each project did on a little bit different
To standardise
Diffecences between projects
To do not forget about fundamentals
Because each qa did exporatory in a little different way, we had a problem that not all the projects consist the same quality verification steps.
So we get best practices from projects,
we created standard checklist,
it was added to each feature description to check if we verified everything.
Based on that we standarised our exploratory testing,
still we had oportunty to verify more
Still on Qmetry page there is our case study
As a test evidence for client
After manual tests
For regression
Problem with mainteniability
Some of the client requests from us evidence what was tested.
After exploratory testing, we were crating test cases for future regression.
Huge problem with updating tc, after a while tc were useless. Before executing we are almost always need to chenge it a little. Working in agile, not in waterfall, in development after each sprint we were doing some improvements.
http://www.qmetry.com/cognifide-managing-both-agile-and-waterfall/
Sometimes exporatory testing took to much time
Problem when to finish
What is the state
Not always we planned what is in scope
We force ourselves for that using session based approach and charters.
It was also a change in test result evidence, we drop test cases.
Testing notes were enough. We were able to show our clients what was tested.
Charters were devided into few.
We had clear timebox.
We plan what we are going to expore during each session
We are able to stop, thnik and decide if we need more.
Test session notes were connected to the feature in JIRA.
To improve quality level in our projects.
We introduced cross testing,
No duplication
Two testers must test same story
Story tested once by tester was retested by other tester.
Not duplicating the tests already executed, but extending it.
We had a session notes already so it was easy for next QA to verify what else he/she need to test.
Once we get more juniors testers, we try to use cross testing to learn them how to test our applications.
A lot waiting for cross check
Not delivered
We were started be more mature,
expirienced testers in the company.
So in the project with few that kind of testers often cross testing found nothing.
But this extend time to deliver feature, it was an usual situation that in qa queue we had many features waitng only for cross test
Then cross test found nothing but the sprint was already finished.
So we introduced test sessions debrief. Other tester debrief the session notes with first one
Short informal meeding, which was about to define if any more tests are needed. If not we simply close the feature.
Another way of speed up the teesting process
Integration between QAs – company pair testing
To speed up the learning process we introduced pair testing. Not only for that, it was also geat oportunity to integrate witch each other.
It was also a first mentoring action, which later transform for a whole program, that each week we have mentoring meeting which share the domain knowledge.
Some time ago we even organise company pair testing, we shuffle testers from any project to do a pair testing. That was a great fun and also oportunity to integrate with other testers with which we are not working daily.
Pair testing was great for juniors, we find how more expirienced testers work, test, what kind of bugs they find.
Process more mature but not in budget
Agree level of quality with client
Secure budget
Engage before the project
QA process and practive become more mature. We were verifaing the quality on many levels, we had already some standards, we weare clear what we want to verify as a minimum.
So we need to secure a budget for that in the projects.
We started taking part in the engagement even before the project. Started to be more proactive
During discavery phase we talk to client to highlight our vision on quality, agree tle level of quality. Agree what and when quality actions taking place during the project
A lot were checked
A lot of time to deliver something
Dev qa ping pong
We want that level of quality
Because we were testing more and more cases we end up with a situation that each feature consist some defects found during testing. This again place is on point that delivering the feature takes more time, we had a lot of discussions if the bug needs to be fixed or not. We were simply to good as a testers
Solution for that was a developer checklist
As a contract with developers
Demo content as a trick to force tests
At the begining of the project we agree a contract with developers what kind of activities they need to do before submitting a feature to test. The most important point of this list was demo content. It was a trick that forced our Devs to at least verify a basic scenario,
Others items on the list was to confirm if documentation is in place, code review pass, there was some design session with TL, it is working with the specific conditions etc.
Automation was already in place
First thing to descope
First when we have time,
then mandatory,
One person dedicated, whole team?
then only for key features
Balance
Big projects, clients
Till that time we were automating regression tests as a separate tasks. Of course that was a first thing to descope when we have limited time.
Once we started getting bigger and bigger projects we cannot work like that anymore
We added automation to our process inside the feature. First we had automation after the testing but before closing the task. So you are no able to close the feature story without proper automation
Then we gone one step further and automation needs to be delivered to tester along with implementation of the future itself. We were working closely with developers on features as soon as possible to do automation in parallel
We also test the set up when only one dedicated QA was automating regression but this lead us to a point where no one more then this tester were interested in tests.
A lot of activities needs to be done before close
Standardise the DoD
Delivered and maintainable
We had a lot of activities to finish before closing the story. We introduced definition of done, agreed on the begining of the project. This geve us a checklist to do not forget about anything
No longer open
Open vs new?
Misunderstood for a client
Similar:
Tested -> resolved
KANBAN
Powiazanie z procssem, czytelność, agile
Another change in Jira workflow
Open was misunderstood, everyone understands that I different way. Open Vs new why new is not open so is closed? A lot of discussions to be made with the clients to explain that.
That time we also sometimes started to use kanban so differentiate new with Todo allows us to maintain the approved stores which are valid and confirm by the tailted person
Checklist to know if ready for development
Stardardise actions required from client
How to know what needs to be ready before we move something into Todo column? Go through the dor list. This also standardised the actions that we required from the client, if the integration data are provided, if there are any dependency, did we done design session, are acceptance criteria are written etc
To be on the same page
To do it constantly
We also started using three amigos principle for verification if story is ready for development. Three perspectives meet together and decide if we are able to start
To use the same language
No technical stories and bussines stories
Upskill the BA = workshops
Stardardise a tempalte of story
Still chalenge when to use it
BDD describing
Wciaz nie jest jasne kiedy gdzie bdd
Before we had acceptance criteria in stories, but the one that was understable by Devs and QA were not by Ba. We introduced bdd I few project to test the new approach, it was not easy on the start. Then we standardised the way how we write it, provide template, had many workshops with ba, upskill temu how to write good bdd.
Still we have a challenge when to use it, not always it fit for purpose. We had an example of story which scope was to implement a design change described in bdd rather than just uploading a image
BDD from story into feature file
Dictionary,
Hard to balance
Idea BA write feature files
Not always BDD as automation
The benefit that we also want to get from bdd was to easily transfer acceptance criteria into a automated test. This requires a lot of attention from ba to use the same sentences over and over again. And as can imagine not always it was done. We try to encourage back to work on feature files instead of Jira description but it was to much. Our initial focus on bdd was to simplyfiy the requirement production. So still we were using bdd in stories for requirements but we stopped require that those will be 1 to 1 napęd into automated files.
To secure budget
To know excalcy what is in scope
What are our standards
As a whole company
Not only in QA practice we found standards usefully. As a whole company we worked out a document which consist our company wide standards. We had a good alignment between projects using the same standards.
We also known which standard our client select and expect from us .
Static ananlysis as part of build befere
Standard across company
Clear KPI what level support - TIOBE
Security rules into Sonar
Jacoco as test coverage
Static analysis was introduced before, but we would like to compare projects with each others and have a clear KPI
We I troduced qubacz and of course standardised a expected minimum KPI.
We also added a security rules into static analysis.
We were working together with other practices on the quality. It was ours initiative but other practices starts to be interested into the quality
Pozniej rule do security, wspolpraca praktyk od poczatku
Dostarczanie wspolne
Inicjatywa od qa do wprowadzania checkow przez devow
Mature company now
Qa audits, then review
Then mentoring
Reporting none,
Mandatory,
Only when client expect
Monitoring of NFR, Regression – smashing
JIRA as status
Governance as a company way
Raporty, na poczatku nie byo, potem byly mandatory, porownywalismy siebie nawzajem,
Potem raporty nie byly potrzebne
Potem doszedl smashing
Jak sie zminiala kontrola vs dojrzalosc
Ludzie stali sie doswiadczeni,
Jest ich wiecej
Nie ma potrzeby aby ich trzymac za reke
Przychodza jak maja problemy
Leads workshops
Z kontrol na enablement
With support on demand
The way how we test envolved
Again a lot of checks, qa proctice was more experienced
Extending AC by QA
Nie balismy sie rozwijania sie ac
Zamiast test cases byly ac
Tabelki status dev I qa
The biggest improvement
We were no longer testers
from the biz dev to bau on production
Developers responsible for tests
Before Flip over the wall
Implemented and tested
QA validation
To define what is in dev responsibility
Testing notes
Part of the story
Not on local machine!
Do we need more tests?
Green/amber/red tasks
Initial checks
Constant monitoring
Planned full tests
To get bussines feedback
QA was a master of merge
Separate features delivered
Kanban
Do not wait to the end of the sprint
Less regression on UAT
Hardening?
To help BA with their story production
Process which support the way we produce stories
Still not enough
Some parts of process to improved
PO part of the team
How to present which story is ready to deliver
Continuous deployments?
Demo to PO
Approve / decline
Release to Production
QA responsible to maintain version of application
JIRA + Bamboo
Version in feature,
Where deployed
Taka jaka potrzeba tak robimy w projekcie
Jenkins vs bamboo
Duplicated servers
Sync them, always the same version
Hot fixing
No downtime for authors/users
To get some fresh exploratory ideas
Not limited to QA – Financial and HR
Different devices
Did we found the balance?
Each project is different
Only common things standardised
Is not the end of our path