Snuffling Cards App

Travel Expense Tracker App

Acceptance Criteria (High Level)

High-Level Acceptance Criteria here

1. Authentication flow works end-to-end
2. Add/edit expense with fields: Your name, Expense, Amount, Category.
3. Users can create, view, update, and delete their own expenses.
4. Input form appears before charts.
5. Reporting and analytics
6. API contract and documentation consistency
7. Postman collection and API reference reflect current payload/validation rules.
8. Quality gate (automated tests)
   • Fast route/API validation tests pass.
   • Playwright E2E happy-path and auth-guard tests pass.
   • CI test workflow installs dependencies/browser and runs the suite successfully.

Out of Scope

Password reset email, OAuth/social login, multi-tenant admin, shared wallets, attachments/receipts, budgets, recurring rules, export CSV, non-SQL production DB — not required by this spec unless you extend it.

Working on submitting my application. Two topics I currently think about

✓ Call for Speakers

When QA meets AI or Everything Everywhere All at Once

Artificial intelligence is no longer a futuristic concept, it is embedded deeply into today’s digital products, business processes and decision-making systems. As AI continues to evolve at remarkable speed, the role of Quality Assurance must evolve with it. Ensuring quality in AI‑driven systems is no longer about verifying deterministic outputs; it’s about understanding complexity, probabilities and the dynamic nature of systems.

AI’s conceptual roots stretch back to the 1950s, when early researchers sought to build machines capable of imitating human intelligence. Understanding how AI systems learn, reason and evolve has become essential for modern QA.

Unlike traditional software, which follows predefined rules and produces predictable outcomes, AI systems operate probabilistically. They adapt based on data, making them inherently less stable and more prone to unanticipated behavior. This shift requires QA teams to rethink their methods, frameworks and expectations.

During my presentation “When QA Meets AI,” I focused on some challenges we face when testing systems today. I walked through concept drift, explaining how models can silently lose accuracy as real-world conditions change. I also covered data poisoning, highlighting how even small issues in data quality can significantly impact outcomes. We also explored adversarial testing, showing how subtle, almost invisible input changes can lead to unexpected or incorrect model behavior.

What made this especially valuable was not just the theory, but connecting these topics to real world QA responsibilities how we, as quality professionals, need to detect, question and continuously validate AI systems in changing environments.

The presentation resonated strongly with the audience, sparking discussion and reflection, which felt nice.

I had a chance to attend the API Days Conference in Helsinki, Finland 2025. The conference brought together professionals from the API ecosystem, including developers, architects and business leaders. It was a great opportunity to learn about the latest trends and best practices in API design, development and management.

API Days Conference in Helsinki, Finland

SAVE THE DATE! APIOps Helsinki 2026 will bring the API community together again in June. This hands-on conference is an opportunity to work on current topics, connect with peers, and learn through workshops, expert panels and APIOps clinics.

🗓️ 2.-3.6.2026 📍 Epicenter, Helsinki, Finland

(Psst! Early bird tickets are on sale now - register early and secure your place at the conference at a reduced price)

Osaango is partnering with apidays and other partners for this event, proudly continuing the APIdays Helsinki tradition.

For 2026 my speech topic is “Boosting API Testing with AI. Postman”, more details in that post LINK [Boosting API Testing with AI.] (https://silver-palm-tree-5wpjrr79gp9c7959-4000.app.github.dev/ai/PostmanAPI/)

Many of us began with prompt engineering, agents represent a fundamental shift. Copilot Studio Academy allows to get familiar with tools free of charge, for the beginning at least. Here is my journey so far.

Recruit Level. IT Helpdesk Device Selection Agent

This agent helps employees choose the right equipment when joining a company or upgrading their devices.

✓ Agent Academy Recruit

This is DONE.

—

Problem: Employees needs a laptop, and wow cannot decide which one. Solution: The IT Helpdesk Agent guides users through the decision process.

The agent can:

1. Recommend suitable devices
2. Check compatibility with company standards
3. Suggest accessories or additional tools

This reduces the number of manual IT requests. The agent acts as a decision support system for IT procurement. The result is not just a response, but a persistent and reusable capability, moving from isolated interactions to designed systems. The Academy articulates this evolution well, agents combine large language models with retrieval mechanisms (RAG) to transition from passive responses to active task execution and automation.

Microsoft Copilot Studio Recruit is Completed

Operative Level

In Operative tasks get more complex. The level focuses on building enterprise-grade multi-agent systems and applying them to real business scenarios using Microsoft Copilot Studio. As part of the course outcomes, I designed and implemented two AI agents:

🤖 Hiring Agent Automates core hiring workflow orchestration and candidate evaluation.

🎤 Interviewing Agent Prepares interview materials, analyzes candidate fit, and supports the interview process. The goal was to design Hiring and Interviewing Agents that support recruiters and hiring managers. Key implementation areas are:

1. Multi-Agent Architecture
2. Trigger-Based Automation
3. Responsible AI and Safety Controls
4. Enterprise Data Grounding
5. MCP Server Configuration

Mission accomplished

Interviewing Agent

Hiring Agent

Practical constraints

• You need the right environment (Microsoft 365, Dataverse, all permissions - you basically admin too)
• Licensing matters
• Some features depend on access levels
• Not everything works out-of-the-box
• In other words: this is real-world engineering

Meetup events bringing together professionals across testing community. The event combines networking, knowledge sharing with focus on the future of software testing.

Finnish Testing Meetup in Helsinki, Finland

✓ Find the group here

About participation

Last meetup was a great opportunity to meet people and take part in discussions. I contributed to the program by sharing insights and actively participating in conversations about testing practices, challenges and innovation. The event also featured a competition for the Best Tester of the Year, highlighting excellence within the field.

Key takeaways

The presentations and discussions strengthened connections within the community and reinforced the importance of continuous learning and quality in testing.

✨ Voting is closed! ✨

You can cast your vote here.

If you’re building AI-powered applications, a solid understanding of REST is not optional, it’s foundational. The same principles that made REST the backbone of traditional web systems have made it a perfect fit for AI services: clear resource modeling, stateless interactions, and standard HTTP semantics.

Most AI models don’t manage state. Every request must carry its own context. That’s not a limitation, it’s exactly where REST shines. While refreshing my own skills and preparing for an upcoming APIOps talk, I built my own REST API and defining quality gates around it.

Reframing, while remembering Testing Automation Pyramid by M.Cohn: API testing is not just another layer, it’s the layer where quality gate actually takes shape. Think about it: If you’re working with AI, it’s worth asking: are you validating your system where it matters or only where it’s visible?

Testing Automation Pyramid by M.Cohn

So how and why API testing adds the layer of quality?

REST API Quality gates

Travel Expense Tracker (AI Features in Progress)

Before AI new feature change is merged into the Travel Expense Tracker, I expect a certain level of confidence in overall quality. Not assumed, not implied, but verified. And yet, without the structure, these checks are drifting. This is why I started to draft quality gates.

Quality gates are automated checks that must pass before a change is considered ready. They are not just a checklist, but a structure for thinking about where and how we validate behavior. And as with test automation in general, the effectiveness of these gates depends on how well they are distributed.

They follow the same principle as the test automation pyramid: many fast, focused checks at the bottom, and only a few broader, slower checks at the top.

At the foundation are unit-level gates. Fast, precise, and close to the code. When they fail, they point directly to the problem area. This is where most validation should happen, because it is the cheapest place to detect issues and the easiest place to fix them.

Above that sits the API layer 1, first in-process. REST rules, validation logic, authentication resolution. This layer ensures that the application behaves correctly as a service.

Moving further up, the API layer 2 is exercised again, but this time over real HTTP. This layer acts as a contract, ensuring that what is exposed externally matches expectations.

At the top are end-to-end gates. These cover critical user journeys: registering, adding an expense, logging out and back in, handling authentication redirects. They are the most visible tests, but also the most expensive. For that reason, they are kept intentionally small in number. Their purpose is not to validate every detail, but to confirm that the system works as a whole.

In practice what often goes wrong is not the absence of tests, but imbalance. Too many checks at the top, too few at the bottom. Too much reliance on slow, brittle validation, and not enough confidence built early. Thinking in Quality gates is meant to correct that imbalance. This ensures that most issues are caught where they are cheapest to fix, while still preserving a thin layer of high-level validation where it matters most.

Journey to be continued ..

This site is a GitHub Pages project. Most of the customization, content passes and troubleshooting happened in the editor together with an AI agent (the same kind of workflow you get in Cursor, Copilot Chat, or similar): I described the goal, reviewed proposed diffs, ran the site locally, and steered when something looked wrong. Note: document the progress into separate notebook etc., that will help to remember the tasks.

Below is the path we actually followed—not a generic tutorial, but the sequence that got this repository to a shippable state.

1. Start from a working baseline

• Jekyll via github-pages, theme loaded with remote_theme: mmistakes/minimal-mistakes in _config.yml, plus the usual plugin group (jekyll-paginate, jekyll-feed, and friends in the Gemfile).
• Synced with GitHub.
• Outcome: One clear source of truth: whatever is on main is what visitors see after the Pages workflow runs.

2. Install gems

• Installed gems with bundle install and ran bundle exec jekyll serve to catch Liquid errors and broken includes before pushing.
• Ruby 3.4 on Windows: the optional wdm watcher gem was dropped from the Gemfile because its native extension often fails on newer Ruby—the site still builds; auto-reload during serve is just a bit slower.
• Outcome: A repeatable command (jekyll serve) that validates changes in minutes.

3. Make the site yours in _config.yml and data files

• Site identity: title, url / baseurl, GitHub username, search toggle, and defaults for layouts (posts, pages).
• Author profile: wired through _data/authors.yml so posts can set author: … and pick up bio, avatar, and social links consistently.
• Outcome: Shared metadata instead of duplicating author blocks in every file.

4. Layer a custom look without forking the theme

• _sass/design-tokens.scss — colors, radii, spacing, and motion variables used across the skin.
• SCSS overrides — files such as _sass/default.scss, nav.scss, home.scss, grid_layout.scss, footer.scss, post.scss, and taxonomy.scss adjust layout density, cards, and archive presentation while following the theme’s structure.
• assets/css/custom.scss — entry point that pulls overrides together for the build.
• _includes/head/custom.html — extra font links (for example Cormorant Garamond, Newsreader, DM Sans) and any head snippets the theme leaves open.
• _includes/footer/custom.html — small extensions to the shared footer when needed.

We iterated visually more than once: try a direction, preview in the browser, revert or refine when something felt too heavy or off-brand. The AI was useful for generating coherent SCSS across many files; I still chose what matched the site’s tone.

5. Layouts, navigation, and bilingual structure

• Custom layouts under _layouts/ (for example home.html, posts.html, category layouts) shape how listings and hero sections behave.
• _data/navigation.yml and _data/translations.yml feed the primary nav and language switcher.
• _includes/language-switcher.html connects English pages with their Finnish counterparts.
• Finnish section lives under fi/ (pages mirrored from the root where it makes sense), and Finnish posts use lang: fi, permalink: /fi/..., and lang_ref back to the English URL.

Outcome: One repo, two languages, with explicit cross-links instead of duplicate sites.

6. Content workflow: posts as small projects

• Each post is a Markdown file under _posts/ with front matter (title, tags, categories, header, description, optional highlight_home).
• Long-form or spec-style posts (for example the expense tracker write-up) were drafted in passes: outline → sections → tables → tighten wording; the assistant helped keep structure and terminology consistent.
• Parallel EN/FI posts share the same factual content; Finnish versions carry translated titles, descriptions, and body copy, plus lang_ref for pairing.

What worked well

• Concrete prompts beat vague ones: “match Minimal Mistakes variables,” “do not fork the theme,” “keep fi/ permalinks stable.”
• Letting the agent run terminal checks (bundle exec jekyll build, status, diff) caught issues early.
• Treating AI output as a proposal: always skim the diff; typography and spacing need a human eye.

What I still do myself

• Final editorial voice on posts and bios.
• Deciding what not to ship (experiments removed, dependencies dropped).
• Privacy and accuracy—anything public-facing is still my responsibility.

If you are building something similar: clone a Minimal Mistakes starter, turn on jekyll serve, keep overrides in _sass + _includes, and use an AI agent as a fast editor and refactor partner—not a substitute for reviewing what goes to main.

Finnish version: Verkkosivuston rakentaminen tekoälyagentilla.