← Academy Blog

Training marathon 2022

Translated into:

Embarking on our Binary Studio Academy 2022 QA entrance test prep marathon! Weekly blog posts featuring test-like questions, explanations.

  • [QA] How many test cases are required to achieve 100% decision coverage?
    function WhatIsGreater(a, b) {
      let result;
      if (a > b) {
        result = 'a is greater than b';
      }
      if (b > a) {
        result = 'a is less than b';
      } else {
        result = 'friendship :)';
      }
      return result;
    }

    a) 1 test is enough
    b) 2 tests are required for full coverage
    c) The required number of tests cannot be determined due to lack of information
    d) Requires 3 tests

    Expand the correct answer with an explanation

    To answer this question you need to know the basics of flowcharts. Flowcharts use special shapes to represent different types of actions or steps in a process.

    Process Code

    Thanks to the flowchart, we can clearly see how our code works and analyze how many tests are needed to achieve 100% Decision/Branch coverage. The main aim of the Decision/Branch coverage is to cover all the branches at least once (true and false). That is, you need to find and cover a minimum number of ways.

    Picture of our code as a flowchart:

    Our Code

    So we have 3 branches, the number of test cases for which is 3:

    1. The first - checks that if WhatIsGreater (2, 1), then as a result of execution if (a> b) we get 'a is greater than b'.
    2. The second - makes sure that if WhatIsGreater (1, 2), the program will pass if (b> a) and the result will be 'a is less than b'.
    3. The third test case - checks that in other cases the result is 'friendship :)'. That is, if the parameters are the same WhatIsGreater (2, 2), we get 'friendship :)'.

    To achieve 100% decision coverage we need 3 test cases.

  • [QA] One part of QA`s work is requirements testing. Analyze the requirements below. What do you think is wrong with them?
    1. The system should be user-friendly and accessible.
    2. There should be a way to authenticate.
    3. Create a support system with live chat, contact form and help for authorized users.
    4. An unauthorized user can use the chat and contact form.
    5. A student will log into the system by providing his username, password, and other relevant information.
    6. Each page of the system will load in an acceptable time-frame.
    Expand the correct answer with an explanation

    Poor written requirements create a risk that the developer, QA, PO and end-user can expect different performance from the functionality.

    When testing the requirements, we must pay attention to:

    • unambiguous requirements and their completeness - everyone should understand the requirements equally;
    • consistency;
    • the need for requirements and the possibility of their implementation;
    • the ability to verify the established requirements after their implementation.
    1. The system should be user-friendly and accessible

    Convenient for whom and what does affordable mean? The requirements lack clarity and unambiguity. Different people perceive and interpret these words differently.

    1. There should be a way to authenticate.

    In this case, it is also not clear what the authentication method should be - e-mail and password, sending a temporary code to an e-mail address or a one-time password via SMS. The options are different. The requirements should be clear. It is also important to be sure that the requirements are really necessary and can be implemented.

    1. Create a support system with live chat, contact form and help for authorized users.

    Imagine how many options and tasks there can be in this case? Online chat support, phone support, 24-hour email support, help pages on the website… The requirements should reflect the functionality that the user really needs. Make sure that the requirements are essentially clear and concise, but at the same time able to convey all the needs.

    1. An unauthorized user can use the chat and contact form.

    This requirement conflicts with the previous one, which states that the support system should be available to authorized users. The requirements should not be contradictory or conflicting. It is necessary to clearly understand how the system should behave in a given case.

    1. A student will log into the system by providing his username, password, and other relevant information.

    By "other necessary information" the customer, developer and tester can mean different things. One of the criteria for good documentation - unambiguity - is the same perception of the requirements of all team members, there should be no differences in interpretation.

    1. Each page of the system will load in an acceptable time-frame.

    Problems with this requirement: each page means that there can be many pages, which will lead to an explosion of the testing efforts. It is important to be able to check all the established requirements after their implementation.

    In addition, the page should be loaded in a reasonable time, and what are the acceptable deadlines? Acceptable for whom?

    It is necessary to specify which pages are meant by "student registration and enrollment pages", as well as to indicate an acceptable time interval, for example, 5 seconds.

  • [QA] The database has a Contact table, which stores: the username, birth date, and city where the user lives.Weekly Challenge

    QA Table

    This week's tasks:

    1. Display the (Name) and date of birth (BirthDate) of all contacts with the second letter "a" in the name. Sort the sample by descending date of birth (BirthDate).
    2. In the Contact table in Lena contact change the values: BirthDate = 1987-10-08 and UsrAdressLiving = Харків.
    3. Add a new contact to the Contact table: Name = Alex, BirthDate = 1986-10-08, UsrAdressLiving = Київ.
    Expand the correct answer with an explanation
  • [QA] What is verification?
    1. Verify that the software is implemented according to the design.
    2. Verify that the software meets the customer's requirements and expectations.
    3. Verify that the software meets user requirements and expectations.
    4. Verify that the software is implemented according to the expected requirements.
    Expand the correct answer with an explanation

    Let's remember what Verification and Confirmation are.

    Verification. It answers the question "Does the functionality work as required?". Verification - the process of evaluating the system and its components in order to compare the results of the current stage of development with the initial conditions. It is the implementation of tasks, goals, deadlines for product development, and compliance with standards.

    Validation. It answers the question: "Do we expect what the user expects?". We make sure that the developed software meets certain business requirements and user needs.

    The correct answer is: Verify that the software is implemented according to the expected requirements.

  • [QA] This week we will practice prioritizing test cases. Testing deadlines are often tight. In such cases, there is a risk of missing testing of some important features. Therefore, it is important to prioritize each test when documenting it.Weekly Challenge

    Object:

    Internet-shop

    Status:

    At the development stage, but ready: the main page with promotional products; catalog; product cards with a photo (with the possibility of zoom); product pages; search; filters (price, manufacturer); sorting by price; shopping cart page with the ability to change the quantity of products, delete products; ordering page; integration with the payment system, sending an e-mail letter with order details.

    Customer requirements:

    • The user should see promotional products on the main page.
    • The product card preview must contain:
      • photo
      • price
      • “Add to cart” button.
    • After clicking on the card, the product page opens with:
      • description
      • price
      • photo
      • the ability to add the product to the cart.
    • The user must have the option in the cart:
      • remove the product
      • change its quantity
      • have a button "Order".
    • On the ordering page should be the choice of payment type:
      • online payment by card
      • cash on delivery
      • and one type of delivery - self-pickup at the post office.
    • Also on the order page must be:
      • “Email” field
      • “Phone Number” field
      • “Buy” button.
    • If the user has chosen to pay by card, then after clicking on the "Buy" button, the system redirects to the payment page, where the user needs to enter bank card details.
    • After placing an order, a letter with the details of the order should be sent to the user's e-mail box.

    It is important for the customer that the user at least has the opportunity to order the product.

    The classification of test case priorities that we will use:

    • High priority: These test cases cover the critical function of the application, defect prone modules and modules that have undergone recent changes.
    • Medium priority: These test cases include negative test scenarios. Field validations, error message generation test cases are included under this category.
    • Low priority: These test cases cover the remaining functionality of an application (includes UI and less defect prone modules).

    Prioritize the following checks:

    1. Display promotional items on the main page.
    2. Display the corresponding product category on the page of the selected category from the product catalog.
    3. Sort by price.
    4. Display relevant products on the user's screen after searching.
    5. Filtration by price, manufacturer.
    6. Ability to zoom in/out the photo in the product card.
    7. Display product description, price.
    8. Adding the product to the cart, removing the product from the cart.
    9. Correspondence of the product price in the shopping cart to that specified in the product card.
    10. Validation of the fields “Email” and “Phone number” on the ordering page.
    11. Go to the online card payment page.
    12. Go from the shopping cart to the ordering page after clicking on the "Order" button.
    13. Receiving a letter with order details by email.
    Expand the correct answer with an explanation
  • [QA] Retesting or Regression?

    Think and answer what suggestions are related to the Retesting and what suggestions are related to the Regression:

    1. Goal of this test is to make sure that adding new code, improving or fixing bugs do not make instability or discrediting software functionality
    2. During this testing testers check that all test cases that were failed during the last testing, are passed after bug fixing.
    3. This testing is not included checking bugs.
    4. This type of testing guarantees that changes in the code will not affect the functionality of the system.
    5. This testing can be automated.
    6. This type of testing is carried out after fixing the defects.
    7. Test cases that failed generically are subjected to this type of testing.
    8. Test cases that passed generically are subjected to this type of testing.
    Expand the correct answer with an explanation

    Retesting - the type of testing when testers check that all test cases that were failed during the last testing, are passed after bug fixing.

    Regression testing - the goal of this test is to make sure that adding new code, improving or fixing bugs do not make instability or discrediting software functionality. This testing is not included checking bugs. Regression testing can be automated.

  • [QA] This week the task is to find bugs and create bug reports. The screen shows a simple login form. The user opened the site, went to the login form, didn’t enter an email address, but entered a password.Weekly Challenge

    Find bugs on this screen and create bug reports.

    Register form

    Expand the correct answer with an explanation
  • [QA] During testing of a healthy food application, 200 critical bugs were found in the first 20 sprints. Over the next 20 sprints without changing the QA team and approach to testing, 25 critical bugs were found, but customers began to complain about various bugs they found while using the new versions. Which of the principles of testing is clearly observed in this example?

    a) Exhaustive testing is impossible
    b) Pesticide paradox
    c) Testing depends on context
    d) Absence-of-errors is a fallacy
    e) Users always complain

    Expand the correct answer with an explanation

    Let's recall 7 principles of testing

    Testing shows the presence of defects, not their absence

    The testing process does not confirm that any software is completely correct and completely free of problems. Testing helps to significantly reduce the number of undetected defects hidden in the software, but finding and solving these problems is not in itself proof that the software or system is 100% problem-free.

    Comprehensive testing is not possible

    No matter how much we want to believe or wish it to be true (!), To test EVERYTHING - all combinations of input data and preconditions are absolutely impossible. For the simplest functionality, this is more realistic, but such testing would be very inefficient and extremely expensive.

    Early testing saves time and money

    Everything is simple here. The fewer stages of development the bug lives on, the cheaper it is for the project. The cheapest bug is a bug found at the idea stage, the most expensive is a bug found by the end user.

    Defects are grouped together

    The largest number of bugs is usually concentrated in several problematic modules of the program

    Testing depends on the context

    The application usage context will determine the types and kinds of testing. For example, the cloud version of the application requires load testing from thousands of users, but the standalone version, which is installed by the user on his computer - no.

    The absence of errors is misleading

    If your software or system is unusable (or does not meet the wishes of users), it does not matter how many defects are found and fixed - they are still unusable. So in that sense, it doesn't matter how trouble-free or error-free your system is; if usability is so poor that users can't navigate, and / or it doesn't meet business requirements, it has failed despite a few mistakes.

    The pesticide paradox

    This is based on the theory that when you repeatedly use pesticides in crops, the insects end up producing immunity, making it ineffective. Similar to testing, if the same tests are performed continuously, then - although they can confirm that the software is working - in the end they will not be able to find new problems. It is important to continue to review your tests and change or supplement your scenarios to prevent the pesticide paradox - perhaps by using different testing methods, techniques and approaches in parallel.

    The correct answer is the paradox of the pesticide :)

  • [QA] This week`s task is oriented towards practicing your QA skills and solving quite easy, at the first glance, task. Our goal is to test the elevator in the high-rise building with offices. There are 10 floors in total. The elevator has a load capacity of up to 500 kg.Weekly Challenge

    Hint: we expect to see different types of testing applied

    Expand the correct answer with an explanation