Is “only” Automation Annihilating Manual Tester Within…

Client: Can we automate our test cases

Service Provider: Yeah,we can do it!

Client: What team size do you own and what time will it take?

Service Provider: We have got sufficient team size dedicated only for automation…

Client: Sounds great!

Nowadays every software product that is being developed quality is always a high priority, so as to make it useful for end users. For a proper quality product every software goes under scanner of Software Testing, where some group of people having knowledge about the product perform testing activities related to it.

Some of the small projects are managed by having manual test cases and testers keep on executing those prior to release and delivering the project. When the project size increases and at a point when client thinks automation of test cases then ‘we’ (Automation engineers) come into picture. This is a generic scenario in an organization that we come across.

Let’s take an example of a project where automation is needed and manual test cases are written by some other team. At start of it, only priority is to automate, a set of test cases which have high priority based on business needs. Gradually we follow the regression test cases and start automating at a stretch. Here we are only for the automation purpose and the job is to merely follow the test cases automating it.

Looking for the above scenario we do not get chance to do some manual stuffs as that is not our work. Though while automating we do go through the steps/cases and perform some journeys using it. Counterpart here is test cases are always updated and it works!

Manual testing is not only a process or about having a capability of thinking more scenarios but apart from this, it contains lots of other activities. It can be about following some best practices, involvement with other teams, providing suggestions/opinions and it inculcates within if we follow it. Though it can be part of automation too, but not for all the cases.

So, where are we?

Don’t you think doing only automation is killing your manual testing skills that you have?

Is it destroying your thinking?

When we are bound only to automation work, yes it is. Introspect within.

Do we Need Test cases?

I was writing test cases meekly for one of my projects on a busy day at my office. A notion clung my mind why am I doing so. Is this necessary? Is it indispensable?

I tried getting inputs from my fellow colleagues, despite it was vague to question about such an imperative thing.  Every one answered in a similar fashion. It was about its benefits namely repeatability, re-usability, can be used for regression testing (particularly if you don’t have automated scripts), providing an audit trail of testing done (coverage), training – it can be useful for helping to new staff, can provide traceability to requirements etc. Alas, I got all the answers in favor of need as expected.

Test cases are not necessary as it doesn’t imply quality testing and moreover it does not make a good tester in isolation either. In quest of its need I drilled down more.

Software testing is about brainstorming test ideas that you can think. Instead of spending time on writing whether a test is manual type or any other, spend that time in listing or thinking another good test idea. It is about as soon as you get information about the requirements (software requirements specification document though it is always incomplete), we should have a list of ‘Wh…’ questions related to it. Which would certainly help you in evolving your creative thinking too?

Now a day every IT organization is following the agile methodology. There is nothing new in it. Let me give you a more of similar analogy for it. When we speak to a person/group, our notion is more of agile kind of thing. We know what to speak and if we get wrong in between we know how to react to it by asserting new ideas. If we miss some points during the extempore we can share that later on.

Same way if you think in especially for agile software development that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans. We develop something that can have some missing requirements; issues or new changes/redesigns etc. and these are so frequent.

Coming to the software testing context the changes in requirements are more frequent and it is not an easy task to keep testing needs in same pace. Think of a situation where changes are frequent and someone prepares docs (test plans/cases, matrices) etc. for requirements then the work done for the preparation goes in vain and it happens.

This is my Self-experience :(

In my opinion the conclusion is that writing test cases should only be context driven. A simple feature/check list should be enough for it. A good test design document come in handy too for the same. Invest more time in testing the software rather making your test cases fancy.

Be Skeptic, Test More :)

Checking sever side validation

As a QA our main focus should be on testing server side validation rather than testing client side validation (though it is also imp.). For that we can try manipulating the POST parameters using some addons/tools. One of which is Tamper data(manipulates POST parameters only) or Fiddler tool can also be used it can manipulate GET and POST parameters), there are many others too.

Lets take an example explaining why it's important.

Scenario:

Think of dropdown containing values from 1 to 10 and is being used in some calculation. From users perspective s/he may choose any value. Now if a QA manipulates the POST parameters after the selection is done by user and in between the value is changed before the request reaches to server. If the server side validation is not done then the changed value can affect the calculations or the application.We should take care of it.

Be Skeptic, Test More!

A Meager Checklist to Start Testing a Webpage

As a SQA we come across various types of web sites to test on. Every site is different in their own way depending on their need of existence.

The common thing between webpages is the web elements present on it. It can be diverse but countable and testable ;)

SQA person needs to be diligent all the way while testing web sites, moreover the functionalities allied with the web elements. If we look intensively into a site it’s merely a combination of controls that take inputs from a user, save in database and then again shows the same data on the user interface. We as QA personnel are held responsible for all kind of testing performed. Moreover the website should run flawlessly in different set of browsers like Internet Explorer, Firefox, and Safari etc. Some sites are so intricate in their designs/ functionality, so if we could take care of some basic steps it may help in achieving a great quality of product.

Here are some of the checks that can be helpful for testing the various controls we encounter on a web page and should be followed according to the project scope.

Checklist for testing a textbox control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. Tool tip
4. Editable (If enabled)
5. Types(numbers, alphabets, special chars, cases (upper, lower), spaces)/combination of characters that can be entered
6. Char limits
7. Validation if any
8. Tab order
9. Multilingual characters check (if in scope of project)

Checklist for testing a Button control:

1. Look/feel and label associated with/on it
2. Enabled/Disabled
3. Tool tip
4. Clickable if Enabled
5. Validation if any
6. Tab order

Checklist for testing a Dropdown control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. Tool tip
4. Correctness of information shown
5. May/may not contain “Select” as first value (i.e. zero index)
6. Validation if any
7. Tab order

Checklist for testing a checkbox control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. May/may not contain tool tip for every checkbox
4. Check/uncheck single/multiple
5. Validation if any
6. Tab order

Checklist for testing a Radio button control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. May/may not contain tool tip for every radio button
4. From a group only one should get selected at once
5. Validation if any
6. Tab order

Checklist for testing a Multiline/Rich text box control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. Tool tip
4. Editable (If enabled)
5. Types (numbers, alphabets, special chars, cases (upper, lower), spaces, html, images, videos etc.)/combination of characters that can be entered
6. Char limits
7. Multilingual characters check (if in scope of project)
8. Validation if any
9. Tab order

Checklist for testing any text:

1. Look/feel and color
2. Relevance
3. Spellings

Checklist for testing an Image/Picture:

1. Look/feel and label associated with it (if any)
2. Enabled/Disabled
3. Alternate text property should always be provided
4. Validation if any
5. Clicking on images (if clickable, navigation to desired destination)
6. Tab order

Checklist for testing a video:

1. Look/feel and label associated with it (if any)

2. Enabled/Disabled

3. Alternate text property should always be provided

4. Play, pause, forward, backward, volume, mute, maximize buttons, time etc

5. Audio and Video synchronization

6. Tab order

Checklists for testing a File upload control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. Tool tip
4. Uploading a file/doc
5. Max/min file size allowed
6. Multiple file uploading (if allowed)
7. Tab order
8. Validation if any

Checklist for testing a Calendar control:

1. Look/feel and label associated with it
2. Enabled/Disabled
3. Tool tip
4. Selecting suitable dates
5. Manually entering dates (if allowed)
6. Tab order
7. Validation if any

Checklists for testing links:

1. Look/feel and text associated with it
2. Enabled/Disabled
3. Tool tip
4. Clickable (navigation to desired destination)
5. May/may not have distinct color for a link (different color recommended)

Checklists for testing Data grids/tables:

1. Look/feel
2. Enabled/Disabled
3. Sorting of columns (recommended, depends on project scope)
4. Pagination
5. Tab order

Albeit we can have many more scenarios that need to be tested comprehensively, above are the minimal sets of steps on which without contemplation we can start with. As said discovering the unexpected is more important than confirming the known.

Be Skeptic, Test More :)