Software Quality Engineering

If you fall behind, skip Part 8 (old syllabus revision) and Part 3 (code) — do Parts 1, 5, 6 no matter what.

Based on the real papers I found online:

1. Total questions: around 50. Most are MCQs worth 1 mark each.
2. The rest are subjective questions worth 2, 3 or 5 marks.
3. There is NO negative marking. Never leave a blank. If you don't know, guess.
4. A student who sat the recent Fall paper finished it in 35 minutes and called it easy. So don't panic.
5. The MCQs are fill-in-the-blank sentences taken straight from the slides. Example from a real paper: "______ ensures project progress as per plan." Answer: Tracking and Controlling. So learn the sentences, not just the ideas.
6. Some MCQs also come from the first half of the course (CMMI, ISO 9126, defect definitions). That is why I added Part 8.
7. VU does not need the exact textbook definition in subjective answers. Your concept must be clear. Write in your own words, use bullet points, and always write something.

These came in the subjective section. Prepare these first:

1. Name the three major activities of software testing.
2. An error occurred at the client side after the product was delivered. What is it called? (Answer: a post-release / post-production defect.)
3. What are the best strategies that can make a project successful?
4. A customer wants to change requirements after delivery AND has reported an error. What steps would you take? (Answer: for the change → prepare a Change Request template, do impact analysis, share estimates. For the error → fix through a Hot Fix if urgent, or a Patch if the client can wait.)
5. Who provides the data for a project audit? (Answer: the Project Manager, then explain in your own words.)

Simple meaning: it is a set of rules that tells everyone in the company how to run a project from start to finish, so that no project depends on one person's memory.

Points to remember:

1. The PM Framework is a bridge between Development, Sales, Finance and Management. (This was an actual quiz question — the missing word was Development.)
2. Its objective is to make the project progress visible and auditable at any time during the project lifecycle.
3. Its audience is Higher Management.
4. It starts after the contract is signed.
5. It replaces random, "as you like it" development with a systematic and consistent approach across the whole SDLC.
6. Auditable data is put into all phases of project management.

The 7 artifacts (documents) of the PM Framework — memorise this list

1. Signed Contract
2. Specification Documents
3. Estimations
4. Gap Analysis
5. Project Plan
6. Demo Plan
7. Invoice Plan

Rules inside the framework (small details that become MCQs)

1. Scope can be cleared phase by phase or all at once — it depends on the project.
2. Scope must be baselined with Sales first, then with the Customer if needed.
3. Invites for the scope meeting are created by the PM.
4. If effort variation is more than 25%, a meeting with Sales is required.
5. Invoice deadlines are shared with the Finance Department.
6. Demos are given by the PM; if the PM is on leave, his replacement gives the demo.
7. There are two kinds of demo: Internal Demo and External Demo (with the client).
8. If a deadline is missed, the PM shares an updated plan and the updated deadline with the client and Finance.

Simple meaning: deciding what work will be done, how many hours it will take, and on which dates.

1. Project planning covers development effort, quality assurance and demo dates.
2. Estimation is a prerequisite to project planning. You cannot plan before you estimate.
3. Estimation is NOT the same as a timeline. This is a favourite exam point. - Estimation is measured in man-hours. - Timeline is progress shown on a calendar. - 200 hours does NOT mean 5 weeks.
4. A baselined project always helps to manage Change Requests. (Because you can prove what was originally agreed.)
5. Baseline data is always not what the actual data will reflect — the plan and reality will differ.
6. Task status values used in the plan: Completed, WIP (Work In Progress), Pending.
7. In the handout example: total task hours = 255, plus Project Management and Testing = 48, giving 303 total hours and 303 ÷ 8 = 37.875 man days.

Simple meaning: checking regularly that the project is actually moving the way the plan said it would.

1. Tracking and Controlling ensures project progress as per plan. this exact sentence appeared as an MCQ
2. Daily Standup meetings (SCRUM meetings) ensure daily progress and improve communication in the team.
3. Weekly Status Meetings ensure the overall progress of the project.
4. The Project Plan is the key input for monitoring. You cannot monitor without a plan.
5. Project planning is a prerequisite to project monitoring.
6. The main artifact here is the Weekly Status Report.
7. Depending on the nature of the project, multiple status reports can be generated. ← real MCQ, answer was Multiple Status

What is in a Weekly Status Report

Project Name · Planned Start Date · Planned End Date · Actual Start Date · Estimated End Date · Planned % Completion · Current % Completion · then a row for each Milestone/Phase with planned vs actual dates and % completion.

Simple meaning: an independent check to see whether the PM actually followed the rules.

1. The audit of the PM process area is done as per the PM Framework.
2. The Project Manager is responsible for providing the relevant data for the audit. came in the recent Fall paper as a subjective question
3. Project Health is determined by the Audit.
4. Audit data is used to take corrective measures.
5. The audit checks: Scope, Budget, Roadmap, Demo Plan, Updated Plan — each marked Yes / No / NA.
6. It also assesses project quality and the reasons behind known problems.

Project Health ratings (learn the order — easy MCQ)

Simple meaning: a way to turn "how much work is really finished" into a number, so you can see early if you are late or over budget.

1. EVM is a tool that gives objective measures of the cost and schedule performance of the whole project.
2. Its purpose is to highlight cost and schedule problems early, so remedial action is taken before it is too late to recover.
3. Earned value is expressed as a budgetary value of the work done on the project.
4. EVM is a project management tool, NOT a financial tool. common trick MCQ
5. The results are presented in graphical format.
6. Measuring planned effort against effort spent alone is often misleading — that is exactly why EVM exists.
7. The three values are: - Planned Value (PV) — the effort that was contracted/planned - Actual Value (AV) — the effort actually spent (taken from Weekly Status Reports) - Earned Value (EV) — the effort value of the tasks actually marked Completed

(All formulas and worked sums are in Part 2.)

Simple meaning: a famous industry report that studied why software projects fail.

1. Over the last decade the success rate of software and IT projects has improved, but the failure rate is still high and is a major concern for industry professionals.
2. The report gives three major reasons for failure.
3. The number one reason is inaccurate / improper Requirement Engineering.
4. If requirement engineering is not done accurately, there is an 87% chance of failure. memorise the number 87%
5. The biggest challenge for the industry is performing requirement engineering accurately, because it is very hard in today's fast-changing environment.

1. Requirement Engineering is easier said than done.
2. It becomes much harder when the client is not mindful of the requirements and puts requirement documentation on low priority. real quiz answer
3. This leads to ambiguity and uncertainty through the whole project.
4. If requirements are not documented, the development team is not sure what to build, so the chance of failure becomes very high.
5. Without proper documented requirements, the actual purpose of the software development is lost.

1. Requirement engineering is the most important area of the entire software life cycle.
2. Reason: an error made in this phase costs a lot in the later stages. real MCQ
3. Faulty or missing requirements are the biggest reason behind project failure.

The 5 problems that occur during requirement engineering

1. The requirement document is treated as an overhead in the SDLC.
2. In reality it gets only about 10% of the whole project budget.
3. Ideally it should get 20% of the budget for requirement gathering and documentation. real MCQ, answer 20%
4. Negligence in this phase negatively affects the entire project — quality, cost/budget, deliverables, meeting customer requirements, and revenue.

1. A requirement is a feature of the system, or a description of something the system is capable of doing, in order to fulfil the system's purpose. real MCQ definition
2. Requirement engineering is NOT a technical activity — it is purely a communicational activity. very common MCQ
3. Different stakeholders have different concerns and points of view.
4. The challenge is to create a win/win situation for all stakeholders.
5. A non-technical client is difficult because of knowledge issues.
6. A technical ("techie") client is also difficult at times, for the same reason — knowledge issues.

1. Software requirements come with a lot of variation and change through all stages of the SDLC.
2. In other domains, requirements are fully understood and fixed at the beginning and stay the same. The handout's example is the construction industry.
3. Software is not tangible (you cannot touch or see it) until the first demo-able version.
4. Requirements change AFTER that first demo. That is the core difference.

Memory trick: C C C F N V T → "Correct Coherent Complete Feasible Necessary Verifiable Traceable"

Attribute 1 — CORRECT

1. The requirement must capture the client's expectation with no ambiguity at all.
2. All stakeholders must communicate openly to correctly turn the client's need into a requirement.
3. Good practice: write the requirement in a single line.
4. It must not exceed 30 to 50 words in length.
5. Avoid open-ended and subjective terms.
6. Words like "etc." and "assumed" are completely inappropriate.
7. Handout example: "GUI should be user friendly." — What does user friendly mean? More images or more text? Which colour scheme? Fix: ask the client for a reference site or sample material to start from. Do not fall into the trap of subjective terms.

Attribute 2 — COHERENT

1. Requirements must be consistent and must not conflict with other requirements or with the project scope.
2. Vocabulary and technical terms must be consistent and defined, so all stakeholders are on the same page.
3. The requirement should be logical and should add value to the project.
4. Handout example: Requirement 1 says "Customer support should be IT ISO-ITIL 3.0 compliant"; Requirement 2 says "The network support should be ISO-90 – ITIL 3.0 compliant." Which is right? Answer: only ONE standard should be used.

Attribute 3 — COMPLETE

1. The requirement must not leave any room for guessing or assuming.
2. "Assumption is the mother of all failures." memorable line, easy MCQ
3. All stakeholders must understand it in exactly the same way.
4. It must express the entire need and state all conditions and constraints under which it applies.
5. Requirements should be closed-ended as much as possible.
6. Incomplete requirements lead to a faulty system, customer rejection and unhappy users.
7. Handout example: "The product shall provide status messages at regular intervals not less than every 60 seconds." — What are status messages? Where will they be displayed? Fix: state that they appear in a designated area of the UI or as pop-up messages.

Attribute 4 — FEASIBLE

1. A requirement is feasible if it can actually be implemented within the scope and limitations of the project.
2. In other words, a feasible requirement is one that can be satisfied.
3. Best practice: involve the developer to give a technical reality check.
4. It is very difficult to identify a feasible or non-feasible requirement without technical input.
5. Example given in the handout: "having zero bugs in a software product is not a feasible requirement", because proving it would take forever.
6. Handout example: "The product shall switch between displaying and hiding non-printing characters simultaneously." — Computers cannot do anything simultaneously, so it is not feasible. Fix: "The user shall be able to toggle between displaying and hiding all HTML and non-HTML tags."

Attribute 5 — NECESSARY

1. The requirement must be necessary and must add business value.
2. It should come from the business goals and the need behind building the software.
3. Work on what the CLIENT expects, not what the DEVELOPER wants.
4. Effort spent must be mapped to business value.
5. Unnecessary work leads to scope creep.
6. Gold Plating (adding extra features nobody asked for) is the typical example of breaking this rule.
7. Handout example: the client wanted one social media login plus normal sign-in. The developer got excited and built three social logins but forgot normal sign-in. The client rejected the demo, because normal sign-in had more business value from the customer's point of view.

Attribute 6 — VERIFIABLE

1. A requirement is verifiable if it can be implemented and demo-ed, and QA can close it after verification.
2. Requirements that are not testable are not verifiable.
3. Each requirement must be expressed unambiguously.
4. Avoid the words "must", "shall" and "etc." while documenting. real MCQ
5. Always ask the client for a numeric value.
6. Handout example: "Loading time of the website should be as minimum as possible." — What is minimum? QA has no number to test against, so development and QA will always argue. Fix: "Minimum loading time should be at most 200 milliseconds."
7. Good practice: get requirements vetted by the QA department too.

Attribute 7 — TRACEABLE

1. Requirements must be linked to their source in the Requirement Specification (SRS).
2. A requirement is unique if it has a unique identifier, like an ID number. real MCQ
3. Traceability is what ensures the product is built as per the need/requirements. real MCQ
4. Requirements must be linked with Use Cases, design and test cases.
5. Requirements need forward and backward integration (matching): - Forward integration → identifies WHERE the requirement gets USED. - Backward integration → identifies WHERE the feature ORIGINATED.
6. Handout example (real RCA): a project was delivered late. Root cause analysis found that the audit team could not identify which requirement the key developer was working on, and he had spent most of his time on a non-traceable requirement that was never in the SRS. Non-traceable requirements often lead to project failure.

1. Functional requirements define WHAT the system should do and how it should behave in a certain situation or environment.
2. They describe the core functionality of the application.
3. They may include calculations, technical details and other specific functionality.
4. They drive the application architecture of the system.
5. Functional requirements are captured using USE CASES. guaranteed MCQ
6. A Use Case is a list of actions or event steps, typically defining the interactions between systems, to achieve a goal.
7. Use Cases serve as the connector between the different phases of the SDLC.
8. The Use Case ID is what makes requirements traceable.
9. Use Case templates are used to generate Use Case diagrams.

Use Case template — the 11 fields (be ready to write these)

1. Use Case Name
2. Use Case ID
3. Actor
4. Summary
5. Pre-Condition
6. Post-Condition
7. Extend
8. Uses
9. Normal Course of Events
10. Alternative Path
11. Exception

(Two filled examples — Sign In and Register New Patient — are in Part 4.)

1. The first demo-able version leads to Change Requests or WishLists or Bugs from the client.
2. Changes are managed using a Change Request Template, used as an appendix.
3. Impact analysis MUST be performed before accepting any new requirement, and the result communicated to the client. real MCQ
4. This avoids conflict over schedule, budget and requirements.
5. The project team always has to put in extra effort for a change request.
6. Bugs must be fixed — because they are in-scope errors that were already committed to be delivered in correct form. real MCQ

1. A release is the distribution of the final version of the software product.
2. Product development is achieved via Release — a working product delivered to the customer.
3. A release contains: a set of features + environment variables + backlog.
4. Features are further divided into doable releases.
5. Each Release is itself a Project, with tangible deadlines.

How a release is built (exact source of a real MCQ)

1. Features are provided by the Sales / Business Development team.
2. Environment Variables are provided by the Technical team. ← real MCQ, answer Technical Team
3. An Environment Variable mainly means the next software version that the product must be compatible with.
4. Backlogs are discussed and finalised between Sales and the Technical team, then communicated to the technical team so it can plan the release.

1. Release management includes the planning, scheduling and execution of the agreed features of a release.
2. Deadlines and timelines are shared with the clients.
3. The most important part is getting APPROVALS on the schedule and the features to be added.
4. In short: release management is controlling a software build through its different stages.

1. A release note is a document distributed and released as part of the final product/build.
2. It contains: - the scope of the software product - performance benchmarks - features added / delivered - known issues / known defects the customer might face - which defects and deficiencies were fixed in this release - installation and deployment steps - test results and information about the test procedure - limitations - testing roadmap — included to give confidence to the client
3. Release notes are WRITTEN by the Technical Writer, but the QA team is the OWNER of the document. classic MCQ
4. They are distributed only after the product is carefully tested and approved.
5. Pre-release (dormant) defects are usually listed here.

1. SQA is the process of making sure the developed product meets the customer's requirements and all features work as planned.
2. The SQA team is considered the INTERNAL CUSTOMER of the product. confirmed real MCQ
3. The product is released only if the QA team approves it.
4. SQA is an ongoing process — it is part of every stage of the SDLC until the product is complete.
5. SQA is not a one-go process.
6. Correctness-centric activities are the basis of QA.

1. Requirements must be reviewed and approved by QA before they are finalised.
2. To prevent rework, requirements should be validated and approved by the Quality Assurance team. ← real MCQ, answer Quality Assurance team
3. QA writes test cases against all the use cases.
4. QA must be involved from the initial stages of the project.
5. QA is a major stakeholder in gathering and finalising software requirements.

1. Requirement verification is a structured and organised activity to confirm the built product fully addresses the documented and agreed requirements.
2. QA performs various tests during all stages of the SDLC.
3. Verification ensures a planned and documented procedure to identify defects.
4. Requirements must be validated and approved by QA and all stakeholders BEFORE development, to prevent rework.

1. The purpose of quality engineering is to ensure the delivered product is stable, reliable, and meets the client's requirements.
2. People expect a product with zero bugs or defects.
3. In reality, software with a zero-bug count is practically not possible.
4. This unrealistic expectation often leads to financial loss, loss of clients, and law suits.

1. QA and defects are always tied to each other — the relationship never disappears. (Slides call them "head-to-head".)
2. QA always tries to keep defects at a minimum level.
3. High priority or sensitive areas of the product should be defect free.
4. The last resort: at the very least, the critical functionality must work.
5. Defects must not damage or threaten the critical functions of the product.
6. Through standards and best practices defects can be reduced to a minimum, but never totally removed.

1. Pre-release defects are called DORMANT DEFECTS.
2. They are inactive but have the potential to create problems for users and customers.
3. They are triggered only in a specific situation, or they sit in a low-priority area where QA attention is low.
4. They usually do not get attention until they are triggered.
5. If they appear at a client site, they are fixed depending on impact, but they are usually made part of the release notes.
6. Handout example: a cash register scans thousands of items (bread, milk, cheese) every day without trouble. But when a customer pays using cash + credit card + gift voucher together, the system hangs — because this uncommon payment combination was never tested properly. this exact example is a real MCQ

1. Post-release defects appear in production or at the customer site.
2. The software supplier company has to pay from its own pocket to fix them.
3. They have a higher cost of fixing — mainly because of multiple installations; the defect must be fixed at every site.
4. Besides financial loss, they damage company image, trust, reputation and market position.
5. Handout example: a requirement was to export database logs into a CSV file. During testing, CSV worked fine. In production the CSV was generated but records went missing, requiring a hot-fix. Analysis showed that after 500,000 records, further records went missing. The fix: generate a separate CSV after 500,000 records and merge the two files into a third. QA had only tested 30,000 records because no upper limit was mentioned in the SRS. real MCQ

1. Defect prevention reduces both the number of defects and the cost to fix them.
2. It also digs into the sources of the error and suggests action to avoid them.
3. The key assumption: there ARE known error sources or inappropriate actions causing the defects. real MCQ
4. Every error source has to be fixed.
5. Best way: detect early → find the source → take corrective action so it does not happen again.

(a) Education and Training

1. The people factor is one of the most critical factors in designing, producing and delivering quality software.
2. Sometimes a lack of skills or relevant training leads to disastrous defects that could have been prevented.
3. "Change is constant and it is fast paced" — so engineers must stay aware of the latest trends.

(b) Domain Knowledge

1. Software developers are NOT domain specialists — they are pure TECHNICAL resources. ← real MCQ, answer Technical resources
2. For some projects, domain specialists are hired to work with business analysts and developers.
3. Domain knowledge is essential for understanding the requirements, because every domain has its own terminology.
4. The same word may have a different meaning in a different domain.
5. Low domain knowledge leads to ambiguity, confusion and demotivation in the team.
6. Handout example: a property tax calculation project — the resident supplies total covered area, total constructed area, total floors, and property type, so the right category and on-road/off-road rates can be applied. A domain specialist is needed to derive the correct rates and formula. real MCQ

(c) Lack of Expertise in Phases of SDLC

1. Delivering quality software depends on adherence to SDLC best practices.
2. Lack of execution details of the phases of the SDLC is a main cause of defects. real MCQ
3. Example: weak knowledge of Requirement Management or Product Integration is a root cause of defects.
4. There are also different variations of the SDLC; not knowing the chosen methodology hurts team performance.

(d) Lack of Process Knowledge

1. Process knowledge is essential at both team and individual level.
2. Creating a process and on-boarding/implementing a process are two different things. memorable line
3. Success depends on how well the process is defined AND how well it is implemented.
4. Handout example: during a project, after showing the demo, if the Project Manager is not fully aware of how to manage a Change Request, he may ask the developer to write out-of-scope code. This delays or impacts in-scope features, so defects appear in features that were in scope. real MCQ

1. Defect prevention helps, but it can never guarantee a 100% defect free product.
2. Realistically there will be defects, no matter how good the prevention mechanism is.
3. So a vigorous defect reduction process must be in place to remove defects.
4. The aim is to reduce defects as much as possible from their sources, to prevent them in future.

1. Inspection is one of the most commonly used QA activities.
2. To reduce bugs, INSPECTIONS are a very effective QA alternative. confirmed real MCQ
3. Inspections identify "smells" at any phase of the SDLC.
4. They are usually a walkthrough of different artifacts, to provide another EYE.
5. Inspections are applied at CODE level to check compliance with different artifacts. ← real MCQ, answer Code level
6. They are conducted by multiple teams in a coordinated way.
7. Because the examination is direct, the detected defects are precisely located and therefore easy to fix.
8. Handout example: during the development phase, before QA started, a code review found that when login is performed via social media, normal login generates an error. Multiple developers shared a code base. Inspection revealed that the social login plugin was changing the status of a variable at database level which the normal-login team was using — breaking normal login. Decision: use a different plugin. Lesson: the decision to use plugins or off-the-shelf solutions should be taken only after careful review.

1. Testing is defined as a CORE QA activity, with the purpose of identifying faulty areas to be fixed.
2. QA executes the product to find defects and to confirm the product gives the required output.
3. Testing is conducted at DIFFERENT levels of the SDLC, but the purpose stays the same. ← real MCQ, answer Different
4. Formal testing starts when the development team hands the code over to the QA team.
5. Different sub-testing activities then run to ensure stability, right up to post-release level.

1. Even with strong prevention and reduction, defects can still exist — and this is riskier in high-impact applications.
2. Examples of high-risk domains: medical, transportation, nuclear.
3. A few faults are generated only under rare conditions at real time.
4. It is impossible to test all conditions exhaustively.
5. So the final strategy is to break the fault–failure relation to contain the damage — that is, "tolerate" the fault or limit the resulting damage.

1. Traditional hardware systems need a high level of reliability and availability, and use backups that give reduced functionality if something fails.
2. N-Version Programming (NVP) = running multiple versions of the same specification in parallel.
3. If there is a fault in one version, a fault-free version is dynamically switched in.
4. N-Version ensures that faults in a limited number of versions do not compromise the global system.
5. The big criticism: the faults are NOT identified and therefore NOT fixed — which contradicts defect prevention. excellent subjective point, often missed

1. For safety-critical systems, a fault even in a low-priority area must be avoided because of the consequences.
2. Hazard reduction technique = automatic locking of some portion of the software.
3. Damage control is achieved through "escape routes", to ensure minimal global damage.

1. Defect Resolution is a process that keeps a record of a reported defect until the testing department closes it.
2. Normal flow: QA identifies the defect during testing → sends it to development to fix → returns it to QA to be validated.
3. Sometimes defects are not solved — because of lack of communication, misunderstood requirements, or inability to remove them.
4. In that case, all the parties must agree to it.

1. The defect lifecycle covers all the steps from defect identification/reporting to defect resolution.
2. All reported defects must be fixed, re-verified, and formally closed by the QA team.
3. Defects are tracked by assigning different statuses.
4. Statuses used: Assigned, In-Progress, Fixed, NotAFix, Pending, Not Reproducible, Closed.
5. The defect lifecycle starts with the DISCOVERY of the defect and ends when the defect is closed and confirmed as not reproducible. real MCQ
6. Workflows are the customised steps a defect goes through; tools provide pre-defined steps for this.

1. The most important factor: every decision about a defect must be accepted by ALL stakeholders.
2. If it is decided a defect will not be fixed in the current release, all stakeholders must agree.
3. Minor or cosmetic defects with very little impact are usually deferred to the next release, by mutual consent.
4. A reported defect can be re-classified as "not a bug" — but again, only with consensus.

1. Defect logging is the very first step in defect resolution.
2. QA tests the product to identify, discover and report all defects.
3. A defect log is created with parameters like defect ID, priority, severity level, current status.
4. Defect logging ensures that all the necessary details about defects are provided to the development team, so they can understand and fix them. ← real MCQ, answer Defect log

1. Defect tracking is the method to track discovered and reported defects.
2. It ensures defects are monitored and controlled through the different stages of resolution.
3. It is done using templates or tools to ensure a global status view.
4. Modern products are complex and may have huge numbers of defects with high severity, which makes logging and tracking very important.
5. Defect log files are shared among team members to improve collaboration.

Defect Log template fields

Defect Number · Date Created · Created By · Defect Description · Steps to Reproduce · PM Process · Lifecycle Phase · Priority · Owner · Assigned Date · Estimated Time to Fix · Status · Resolution · Resolution Date · Actual Time to Fix

Product based: 1. Defect resolution is an ongoing activity and continues even after the product is deployed at the client's site — even at just one site. ← real MCQ, answer Product 2. A special support team is available after deployment to provide hot-fixes. 3. The support and quality maintenance plan is established in the earlier stages of the SDLC. 4. Post-deployment defects are more critical and cost many times more than ones fixed earlier.

Project based: 1. Bugs are identified, reported and fixed during the project lifecycle. 2. All defects must be discovered and fixed before handing over to the customer. 3. Defects marked "NotAFix" must be agreed by all stakeholders. 4. Service Level Agreements (SLA) are signed by both parties for post-deployment support.

1. Product evaluation is the process of evaluating the reliability, stability and market value of the product.
2. It assesses the final version against requirements, best practices and software development principles.
3. Key components: code quality, sustainability of the product, defect backlog, features, reliability of features, compatibility, support of features.

1. Software maintenance defines the scope of support to be provided, with all relevant terms and conditions.
2. Product-based and project-based defect handling are different, and so is the post-deployment support.

The 3 levels of software support (memorise the order)

1. Usually MS Excel sheets are used to log and track defects. real MCQ
2. Many other free and paid tools are also available with extra features.
3. The support team holds the ADMIN rights and adds QA and Development resources as needed.

1. Mantis is a tool used to keep a log of and track the details of defects. real MCQ
2. It is also available on the cloud, which makes collaboration among team members and stakeholders easier and faster. ← real MCQ (how Mantis enhances collaboration = by offering cloud-based services)
3. Websites shown in the lecture: mantisbt.org (download/demo) and a hosted instance on mantishub.io.
4. Views demonstrated: Dashboard View, Defects/Issues Tracking & Logging, Detailed View of Defects & Issues.
5. Lab steps demonstrated in the lectures: - Create User - Create Project - Login via User - Add Users - Assign issues to Users - Change the description of a logged defect

1. Software testing is the process of executing the software product to ensure it gives the desired outcomes and satisfies all requirements and business needs.
2. It also finds defects and bugs, so they can be recorded, analysed and corrected.
3. In simple language: testing is comparing the ACTUAL behaviour with the DESIRED behaviour.
4. It provides a concrete and objective view of the quality of the product.

1. Testing is one of the major techniques to gain confidence in the software.
2. It is one of the most important parts of the QA activities.
3. It gives objective information about quality so stakeholders can trust the product.
4. It also reveals the risks associated with implementing the product.
5. The most natural way is to dry-run the software in a controlled or simulated environment, so defects are handled before deployment.
6. For software products, the production environment is simulated to minimise the bug count.
7. Products usually have performance tests as well.

1. Code is the main artifact to be tested.
2. Testing is performed by writing and executing test cases.
3. Test cases are derived from / written against USE CASES (SRS).
4. A test case describes the testing activities, pre and post conditions, expected system behaviour and result for a specific test.
5. A use case describes all the steps the final user performs to complete the task — and those steps become the input of the test cases.

Also remember: defect fixing and re-verification are both part of software testing. (Trap MCQ: "Debugging" is NOT one of the three major activities.)

1. Functional testing verifies that the software and all its functions perform in total conformance with the software requirements.
2. Its focus is the EXTERNAL behaviour of the software.
3. How the functionality is achieved internally (the programming/coding) is NOT tested here.
4. It is called abstract level testing, because it only ensures the software gives the desired output to the end user.

1. Structural testing is the complete opposite of functional testing.
2. It focuses on the INTERNAL implementation details of the product.
3. It tests the programming structures and data structures used in the program.
4. It verifies internal units such as code structure, blocks, data structures and all relevant interconnections.
5. It is concrete testing from the code viewpoint — code is tested at statement level, module level, or sub-system level.

1. Functional testing and black box testing are used interchangeably — functional testing is achieved by performing black box testing. real MCQ
2. In its simplest form it is an ad-hoc run and execution of the system to see any difference between expected and actual performance.
3. If there is a gap, the process is repeated to eliminate the possibility that a hardware failure caused the difference.
4. A Specification Checklist is a good way to perform this testing — it describes the functionality and features with sample input and expected output data.
5. Smoke Tests are the most abstract level of testing, aiming to ensure that the most important functions work.
6. Black box testing tests boundary values and exceptions besides normal flows.

Black Box — Example 1 (arithmetic / calculator)

The software takes input and gives output; what happens inside is unknown. Test ideas: - Test floating point numbers, integers, and the boundaries of integers - Divide by 0 — a classic error - Use mouse, keyboard, typing and pasting to explore ways of entering values

Black Box — Example 2 (Date class with DaysInMonth(month, Year))

Condition and boundary tests: - Check for leap year (every 4th year) - Try years such as even 100s, 101s, 4s, 5s - Try months such as June, July, February, and invalid values

1. Structural testing is achieved by performing white box testing.
2. It verifies correct internal implementation — programming/code, data structures, blocks, relationships and interconnections. real MCQ
3. It tests execution behaviour and internal code.
4. White box testing is performed by the DEVELOPER himself, because it requires extensive knowledge of the code and the flow of code. guaranteed MCQ
5. Different debugging tools are used to check coverage.

The 3 coverage levels

1. A review is another kind of software testing, performed BEFORE executing the test cases or the code.
2. A review is a STATIC testing method — the artifact (such as code) is manually examined WITHOUT execution. real MCQ
3. The goal is early defect detection and removal.
4. Mistakes overlooked in the early stages get identified and corrected, which improves software quality.

Rationale for reviews (why they are worth it)

1. Reviews are a time-saving activity.
2. They need no formal planning or resource utilisation — they are informal testing.
3. Defects identified at this stage are easier and less costly to fix than defects found in formal testing.
4. Reviews include code walkthrough and design walkthrough.
5. They are usually done by a more experienced technical person who is NOT the author of the code.
6. An informal code walkthrough also increases knowledge sharing.

1. Inspection is a TYPE of review — the most formal type of static testing.
2. The activity is led by a trained facilitator or moderator who is NOT the author of the code.
3. It aims to evaluate the level of compliance with specific rules, principles or best practices.
4. All inspection activities are well documented, and all defects identified are LOGGED in the defect logging sheet.
5. Code inspection is basically the removal of redundant or unwanted code.

Standard inspection questions from the handout

1. Is the compilation listing free of warning messages?
2. Are there any uncalled or unneeded procedures?
3. Can any code be replaced by calls to external reusable components or library functions?
4. Will requirements on execution time be met?
5. Is the code well-structured, consistent in style, and consistently indented?
6. Are there any blocks of repeated code that could be condensed into a single procedure?
7. Are symbolics used rather than "magic number" constants or string constants?

1. A test checklist is a list of steps to be executed every time testing is performed.
2. It lists all activities and tasks to be done before and during the test.
3. A test checklist is NOT functional testing — it does not include functional testing. trap MCQ
4. It is simply a list of activities to ensure readiness for formal QA tests.
5. Test checklists are very critical to test the overall behaviour of the system.

Example 1 — Data security checklist

• Are data inputs adequately filtered?
• Are data access privileges identified (read, write, update, query)?
• Are data access privileges enforced?
• Have data backup and restore processes been defined?
• Have data backup and restore processes been tested?
• Have sensitive and critical data been allocated to secure locations?
• Have data archival and retrieval procedures been defined?

Example 2 — Performance checklist

• Has the database capacity been identified?
• Has anticipated growth data been obtained?
• Is the database self-contained?
• Is the system architecture defined (Tiers, Servers, Network)?
• Have the various environments been created?
• Is load balancing available?

1. Configuration management is the collection of best practices for tracking and controlling changes in software development.
2. Multiple teams and resources work on different parts of the software at the same time, and their work needs constant changes.
3. The CM team keeps a record of different versions, determines what was changed and who changed it, and lets you revisit or revert changes.
4. Configuration management is closely associated with QA — QA receives the shipment of software code from the CM team, and vice versa.

1. Multiple developers work on a shared code base toward a single working software.
2. Development, testing, Beta and Production all need different versions of the same software.
3. SCM makes sure a specific version is available with all its change history.
4. CM eliminates the confusion and error caused by the existence of different versions of artifacts.
5. Tools used: VSS, TFS and Git.
6. There has to be a SINGLE repository to manage all the releases.
7. SCM manages which change requests were requested by which customer.
8. Versioning and backups make it easy to revert any change if a customer does not like a release.

1. A single product may have different versions based on different clients' needs, and each version may have multiple code bases.
2. Changes requested by one client must NOT be visible to other clients, and must not impact them.
3. It is SCM's job to manage customer requests and determine which version of software each client is using.
4. Without Configuration Management it is impossible to track multiple software versions and their multiple code bases.
5. Changes in software are a fact of life — either for error removal or for product refinement — and SCM must manage all of them in complete detail.

1. This is one of the most important activities in the whole testing process, because most testing decisions are made here and they determine the quality of the testing.
2. The decisions are based on key questions: - What are the objectives and overall goals of the testing activities? - Which specific areas/features of the software are to be tested? - What is the exit criteria — when do we stop testing? - In which environment(s) will the software be tested?
3. Test planning also involves defining the scope, approach, resources and schedule of testing, identifying test items, test cases, testing tasks, who performs each task, and any risks needing contingency plans.

1. A test case is a standard, formal document describing the testing activities, pre and post conditions, expected system behaviour and result for a specific scenario.
2. It contains test data, steps to perform, expected results and actual results.
3. Test cases result in DYNAMIC execution of code. (Contrast: reviews are static.)
4. All requirements are divided into use cases; test cases are then written against all the use cases to verify users can perform them.
5. Test cases guide the tester through a sequence of steps to validate that the application is free of bugs and works as the end user needs.

The 8 best practices for writing test cases (likely 5-mark question)

1. Each test case should test only ONE test condition at a time.
2. Multiple test cases should not be combined into a single test case.
3. Ensure coverage of both positive AND negative scenarios.
4. Include detailed test steps and all necessary data and information on how to execute the test.
5. Expected and actual results must be added. On any variation from the desired result, a defect must be logged, which then goes through the defect lifecycle; the tester verifies it again after the fix.
6. Test cases should be repeatable.
7. Avoid complex English to remove ambiguity and difficulty in understanding.
8. Test cases must be traceable to requirements (Use Cases).

1. Every product has functional requirements stating what the system is supposed to accomplish.
2. Test cases define all the steps to test that functionality.
3. When a test case is closed, the product is considered to be providing that functionality as per the requirement — test case closure means success of the functionality.
4. A test case can refer to multiple functionalities, depending on the use cases.
5. There can be multiple tests against one scenario.
6. If an individual step fails, then the OVERALL test case FAILS. real MCQ
7. Graphics have test cases also.

Test case template columns

Project Name · Module Name (in case of a Product) · Test Case ID · Test Scenario · Test Steps · Test Data · Expected Results · Actual Results · Pass/Fail · Comments The Comments section can be used to refer to the Use Case #.

(But the core testing activities are generally the same for both.)

1. A unit is the smallest and testable part of software — a function, class or interface.
2. Usually a unit has one or more inputs and a single output.
3. Unit testing is the level of testing where individual units are tested and algorithms are verified independently.
4. Its purpose is to validate that each unit performs as per requirements and design.
5. It is the very first level of testing and is more of a development process.
6. It is performed by the DEVELOPER himself. guaranteed MCQ
7. Because units are tested individually and independently, unit tests are a cheap way to verify functionality without impacting other functionality.
8. Unit tests ensure stability and functionality from the beginning, even before formal testing starts.

Impact of unit testing

1. It ensures early defect removal, because it is easy to look for defects individually and independently.
2. Because it is done in isolation, it is easy to debug the code and prevent defect reproduction.
3. The effort happens at the developer's level, and the developer can easily understand the code.
4. The cost of fixing a defect found during unit testing is much less than a defect found at higher levels.

1. Sanity testing is the next level of testing after unit testing, in which multiple units are tested together.
2. Multiple developers work on different modules of the same software on a common code base.
3. The SCM/Configuration Management team merges the code, and that merged code is handed back to developers to perform sanity testing.
4. The logic: if the units work individually and independently, they should also work in combination.
5. The focus is on the integration of different components working together, so components and their interconnections are examined.
6. Before and after integration, the testing result should be the same.

Sanity Testing Reporting

1. Provides the overall status of integration testing.
2. Helps identify critical areas that are to be fixed.
3. Features are identified with the data that requires bug fixing.
4. Bugs are classified for all units/features as Critical, Major, Medium and Cosmetic.
5. Example in the handout: a product with 4 features — Registration, Booking, Payment and Reports — showing bugs by severity level. It reflects the integrated status of multiple features.

1. Features are functional requirements that are developed as a unit.
2. Depending on the size and nature of a feature, there can be multiple underlying UNITS. ← real MCQ, answer Units
3. Feature level testing makes sure the software and its features work properly to meet all intended specifications and requirements.
4. Feature level testing requires integration testing if there are multiple units.
5. In feature level testing, all features of the product are to be tested.

Example 1 — Feature: Booking of a Hotel Room via Website

Underlying units: 1. Registration of User 2. Searching of Rooms in Hotel 3. Selecting a particular Room in a Hotel 4. Filling in payment details 5. Verification of Payment Details 6. Generation of Unique Booking ID 7. Sending Booking ID to User via Email

Example 2 — Feature: Hierarchy Management (N-Level)

Underlying units: 1. Register Hierarchy 2. Add Hierarchy Name 3. Add Hierarchy Level 4. Add Root of Hierarchy 5. Root Hierarchy can have a child 6. Child can be a root node also

1. This is an advanced level of testing where the fully integrated final product is tested.
2. It is evaluated in the exact environment in which it will be used by the end users — the nearest possible match to the Production Environment.
3. It tests behaviour from the USER's viewpoint.
4. It evaluates the overall architecture and the product's ability to satisfy business requirements.
5. It has very little to do with code design and structure.
6. System testing is performed by INDEPENDENT testers who did not contribute to the development activities. guaranteed MCQ
7. It verifies the application meets the technical, functional and business requirements set by the customer.

1. Stress testing is another form of system level testing.
2. Its purpose is to evaluate the effectiveness and stability of the software under UNFAVOURABLE conditions.
3. It mostly involves quantitative tests to gather stats on the frequency of crashes and errors.
4. Benchmarking is done.
5. During the test, adverse and unfavourable conditions are created DELIBERATELY and maintained.
6. The fully integrated system is evaluated in those environments to measure its breaking point.
7. Classic example: hitting a website with multiple concurrent users/clicks to test the load.

1. Regression testing verifies that with the addition of a new feature, the previously developed and tested system still performs correctly.
2. A complete project includes maintenance, defect fixing, optimisations and error correction, all of which continuously update the product.
3. The goal: make sure a change in one part does not impact other parts, and that the newly added features are fully integrated with the existing system.
4. In one line: regression checks that previous behaviours are still intact after enhancements.

Handout example

In release 1.1 two features were added/updated (Discount Card, and payment with Discount Card / PayPal). These must not impact the already developed features — and regression testing verifies that.

1. Test reporting is the most important artifact of the whole software testing activity.
2. It shows the overall status of all testing performed throughout all stages.
3. Because there are different tests at different stages, it is extremely important to track all tests and their results.
4. It helps perform root cause analysis and follow-up.
5. One common format is the Test Dashboard.

1. Test dashboards are the statistical analysis of the overall testing activity in progress.
2. Data is presented statistically and visually.
3. They help the QA team monitor test activities, report on progress, find gaps in test coverage, and identify test areas that may require additional investigation.
4. They help decision makers modify test cycles.
5. Example 1: the dashboard shows the count of defects of all statuses (closed, fixed, hold, NotAFix, etc.) separately for all the features of the product.
6. Example 2: the same data shown graphically, which makes it easy to understand and helps identify priority areas.

1. Release notes are distributed with the software release, revealing what is included in the software — the features, and the steps to install and deploy the product.
2. The list of known defects that are NOT fixed is part of the release notes.
3. They also mention what defects and deficiencies WERE fixed in that particular release.
4. They contain test results and information about the test procedure, to increase client/end-user confidence.
5. Release notes include outstanding issues and limitations.
6. The testing Roadmap is shared in the release notes.

1. Productionizing means deploying the staging server codebase to the Production Server, which is provided by the client or arranged with a vendor.
2. Post-production issues are reported by END-USERS once the staging environment is productionized.
3. A good QA will ensure there is no critical bug on the production side, but even good QA cannot ensure 100% bug-free code.
4. An issue that is low priority from the development viewpoint may be HIGH priority from the end-user's viewpoint — and it still needs to be addressed.

1. Pre-production and post-production issues are handled differently, simply because the end-user is usually not involved during development.
2. During development, in-scope bugs are fixed and shipped to ensure maximum compliance with the agreed requirement.
3. In production, the client may report something that is not a bug but still needs fixing. There are two kinds:

4. THE FIRST STEP when an issue is reported from production is to CLASSIFY it as either a Bug or a WishList, and only then take the appropriate steps. very likely MCQ

1. Hot fixes are issues reported from Production (the Live Site).
2. A hot fix can be either a WishList or a Bug — in either case there is very little time to respond, because of importance and criticality.
3. There are scenarios where the client is not worried about the cost and just wants the issue fixed as soon as possible, because it may be impacting the business.
4. In this situation, the complete QA process is NOT executed, mainly because of the time factor.
5. The team depends on Unit Testing and Code Reviews to fix hot fixes, rather than Regression Testing. memorise this exact line

1. A patch, as opposed to a hot fix, is for issues that are critical but where the client can wait for a short period of time.
2. The timeframe for a patch to be delivered is less than for a Release.
3. The dev team does a proper estimation which INCLUDES QA cycles, and then shares the deadline.
4. Usually leftover bugs, or WishLists, or both, are delivered as a patch after a Major Release.

Handout example of a Patch

A client asked for a website where a user registers via the registration page, fills the form, submits details, and can then log in with credentials. After the project was delivered, the client wanted registration using Social Media. - The catch is to identify this request as either a WishList or a bug. - The Specs document / SRS is what settles this, because in case of a conflict, verbal communication is not enough to convince the client. - If the client agrees it is a WishList, then estimates and deadlines are shared accordingly.

SPI = Earned Value (EV) ÷ Planned Value (PV)

CPI = Earned Value (EV) ÷ Actual Value (AV)

How to never forget which is which

• EV always sits on TOP in both formulas.
• SPI → Schedule → divide by Planned Value.
• CPI → Cost → divide by Actual Value (actual money/effort spent).
• In both, less than 1 is BAD news.

What the three values actually are

• Planned Value (PV) = planned effort = the contracted effort
• Actual Value (AV) = actual effort taken from the Weekly Status Reports
• Earned Value (EV) = the effort of all tasks marked "Completed" in the project plan

Given: - Planned Value (PV) = 206 - Actual Value (AV) = 358 - Earned Value (EV) = 230

Step 1 — CPI: CPI = EV ÷ AV = 230 ÷ 358 = 0.642 0.642 is less than 1 → OVER BUDGET

Step 2 — SPI: SPI = EV ÷ PV = 230 ÷ 206 = 1.116

IMPORTANT WARNING — there is a mistake in your handout here. The handout writes the final result as "Over Budget --- Behind Schedule". But SPI = 1.116 is greater than 1, which by the rule means AHEAD of schedule, not behind. What to do in the exam: if you are asked to calculate, apply the rule properly and write "over budget, ahead of schedule", and show your working. The working is what earns the marks. If the MCQ options force you to pick the handout's stated answer, pick it. Do not lose time arguing.

Given: - Planned Value (PV) = 112 - Actual Value (AV) = 216 - Earned Value (EV) = 40

Step 1 — CPI: CPI = 40 ÷ 216 = 0.185 → less than 1 → OVER BUDGET (Reason line from the handout: "Actual is greater than what is earned.")

Step 2 — SPI: SPI = 40 ÷ 112 = 0.357 → less than 1 → BEHIND SCHEDULE (Reason line: "Earned is less than Planned.")

Final Result: The project is Over Budget AND Behind Schedule.

Total Man Days = Total Hours ÷ 8

Handout example: - Sum of all task estimates = 255 hours - Add Project Management and Testing = 48 hours - Total Hours = 255 + 48 = 303 - Total Man Days = 303 ÷ 8 = 37.875

Total Man Time = Number of Participants × Planned Time

Level 4 (measure it): | Meeting | Participants | Planned Time | Total Man Time | |---|---|---|---| | Internal Kick-Off | 4 | 60 min | 240 min | | Client Kick-Off | 5 | 60 min | 300 min | | Total | | | 540 min = 9 hours |

Level 5 (optimise it) — Option 1: reduce the audience | Meeting | Participants | Planned Time | Total Man Time | |---|---|---|---| | Internal Kick-Off (PM, Team Lead) | 2 | 60 min | 120 min | | Client Kick-Off (Client, PM) | 2 | 60 min | 120 min | | Total | | | 240 min = 4 hours |

Level 5 — Option 2: merge the two kick-offs | Meeting | Participants | Planned Time | Total Man Time | |---|---|---|---| | Kick-Off (PM, Team Lead, Client) | 3 | 60 min | 180 min | | Total | | | 180 min = 3 hours |

The moral of the story line to quote: "Process without Stats can't be improved."

Cost = A(F) + B(Q)

Where A and B = levels of investment, F = Features/Functions, Q = Quality

1. In most development projects, functionality and quality (QA precisely) are natural enemies.
2. Budgets are usually fixed, so features and quality compete for a share of the budget.
3. In a fixed-price project, if the number of features increases, the quality decreases.

Worked example: Total budget PKR 100,000 for 4 features - Cost per feature = 100,000 ÷ 4 = PKR 25,000 - Development cost of 4 features = PKR 80,000 - Quality cost of 4 features = PKR 20,000

Risk Exposure (RE) = Probability (p) × Potential Loss (L)

Risk is defined by its probability and its impact / potential loss. Probability and loss are directly and strongly related to the level of criticality of the software.

IEEE criticality levels (memorise the order A → D)

<?php
    $Amount = 100;
    if ($Amount = 100)          // WRONG — this is the ASSIGNMENT operator
        echo "Start calculation";
        Calculatetax();
    else
        Exit();
    ?>
    

What is wrong: = assigns a value; == compares. So the condition is always true.

Corrected version:

if ($Amount == 100)         // CORRECT — comparison operator
    

Concept to write in the exam: - Error = a human action that produces an incorrect result — a mistake made by the programmer. - It can be a syntax error or a semantic error. - Causes: confusion in understanding the requirement, miscalculation of values, or misinterpretation of a value. - The cost of fixing a logical error increases with the number of lines of code to be analysed.

Requirement: write a program to add two numbers.

#include<stdio.h>
    int main () {
        int value1, value2, ans;
        value1 = 5;
        value2 = 3;
        ans = value1 - value2;                          // <-- THE FAULT
        printf("The addition of 5 + 3 = %d.", ans);     // <-- THE FAILURE shows here
        return 0;
    }
    

How to answer: - FAULT: an incorrect step, process or data definition in the program. Here, due to the wrong sign (- instead of +) there is a deviation from the expected result. Faults are the result of errors. - FAILURE: the inability of the program to behave as expected within the given performance requirements. Here, due to the fault there is a failure in the output — instead of adding the two numbers, it subtracts them. Output shows 2 instead of 8. - Laprie's definition to quote: a system failure occurs when the delivered service no longer complies with the specifications.

The chain to memorise: ERROR → FAULT → FAILURE

Famous bug example to quote: 28 July 1962 — Mariner I space probe. A bug in the flight software caused the rocket to divert from its path on launch, and mission control destroyed it over the Atlantic. The investigation found a formula written on paper in pencil was improperly transcribed into computer code, so the computer miscalculated the trajectory.

Defect example: the user expects to make online payments with debit/credit cards, but the option to select the debit card is missing in the production software.

Float calculate (int a, int b, int c)
    {
        Float e = 0.0;
        if (a == 0)
            return e;
        int x = 0;
        if (a > b && c < b && c > a)      // try a=4, b=3, c=2
        {
            x = a;
        }
        e = 1/x;                          // DANGER: divide by zero if x stays 0
        return e;
    }
    

How to answer: 1. Statement Level testing ensures every statement executes at least once. 2. Branch Level testing ensures every branch (if-else, while, for, switch) is taken both ways. 3. Test 1: a = 0 → covers the early return e; branch. 4. Test 2: a=4, b=3, c=2 → the condition is FALSE (because c=2 is not greater than a=4), so x stays 0, and e = 1/x causes a divide-by-zero error. This is the hidden defect this example exposes. 5. Test 3: values that satisfy all three conditions → x = a, and the division is safe.

int main () {
        int a, b, c;
        c = a + b;
        if (c > 100) { cout << "It's done"; }
        if (a > 50)  { cout << "It's Pending"; }
    }
    

The four test cases given in the handout:

Point to state: Path Coverage means testing all the possible paths (all decision points). Path level testing ensures maximum coverage of code.

Bonus point if asked to critique: these four cases do not cover the TRUE-TRUE path (both conditions true at once). A case like a = 60, b = 60 would cover it.

public class Calculator {
        public int add (int x, int y) {
            return x + y;
        }
        public int sub (int x, int y) {
            return x - y;
        }
    }

    public class test {
        public static void main(String [] args) {
            int result = 0;
            Calculator a = new Calculator();

            result = a.add(5, 9);
            System.out.println(result);      // expected output: 14

            result = a.sub(5, 9);
            System.out.println(result);      // expected output: -4
        }
    }
    

How to answer: 1. Each method (add, sub) is a unit — the smallest testable part of the code. 2. The test class exercises each unit independently, comparing the actual output to the expected output. 3. This is done by the developer himself, before the code goes to QA. 4. Unit tests ensure stability and functionality of the software from the beginning, even before formal testing starts.

For a calculator / arithmetic function: - Floating point numbers, integers, and the boundaries of integers - Divide by zero — the classic error - Enter values using mouse, keyboard, typing and pasting

For DaysInMonth(month, Year): - Leap year check (every 4th year) - Years such as even 100s, 101s, 4s, 5s - Months such as June, July, February, and invalid values

• Use Case Name: Sign In
• Use Case ID: 1
• Actor: Administrator, Super User, Doctor, Receptionist, Accountant, Lab Manager
• Summary: Describes the scenario in which the actor logs into the system before using it.
• Pre-Condition: The actor must already be registered and authorised with the system.
• Post-Condition: If the actor enters a valid username and password and is an already-registered, activated user, he is logged in successfully. If not, the system state remains unchanged.
• Extend: N/A
• Uses: N/A
• Normal Course of Events: The actor enters the username and password given by the Administrator into the Sign-in form and presses Login. The system validates them and redirects the actor to his home page.
• Alternative Path: If the actor is not currently activated by the Administrator, the system will not let him log in and displays "You are not activated anymore".
• Exception: If the actor enters an invalid username or password, the system displays an error.

• Use Case Name: Register new patient
• Use Case ID: 7
• Actor: Receptionist, Administrator
• Summary: Describes the scenario in which the actor registers a new patient in the system.
• Pre-Condition: The actor must be logged in before performing registration.
• Post-Condition: The patient is successfully registered if not already registered, and becomes eligible for Appointment reservation, Doctor Checkup, Lab tests and other applicable processes.
• Extend: N/A
• Uses: Patient registered, Cancel registration
• Normal Course of Events: The actor enters all necessary details in the registration form and presses "Register". The system saves the patient and displays "Patient Registered Successfully!"
• Alternative Path: If the actor does not want to register, he presses "Cancel Registration" and the system redirects him to the home page.
• Exception: If the patient is already registered, the system prompts "Patient Already Registered!" and does not allow registering again.

Project Name: __ Module Name (for a Product): ____

Rule to quote: if an individual step fails, the overall test case fails.

Project Name · Planned Start Date (as per contract) · Planned End Date (as per contract) · Actual Start Date · Estimated End Date (if different from planned) · Planned % Completion · Current Project Completion Status (% complete)

Then per phase: Milestone/Phase · Planned Start Date · Actual Start Date · Planned End Date · Estimated End Date · % Completion · Comments

(Full table is in Part 3.3 — go back and read it once more.)

1. ______ ensures project progress as per plan.Show answer
2. Depending on the nature of the project, ______ reports can be generated.Show answer
3. Who is responsible for providing data for the project audit?Show answer
4. The Project Management Framework is a bridge between ______, Sales, Finance and Management.Show answer
5. What determines Project Health?Show answer
6. EVM is a tool that provides objective measures of ______.Show answer
7. SPI is the ratio of ______.Show answer
8. CPI less than 1 indicates the project is ______.Show answer
9. SPI less than 1 indicates the project is ______.Show answer

10. According to the Cavendish software chaos report, the main cause of failure in software and IT projects isShow answer
11. What percentage of failure chances are associated with requirement engineering if not done accurately?Show answer
12. What is a significant challenge for the industry according to the report?Show answer
13. Why is requirement engineering the most important area of the software life cycle?Show answer
14. The major reason behind project failure isShow answer
15. A client's lack of involvement causesShow answer
16. If requirements are not documented properlyShow answer
17. Ideally, how much of the project budget should go to requirement gathering and documentation?Show answer
18. The requirement document actually takes only ______ of the whole project budget.Show answer
19. Negligence in the requirement engineering phase causesShow answer
20. A requirement is defined asShow answer
21. What makes requirement engineering challenging?Show answer
22. Why are non-technical clients difficult to handle?Show answer
23. Requirement engineering becomes difficult whenShow answer
24. How do software requirements differ from requirements in other domains?Show answer

25. Which attribute says the requirement must not leave any room for guessing or assuming, so all stakeholders completely understand it?Show answer
26. Which type of requirement must add business value and come from business goals?Show answer
27. A requirement is verifiable ifShow answer
28. What should be avoided in documentation to make a requirement verifiable?Show answer
29. Which attribute ensures the product is built as per the need/requirements?Show answer
30. A requirement is considered unique byShow answer
31. Forward integration in traceability is usedShow answer
32. Backward integration in traceability is usedShow answer
33. In the RCA example, what was the core reason for the project failure?Show answer
34. Which attribute is broken by "GUI should be user friendly"?Show answer
35. Which attribute is broken by two requirements naming two different ISO standards?Show answer
36. Which attribute is broken by "the product shall hide and display characters simultaneously"?Show answer
37. Gold plating is a typical example of breaking which attribute?Show answer

38. What do functional requirements define?Show answer
39. How are functional requirements captured?Show answer
40. What leads to change requests or bugs after the first demo-able version?Show answer
41. What must be performed before incorporating any new requirement after a change request?Show answer
42. Why should bugs be fixed?Show answer
43. To build a release, Environment Variables are provided byShow answer
44. Features for a release are provided byShow answer
45. Release Notes are owned byShow answer
46. The SQA team is considered to be the ______ customer of the product.Show answer
47. To prevent rework, requirements should be validated and approved byShow answer
48. Any behaviour-related requirement of the software product can only be actualised throughShow answer
49. Features and quality of the software product are determined throughShow answer

50. What is the primary purpose of Quality Assurance?Show answer
51. Defect refers to the deviation from ______ requirement.Show answer
52. Defect is mainly caused byShow answer
53. In the pre-release defect example, why did the cash register fail?Show answer
54. What was the root cause of the post-release CSV defect?Show answer
55. ______ is based on the assumption that there are known error sources or inappropriate actions causing defects.Show answer
56. One of the critical factors in delivering quality software isShow answer
57. Software developers are not domain specialists — they are pure ______ resources.Show answer
58. Why is domain knowledge important?Show answer
59. Which project example needs domain specialists?Show answer
60. A main cause of defects isShow answer
61. What is the impact of a lack of process knowledge?Show answer
62. What happens if a PM is not fully aware of managing Change Requests?Show answer
63. What is the goal of defect reduction?Show answer
64. To reduce bugs, ______ are a very effective QA alternative.Show answer
65. Inspections are applied at ______ level.Show answer
66. What does software inspection deal with?Show answer
67. What is the main purpose of testing in QA activities?Show answer
68. Testing is conducted at ______ level.Show answer

69. ______ ensures that all the necessary details about defects are provided to the development team.Show answer
70. Defect resolution in a ______ based scenario is an ongoing activity even after the product is deployed.Show answer
71. What is the difference between product-based and project-based defect handling?Show answer
72. What are the three levels of software support?Show answer
73. What tools are commonly used for defect handling?Show answer
74. What is Mantis used for?Show answer
75. How does Mantis enhance team collaboration?Show answer
76. What does the defect lifecycle begin with?Show answer

77. What is the primary purpose of software testing?Show answer
78. Which activity is NOT one of the three major activities in software testing?Show answer
79. Functional testing is focused onShow answer
80. Which testing is concerned with the internal implementation details?Show answer
81. Which term is used interchangeably with functional testing?Show answer
82. What does white box testing aim to verify?Show answer
83. What is the purpose of reviews in software testing?Show answer
84. What is the primary purpose of a Test Checklist?Show answer
85. Smoke tests are the ______ level of testing.Show answer
86. Divide by zero is a classic error found throughShow answer

87. What is Unit Testing focused on?Show answer
88. Who performs unit testing and white box testing?Show answer
89. What does Sanity Testing verify?Show answer
90. What is the primary goal of Sanity Testing Reporting?Show answer
91. Depending on the size and nature of a feature, there can be multiple underlying ______.Show answer
92. What does Feature Level Testing aim to ensure?Show answer
93. What is System Level Testing focused on?Show answer
94. What is the purpose of Stress Testing?Show answer
95. What does Regression Testing verify?Show answer
96. If an individual step fails, the overall test case isShow answer

97. What is the purpose of a Test Dashboard?Show answer
98. What is typically included in Release Notes?Show answer
99. What are Hot Fixes designed for?Show answer
100. What distinguishes a Patch from a Hot Fix?Show answer
101. In post-production issues, what is a "Ripple Effect"?Show answer
102. What is the first step when an issue is reported from production?Show answer

103. CMMI Maturity Level 2 is also known asShow answer
104. In the ______ representation, the organisation achieves the goals of the process areas associated with each maturity level.Show answer
105. Due to the lack of ______, different stakeholders of software have different definitions of the same product.Show answer
106. A working software can be developed usingShow answer
107. Configuration Management tools includeShow answer

1. Test Planning and Preparation — set the goals of testing, choose the appropriate testing strategy, and prepare the test cases and the general test procedure.
2. Test Execution — execute and implement the testing strategy and measure the product's behaviour.
3. Analysis and Follow-up — analyse the results to see whether a failure occurred, take corrective actions, and monitor them so the defect is removed and does not reappear.

Also mention: defect fixing and re-verification are part of software testing.

This is a post-release defect (also called a post-production issue). It appears in production or at the customer site after delivery. The supplier company has to fix it at its own cost, and the cost of fixing is higher than for other defects because the product may be installed at multiple sites and the fix has to be applied at every one. Besides financial loss, it damages the company's reputation, trust and market position.

Step 1 — Classify. The first step for any issue reported from production is to classify it as a Bug or a WishList.

For the requirement change (WishList): 1. Prepare and use a Change Request template. 2. Perform impact analysis on schedule, budget and existing requirements. 3. Share the estimates and timelines with the client. These are paid changes — the client bears the cost. 4. Use the SRS/Specs document to settle any dispute; verbal communication is not enough.

For the reported error (Bug): 1. If it is urgent and impacting the business, deliver a Hot Fix. Because of the time pressure the full QA process is not run; the team relies on unit testing and code reviews rather than regression testing. 2. If it is critical but the client can wait a short period, deliver it as a Patch, with proper estimation that includes QA cycles. 3. If the bug was caused by the latest build (Ripple Effect), the vendor bears the cost.

The Project Manager is responsible for providing the relevant data for the audit. The audit of the PM process area is carried out as per the PM Framework, and it covers all the process areas of project management. The purpose is to evaluate how far the project management standards were followed, to assess project quality, and to find the reasons behind known problems so corrective measures can be taken. Project Health is determined by the audit and is rated as Critically Deficient, Weak, Satisfactory, Good or Very Good.

1. Do requirement engineering properly — it is the number one cause of failure (87% chance of failure if done badly). Allocate around 20% of the budget to it.
2. Follow the PM Framework — signed contract, specs, estimations, gap analysis, project plan, demo plan, invoice plan.
3. Baseline the project, because a baselined project makes change requests manageable.
4. Track and control — daily scrums for daily progress, weekly status meetings and reports for overall progress.
5. Involve QA from the start — requirements must be QA-approved before development, to prevent rework.
6. Perform impact analysis on every change request and communicate it to the client.
7. Audit each phase and use EVM with SPI and CPI to catch cost and schedule problems early.
8. Prevent defects through training, domain knowledge, SDLC expertise and process knowledge, and reduce them through inspections and testing.

EVM is a tool that provides objective measures of the cost and schedule performance of the whole project. Its purpose is to highlight cost and schedule issues in time, so that remedial action can be taken before it is too late to recover. Earned value is expressed as the budgetary value of the work actually completed on the project. It compares three values — Planned Value, Actual Value and Earned Value — and the results are presented in a graphical format. It is a project management tool rather than a financial tool.

SPI (Schedule Performance Index) = Earned Value ÷ Planned Value. It tells us about the schedule. If SPI is greater than 1 the project is ahead of schedule; equal to 1 means on time; less than 1 means behind schedule, because the earned value is less than what was planned.

CPI (Cost Performance Index) = Earned Value ÷ Actual Value. It tells us about the budget. If CPI is greater than 1 the project is under budget; equal to 1 means on the planned budget; less than 1 means over budget, because the actual effort is greater than what has been earned.

In both, Earned Value is the numerator; SPI compares it against the plan, and CPI against what was actually spent.

1. Correct — captures the client's expectation with no ambiguity; a single line of 30–50 words; no subjective terms, no "etc." or "assumed".
2. Coherent — does not conflict with other requirements or the scope; vocabulary is consistent for all stakeholders.
3. Complete — leaves no room for guessing or assuming; states all conditions and constraints; closed-ended.
4. Feasible — can actually be implemented within the scope and limitations; needs developer input as a technical reality check.
5. Necessary — adds business value and comes from business goals; work on what the client expects, not what the developer wants; avoids gold plating and scope creep.
6. Verifiable — is demo-able and testable so QA can close it; avoid "must", "shall", "etc."; always ask for numeric values.
7. Traceable — has a unique ID, is linked to its source in the SRS, and to use cases, design and test cases, with forward and backward integration.

Release management includes the planning, scheduling and execution of the agreed features of a release. The deadlines and timelines are shared with the client. The most important part is obtaining approvals on the schedule and the features to be included. In short, release management means controlling a software build through its different stages and distributing the final version to clients.

A release note is a document distributed as part of the final product/build. It contains the scope of the release, performance benchmarks, the features added or delivered, the known issues the customer might face, what was fixed, installation and deployment steps, test results and the testing roadmap. Release notes are written by the technical writer, but the QA team is the OWNER of the document. They are distributed only after the product has been carefully tested and approved.

SQA is the process of making sure the developed product meets the customer's requirements and that all features work as planned. The SQA team is considered the internal customer of the product, and the product is released only if the QA team approves it. SQA is an ongoing process and is part of every stage of the SDLC until the product is complete — it is not a one-go process.

1. Defect Prevention (error source removal) — addresses the root causes of defects to stop them recurring, by clarifying human misconceptions and ambiguities.
2. Defect Detection / Reduction (fault detection and removal) — finds and removes as many defects as early as possible through QA, code reviews, code inspection and design review.
3. Defect Containment — measures how many defects QA caught out of the total, and keeps a defect local to avoid a global effect, reducing escaping defects and the resulting damage.

N-Version Programming is a software fault tolerance technique in which multiple versions of the same specification are run in parallel. If a fault occurs in one version, a fault-free version is dynamically switched in, so that faults in a limited number of versions do not compromise the overall system. Its drawback is that the faults are never identified and therefore never fixed, which is a contradiction of defect prevention.

A hot fix is for an issue reported from the live production site that must be fixed immediately, because it is impacting the business. It can be either a bug or a wishlist. Because of the time pressure, the complete QA process is not executed and the team relies on unit testing and code reviews rather than regression testing.

A patch is for issues that are critical but where the client can wait a short period. The development team does a proper estimation that includes QA cycles before sharing the deadline. A patch takes less time than a full release, and usually leftover bugs and/or wishlists are delivered as a patch after a major release.

Multiple developers work on a shared code base toward a single working software, and development, testing, beta and production each need a different version. Configuration management tracks and controls changes — it records what was changed and by whom, keeps a single repository of releases, allows changes to be reverted, and keeps one client's customisations invisible to other clients. It eliminates the confusion and error caused by multiple versions of artifacts, and works closely with QA, which receives code shipments from the CM team and returns them. Tools used are VSS, TFS and Git.

1. Each test case should test only one test condition at a time.
2. Multiple test cases should not be combined into a single test case.
3. Cover both positive and negative scenarios.
4. Include detailed steps and all necessary data.
5. Record expected and actual results; on any variation, log a defect which then goes through the defect lifecycle and is re-verified after the fix.
6. Test cases must be repeatable.
7. Avoid complex English to remove ambiguity.
8. Test cases must be traceable to requirements (Use Cases).

Product testing is done for the organisation's own product, developed with its own budget and against market standards. It is an ongoing activity for the life of the product, and test cases are regularly updated with each release.

Project testing is done for a client, with the client's budget and requirements. It is primarily a one-time activity that ends when the product is delivered, and the test cases are specific to a specific environment.

Verification is concerned with the engineering and programming side. Its purpose is to ensure the final product is error-free and that selected work products meet their specified requirements. It does not evaluate the usefulness of the system — it checks whether the system is well-engineered. In short, verification is about building the product the right way. It includes testing, design analysis, inspections and code reviews.

Validation ensures the final product or its components fulfil the requirements and their intended use when deployed in the intended environment. Its goal is to capture the client's requirements correctly and then meet them — that is, building the right thing. No code is required for validation; it uses Proof of Concept, WireFrames, Requirement Modeling and prototypes.

A review is a static testing method in which artifacts such as code are manually examined without execution, with the goal of early defect detection. It is informal, needs no formal planning or resource utilisation, includes code and design walkthroughs, and is done by an experienced person who is not the author.

An inspection is a type of review and is the most formal type of static testing. It is led by a trained facilitator or moderator who is not the author, checks compliance with specific rules, principles and best practices, is fully documented, and all defects found are logged in the defect logging sheet.

Stress testing is a form of system level testing whose purpose is to evaluate the effectiveness and stability of the software under unfavourable conditions. It mostly involves quantitative tests to gather statistics on the frequency of crashes and errors, and benchmarking is done. During the test, adverse conditions are created deliberately and maintained, and the fully integrated system is evaluated in them to measure its breaking point. A good example is hitting a website with multiple concurrent users to test the load.

Regression testing verifies that after adding a new feature, the previously developed and tested system still works correctly. A project involves continuous maintenance, defect fixing, optimisation and error correction, all of which keep changing the product. The goal is to make sure that a change in one part does not impact other parts and that the newly added features are fully integrated with the existing system. Example: in Release 1.1 a Discount Card and PayPal payment were added, and regression testing confirms that Login, Product Listing and Shopping Cart still work.

A test dashboard is the statistical analysis of the overall testing activity in progress, presented in a visual and statistical format. It lets the QA team monitor test activities, report on progress, find gaps in test coverage, and identify areas needing further investigation. It shows the count of defects by status for every feature, and the graphical representation helps identify priority areas.

Even with strong defect prevention and reduction, defects can still exist, and this is especially risky in high-impact applications such as medical, transportation and nuclear systems. A few faults are generated only under rare conditions at real time, and it is impossible to test all conditions exhaustively. So the strategy is to break the fault–failure relation to contain the damage — either by tolerating the fault, or by containing the failure so the resulting damage is reduced.

1. Level 1 — Customer Support Team: a special team, separate from QA and development, with the expertise to give technical support to customers.
2. Level 2 — QA Team: members of the QA team get involved in supporting customers.
3. Level 3 — Development Team: members of the development team get involved in supporting customers.

Pre-release defects are called dormant defects. They are inactive but can create problems for users. They are triggered only in a specific situation or exist in a low-priority area where QA attention is low. They are usually made part of the release notes. Example: a cash register scans thousands of items daily without trouble, but paying with cash + credit card + gift voucher together hangs the system, because that combination was never tested.

Post-release defects appear in production or at the customer site. The company has to pay from its own pocket to fix them, and they cost more because of multiple installations. They also damage reputation and trust. Example: a CSV export worked in testing but lost records after 500,000 rows in production, requiring a hot-fix; QA had only tested 30,000 records because no upper limit was mentioned in the SRS.

F R U E M P → Functionality, Reliability, Usability, Efficiency, Maintainability, Portability

ISO-9126 is the International Standard for Software Evaluation, providing a hierarchical framework for quality definition.

• Consumer = Users (use the services; want all specified functions, working correctly and reliably over time) + Customers (acquire the software; same expectations plus concern about cost)
• Producer = everyone involved in development, management, maintenance and service. Their biggest concern is fulfilling contractual obligations by producing software that conforms to specifications.
• Off-the-Shelf (OTS) products = plug-and-play products, usually known as plugins. Defined as software products available for any user, at cost or not, used without the need to conduct development activities. Their main purpose is reusable functionality. One solution does not fit all, so analyse carefully before selecting.

• Defect Prevention — strategy to identify root causes of defects and prevent them recurring. Recurring defects are very costly.
• Defect Detection or Reduction — it is unrealistic to expect a project or product with 0 bug count. Prevention can never be 100% effective, so we need techniques to remove as many injected faults as possible.
• Defect Removal or Containment — aims to reduce the chance of a defect passing from one phase to another, by breaking the causal relation between faults and failures.
• The filter diagram: Requirement Defects → Design and Planning Defects → Coding Defects → Testing Defects, ending at a 99.9% bug-free product. Remember: 99.99% does not mean 100%.

• Direct costs of missing quality: easily observable and measurable, occur immediately — financial loss, physical injury. They are tangible and visible.
• Indirect costs: invisible and difficult to calculate, appear long after the incident — loss of market share, reputation, shareholder trust and investment. Quote: Nokia's CEO — "We didn't do anything wrong but somehow we lost."
• Yahoo example: a breach affecting at least half a billion accounts (reported 2016, occurred late 2014). Verizon had agreed to buy Yahoo for $4.8 billion; after the breach the price dropped by $350 million to $4.48 billion.
• Approaches to measuring the cost of missing quality: Cost Analysis, Impact Analysis, Risk Analysis.
• Impact analysis order: Root-cause analysis → Identify problem → Fix it → Keep going.

Level 4 vs Level 5: Level 4 addresses special causes of variation and gives statistical predictability; Level 5 addresses common causes and changes the process to improve performance while keeping that predictability.

Level 2 vs Level 3: at Level 2 the process differs for each project; at Level 3 the process is tailored from the organisation's standard set of processes.

• Process Area — a cluster of related practices that, implemented together, satisfy a set of goals. There are 24 process areas (the engineering module mentions 22 in one place — if asked, the handout says 24 process areas in total in the Process Area/Goal section).
• Generic Practices — expected activities that achieve the associated generic goal and contribute to institutionalisation.
• Specific Practices — expected activities that achieve the associated specific goal of a process area.
• Capability levels: six, numbered 0 through 5.
• Two representations:
• Continuous — the organisation chooses the processes critical to its business and achieves high capability levels.
• Staged — the organisation achieves the goals of the process areas associated with each maturity level. real MCQ

1. Requirement Management
2. Requirement Development
3. Technical Solution
4. Product Integration
5. Software Validation
6. Software Verification

Key artifacts: Requirement Development → SRS. Technical Solution → Technical Design Document.

Requirement Management practices: Understand Requirements · Obtain Commitment to Requirements · Manage Requirements Changes · Maintain Bidirectional Traceability · Identify Inconsistencies. A Traceability Matrix is used to manage cross-referencing.

Product Integration: assembling the product from components; the main risk is a heterogeneous development environment; integration is done incrementally, and Sanity testing confirms no new defects were introduced.

• EPG (Engineering Process Group) — the organisation's focal point for implementing software processes; evaluates the existing process, defines what it should be, and suggests improvements; acts as an oversight committee.
• PAT (Process Action Teams) — the "worker bees"; each process area has a PAT; they write the procedures, pilot them and update them; they produce documentation, policies, processes, procedures, charters and action plans, and bring standardisation of artifacts through templates.
• Audits — a tool to measure the organisation's compliance level with the established process, and to find the reason behind non-conformance. Conducted by an independent auditor who studies the process, evaluates conformance, then assigns ratings.

The 3 audit types (easy MCQ)

Audit team: a certified lead auditor plus 2 to 3 members; domain experts join for tough scenarios. Process reviews frequency: usually biannual, quarterly or on a need basis. CMMI Appraisal = a process to collect, review and analyse data to measure performance or compliance, providing ratings that reflect the capability or maturity level.

• Known as the "golden triangle".
• Process is the "glue" that holds the other two together — it is often called the leg of the triad.
• A process is a set of practices performed to achieve a given purpose, uniform across the organisation.
• A process serves as an integration point which ensures synergy.
• Process is not a magic stick — it needs time to show results.
• Technology by itself will most likely not be used effectively; it gives the most benefit in the context of an appropriate process roadmap.
• Benchmarking = comparing existing processes and performance metrics to the industry's best practices. But there is no good or bad process — internal limitations, circumstances and resources must be evaluated first, because what works in one situation might not work in another.

Mature vs Immature organisations

• A QMS is a formalised system to achieve quality; without it there may be tragic situations or product/system failure.
• It ensures documentation of processes, policies and workflows.
• The famous definition "conformance to requirements" is called unfortunate, because requirements themselves are sometimes full of defects — known as toxic requirements. Conformance to toxic requirements is not quality, and the software engineering community has a moral obligation to eliminate them.

1. 87% — chance of failure if requirement engineering is inaccurate (Cavendish report)
2. 20% — ideal budget for requirement gathering; 10% — what it actually gets
3. 30 to 50 words — maximum length of one requirement
4. 200 milliseconds — the verifiable fix for "minimum loading time"
5. 25% — effort variation that triggers a meeting with Sales
6. 60 seconds — the incomplete "status messages" example
7. 500,000 records — the post-release CSV defect threshold; QA had tested only 30,000
8. ÷ 8 — hours to man-days (303 ÷ 8 = 37.875)
9. $4.8bn → $4.48bn, a drop of $350 million — Yahoo/Verizon
10. Half a billion Yahoo accounts breached
11. 3 levels of support, 3 defect categories, 3 major testing activities, 3 audit types, 3 coverage types
12. 5 CMMI maturity levels, 6 capability levels (0–5), 6 ISO-9126 characteristics, 6 engineering process areas
13. 7 requirement attributes, 7 PM framework artifacts, 8 test-case writing rules

14. SPI = EV ÷ PV — less than 1 means behind schedule
15. CPI = EV ÷ AV — less than 1 means over budget
16. Man Days = Total Hours ÷ 8
17. Total Man Time = Participants × Planned Time
18. Cost = A(F) + B(Q) — more features in a fixed budget means less quality
19. Risk Exposure = Probability × Loss

20. Tracking and Controlling ensures project progress as per plan
21. Multiple Status reports can be generated depending on the nature of the project
22. Daily scrums ensure daily progress; weekly status meetings ensure overall progress
23. The Project Manager provides data for the audit; the Audit determines Project Health
24. EVM is a project management tool, not a financial tool
25. Requirement engineering is a communicational, not technical, activity
26. Assumption is the mother of all failures
27. Change is the only constant
28. Software is not tangible until the first demo-able version
29. Computers cannot do anything simultaneously
30. Gold plating breaks the Necessary attribute
31. Avoid "must", "shall", "etc." — they make requirements unverifiable
32. Forward = where it is used; Backward = where it originated
33. Functional requirements are captured using Use Cases
34. Sales gives Features; the Technical team gives Environment Variables
35. Release Notes: written by the Technical Writer, OWNED by QA
36. The SQA team is the INTERNAL CUSTOMER of the product
37. Requirements must be approved by the QA team to prevent rework
38. Zero-bug software is practically not possible
39. Software developers are technical resources, not domain specialists
40. Creating a process and implementing a process are two different things
41. To reduce bugs, INSPECTIONS are a very effective QA alternative
42. Inspections are applied at CODE level
43. Testing is conducted at DIFFERENT levels
44. N-Version Programming: faults are not identified, so not fixed — contradicts defect prevention
45. Defect log ensures all necessary details reach the development team
46. The defect lifecycle starts with the DISCOVERY of the defect
47. Mantis logs and tracks defects, and is cloud-based for collaboration
48. MS Excel is the usual tool; the Support team holds admin rights
49. Smoke tests are the most abstract level of testing
50. Divide by zero is a classic black-box error
51. Review = static and informal; Inspection = the most formal static test, moderator-led, defects logged
52. A test checklist does NOT include functional testing
53. Unit testing and white box testing are performed by the DEVELOPER
54. System testing is performed by INDEPENDENT testers, in a near-production environment
55. Depending on size and nature of a feature, there can be multiple underlying UNITS
56. If an individual step fails, the whole test case fails
57. QA receives the code shipment from the CM team, and vice versa
58. Without CM it is impossible to track multiple code bases
59. The first step on a production issue is to classify it as a Bug or a WishList
60. WishList = the client pays; Ripple Effect = the vendor pays
61. Hot fixes rely on unit testing and code reviews, NOT regression testing
62. A Patch takes less time than a Release and includes proper QA cycles
63. CMMI Level 2 is called Managed; Level 2 relies on HEROES
64. Staged representation = achieve the goals of the process areas at each maturity level
65. Process is the "glue" of the People–Process–Technology triad
66. Defect = deviation from the CUSTOMER requirement
67. Bug = found BEFORE shipping; Defect = found AFTER shipping
68. Error → Fault → Failure
69. Verification = building the product right; Validation = building the right product
70. No code is required for validation

1. Do the MCQs first and fast. Most are one-blank recall. Bank those 50 marks.
2. Never leave anything blank — there is no negative marking.
3. For subjective answers, write 3–5 bullet points. VU marks concept clarity, not exact wording.
4. Save each answer before moving to the next question.
5. If a calculation appears, show your working — the working carries the marks even if the arithmetic slips.
6. A recent student finished this paper in 35 minutes and called it easy. Stay calm.

Good luck, Hasnat.