Code structure for automated checks


I have been reading about how to structure my automation scripts for checking
scenarios, and this is what I have learnt.
 
The Test Pyramid
(Source: Test Pyramid)
First of all, we should know the test pyramid concept that was developed by Mike Cohn, and described in his book Succeeding with Agile.
In a nutshell, the concept is about having many more low-level unit tests than high-level end-to-end UI tests. UI tests are brittle, expensive to write, and time consuming to run. So, the automation should lean much more towards unit tests.
 test-pyramid
UI layer refers to the end-to-end checks using something like Selenium or Sahi. The Service layer refers to checks that act through a service layer of an application. (Eg. checking through an API layer)
And the final base of checks is the low-level unit tests.
 
Guidelines for structuring automated tests
#1 Structure – Prioritize creation of unit tests to cover most test scenarios over
any other types of tests. Unit tests should cover the bulk of your testing strategy.
Keep UI tests to a minimum, only covering critical happy flow scenarios & failures. Avoid making assertion on validation error message in UI level. It should just verify the error case by virtue of redirect to same page. All validation scenarios are already covered with messages in unit tests
#2 Speed – Team should collectively decide the acceptable time for running the test suite, define it for all test types – unit, integration and acceptance.
#3 Robustness – Avoid testing JavaScript behavior and scenarios heavily using
Selenium based acceptance tests. Instead, use Jasmine-based pure JavaScript unit testing, which are more robust and fast.
Create mocks for any external services that tests might be dependent on.
#4 Debugging – When it fails, it should point broken code.
 
Self Testing Code
Every object should be able to test itself. Write your code in such a way that typing a command should make the whole software system do a self-test.
Also, practice Test Driven Development while working.
This command will be run every time code is committed and pushed to Git develop branch. By running the test suite frequently, at least several times a day, you’re able to detect such bugs soon after they are introduced, so you can just look in the recent changes, which makes it much easier to find them.
Build a testing culture where developers are naturally thinking about writing code and tests together.
 
When Should a Test Be Automated?
(Source: Automate)
Do not over-automate. Only some tests should be automated.
Decision process would use following questions:
1. If I automate this test, what manual tests will I lose (not be able to execute in the time given)? How many bugs might I lose with them? What will be their severity?
2. An automated test has a finite lifetime, during which it must recoup that additional cost. Is this test likely to die sooner or later? What events are likely to end it?
When deciding whether to automate a test, you must estimate how many code changes it will survive. When the test breaks after code change, if it hasn’t repaid the automation effort by that point, you would have been better off leaving it as a
manual test
Create product-specific test libraries. After that many user interface changes will
require no changes to tests, only to the test library, thus, saving a lot of effort.
3. During its lifetime, how likely is this test to find additional bugs (beyond whatever bugs it found the first time it ran)? How does this uncertain benefit balance against the cost of automation?
If those questions don’t suffice for a decision, other minor considerations might tip the balance.
 
Note – The tests you need are often called task-driven tests, use-case tests, or scenario tests. Because scenario tests favor common tasks, they find the bugs most users will find.
Some of the secondary considerations
* Humans can notice bugs that automation ignores, especially GUI issues.
* But, while humans are good at noticing oddities, they’re bad at painstaking or precise checking of results.
* As humans can’t be precise about inputs, repeated runs of a manual test are often slightly different tests, which might lead to discovery of a support code bug.
For example, people make mistakes, back out, and retry inputs, thus sometimes stumbling across interactions between error-handling code and the code under test.
* Because test automation takes time, you often won’t report the first bugs back to the programmer as soon as you could in manual testing.
* Automated tests, if written well, can be run in sequence, and the ordering can vary from day to day
* An automated test might not pay for itself until next release. A manual test will find any bugs it finds this release. Bugs found now might be worth more than bugs found next release.
 
Page objects
Within your web app’s UI there are areas that your tests interact with. A Page Object simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place.
Some other articles I read that could be useful –

Why I am signing the petition to stop ISO 29119


There is a movement being started to stop ISO 29119. If you are even a wee bit serious about your profession, you should be knowing about it. Here’s all about it. Read it if you want to know more, or just skip to the end and sign the petitions.

James Christie gave a presentation in CAST 2014 on Standards – promoting quality or restricting competition? He talked about how some organizations are trying to enforce testing standards for their own economic gain, while victimizing the software testing profession. He also stated how the standards promote excessive documentation over actual testing, thus affecting the quality of testing by taking away time from the process. At a time, when we are trying to implement Agile, and moving towards exploratory testing, heavy documentation and rigid processes make no sense. And, to force it down the throats of everyone in this profession should not be tolerated.

As Fiona Charles puts it “People on Agile projects will struggle with the conflicting demands of their projects and the standards.”

There is a reason why I have not taken the certification. Why should I pay so much money for something that won’t add any value to my work, except a bunch of words I might never need to use? I know this for a fact that being certified does not say anything about the tester’s expertise or potential. Most current certifications, for a fact, can be easily passed by rote learning. But, would that help? Rote learning never helps. How much do you remember of the history lessons from your high school? You did pass the exam.

I have known many testers who are certified, but do not have a clue about testing, and are low performers. I have also known many testers, who are awesome at their work, have high potential, are high performers, and are not certified. That is why I ignore the certification status of people I interview, and instead focus on finding out myself about how much they are interested in testing, and how well they know their craft.

This is what Karen Johnson says about wrong hiring based on blind belief in certifications:
“For several years when I was working as a test manager, I interviewed and hired numerous people. Once during an interview, a candidate pulled out a certificate and held it up for me, telling me he should be hired instantly due to his certification. I asked that he put the certificate away and talk with me. After discussion, it was my assessment that the candidate had little working understanding of how to test a product. Perhaps he had memorized material or had someone else take the exam for him – whatever had been the case; there was no evidence that the candidate would be able to perform well. As this event took place some years ago, I will refrain from trying to recall more specifics.
Given this same scenario, if I did not have a testing background but needed to hire someone, perhaps I would have been convinced based on the certificate that the candidate was equipped for the job.

If a company is hiring testers and the person or persons interviewing do not understand testing (which is often the case with HR), I do not believe that hiring person is qualified to make a decision – or even qualified to establish a pool of candidates for others to interview. This is where certification is dangerous – at first glance, it sounds good, it seems like it should provide some assurance that a person is qualified. But as I have found, having a certificate does not provide evidence of a person’s knowledge or skill.”

If you read my blog, you will know I am not against learning. In fact, I am very passionate about learning. I keep reading books and blogs to learn more about my profession. But, I want to learn out of curiosity and interest, not out of fear. That is what this standard tries to instill – the fear of losing your job or validity as a software tester if you have not paid the bucks to get certified by rote.

If the standard is accepted, companies will start believing that testers without a certification are not good, which is far from the truth. They will start over-depending on tester certifications to judge the quality of a tester.

Iain McCowatt says “Standards in manufacturing make sense: the variability between two different widgets of the same type should be minimal, so acting in the same way each time a widget is produced is desirable. This does not apply to services, where demand is highly variable, or indeed in software, where every instance of demand is unique.

Attempting to act in a standardized manner in the face of variable demand is an act of insanity: it’s akin to being asked to solve a number of different problems yet merrily reciting the same answer over and over. Sometimes you’ll be right, sometimes wrong, sometimes you’ll score a partial hit. In this way, applying the processes and techniques of ISO 29119 will result in effort being expended on activities that do nothing to aid the cause of testing.”

Karen also explains this in detail in her blog where she says that the knowledge required by an e-commerce software tester, a BI software tester, and a Medical device tester are vastly different, and can not be covered by a generic testing certification. The testers would instead do better to learn more about their domain, and to get domain-specific knowledge.

ISO 29119 claims that it is “an internationally-agreed set of standards for software testing”. But, it is not “internationally-agreed”. In fact, many influential software testers, and the experts that I look up to, are against it.

Karen Johnson – My Thoughts on Testing Certifications
Fiona Charles – Why I oppose adoption of ISO 29119
Iain McCowatt – Stop 29119
Keith Klain – The Petition to Stop ISO 29119
Michael Bolton – Rising Against the Rent-Seekers
James Bach – How not to standardize software testing

If you agree with the above view point, and are interested in saving our profession from vandalism, please sign the below shared documents:

The Professional Tester’s Manifesto

The Petition to ISO

Other articles of note –
ISO 29119 Debate
On ISO 29119 content

Book Summary: Don’t make me think by Steve Krug


I just finished reading this book. This is a very good book on usability. Everyone who is interested in improving their website, or in being a success in the Web domain, should read this.

I wanted to write a summary for myself for the times when I am not having this book with me and want to recap the main points discussed, or for the time when I am in a hurry and just want a summary to go through before starting my work. So, here it goes..
(Please read the book for detailed information and explanations. It will be totally worth it. Don’t expect to know everything there is in the book by reading the highlights below.)

1. Usability is mostly just common sense, but not necessarily obvious until after someone has pointed it out to you.

2. First law of Usability: “Don’t make me think”
* Get rid of uncommon names/text
* links/buttons should be obviously clickable
* Pages should be self evident, etc.

3. How we use the web
* we don’t read pages, we scan them
* We don’t make optimal choices. We satisfice (choose first reasonable option)
* we don’t figure out how things work. We muddle through

4. Design pages for scanning, not reading
* Clear visual hierarchy
* Conventions are your friends
* Break pages into clearly defined areas
* Make it obvious what’s clickable
* Keep noise down to a dull roar

5. It doesn’t matter how many times i have to click, as long as each click is a mindless, unambiguous choice.

6. Get rid of half the words on each page, then get rid of half of what’s left

7. Web navigation.
Following elements should be presented as per conventions:
* Site ID
* Sections
* Utilities
* Subsections
* “You are here” indicator
* Page name
* Local navigation (Things at current level)
* Small text version (links in footer)

8. Web navigation.
* Persistent navigation including 5 elements – Site ID, “home” link, Search option, Utilities, Sections

9. To check if a page is well designed – Choose a page, keep at arms length , and answer following questions as quickly as possible
* What site is this? (Site ID)
* What page am I on? (Page name)
* What are major sections of this site? (Sections)
* What are my options at this level? (Local navigation)
* Where am I in the scheme of things? (Bread crumbs)
* How can I search?

10. Home page should answer the following 4 questions, at a glance, correctly and unambiguously –
* What is this?
* What do they have here?
* What can I do here?
* Why should I be here – and not somewhere else?
* Where do I start?

11. Add a good tagline to make it clearer

12. Web design arguments within team are a waste of time. Instead, conduct usability tests by calling outside people for opinion

13. Ideal number of users for each round of testing is three, at most four

14. How to conduct usability testing – two kinds of testing – “get it” testing, “key task” testing

15. For doing usability testing by yourself, find more advice in chapter “Usability testing: The movie” that is in the first edition of this book

16. Web site should be behaving like a Mensch. Each problem user encounters on the site lowers the user’s level of goodwill reservoir

17. Things that diminish good will
* Hiding information that I want
* Punishing me for not doing things your way
* Asking me for information you don’t really need
* Faux sincerity, and disingenuous attempts to convince me that you care about me
* Putting sizzle in my way – Flash intros, animations, etc
* You site looks amateurish

18. Things that increase goodwill
* Know the main things that people want to do on your site and make them obvious and easy
* Tell me what I want to know
* Save me steps wherever you can
* Put effort into it
* Know what questions I am likely to have, and answer them
* Provide me with creature comforts like printer friendly pages
* Make it easy to recover from errors
* When in doubt, apologize

19. Accessibility is part of Usability
5 things you can do right now:
* Fix usability problems that confuse everyone
* Read an article. Highly recommended article – “Guidelines for accessible and usable Web sites: Observing users who work with screen readers” by Mary Theofanos and Janice Redish
* Read a book
* Start using cascading style sheets
* Make sure you have implemented the most common things
– Add appropriate alt text to images
– Make your forms readable with screen readers. Use labels for fields
– Create a “skip to main content” link at the beginning of the page
– Make all content accessible by keyboard
– Don’t use java script without a good reason
– Use client-side (not server-side) image maps

Issue in auto suggestions when multiple words of the same record start similarly


similar multiple words in a record

This one adds to my list of test cases for auto suggestion functionality. It really depends on the implementation whether this test applies or not, but it is still good to add to your check list.

In our case, auto suggestions are displayed using keywords mapped to the record. There is one keyword for each word in a name.

Example: “New Delhi” should show up as a suggestion when either “New” or “Delhi” is typed in.
So, there are two records in database – one with “New” as a keyword, and one with “Delhi” as a keyword.

But, what happens when words in a single name start similarly.

For example, there is a city named “Tarn Taran”. Both words in the name start with “Tar”.
When I type in “Tar”, both keywords “Tarn” and “Taran” will get matched, and if it’s not handled in the code, Auto-suggest list will display two records for “Tarn Taran”.

Improving tester-programmer relationship


testing tipsHere is something to read for today. I found this book, written by Ajay Balamurugadas, while browsing through Google results, and thought I should share it here too.

It has a lot of tips that will help you become a better tester (but only if you implement what you read 🙂 ).

Books on testing

 

Edit: Removed book’s specific link. Instead, I am sharing the download page for all 6 books written by the author

Testing Auto Suggest functionality


auto_suggest_list

Testing AutoSuggest functionality – Verification of Autosuggest list:

I am taking an example of a text box that will suggest city names from a list of cities according to inputs entered by user. Suggestions displayed are list entries that start with the string given as input. The maximum display limit of suggestions will be 10. The list of suggestions should be displayed in ascending alphabetical order.

 

1. Enter 1 character in the autosuggest field for which values are not present in the auto suggest list.

Eg. Enter “x” when there is no city name in the list that starts with ‘x’
>> No suggestions should be given to the user
>> On replacing the “x” with a character that is the first letter of a city in the list (like “n”), suggestions will be given to user accordingly (cities whose name starts with ‘n’)

2. Enter 1 character in the autosuggest field for which values are present more than the max display limit of auto suggest list. (Max limit + 1)

For example, there are 11 cities with names starting with “h” in our database. So, we enter “h” in the input field, and check the suggestion list
>> All city names displayed in the list should start with the letter “H”
>> Suggestion list should display only 10 out of the 11 available cities.
>> Confirm which 10 of the records should be displayed, and which 1 city should be ignored (should be mentioned in the requirements)
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

3. Enter 1 character in the autosuggest field for which count of values present is exactly equal to the max display limit of auto suggest list. (Max limit)

For example, there are 10 cities with names starting with “L” in our database. So, we enter “L” in the input field, and check the suggestion list
>> All city names displayed in the list should start with the letter “L”
>> Suggestion list should display all the 10 available cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

4. Enter 1 character in the autosuggest field for which count of values present is exactly 1 less than the max display limit of auto suggest list. (Max limit – 1)

For example, there are only 9 cities with names starting with “E” in our database. So, we enter “E” in the input field, and check the suggestion list
>> All city names displayed in the list should start with the letter “E”
>> Suggestion list should display all the 9 available cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

5. Enter 1 character in the autosuggest field for which count of values present is exactly 1.

For example, there is only one city that has its name starting with “Y” in our database.
So, we enter “Y” in the input field, and check the suggestion list
>> Only the city name starting with the letter “Y” should be displayed in the list
>> Suggestion list should display the city name that starts with “y”.

6. Check for case-sensitivity
>> Suggestions provided for “H” should be the same as those provided for “h”
>> If suggestions are not provided for “x”, they should not be provided for “X”
>> If records are displayed, the input string should be highlighted in the records that are displayed in the suggestion list.

7. Assuming, cities exist whose names start with “H”
Enter “H”. Remove the character using backspace. Enter “h” (or vice-versa; replacing “h” with “H”)
>> Suggestions provided for “h” should be the same as those provided for “H”
(I found a bug in Google search with this test case)

autocomplete issue in google search

8. Verify that user is able to select any value from autosuggest list
Assuming, at least 3 cities exist whose names start with “H”.
>> After user enters “H”, user should be able to select any value using only the keyboard (up & down keys)
>> After user enters “H”, user should be able to select any value by clicking on it
>> User should be able to select the first displayed suggestion
>> User should be able to select a suggestion in between extremes (the 2nd one)
>> User should be able to select the last displayed (3rd) suggestion

9. Enter 1 character in the autosuggest field for which values are present in the auto suggest list. Then, replace it with another character for which values are present.

Eg. Assuming cities starting with letters ‘s’ & ‘t’ exist in the test list
Enter “s”. Remove the character using backspace. Enter “t”
>> On entering “s”, suggestions should be displayed with city names that start with “s”
>> On pressing backspace, the displayed suggestions should be removed (hidden from view)
>> On replacing the “s” with “t”, suggestions will be given to user accordingly (only cities whose name starts with ‘t’)

10. Enter 1 character in the autosuggest field for which values are present in the autosuggest list. Then, replace it with another character for which values are not present.

Eg. Assuming cities starting with letter ‘s’ exist in the test list, and there are no city names that start with “x” in the list.
Enter “s”. Remove the character using backspace. Enter “x”
>> On entering “s”, suggestions should be displayed with city names that start with “s”
>> On pressing backspace, the displayed suggestions should be removed (hidden from view)
>> On replacing the “s” with “x”, no suggestions should be given to the user

11. Enter 2 letters such that city names starting with 1st letter exist, but city names starting with the 2 letter combination don’t.
For eg., we have cities that have names starting with “s”. But, there is no city name that starts with “sd”.
Enter “sd”, and check the displayed suggestions.
>> No suggestions should be given to the user

12. Enter 2 letters such that city names starting with 2nd letter exist, but city names starting with the 2 letter combination don’t.
For eg., we have cities that have names starting with “d”. But, there is no city name that starts with “kd”.
Enter “kd”, and check the displayed suggestions.
>> No suggestions should be given to the user

13. Enter a 2 letter combination such that the count of city names starting with the 2 letter combination is more than the max display limit of auto suggest list. (Max limit + 1)

For example, there are 11 cities with names starting with “ha” in our database. So, we enter “ha” in the input field, and check the suggestion list
>> All city names displayed in the list should start with the string “Ha”
>> Suggestion list should display only 10 out of the 11 available cities.
>> Confirm which 10 of the records should be displayed, and which 1 city should be ignored (should be mentioned in the requirements)
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

14. Enter a 2 letter combination such that the count of city names starting with the 2 letter combination is exactly equal to the max display limit of auto suggest list. (Max limit)
For example, there are 10 cities with names starting with “Le” in our database. So, we enter “Le” in the input field, and check the suggestion list
>> All city names displayed in the list should start with the string “Le”
>> Suggestion list should display all the 10 available cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

15. Enter a 2 letter combination such that the count of city names starting with the 2 letter combination is 1 less than the max display limit of auto suggest list. (Max limit – 1)

For example, there are only 9 cities with names starting with “Ed” in our database. So, we enter “Ed” in the input field, and check the suggestion list
>> All city names displayed in the list should start with the string “Ed”
>> Suggestion list should display all the 9 available cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

16. Verify that user is able to select any value from autosuggest list after entering a 2 letter combination.
Assuming, at least 3 cities exist whose names start with “Hu”.
>> After user enters “Hu”, user should be able to select any value using only the keyboard (up & down keys)
>> After user enters “Hu”, user should be able to select any value by clicking on it
>> User should be able to select the first displayed suggestion
>> User should be able to select a suggestion in between extremes (the 2nd one)
>> User should be able to select the last displayed (3rd) suggestion

17. Enter 2nd,3rd, 4th char (and so on..), and verify the values displayed in the autosuggest list.
>> Suggestions should keep getting updated according to the newest letter added as input
>> The input string should be highlighted in the records that are displayed in the suggestion list.
>> If we have a city “Ahmedabad” in our list, and there is no other record that starts with the string “Ahmedabad”. When we enter “Ahmedabad” as our input, only one suggestion of the city should be displayed (duplicates should not be present, and full name should narrow down the suggestion list).

18. Copy-Paste should work.
Assuming cities starting with letter ‘Si’ exist in the test list
Copy the string “Si”, and paste it into the text box
>> All city names displayed in the list should start with the string “Si”
>> Suggestion list should not display more than 10 cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)

19.Enter first character as special character and verify the autosuggest list.
Eg. Assuming cities starting with letter ‘s’ exist in the test list.
Enter any special character (like +,_,*,$,etc…), and then enter “s”
>> Confirm requirements. One of the two results might occur:
i) No suggestions should be given to the user
ii) Special characters should be ignored while checking inputs, and suggestions should be displayed to you for city names that start with “s”

20. Enter a city name that contains a special character. Check for all possible special characters.
Eg. “St. Louis”, “New Delhi”, “Chittur-Thathamangalam”, “Daman & Diu”,”O’ Valley”
>> Proper suggestions should be displayed to user if the cities exist in the list

21. Check what happens when you enter names with non-english special characters.
Eg. “Orléans”
>> Confirm requirements

22. Without entering anything in the search text box, click Search icon or hit enter key
>> Confirm requirements. If city is mandatory, user should be displayed an error, otherwise, results should be displayed according to default.

23. Without selecting anything from suggestion list, hit enter key or click search icon
Eg. Enter a full city name like “New Delhi”, and hit enter key or click search icon.
>> If requirements require selection, an error should be displayed to the user
>> Otherwise, results should be displayed for the city “New Delhi”

24. Enter a city name that is not present in the suggestion list, and hit enter key or click search icon
Eg. Assuming “Paris” is not in our list, and hence will not be displayed as a suggestion in any case.
Enter “Paris”, and hit enter key or click search icon.
>> An error should be displayed to the user

25. Check scenario where a city name contains more than 1 word.
Eg. If “New Delhi” is in the test list,
Enter “New” and check auto suggest list. Enter “Delhi” and check auto suggest list.
>> If users are likely to enter a word other than the first for the city name, entering the contained words (other than 1st word) should also display the city name in suggestions.
As in India, people are as likely to call the city “Delhi” as they are to call it “New Delhi”, the suggestion list should display “New Delhi” when either of the “New” or “Delhi” is typed by the user.

26. Check by entering input with a preceding space character
Eg. Assuming cities starting with letter ‘s’ exist in the test list.
Enter a space character (” “), and then enter “s”.
>> Preceding space character should be ignored, and suggestions should be displayed to you for city names that start with “s”.
>> Suggestion list should not display more than 10 cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)
>> The matching text should be highlighted in the auto-suggest list

27. Check by entering input with a succeeding space character
Eg. Assuming cities starting with letter ‘s’ exist in the test list.
Enter “s”, and then enter a space character (” “).
>> Succeeding space character should be ignored, and suggestions should be displayed to you for city names that start with “s”.
>> Suggestion list should not display more than 10 cities.
>> Check the sorting order of display of the suggestions. (According to given requirement, the list of suggestions should be displayed in ascending alphabetical order.)
>> The matching text should be highlighted in the auto-suggest list

28. Check handling of input to be entered that can be called by different names (different spellings).
Eg. In our example of city names, a city can have an old name, and a new name. The name of a city called “Baroda” was changed “Vadodara”. A user is likely to type in any of the two names.
>> Confirm requirement on whether the user should be displayed the new name in suggestion list when typing old name, or whether both the names are to be treated as independant & separate records.

29. Enter some characters, select a value from the auto suggest list, delete the value from the text box, then enter a different input and select from auto suggest list.
Eg. Assuming “Mumbai” and “Chandigarh” are in the test list.
Enter “Mum”. Select “Mumbai”. Clear the input text box, and then type “Cha”. Select “Chandigarh”
>> The last selected value (“Chandigarh”) should be displayed as selected. On hitting enter key or clicking button, results should be displayed according to input = “Chandigarh”

30. If values in auto suggest list come from more than one categories, check display of the list values on entering input
>> Confirm requirements on the sorting order of values to be displayed from across categories.
>> Check that all related values from across categories are displayed in the auto suggest list. None of the available categories should get missed out

31. Check that the auto suggest functionality works as expected across various browsers and their different versions. (Cross Browser compatibility check)

32. In all pages where the auto suggest is implemented, check that existing functionality of page is working properly. At times, javascript errors occur, or the new code starts interfering with the existing functions.

33. Check widening of suggestion list when characters are removed from input field.
Eg. Assuming there are 11 cities with names starting with “ha” in our database, and there are 6 cities with names starting with “hal” in our database.

Enter “HA”. Enter “L”. Remove “L”.
>> On entering “HA”, 10 cities should be displayed in the suggestion list (max. limit)
>> When “L” is added to make it “HAL”, suggestion list should be updated to display only the 6 cities that start with “HA”
>> When “L” is removed to make the input “HA” again, suggestion list should be updated to display the same 10 cities that were being displayed earlier (before typing “L”).

34. Check how drag-drop of text is being handled by the input text box
Eg. Assuming city “Pune” is present in our database, and the page containing the auto suggest functionality input box also has the text “Pune” written somewhere in it.

Drag-drop the text “Pune” from the page into the input text box
>> “Pune” should be displayed in the suggestion list to the user
Along with my own list of test cases, I also used the list in given link as guidance material. A very big thanks to the writer! 🙂

Why do you need testers


A very, very common question by people who cannot understand why developers can’t find or prevent bugs in their own code. Maybe they are managers who haven’t been developers. Maybe they are developers who are finding it hard to admit that they can also make mistakes.

So, I was asked what I would do if I was told that the project would be taken live without testing, and that testing was not required.
I replied I would let them take it live without testing, and then let them face the music from the customers themselves. That would be the practical way. Because experience is the best teacher, and the best way to let someone know something’s importance is to let them have a lack of it.

No amount of debating can convince a person who has made up his mind that testing is not required. He has to be either forced into accepting it as a part of work life, or he has to be made to face the consequences of its lack to realise the importance.

But, if you need the theory behind why testing is required,  here’s why.

1. The most important point. There’s a difference between a developer’s attitude (creation), and a tester’s attitude (destruction).

A developer wants to show that the code is working. Because of this, he/she subconsciously selects such test inputs that have low probability of causing errors. It’s in the psychology, one cannot help it.

A tester wants to show that the code doesn’t work. Not that they are against it or anything. They just break it so that it can go all patched up, and smooth, into the customers hands.
Testers love to be the only ones who break it, so that the team doesn’t ever have to face a red-faced customer demanding they fix the issue that very moment. Errors can take days to resolve at times, but when the problem is at the customer’s end, every minute counts.

2. People say every thing was fine and smooth, even before the tester stepped in. Are you sure?
There was no tester before who would have told you that some very critical problems had been left hidden beneath the illusory smooth surface of the code. You know, developers are human, and they can make mistakes too. One needs to make sure that at least the severe mistakes don’t land in the hands of the customer.

Very few Customers tell you about the problems they face. Most of them just get irritated, try to work around, and stick to you only until a better service/software comes in the horizon. Then, suddenly, your user base just stops being yours, and shifts to your competitor who cared more about finding the quality issues and fixed them. (Wanna know more?)

3. Have you heard of the game ‘Chinese whisper’?
People sit around in a circle. One person whispers something into the neighbour’s ear, who whispers the message into the next person’s ear. The message is passed until it reaches back to the person who had started the chain. When the chain ends, the message always gets drastically twisted into something else.

Now, consider the learning from the game above into the software development cycle. When a software is developed, a number of teams and people are working together.  The requirements are passed on in a chain and might have passed through many levels until they finally reach the developer who will work on it. Imagine how distorted the requirements might have become till they reach the end of the chain.

The tester being in the process since the beginning (requirements phase) will be able to inform you about the misunderstanding of the requirements. Also, testers make it a point to understand the bigger picture and are at a better position to ascertain quality than the developer who has knowledge only about the part of the code he/she is working on.

4. The later the stage when the bug is found, the higher is the cost of fixing it.
As the bugs reported by a customer maybe vague due to their lack of knowledge about the code, it would be even harder and more time consuming for the developer to isolate the exact line of code that is causing the issue. And what worse experience than a customer shouting at the other end, while you’re desperately trying to find the cause of the elusive bug just reported to you, with immense pressure to resolve the bug immediately. You are at the brink of pulling your hair out because here you have not even understood where the problem is, and you are being asked to deliver a solution within an hour. You just want to stand up and shout curses in the air, just because the issue was not found earlier when you had an option to not deliver a software with such critical problems without solving them. If the bug had been found earlier, you would have worked with a calmer state of mind too, thus helping you to work faster.

5. Code might work perfectly fine as an individual unit, but might break when two separate units are integrated together.
You have website that works fine in itself. You have a backend portal that works perfectly fine in itself too. Maybe, the two softwares were made by two different teams who don’t have much idea about the other team’s software. Now, you integrate the two softwares through an API. But, things go wrong. Data collection gets wrong, and reports are incorrect, because they realised too late that the softwares had not been integrated properly. Maybe a variable was required to be passed but wasn’t due to some misunderstanding of specifications. Maybe the value passed was not the same as expected. And this integration error, that none of the teams could have found themselves without first taking weeks, or months, to go through the entire code of the other team, causes a huge loss in revenue.

But, if people, even after the practical/theoretical knowledge of the importance of testing, think they can do without testers in their team, I’m really curious to know what their game plan is to reach the #1 spot. Or if they are already #1, I’d like to know their game plan for maintaining their spot. Because, as far as I know, it’s just not possible.