IEEE International Conference on Software Quality, Reliability and Security, QRS

About IEEE International Conference on Software Quality, Reliability and Security, QRS

About This Proceedings Series — Not a Journal

The IEEE International Conference on Software Quality, Reliability and Security, universally shortened to QRS, is recorded here with ISSN 2693-9177. Like the other titles in this set, it is not a journal. It is the proceedings series of an annual international conference, sponsored by the IEEE Reliability Society, at which engineers and scientists from industry and academia present work on how to build software that is dependable and trustworthy. Accepted papers are published in the conference proceedings and distributed through IEEE channels, including IEEE Xplore, and the series is tracked as a proceedings source in Scopus-based listings. The site record attributes to it an h-index of 13 and an SJR of 0.270, with no quartile shown. Those are early-series, proceedings-level figures and should be interpreted as such: QRS in its united form dates only from 2015, so its backfile under this exact title is younger and smaller than the longer lineage its predecessor conferences bring to it.

The letters in the name are the programme in miniature. Q stands for Quality, R for Reliability and S for Security. The conference's own description, repeated across its calls for papers, stresses that the three concerns complement each other and cannot be substituted for one another: software can pass functional tests and still fail under load, resist attack and still corrupt data, or be reliable in normal operation and insecure against a deliberate adversary. QRS exists to keep those questions in one room, so that testing researchers hear from security researchers, reliability modellers hear from practitioners, and tool builders are challenged by the people who must use their tools in production.

History: From Hong Kong in 2000 to a United Conference in 2015

The QRS history, as stated in the calls for the 25th and 26th editions, begins in 2000 in Hong Kong, where the first edition was held under the name Asia-Pacific Conference on Quality Software. That conference developed into the International Conference on Quality Software, QSIC. In parallel, the IEEE International Conference on Software Security and Reliability, SERE, served the security and reliability side of the same community. In 2015 the two conferences were combined into a single conference, QRS. The first united edition was held from 3 to 5 August 2015 in Vancouver, Canada. That merger explains a common source of confusion in catalogues: papers before 2015 may appear under QSIC or SERE, while papers from 2015 onward appear under QRS, but the community, the sponsorship and much of the leadership are continuous across the change of name.

Anniversary counting follows the 2000 origin, not the 2015 merger. The 25th QRS was therefore held in Hangzhou, China, from 16 to 20 July 2025, returning, as its call noted, to the country where the first conference was organised. The 26th QRS was announced for 22–25 July 2026 at the University of Florence, Italy. Edition numbers, locations and dates should always be checked on the official site for the relevant year — the conference has used techconf.org subdomains such as qrs15 and qrs21 for individual editions — because each year has its own committee, deadlines and venue arrangements.

The sponsor matters to the conference's character. The IEEE Reliability Society is the IEEE society concerned with reliability, availability, maintainability, safety, dependability, security and trust across hardware, software and human factors, with technical activities that include system and software assurance, trustworthy computing and cybersecurity, cloud computing and the reliability of artificial intelligence systems. QRS inherits that breadth: it is a software conference, but one rooted in a reliability engineering tradition that asks for evidence, measurement and failure analysis, not only for novel algorithms.

Scope: Quality, Reliability and Security Together

Calls for papers for QRS list a wide but coherent set of topics. Core topics include the reliability, security, availability and safety of software systems; software testing, verification and validation; program debugging and comprehension; information and software quality assurance; fault tolerance for reliability improvement; modelling, prediction, simulation and evaluation; metrics, measurement and analysis; software penetration and protection; software vulnerabilities; formal methods; malware detection and analysis; intrusion detection and prevention; operating system security and reliability; secure and reliable storage; information and knowledge management; mobile and smartphone applications; and work on the internet of things and cloud computing. More recent calls add artificial intelligence based techniques for quality, reliability and security, machine learning and deep learning models and systems, natural language processing and large language models, and knowledge-based techniques for the same ends. That addition is not fashion alone: learned components create new failure modes, new testing problems and new attack surfaces, and QRS treats the assurance of AI-enabled software and the use of AI for assurance as two sides of one programme.

A useful way to read the scope is by the kind of evidence each topic demands. Testing and debugging papers are expected to show that a technique finds real faults, ideally on recognised reference suites and real projects, with cost and false-alarm behaviour reported. Reliability modelling papers are expected to fit and validate models against failure data, not merely to propose a distribution. Security papers are expected to describe a threat model, evaluate detection or protection against plausible attacks, and discuss limitations honestly. Measurement papers are expected to define metrics operationally and show what decision they improve. Papers that ignore the evidential norm of their subfield are at a disadvantage at QRS even when the underlying idea is interesting, because the conference's reliability heritage makes reviewers ask, persistently, how the claim was validated.

Alongside regular papers, QRS editions typically include workshops, special sessions, industry or practice contributions, fast abstracts and a doctoral or student programme, with details varying by year. The 2015 call, for example, listed separate deadlines for workshop proposals, regular papers, workshop papers and a student doctoral programme. Authors should read the current year's tracks carefully: a short or workshop paper is not a failed regular paper but a different format with different expectations, page limits and sometimes different proceedings placement. Extended versions of selected QRS papers have also been invited to journal special issues — a special issue of the Journal of Systems and Software on software quality, reliability and security was organised around QRS 2019 — but such invitations are per-year arrangements, not a standing guarantee, and should never be promised to co-authors in advance.

How Review and Publication Work

QRS follows the standard IEEE conference cycle: a call with a submission deadline, peer review by a programme committee drawn from the three constituent communities, notification on a stated date, and a camera-ready deadline tied to IEEE publication requirements and copyright release. The 2021 edition's site shows the operational tail of that cycle clearly, with announcements on hybrid presentation arrangements, best paper award selection, camera-ready submission, IEEE copyright release and video presentation. Authors who have only published in journals should note how compressed and non-negotiable conference timelines are: there is usually no major-revision round, so a paper must be essentially complete at submission, and a missed camera-ready step can remove it from the proceedings.

Acceptance is competitive but not extreme. Compilations of QRS acceptance data across earlier editions report an average acceptance rate of about three in ten submissions over many years, with individual years varying — for example rates in the mid-twenty percent range were reported for several recent editions in those compilations. Those figures come from secondary compilations of conference data rather than from a single official statement, so this profile reports them only as an approximate historical pattern and directs authors to the relevant year's own report for an authoritative number. What can be said safely is that QRS is selective enough that acceptance signals genuine peer scrutiny, while remaining a community conference that welcomes solid applied and empirical work alongside theory.

Indexing, Metrics and Honest Interpretation

The site record for this proceedings gives ISSN 2693-9177, h-index 13 and SJR 0.270, publisher Institute of Electrical and Electronics Engineers in the United States, and subjects Computer Science and Engineering. An h-index of 13 under this exact title is consistent with a united series dating from 2015 whose predecessor titles hold part of the community's earlier citation history under other names. Readers tracing an author's record should therefore search QSIC and SERE as well as QRS for pre-2015 work, and should not penalise the conference for a divided catalogue history that its own community understands.

No Clarivate Journal Impact Factor is claimed here, because QRS is a conference, not a journal in the Journal Citation Reports. Its proceedings are sought in IEEE Xplore and are tracked in Scopus-based sources, which is the coverage that matters for most institutional counts of conference papers; coverage of a specific year in a specific index should still be verified for that year if an employer or funder requires it. Likewise, no article processing charge in the journal sense applies. Costs are conference costs — registration, and any workshop or additional-page charges set for that edition — and only the official site for the current year should be trusted for amounts. Any third-party site quoting a fixed publication fee for QRS should be treated with caution.

Who QRS Suits Best

QRS suits researchers and practitioners whose work sits at the meeting point of software engineering and dependability: a testing technique evaluated on real systems, a reliability model fitted to industrial data, a vulnerability study with a clear threat model, a quality assurance approach with measured outcomes, or an assurance method for machine learning components. Its mixed academic and industry audience rewards papers that state the practical problem plainly and report negative or limiting results honestly. Safety-critical and mission-critical domains — where, as the QRS special issue call put it, software failures can cause property damage, financial loss, injury or worse — are a natural home for this work, and case studies from such domains are valued when confidentiality limits can be respected.

It suits less well work that is purely about general software development process with no quality, reliability or security claim, general artificial intelligence with no assurance angle, or cryptography with no software-system connection. Those papers have larger, more specialised venues. It also suits less well authors who need a journal-length exposition or a revise-and-resubmit cycle; the better strategy for a large study is often a focused QRS paper on one validated result, followed by an extended journal version where the programme invites or permits it, with full disclosure of the earlier publication.

Practical Advice for Prospective Authors

Choose the track and topic area deliberately and write the evaluation to the standard of that area: baselines, datasets or reference suites named and justified, threats to validity discussed, and artefacts made available where possible. Define quality, reliability or security operationally in the introduction — which failure, which attacker, which metric — rather than invoking the three words as a general blessing. Keep the title and abstract specific; programme committees assign reviewers from them. Follow the current year's format and page limit exactly, complete the IEEE copyright step on time, and plan attendance or the year's permitted remote presentation early, including visas for the host country. Finally, cite the finished paper by its DOI and proceedings details, and if an extended journal version follows, cite the QRS paper in it.

Distinguishing QRS From Similar Names

QRS should not be confused with quality journals whose titles contain the same three words, with the Journal of Systems and Software special issues that have drawn on QRS papers, or with its own predecessors QSIC and SERE, which are earlier forms of the same community rather than separate current conferences. It should also not be confused with unrelated uses of the initials QRS in medicine or other fields. The identifying combination is exact: IEEE sponsorship through the Reliability Society, the 2000 Hong Kong origin as a quality software conference, the 2015 combination of SERE and QSIC, the ISSN 2693-9177 in this record, and annual editions counted from 2000, reaching the 25th in Hangzhou in 2025 and the 26th in Florence in 2026.

Frequently Asked Questions

Is QRS a journal? No — it is an annual IEEE conference whose proceedings are tracked with ISSN 2693-9177. What do the letters mean? Q for Quality, R for Reliability, S for Security. When did it start? The first edition was held in Hong Kong in 2000 under the Asia-Pacific Conference on Quality Software name; QSIC and SERE combined to form QRS in 2015. Who sponsors it? The IEEE Reliability Society. Where were recent editions? Vancouver hosted the first united edition in 2015, Hangzhou hosted the 25th edition in 2025, and Florence was announced for the 26th in 2026. What metrics does this record give? H-index 13 and SJR 0.270, with no quartile shown — described here as not publicly disclosed in the record. Is there a journal impact factor? None is claimed, because it is a conference proceedings series. How selective is it? Historical compilations suggest roughly three in ten submissions accepted on average, varying by year; consult the specific year's report for an authoritative figure.

Editorial Assessment

QRS earns its place by holding together three concerns that software practice constantly pulls apart. Its history is shorter under its current name than its community's real history, which stretches to 2000, and its proceedings metrics under this title — h-index 13, SJR 0.270 in this record — understate the standing of a Reliability Society sponsored meeting that draws both academics and practitioners and that has sustained itself for more than two and a half decades in combined form. Its papers are conference papers, with the brevity and unevenness that format implies, and readers should evaluate individual contributions on their evaluations and artefacts. For authors with validated work on testing, reliability, security or the assurance of AI-enabled software, it remains a focused, credible and appropriately demanding venue.

At a Glance — Verified Record Data

• Title: IEEE International Conference on Software Quality, Reliability and Security (QRS).
• Type: Annual conference proceedings series — not a journal.
• ISSN in this site record: 2693-9177.
• Publisher in this record: Institute of Electrical and Electronics Engineers, United States.
• Sponsor: IEEE Reliability Society, per the conference's own calls for papers.
• Origin: First edition Hong Kong, 2000, as Asia-Pacific Conference on Quality Software; QSIC and SERE combined into QRS in 2015, first united edition Vancouver, 3–5 August 2015.
• Subject areas in this record: Computer Science; Engineering.
• Metrics in this record: h-index 13; SJR 0.270; quartile not shown in the record.
• Recent editions: 25th, Hangzhou, China, 16–20 July 2025; 26th announced for University of Florence, Italy, 22–25 July 2026.

Topics Regularly Represented

• Reliability, security, availability and safety of software systems, and fault tolerance.
• Software testing, verification, validation, debugging and comprehension, and formal methods.
• Quality assurance, metrics, measurement, modelling, prediction and evaluation.
• Vulnerabilities, penetration and protection, malware, intrusion detection and operating-system security.
• AI-based assurance techniques, machine learning systems, language models and knowledge-based methods.
• Secure storage, information management, mobile applications, cloud and internet-of-things systems.

Reading a QRS Paper Well

A reader approaching a QRS paper for the first time should look first for the evaluation design rather than for the novelty claim alone. Ask what systems were studied, whether they were open, industrial or constructed for the study, how faults, attacks or failures were introduced or found, and what a practitioner would have to change in order to use the result. Strong QRS papers answer those questions in the text, report costs as well as benefits, and discuss where the method breaks. Weaker papers report only an average improvement on a single collection of examples. That reading habit, applied consistently, turns the proceedings from a long list of titles into a usable map of which assurance techniques have evidence behind them, which are promising but unproven outside one setting, and which problems — flaky tests, alert fatigue, brittle models, unrepresentative failure data — remain open for the next edition to address. It also explains why the conference keeps its three themes together: a testing result that ignores security, a security result that ignores reliability in operation, or a reliability model that ignores software quality will be questioned by the neighbouring community in the room, and the published discussion is richer for it.

For librarians and research managers, the practical task is simpler. Catalogue the series under its ISSN 2693-9177, link the predecessor titles QSIC and SERE for pre-2015 searching, and record individual papers by DOI and year. That preserves the continuity the community itself recognises, while keeping the bibliographic record accurate about which name a given paper actually appeared under.