Best testing Practisesbest testing practices

By -
  • Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.
  • Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.
  • To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.

    E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

  • While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.

  • Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.

  • Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

  • Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

  • If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

  • Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

  • Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

  • Go beyond requirement testing. Test application for what it is not supposed to do.

  • While doing regression testing use previous bug graph (Bug graph - number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

  • Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

  • Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

  • Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

  • It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

  • Testing teams should share best testing practices, experience with other teams in their organization.

  • Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute - make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.

  • Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

  • Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.
    Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge

Comments

Post a Comment

Popular posts from this blog

Progress 4GL interview questions for QAD technology

By -
1.        What is “No-undo” in the variable declaration? 2.        What are the different .pf parameters 3.        What are the different types of  locks in progress? Explain with example. If a record is locked Exclusively, can a shared lock be provided over the same? 4.        What are different type of procedures in progress? Can internal procedure call other internal procedure? If yes how? If no why no? Can external procedure call internal procedures? 5.        How is array defined in progress? What is the limit of extent for progress? Can we create 2 dimensional / multi dimensional arrays in progress / How? If no then how can we achieve the same? 6.        What are browses? 7.        What are queries? 8.        Can we call excel application from progress? How? 9.        What is the difference between can-find and find? 10.     What are the different types of triggers available in progress? Name few database level triggers. 11.     What are the different type
Read more

QAD interview questions for SE and Eb2 version

By -
1.       What is the difference between WO close and WO accounting close. 2.       What are the different types of transaction types in mfg-pro 3.       What is tag count when it is used 4.       Explain the purchase cycle 5.       What is the difference between the WO module and Repetitive  module. 6.       Explain the Payment cycle 7.       Explain the Sales Cycle 8.       What is a schedule order 9.       Explain GTM why and where it can be used 10.   How can u ensure that the supplier is given a schedule on a particular day of the week say only on Monday. 11.   What is MRP .What are the different types of MRP 12.   Can the  status of the the material can be changed 13.   What are financial transactions passed when you do voucher and payments. 14.   What are the transaction  passed when the payment is made 15.   The financial transaction passed when the sales  order is  updated. 16.   What are the primary input for MRP explain  in details 17.   Expl
Read more

Use of API in QAD EE

By -
/*Sample API Program to create currency in QAD EE*/ {us/mf/mfdtitle.i} {us/bbi/gplabel.i} {us/wb/wbrp01.i}         {us/gl/glsec.i} {us/gp/gpuid.i} {proxy/bcurrencydef.i } /* ======== FOR API ========= */ DEFINE VARIABLE viReturn                     AS INTEGER     NO-UNDO. DEFINE VARIABLE ilReturnDataset              AS LOGICAL     NO-UNDO. DEFINE VARIABLE ilPartialUpdate              AS LOGICAL     NO-UNDO. DEFINE VARIABLE icPartialUpdateExceptionList AS CHARACTER   NO-UNDO. DEFINE VARIABLE ocPrimaryKey                 AS CHARACTER   NO-UNDO. DEFINE VARIABLE ocRowid                      AS CHARACTER   NO-UNDO. DEFINE VARIABLE oiDraftInstance              AS INTEGER     NO-UNDO. DEFINE VARIABLE ocPrimaryKeyName             AS CHARACTER   NO-UNDO. DEFINE VARIABLE vho                          AS HANDLE. DEFINE VARIABLE oiReturnStatus               AS INTEGER     NO-UNDO. empty temp-table tCurrency. for first RoundingMethod no-lock where RoundingMethodCode = "
Read more