What if outstanding defect count is high and software production push date is near?

Test Management


My this article is in response to a LinkedIn question “What to do when we are out of time, software is not bug free and tomorrow its going for production?“

Here are my thoughts on this:
1. Make a list of all open defects and share across all key stakeholders like Requirement Owner (PO, Business Analyst), Dev Lead, Dev Manager, Test Lead, Test Manager, Delivery Manager (stakeholders may vary.. depends on your project)

2. Schedule a defect triage meeting to prioritize all defects in following categories –

Category A: Issues which must be fixed. Software cant be released without that.
Category B: high-priority Issues that should be included in the solution if it is possible
Category C: Issues which is considered desirable but not necessary
Category D: Defects which will not be fixed (issues which does not generate any value addition to the software)

3. All stakeholders should decide go/no go based on the following:
– Can we accommodate Category A issues within deadlines? 

  • If Yes – Can we accommodate category B issues within deadlines? If No – Can we accommodate category B issues post the release? 
  • If No – Which all issues from category A can be accommodated? Can release date be postponed? If Yes, are there any contractual obligations from customer? 

Note – “accommodate” means – Issues should be fixed, code reviewed, tested with impact areas.

Remember that last minutes major fixes are usually dangerous. So take wise decision. This decision has to be taken by key stakeholders (not just test team). Make sure that team team give their inputs on impact and testing efforts based on the experience.

Also remember that – Testing team has “some” control on quality. Entire team (dev / test / pms etc) are responsible for the quality.

How to avoid these situations?These situations generally occurs when Project managers / Scrum Master / Dev Managers are not seriously tracking the project progress.

But this does not mean that Software Test team should not do this. At-least before one week of the testing deadline (depends upon your project length), Testing team should start raising concerns about the health of software.
Starting informing the stakeholders that which all features blocked form testing with these issues.
Make sure developers are giving priority of issue fixes rather than working on other stuff.

Make sure there should not be any communication gap from testing team.

Many other factors software testers need to take care of:

  • report valid defects, 
  • test critical features first, 
  • make sure devs deliver critical features first, 
  • large features with more story points should be broken down to sub-features and should be delivered accordingly, 
  • clear doubts in requirement walk-through phase, etc 
  • + many more.. will take sometime later
 
Happy Testing


ISTQB and CSTE Software Testing Certification Comparison – Which one is better?

Certifications


There are two key testing certification bodies – ISTQB & CSTE. ISTQB is easy and popular among UK testers. But CSTE is well recognized in States. (See the comparison table below)

 
[[ A Must Read – 
Sr. No Area of comparison ISTQB CSTE
1 Certification provided by International Software Testing Qualification Board (ISTQB) Quality Assurance Institute (QAI)
http://www.istqb.org/ http://softwarecertifications.org/
2 Prerequisites None. Anyone can take up this examination 18 months of experience in Software Testing + minimal educational experience (check the website… It gives this very clearly)
3 Levels of Certification offered Certified Tester Foundation Level (CTFL) Certified Associate in Software Testing (CAST) 
Certified Tester Advanced Level – Test Analyst (CTAL-TL) Certified Software Test Engineer (CSTE) 
Certified Tester Advanced Level – Technical Test Analyst (CTAL-TTL) Certified Manager of Software Testing: (CMST)
Certified Tester Advanced Level – Test Manager (CTAL-TM)  
4 Certification coverage Can be considered as a subset of CSTE syllabus. Superior coverage when compared to ISTQB.. 10 Skill categories are there
   
ISQTB certification has 4 levels , starts from Foundation. Probably somewhere between 2nd level and 3rd level of ISQTB would match CSTE.
5 Examination pattern ISTQB Foundation: 75 Mins closed book exam consists of approximately 40 multiple choice questions of 1 points each. An exam amounts to 40 points total, pass is 65%(26 points) CSTE has four sections and total exam duration is 270 min. There are 2 section having 50 objective questions and time limit is 45 min and 2 sections having subjective 6 to 10 questions and time limit as 75 min. With 10 min, break after each paper the total duration.
6 Recertification Required for First Level? No Yes – every 3 years
7 Others – CSTE costs approximately thrice compared to ISTQB foundation level
– ISQTB is totally objective while CSTE examination consists of written and objective
– CSTE is preferred in US and Asian countries, while ISTQB/ISEB preferred in UK


Unit Testing Test case preparation Guidelines and checklist

Unit Testing


The following are the suggested action points based on which a test case can be derived and executed for unit testing.

Test case action which acts as input to the software/feature under test:

1. Validation rules of data fields do not match with the program/data specification.
2. Valid data fields are rejected.
3. Data fields of invalid class, range and format are accepted.
4. Invalid fields cause abnormal program end.

Test case action point to check output from the software/feature under test:

1. Output messages are shown with misspelling, or incorrect meaning, or not uniform.
2. Output messages are shown while they are supposed not to be; or they are not shown while they are supposed to be.
3. Reports/Screens do not conform to the specified layout, with misspelled data labels/titles, mismatched data label and information content, and/or incorrect data sizes.
4. Reports/Screens page numbering is out of sequence.
5. Reports/Screens breaks do not happen or happen at the wrong places.
6. Reports/Screens control totals do not tally with individual items.
7. Screen video attributes are not set/reset as they should be.

Test case action points to check File Access

1. Data fields are not updated as input.
2. “No-file” cases cause program abnormal end and/or error messages.
3. “Empty-file” cases cause program abnormal end and/or error messages.
4. Program data storage areas do not match with the file layout.
5. The first and last input record (in a batch of transactions) is not updated.
6. The first and last record in a file is not read while it should be.
7. Deadlock occurs when the same record/file is accessed by more than 1 user.

Test case action points to check internal Logic of the software/feature under test:

1. Counters are not initialized, as they should be.
2. Mathematical accuracy and rounding do not conform to the prescribed rules.

Test case action points to check Job Control Procedures:

1. A wrong program is invoked and/or the wrong library/files are referenced.
2. Program execution sequence does not follow the JCL condition codes setting.
3. Run time parameters are not validated before use

Test case action point to check the program documentation

1. Supportive documentation (Inline Help, Manual etc.) is not consistent with the program behavior.
2. The information inside the operation manual is not clear and concise with the application system.
3. The operational manual does not cover all the operation procedures of the system.

Test case action point to check program structure (through program walkthrough)

1. Coding structure does not follow coding standards.

Test case action point to check the performance of the software/feature under test:

1. The program runs longer than the specified response time.

Sample Test Cases:

1. Creation of record with valid data set.
2. Rejection of record with invalid data set.
3. Error handling upon empty file.
4. Batch program run with test data set.

– Happy Testing
Reference: testingqa.com


Practical Software Testing Tips to become a Smart Software Tester.

Better Testing


Sometime back, I was searching for “Software Testing Tips”, “How to become a smart software Tester”, “Tips for Software Testers”, etc on Google.com.
I come across various websites and in most of the websites, I got these tips – “Have a good test plan”, “Learn & Improve Your Skills”, “Understand the product”, “Write clear, descriptive, unambiguous bug report”. BULLSHIT. These are required skills of a software tester.
So here is my Part 1 of “Practical Software Testing Tips to become a Smart Software Tester.”

Tip 1: Make sure that you clear all your doubts during requirement analysis. Always Ask Yourself “What If..?” (Read How to Review and analyze Software Requirements)

Tip 2: Before the developers deliver the code, have a discussion with them on the functionality/Business rules you have covered in the test cases. Ask them what addition rules they are covering in the code, how the UI will look. This discussion is very required if you want to reduce the QE / Dev conflicts and rework time during test case execution. In case you get conflicts, get it resolved from requirement owner.

Tip 3: Think technically – Try to understand how the application will be designed. Think and ask the developers/DBAs:
What will be the db design?
Any part of code is being reused in multiple places?

Software Testing TipsTip 4: Before you report any defect/bug, Are you discussing/confirming it with Developers? If YES, then you are wasting your time. STOP DOING THIS. Be confident and Report defects promptly.

Tip 5: Whenever you got a new feature to test, do a 15¬20 minute high level test to make sure that newly implemented feature is stable. In case you encounter any blocker issue, send a high priority email to the Dev/QE group saying this need to be fixed on priority.

Tip 6: Before you start Test Case Execution, prioritize your test scenarios. For example ¬ scenarios related to Business rules can be of high priority and need to be tested on Priority. Usability or negative testing scenarios can be tested after that. [This is just an example, testers need to decide based on the scope of testing].

Watch less that 3 minute interactive Video:

Stay Tuned for part 2.

– Happy Testing


Cross browser testing Checklist

Crossbrowser Testing, Testing Checklists

Here is is quick checklist for conducting a Cross Browser Testing. A Tester need to take care of following areas (in each browser) while doing Cross Browser Testing:

  • Page Layout
  • Text Alignments
  • Font Sizes
  • Page Navigation
  • Mouse Hover / Tool Tops
  • CSS, HTML or XHTML validation (various tools available like w3s validator, etc)
  • Java Script
  • Client side Validations of fields – with and without javascript enabled
  • CSS validation
  • Header & Footer Layout
  • Usability Controls (Select options using tab & shift+tab )
  • SSL certificates
  • Image alignments
  • Upload File
  • Export File
  • Submit Functionality
  • Navigation Links & Page Links
  • Check Box functionality
  • Animations
  • Form saving functionality
  • Font Styles
  • Performance of application
  • Tool Tips
  • Grids / Tables in the page – If there are fields like dropdown then check their look and field.
  • Scroll Bar appearance
  • Space between fields:
    • Space between two sub-sections/fields
    • Space between labels & checkboxes/radio buttons
    • Space between two radio buttons/checkboxes
  • Modal/Popups
  • Flash work
  • Page Zoom / Increase Text size

– Happy Testing

Guest Article by Gaurav Dhiman