Two MoTacon attendees are on the left. The MoTaacon logo is in the center, and to the right a prompt to Get Your Ticket.

Mirza Sisic

Mirza Sisic profile image
Mirza Sisic
Senior Test Analyst

I'm a tech geek, casual gamer, and sci-fi enjoyer. I love talking about software testing and being part of the testing community.

šŸŽ‚ MoTaBirthday | October 14, 2019
Open To
Write
Speak
Mentor
Podcasting
Chapter Lead
Explain your job as poorly as possible! image
There was a post on social media where people were asked to describe their job as poorly as possible. I said I basically click things and pester people with questions! How would you describe you...
27 Aug
STEC is complete šŸŽ‰: 19 modules, 59 voices, and a jam packed portfolio to show your growth image
Eighteen months, 19 modules, and 59 amazing contributors later, the MoT Software Testing Essentials Certification is complete! Looking back, my favourite part has been seeing so many community m...
18 Aug
Module 18 is now live in the MoT Software Testing Essentials Certificate! image
During filming for Module 18 of the MoT Software Testing Essentials Certificate, Marie Cruz put a demo e-commerce site through its paces with a k6 Studio load test and managed to reveal a hidden we...
8 Aug
Getting paid what you are worth as a software tester image
Recognise your true value as a tester, navigate salary negotiations with confidence, and make the most of benefits beyond pay
14 Oct
Low-code test automation tools: First impressions and recommendations for beginners  image
Evaluate the pros and cons of low-code automation tools through a tester’s hands-on experience selecting a solution
1 Jul
FinTech Testing 101 image
Watch this talk from Sarajevo MoT Meetup
23 Feb
Feature Spotlight: JQL image
Learn about JQL
15 Dec
Toast message A toast message (or often simply referred to as "toast") is a small, non-modal notification that pops up briefly on a screen to provide feedback about an operation.Key characteristics: Non-intrusive: It appears over the UI but does not block the user from interacting with the rest of the application. Transient: It disappears automatically after a few seconds without requiring the user to dismiss it, and goes away quickly. Informational: Typically used for low-priority updates, such as "Message Sent," "Settings Saved," or "Item Added to Cart." Traditional testing Traditional software testing is the process of evaluating a software application through test scripts to ensure it meets specified requirements and is free of bugs.In a traditional (often Waterfall) environment, testing is typically a distinct phase that occurs after the code has been fully developed but before the product is released to the user.Key characteristics Sequential timing: It usually follows a "test-last" approach, occurring at the end of the development lifecycle. Verification & validation: It confirms the software does what it was designed to do (Verification) and ensures it fulfills the user's actual needs (Validation). Documentation-heavy: Relies on formal and detailed test plans, test cases, and requirement traceability matrices, without much room for flexibility. Goal-Oriented: The primary objective is to identify bugs, errors, or gaps in the software to ensure quality and reliability. Pros and consThe Pros Stability and clarity: Since testing starts after the design phase, the "goalposts" rarely move. Testers know exactly what to look for based on fixed documentation, which can be good for heavily regulated industries where requirements can be very explicit, specific and detailed. Structured control: It’s easy to track progress and milestones. You know exactly when the testing phase begins and ends. Discipline: The heavy emphasis on documentation (test plans, scripts, and logs) creates a highly traceable audit trail, again a big plus in regulated industries. Reduced complexity: Because the software is "finished" before testing starts, there’s no need to worry about the code changing while you're trying to find bugs. The Cons Risk and rigidity: Late Bug Discovery: Finding a fundamental flaw at the very end of the cycle is expensive and time-consuming to fix, which means that testing is often perceived as a bottleneck. High risk of delays: If testing reveals a major issue, the entire release date is pushed back, as there is no "buffer" time. This can lead to bugs being ignored or swept under the rug. Lack of Flexibility: It’s very difficult to pivot. If a user's needs change halfway through development, traditional testing usually can't account for it until the next major version. The result of this rigidity is additional costs, in terms of time and money. The "Wall" effect: There is often a disconnect between developers and testers, leading to a "throw it over the wall" mentality rather than collaboration. Isolated teams communicate less effectively, which can cause misunderstandings and rivalries. Bug clustering The principle of Bug Clustering states that the majority of defects are often concentrated in a small number of modules or components of a software system. It can be seen as an application of the Pareto Principle or the 80/20 Rule in the context of software testing. Bugs are not uniformly distributed throughout the software. Instead, a disproportionately large number of defects "cluster" in a small percentage of the code. The 80/20 Rule: Empirically, it is often observed that approximately 80% of the defects in a software application are found in only 20% of the modules. This clustering usually occurs in high complexity areas, such as, modules with intricate business logic, numerous interdependencies, or complex algorithms are harder to test and maintain, making them more prone to error. Bug clustering can also happen due to code that is frequently modified, updated, or undergoing new feature development tends to introduce new bugs more often and in areas that rely on third-party libraries or old, poorly documented codebases.  Stack Trace The primary purpose of a stack trace is to be used in debugging to help developers locate the exact line of code and the sequence of function calls that led to a specific error, exception, or crash. In practice, it is a list that shows the call stack—the history of nested function calls—starting from the currently executing function (where the error occurred) and tracing backward to the function that initially called it, and so on, back to the program's entry point. Each line in the stack trace represents a stack frame and typically includes:  The function or method name.  The file name where the function is defined.  The line number within that file.  In summary, the developers use stack traces to find what part of the code caused a failure.  Behaviour Driven Development (BDD) Behavior-Driven Development (BDD) is an agile software development methodology that improves communication and collaboration between technical and non-technical team members by focusing on system behavior from the user's perspective, rather than on the technical aspects of the implementation. Focus on Behavior and Outcomes: BDD shifts the focus from writing tests for implementation details to defining and testing the desired behavior and business outcomes of the application as seen by the user. Improved Collaboration: It encourages continuous communication and shared understanding among all stakeholders—developers, testers (QA), and business representatives (e.g., Product Owner)—often referred to as the "Three Amigos." Ubiquitous Language (Gherkin): BDD uses a simple, structured, natural language (often called Gherkin) to write executable specifications (scenarios) that serve as both documentation and automated tests. Given-When-Then Structure: Behavioral scenarios are typically written using this clear, conversational template: Given a pre-condition or initial context. When an event or action occurs. Then an expected outcome or result is verified. Executable Specifications: These human-readable specifications are directly linked to code that can be automatically executed, meaning the documentation always stays synchronized with the actual system behavior, serving as living documentation.  Extension of TDD: BDD is considered a refinement and evolution of Test-DrivenDevelopment (TDD) and Acceptance Test-Driven Development (ATDD), applying its principles to a higher level of abstraction focused on business value.
Subscribe to our newsletter