Feeds:
Posts
Comments

Posts Tagged ‘Software testing’


Checklist 

Пусть у нас есть поле, которое принимает буквенно-цифровые значения (латиницу). Длина поля ограничена 35 символами.

Вспоминая  рекомендации набросаем чеклист:

1. Можно ли ввести в поле буквенно-цифровые значения до 35 символов?  (да)

2. Можно ли ввести в поле буквенно-цифровые значения  35 символов?  (да)

3. Можно ли ввести в поле буквенно-цифровые значения более 35  символов?  (сообщение об ошибке)

4. Можно ли оставить поле пустым?   (уточнить спецификацию)

5. Можно ли заполнить поле пробелами? (уточнить спецификацию)

6. Можно ли заполнить поле табуляциями?  ( уточнить спецификацию)

7.  Можно ли ввести специальные символы (‘,$,/,\, &,-,…)? (сообщение об ошибке) (more…)

Read Full Post »


  1. Необходимо понять, что за программное обеспечение должно быть протестировано, как оно будет использоваться, кем, какие задачи решать.   Если пропустить этот шаг,  то тестировщик рискует пропустить ряд концептуальных багов, которые очень важно  выявить до начала реализации архитектектуры и, тем более, кода.
  2. Создать  тесты для дымового тестирования
  3. Нарезать “слона на бифштексы”  – выделить группы тестов
  4. Написать чек лист для каждой группы тестов, при этом следует не забывать о:
  1. порядке тестов – от простых тестов к сложным. Если на прогоне не пройдут простые тесты, то будет ли смысл в сложных ?
  2. тестах с пустыми полями,  с пробелами, табуляцией,  спецсимволами, значениями по умолчанию, максимальную длину/значение поля.
  3. негативных тестах –  приложение не делает того чего не должно делать (например, нельзя ввести больше 100 символов или дату не в правильном формате.
  4. наличии простых позитивных тестов;
  5. систематичности – лучше одна часть структуры расписанная хорошо, чем везде по чуть-чуть
  6. креативных идеях 😉  – нарабатывайте ваш опыт ))
  7. вопросах по ожидаемым результатам –  помните, что спецификация не идеальна и нуждается в уточнениях  )
  • При наличии времени – детализируйте  чеклист в тест кейсы. Опять же, следует помнить о том: (more…)
  • Read Full Post »


    Sometimes it’s possible to find information that smoke testing and sanity testing are the same, it’s not really so.

    When a build is received, a smoke test is run to ascertain if the build is stable and it can be considered for further testing.

    Once a new build is obtained with minor revisions, instead of doing a through regression, a sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes.  It’s generally a subset of regression testing.

    Some more facts about the difference between Smoke and Sanity testing

    SMOKE TESTING:

    • Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
    • A smoke test is scripted, either using a written set of tests or an automated test
    • A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide.
    • Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification).
    • Smoke testing is normal health check up to a build of an application before taking it to testing in-depth.

    SANITY TESTING:

    (more…)

    Read Full Post »


    Дано:

    интерфейс пополнения денег на счету в виде  Х.УУ,  где    Х – целое число от 0 до 99999 ( например, доллары,  гривны, рубли, евро),  а УУ –  значение в центах, копейках. При этом если  в часть УУ вводится менее 10  центов/копеек, то система интерпретирует ввод как 0У .  Например,  вводим  5 центов/копеек, что трансформируется в 05.

    Баг:

    пополнить баланс на сумму, которая имеет 9 или 8 копеек, как то : 0.09, 0.08, 10.09, 12.08 невозможно

    при этом суммы вида 10.07, 11.18,  0.19  отлично обрабатываются

    Код:

    int sum;
    {
        char textValue[256];
        int hrn, cop;
        _S_edit_pay_sum->getTextUtf8(textValue, bo_namembs(textValue));
        int numparams = sscanf_s(textValue, "%i.%i", &hrn, &cop);
        if ((0 > hrn && 0 > cop) || 2 != numparams) {
            assert(false);		//уже проверено валидатором.
            return BoS_ERR;
            /* NOTREACHED */
        }
        #define SUM_SCALE_VALUE 100
        sum = hrn * SUM_SCALE_VALUE + cop;
    }

    Проблема:
    (more…)

    Read Full Post »


    Exploratory software testing is very powerful approach, but it is often misunderstood. Exploratory testing can be sometimes more productive than scripted testing. I completely agree with James Bach all testers practice some form of exploratory testing, unless they simply don’t create tests at all.

    Exploratory testing can be described as a martial art of the mind. It’s how you deal with a product that jumps out from the bushes and challenges you to a duel of testing. Well, you don’t become a black belt by reading books. You have to work at it. Happy practicing.

    (James Bach, Exploratory Testing Explained v.1.3 4/16/03)

    http://www.satisfice.com/articles/et-article.pdf

    Exploratory testing is also known as ad hoc testing. Unfortunately, ad hoc is too often synonymous with sloppy and careless work and testers does not have enough respect to this approach, but sometimes it’s the only possibility to find interesting and specific bugs.
    Let us take the definition of Exploratory testing given by James Bach

    Exploratory testing is simultaneous learning, test design, and test execution.

    According to ISTQB glossary

    Exploratory testing is concurrent test design, test execution, test logging and learning

    ET is situational practice. What kinds of specifics affect ET? Here are some of them:

    • the mission of the test project
    • the mission of this particular test session
    • the role of the tester 4
    • the tester (skills, talents, and preferences)
    • available tools and facilities
    • available time
    • available test data and materials
    • available help from other people
    • accountability requirements
    • what the tester’s clients care about
    • the current testing strategy
    • the status of other testing efforts on the same product
    • the product, itself
      • its user interface
      • its behavior
      • its present state of execution
      • its defects
      • its testability
      • its purpose
    • what the tester knows about the product
      • what just happened in the previous test
      • known problems with it
      • past problems with it
      • strengths and weaknesses
      • risk areas and magnitude of perceived risk
      • recent changes to it
      • direct observations of it
      • rumors about it
      • the nature of its users and user behavior
      • how it’s supposed to work
      • how it’s put together
      • how it’s similar to or different from other products
    • what the tester would like to know about the product

    Read Full Post »


    GUI Testing is a process to test application’s user interface and to make sure that it confirms the design requirements.
    GUI Testing

    GUI Testing

    GUI testing is a process to test application’s user interface and to make sure that it confirms the design requirements.

    1. Text Box
    a. Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar.
    b. If it doesn’t then the text in the box should be grey or non-updateable.
    c. Try to overflow the text by typing to many characters.
    d. Enter invalid characters – Letters in amount fields, try strange characters like + , – * etc. in All fields.
    e. SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.

    2. Radio Button
    Left and Right arrows should move ON Selection. So should Up and Down. Select with mouse by clicking.
    Check Boxes: Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same.

    3. Command Buttons
    a. If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots.
    b. All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.
    c. Click each button once with the mouse – This should activate
    Tab to each button – Press SPACE – This should activate
    Tab to each button – Press RETURN – This should activate
    d. If there is a Cancel Button on the screen , then pressing should activate it. (more…)

    Read Full Post »


    Approaches to Software Testing

    Static Testing is a process, which is associated with analysis of software. Static testing provides for testing (verifying) of any work product, e.g. code, requirements documents, functional specification, architecture, design documents, etc. Static testing is one of the most effective ways of defects detecting in the early stages of product process. Actually static testing is what can be made for defects detecting without running the code.

    Dynamic Testing is a testing activity providing for software operating. Dynamic testing can not avoid running the code. Better to say, dynamic testing consists of launching the program, running all functional modules and comparing the product’s behaviour with expected one using user interface.

    Software Testing Methods

    Black box testing. Testing software based on functional and business requirements at launching and operating it without knowledge of the internal structure or program source code. A tester tests a product so as an end-user would work with it at launching and operating it. The purpose of this method is to check the proper work of all functions, to verify whether all functions correspond to functional requirements.

    White box testing. Tester uses his understanding of source code and access the code to develop and execute test cases. This method tests the architecture of the system. It tests the design and programming that goes into building system. White box testing is usually applied when application is not entirely assembled, but it is necessary to check each of the components, modules, procedures and sub-functions. White box testing is close interrelated with unit testing, which is often performed by developer who understands the logic of code.

    Gray box testing. In addition to white and black testing sometimes gray box testing is mentioned. This specific method is used when we have access to some part of the developed product, but do not have such access to another parts (f.e. we use precompiled libraries or some external tools as parts of our project).

    Software Testing Levels

    Software Testing Levels: Time

    Unit Testing. This level of testing allows to perform the testing of separate module of the system. It may be a testing even of any particular part of the code (class).

    Integration Testing. Testing of combined parts of an application to determine if they function together correctly. Also, interactions between applications of big system can be checked within this type of testing. In this case this testing is known as Cross-product testing. Usually it is performed after unit and functional testing of modules.

    System Testing.  Checking the operation of the system in a whole. This testing checks as functional as non-functional requirements.

    System Integration Testing verifies that a system is integrated to any external or third-party systems defined in the system requirements. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet).

    Software Testing Levels: Level of specificity

    Acceptance Testing:  Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

    Acceptance testing can mean one of two things:

    • A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression.
    • Acceptance testing is performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development
    Regression Testing:   Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
    Alpha TestingSimulated or actual operational testing  by potential users/customers or an independent test team at the developers’ site, but outside the development organization.  Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing.
    Beta Testing: Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component  or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire feedback from the market.

    Read Full Post »

    Older Posts »