Agile Information Technology

How to Prepare Cross Functional Flowchart in MS Visio

noreply@blogger.com (Priya Ranjan) — Mon, 26 Jul 2010 13:44:00 +0000

This is pretty simple. Follow the steps written below and see the output attached:

1. Open MS Visio 2007 (whichever version you have)

2. Go to File > New > Flowchart > Cross Functional Flowchart

3. Drag and Drop Functional Bands from Cross Functional Flowchart Shape

4. Drag and Drop Separator, if required, in your diagram

5. Decide the flowchart logic on a pen and paper and replicate the same on Visio

6. Color the Fonts, Links, Lines etc to your choice

Visio Cross Functional Flowchart

See the attached document for your reference. You can generated better documents based on the complexity of the flow. I have illustrated with a simple business case - Recruitment Process in an organization.

A Generic Workflow Diagram

noreply@blogger.com (Priya Ranjan) — Thu, 03 Jun 2010 06:20:00 +0000

A generic workflow comprises of following three items:

i. Input
ii. Validation
iii. Process
READ MORE >>

3 Attitudes of a Project Manager – Optimist, Pessimist and Realist

noreply@blogger.com (Priya Ranjan) — Wed, 28 Apr 2010 08:58:00 +0000

Project management is a complex role to play. The project manager does the requirements gathering, feasibility studies, planning, execution and risk mitigation. In the endeavor, the manager has three different takes – optimist, pessimist and realist. Well, how can the same person have three different attitudes? This is both exciting as well as challenging.

Optimist

As a manager, you create a plan, execute them and hope that you'll not fail. You have to manage team, resources, technology, management, vendors, stakeholders etc. While doing so, you hope that everything will comply with the process and the plan. The plans can only be made if you are an optimist.

Pessimist

You have to be a pessimist to identify the scenarios under which the plan may fail. You need to identify the risk. In order to identify risks, take the most negative attitude towards the project execution and see what all factors may cause the failures or deviation from the plan. If you do not identify the threats, you will not create a mitigation plan and the consequences could be really bad to really worse.

Realist

Your attitude towards the projects should be indifferent, unattached and unemotional. While execution, if there is any deviation from the plan or potential delay in the delivery do not get emotional about your plans getting failed. Be a realist. Accept that real life scenarios can be rude and approach towards the remedial actions.

A project manager has to be all of these. Playing the above three cards gives you success and help you become a seasoned project manager.

How to Answer Tough Interview Questions?

noreply@blogger.com (Priya Ranjan) — Mon, 22 Mar 2010 05:00:00 +0000

I posted this on http://www.lifeheed.com/ (http://www.lifeheed.com/article.php?article=35) earlier and thought it would be valuable for community who are following this blog.

If you are looking for a job change, be prepared for the interview process. Well, preparations may not always help. You may get surprise questions in the interview. You need to apply presence of mind, competence and communication capability to approach towards such questions. Let us first understand what sort of the questions are these and then we will take an approach to ace the interview.

What are the tough questions?

"Where do you see yourself in five years?"

"What are your weaknesses?"

"Why should we hire you?"

"Why do you want to quit your current job?"

And the most fundamental question:

"Tell me about yourself?"

There are many such questions. Which question will be thrown upon you, indeed, depends on the mood of the interviewer and the trajectory the interview takes. These questions are tough because there is no definite answer to these. You need to think hard before you can say anything on any of these issues. Interviewers ask these questions from a very open mind. They want to judge your approach and visibility about your past events, current tasks and future plans.

Another type of tough questions could be in the form of testing your aptitude. For example, you have got nine iron balls -- eight of which have same weight and the rest one is slightly lighter than the rest. You have a pair of balance scale. In how many minimum attempts can you find the lighter ball?

Ideally, you should be able to answer such question. If the question is really tough, try to break it into smaller ones and step-by-step try reaching closest possible to the answer.

How to approach tough questions?

So, if you do not know the answers already, how would you handle them? I suggest, utter clarity of your thought process and presence of mind will help you. Brainstorm a little before the interview on possible such questions -- as many as you can. A little amount of homework would be handy during the interview.

Stir your creative juices and think about how to properly answer the broader range of questions (like ones mentioned above) that you will face.

Impossible Questions

Once an interviewer asked me – “How would you move mount Fuji?”

It is practically impossible to answer such a question. You cannot move mount Fuji physically. But you answer it in following ways:

“We do not need to move mount Fuji, the earth is rotating. Hence, mount Fuji is moving by itself.”

“Make a bomb and blast mount Fuji. Pick the stones, dust and trees and displace them.”

So, the answers are also impossible situations. But, at least, you need to think.

Thinking is the mantra when you are dealing with the tough interview questions. Flex your brain muscles and come up with some intelligent scenarios to answer these questions.

Tips for a Résumé to Survive Screening

noreply@blogger.com (Priya Ranjan) — Thu, 18 Mar 2010 05:59:00 +0000

As the market has shown the signs of recovery, you must be looking forward to get a good job opportunity in testing. In the sea of résumés before the recruiter, your résumé really needs to stand out. Needless to say, that résumé can make or break your chances to get even first call.

Use these tips to boost your résumé's chance of survival in the initial scrutiny:

1. Dates are important: Don't try to cover up your age or a gap in experience by omitting dates.

2. Use specific keywords: Many HR folks look for certain keywords from the job description. The résumé must be customized to meet the requirements of the potential job.

3. Be specific in your work: Verbs like "Assisted" or "worked on" sounds vague. Alternatively, use verbs like "designed," "wrote," or "led." Be specific while quoting any action.

4. No typos: This goes without saying, but too many résumés are full of spelling errors, grammatical mistakes and wrong punctuation marks.

5. Keep it short: A five-page résumé may be justified, but you must make it clear through headings and organization why you need so much space.

Last but not the least, your résumé is your baby and must be prepared delicately. In testing you produce lots of documents, test cases and test reports. If you have left errors in your profile, the interviewer cannot regard you as a tester or test manager (whichever is applicable). You may get rejected even though you perform reasonable good in the interview.

What is END and NED?

noreply@blogger.com (Priya Ranjan) — Thu, 18 Mar 2010 05:46:00 +0000

Simply put,

END = Evidence of no defect
NED = No evidence of defect

Let us talk about each of them.

Is is possible to achieve END? Does any application or program exist that have no defect? Practically speaking, no. In a complex application there are lots of controls an interdependent modules. Testing each and every bit is not possible practically. So it cannot be assured that there is no defect in the application. Whatsoever, amount of testing we do on the given application.

But there is another school of thought who says it is possible to achieve END. Consider the program written in C below:

int main()
{
printf("hello, world");
return 0;
}

It simply prints hello, world on execution.We are 100% sure that the line will be printed, without any fail. So the evidence of no defect or END is achieved.

Now comes NED. What does it signify?

Having no evidence of defect means -- you have conducted your testing based on your test scripts. You have covered all the possible areas, you might. Based on the set test cases and the scope of testing you can say that the application passes your test. In other words, there is no evidence of defect in the application.

Test Cases for Triangles

noreply@blogger.com (Priya Ranjan) — Mon, 15 Mar 2010 05:18:00 +0000

We have studied the properties of various triangles in school. Let us apply those properties to test a triangle today.

A triangle is made of three sides (and three angles of course). Let us assume that the vertices are A, B and C, and corresponding sides are a, b, c.

Test cases follow:

1. Enter 0, a, b. No triangle is formed.
2. Enter 1, 2, 4. No triangle is formed because for a valid triangle a+b>c, b+c>a, c+a>b.
3. Enter angles A, B, C. The sum of the angles should be 180 degrees.
4. Enter a, a, a. Valid equilateral triangle.
5. Enter a, a, b. Valid isosceles triangle.
6. Enter angles A, B, C. If any of the angles is 90 degrees and the sum is 180 degrees, it is a right angle triangle.
7. Enter angles A, B, C as 90, 90, 0. The sum of angles is 180 degrees, still the triangle cannot be formed.
8. Enter negative value for a side, e.g. -1, -1, -1. Invalid input.
9. Enter character value for one of the sides, e.g. a, 2, 2. Invalid input.

Please add more to this.

Traceability Matrix: How to Map Requirements to Test Cases

noreply@blogger.com (Priya Ranjan) — Tue, 16 Feb 2010 08:43:00 +0000

Refer to following articles for more:

When you write test cases from a requirement document or use case document, you should remain sensitive towards the coverage of the requirement and converting them to testable items. The test cases are designed keeping in mind about the requirements coverage. If there are areas not covered in the test case, it will go untested. In order to verify whether all the requirements are being tested or not, Traceability Matrix is created. It maps requirements to the test cases.

So, what is the format?

If you have a tool to trace the requirements, fine. Otherwise, traceability matrix can be maintained in a Word document or a Spreadsheet. In the tool, each use cases or requirements are linked in one-to-many relations with the test cases.

In the Spreadsheet, the format of a traceability matrix is a table -- having columns as the requirement id (or use case id) and rows as the test case id. Please refer to the picture below.

Alternatively, traceability matrix can be created in following format in Word document:

And, why is traceability matrix important?

Traceability is important for the successful coverage of requirements in the test cases. Besides, it helps in following:

- Knowing whether whole of the current requirements are considered for testing
- Knowing whether changed requirements are converted into testable items
- Documentation to form the basis of testing
- Understanding where requirements have been built into the system
- Forming the basis for ongoing system documentation

To conclude, writing a traceability matrix is not a one time affair. It should be updated with every change in the requirements to avoid any potential threat of requirement items going untested.

How to Work in TDD Methodology of Software Development

noreply@blogger.com (Priya Ranjan) — Fri, 12 Feb 2010 10:12:00 +0000

Test Driven Development methodology of software development is one of the most popular flavor of agile methodology. Other popular flavors of agile are Scrum, Extreme Programing (XP), Function Driven development (FDD) etc. The main principle behing TDD is to write unit test cases first and then code the unit of the module so that the unit passes the test. TDD saves a lot of time and money in finding the sofwtare defects at the later stage of software development. Farther the testing cycle falls, higher would be the cost to fix the issue.

Following are the steps followed in TDD:

Gather the requirement and fine tune it with detailed understanding
Create automated test scripts to test the each unit of the requirement
Develop the code for the given unit
Test the unit of the code with the automated script
If the code passes the test, means the code fulfills the requirement
Further, if the code is refactored -- run the automated test scripts again for each units till all the unit test scripts are passed

For automation of unit test cases you may use JUnit (for Java projects), NUnit (for .Net projects) or even Selenium (for web-based projects). TDD requires good coding skills and purely manual testers will have to upgrade their skills to meet the requirements of the job in TDD environment.

I'll keep on adding more strategies to make TDD successful. Keep a tab on the blog..

How to Conduct Performance Evaluation of Agile Team

noreply@blogger.com (Priya Ranjan) — Fri, 12 Feb 2010 08:40:00 +0000

Traditional performance measurements are successful with the traditional methodology of software development, where we stress more on individual contributions towards creating the software and reporting is made hierarchical in nature. In agile, the evaluation must also be adaptive, collaborative and frequent.

The traditional performance evaluations focus more on the individual performance and training needs. Whereas, in cross-functional team of agile evaluation of only individual performance would not be fair. So what stand should you take in such a case?

Consider the following:

1. Motivate agile team instead of individual members because together the team can take the project to a big success, not the individual members

2. Complement agile values of collaboration, communication and openness

3. Conduct reviews frequently, preferable every quarter, rather than yearly or half yearly

4. Conduct 360 degree feedback of individual members within the team

5. Seek the Product Owner's feedback on team's performance

6. Seek the ScrumMaster's feedback on individual member's performance

7. Don't forget to acknowledge individual performance

8. Identify the improvement areas of team members to make the team more cross-functional

9. Create empirical formulae and metrics to benchmark team/ member performance. Don’t keep the evaluation fuzzy

I'll elaborate more on the metrics and weight assignment to each of the team/ member’s qualities and how to reach to a conclusion if the performance measurement of the agile team.

How to Measure Agile Team Members' Performance

noreply@blogger.com (Priya Ranjan) — Wed, 10 Feb 2010 11:39:00 +0000

The key elements of agile (say Scrum) methodology of software development is the team is cross-functional, collaborative and self-organized. Means, in Scrum, the entire team is responsible to execute the Sprint tasks; not the individual member of the team. So, the success or failure of the Sprints is based on the cumulative performance of the team. There is, however, a problem in judging an individual's performance; because each team member is not highlighted much during the product development.

So, what should be fair way to do the performance review of the individual members in the team? Consider this:

1. Allocate certain points to team's performance: Based on management's discretion attribute 30-50% of individual's performance to the team's performance. There is no individual heroism in the project. The project will fail if the members of the team are not helping each other. Only if members have acted to their full potential, the project would be a huge success. So, it is fair to attribute project's success or failure to the individuals in the project.

2. Allocate rest of the points to the individual's performance: Having said that the team fails or succeeds together, you should not undermine individual performance and training needs. So, allocate rest of the percentage to the individual's functional deliverables, product/ domain knowledge, collaboration etc.

3. Do a proper benchmarking and normalization in the team: If the project is 2 on the parameter of 5, you cannot expect somebody is 5 out of 5 in the project. It would be an exception. So look into such an issue carefully and do a proper benchmarking.

Phew, performance review is a tough job. Isn't it?

How to Conduct Daily Scrum Meeting

noreply@blogger.com (Priya Ranjan) — Wed, 10 Feb 2010 10:51:00 +0000

Daily stand-up meeting is one of the most critical meetings in agile methodology of software development. It is a quick review of each team member's last days work, planning for the next day's work and impediments the member is facing. ScrumMaster looks into the impediment and can resolve it upfront or in a sidebar meeting.

Stand-up meetings have certain rituals to be followed:

1. Strictly stand-up: For the brevity of the meeting everybody should stand-up till the meeting is finished. Standing-up also raises your concentration level and enables you to listen to other members carefully.

2. Short, 15 minutes meeting: These meetings are conducted to keep the entire team in synchronization and also to keep everyone aware about the impediments faced by the other team members. If any discussion on the impediments takes longer, the discussion should be handled in a follow-up meeting with only those who are affected and those who can resolve the issue.

3. Everybody should be present: 100% presence is necessary to keep the entire team in synch. If you feel you can't participate because of overwork or leave, make one of your team members aware about your part of discussion.

4. Concentrate on every member's discussion: The Scrum teams are self-organizing and there is no strict delegation of work. So if there is any impediment faced by one of the team members, feel free to pitch-in and resolve the issue. For this you need to listen to others very carefully.

5. Everybody has to speak in no strict order: Yes, this is the ground rule of the daily Scrum meeting that everybody has to speak in a desired manner: accomplishment since last meeting, plans till next meting and impediments faced (if any).

6. No detailed technical discussion: Since the time is limited for the Scrum meeting, any lengthy discussion between two members on any issue can lead to wastage of entire team's time. If any such discussion is required, do it in the sidebar meeting.

It doesn't matter at what time during the day you conduct the meeting, it should be followed religiously. Ideally, conduct the meeting in the morning before you start your day's tasks so that you get maximum bandwidth of the support functions and team to get all the roadblocks resolved.

Role of the Product Owner in Scrum (Agile)

noreply@blogger.com (Priya Ranjan) — Mon, 08 Feb 2010 12:20:00 +0000

In Scrum, one of the flavors of agile methodology of software development, there are three fundamental roles: the Product Owner, The ScrumMaster and the team. In current post let us talk about the Product Owner's role in detail.

The Product Owner represents the customer's interest and prioritizes the backlog of tasks according to the business needs. She/ he participates in the Sprint Planning meeting and evaluates the entire product backlog, prioritizes them and include in or exclude from the next Sprint. She/ he has the final say whether the task should be reprioritized or dropped. The team working on the product development can negotiate with the Product Owner on the priority of the task, but the final discretion lies with the Product Owner only. The Product Owner also decides the acceptance criteria for the potentially shippable product after the Sprint is completed.

At times, the Product Owner gets into the temptation of managing the team. But ideally, this role is not meant for managing or dictating the teams work. Once the tasks are assigned to the individual team members, the self organizing team decides itself on how to execute the same. Another problem with the Product Owner is the temptation to interfere the Sprint while it is in progress. The tasks for a particular Sprint are frozen, once it has started. The Product Owner wants to supersede the allocated tasks by including a new one in the mid of a Sprint. This is wrong.

Once the Sprint is finished, the Product Owner evaluates the shippable product based on the acceptance criteria. She/ he also participates in the Sprint review meeting to ensure that all the tasks are completed and the exit criteria for the Sprint is met.

In a nutshell, the Product Owner needs to keep a right balance between the business needs and prioritizing tasks based on the team's strength.

Defining Impediments in Scrum (Agile)

noreply@blogger.com (Priya Ranjan) — Mon, 08 Feb 2010 11:42:00 +0000

Impediments are the roadblocks or hindrances faced by the team in agile methodology of software development. To make the definition look more clear and practical, impediments are any causes which will delay team's deliverables or stop from progressing in a task and eventually costing the team's productivity.

Impediments are discussed everyday in the daily Scrum meetings. The onus lies on the individual team member to raise the barriers faced by him or her in the current task. ScrumMaster acknowledges the issue and works towards removing the barrier and make the member productive again. If the roadblock can be resolved upfront in the daily scrum meeting, fine. Otherwise, ScrumMaster may call for the follow-up meeting with the team members who are affected due to the impediments.

Depending on the nature of complexity of the impediment, ScrumMaster will resolve the issue herself/ himself or delegate it to any of the team members. It again depends on the availability of the team member for her/ him to address the problem. In case of more complex impediment, ScrumMaster may talk and negotiate with the Product Owner to open a new task and put it in the product backlog. If this impediment is a blocker for the task in hand, then both the current task and the impediment task go to the product backlog.

The best thing about the agile is that the entire team is cross-functional. So the impediment can be addressed by anybody in the team having knowledge about the problem and the possible solution. Nobody in the team can say that this is not my job!

Role of ScrumMaster in Scrum (Agile)

noreply@blogger.com (Priya Ranjan) — Mon, 08 Feb 2010 10:49:00 +0000

ScrumMaster acts as a facilitator for the team and is co-ordinator between the Product Owner and the team. He also co-ordinates with the management and the company's support functions to remove any roadblocks or impediments faced by the te team. Typical "command and control" style of management does not produce results for the ScrumMasters. In fact, there is no place for such a manager in agile.

Categorically, ScrumMaster has following three roles:

1. Help the team in achieving its goal: ScrumMaster ensures that the team delivers the quality product in quickest possible time and does not deviate from the agile principles. The onus lies on her/ him to conduct the sprint planning, retrospectives and daily Scrum meetings. She/ he also protect the team from any external disruptions during the sprint.

2. Remove impediments faced by the team: Impediments are discussed on daily basis in Scrum meetings. ScrumMaster needs to resolve these impediments. If she/ he cannot act to resolve it, she/ he must delegate the work to one of the team members or the any third party facilitator.

3. Resolve the conflicts: The ScrumMaster is responsible for removing conflicts in the course of the product development. The conflicts could be one of the following natures:

- Between individual team members

- Between developers and test engineers

- Between the team (developers and test engineers) and the product owner

Well, ScrumMaster has a big role in making the agile implementation successful. The team feels truly empowered only if the ScrumMaster acts to her/ his full potential.

Introduction to Agile Method of Software Development

noreply@blogger.com (Priya Ranjan) — Sun, 31 Jan 2010 18:15:00 +0000

Agile methodology enables product development incrementally and in a lightweight manner. The process adapts to the changing business scenarios and equips team to collaborate in every task. Agile can be interpreted differently by the different pool of practitioners. For team, it provides opportunity to be flexible, cross-functional and self-organized. For managers, it is a set of best engineering practices that allow rapid delivery of high quality software. For stakeholders, it is business approach that aligns development with customer needs and company goals.

Agile is implemented with flavours such as Scrum, Extreme Programming (XP) and Agile Unified Process (AUP).

Scrum—Flavor of Agile

Scrum is one of the most famous and mature flavors of Agile methodology. It is a simple set of rules and practices that encompass transparency, adaptability and empirical process control in software development.

Scrum Flow

Product roadmap starts with a short user story, which acts as requirement for the development team. The story is then converted into tasks. Tasks are prioritized and performed in short intervals, called Sprint, of 2-4 weeks. It is not expected that the entire product would be ready in one sprint but would be delivered incrementally sprint after sprint. Each Sprint starts with iteration planning meeting to figure out the product backlogs. The team is collectively responsible to release a potentially shippable product at the end of the sprint.

Every day, team members participate in the stand-up meeting to keep a tab on progress and to figure out whether there is any bottleneck faced by any of the members.

At the end of each Sprint 2-4 hours Sprint review meeting is done. The meeting is attended by the Product Owner or any other interested stakeholders to evaluate tasks and status of potentially shippable product.

Scrum Roles

Onus of implementing iterative and incremental skeleton of Scrum is distributed among three different role players: the Product Owner, the Scrum Master and the Team.

Product Owner brings up the end users’ perspective, prioritizes tasks to be performed in sprints and ensures the success of the product. Scrum Master monitors the rules and practices of Scrum and implements them to meet organizational goal. The self-organized and cross-functional team is responsible for developing functionality and make every iteration successful.

Scrum Artifacts

Product Owner maintains a Product Backlog. It is requirements in the form of tasks. The Product Backlog is not expected to be complete, rather it keeps on evolving. Product Owner prioritizes tasks from this list for each sprint and strikes out completed tasks.

Completion of tasks is tracked in Burndown Chart. The chart depicts tasks yet to be completed with remaining time in a sprint. Please refer to the chart below for more clarity. The curve should meet the time axis at the end of sprint.

Agile believes in just enough documents to suffice the product development. It is upto the comfort level of the team, product owner and customer to come up with more/ less artifacts.

Let’s Talk about Performance Engineering

noreply@blogger.com (Priya Ranjan) — Mon, 25 Jan 2010 17:09:00 +0000

As I say repeatedly, performance engineering is a complex process. Thousands of dollars spent in fixing poorly performing applications. The performance bottleneck and pitfalls of the software product can not be combated at one go, but incrementally.

Broadly and for the simplicity sake, performance engineering can be divided in following stages:

Performance Test Strategy

Here we define the scope, environment, methodology, metrics and reporting of the performance testing. The tool required to generate the load and analyze the application behaviour is also identified under this head.

Performance Bottleneck Identification

Software architecture affects the performance to a great extent. The performance bottlenecks must be identified while various components of software is designed. Performance specialists must come up with a plan which enables in identifying all such bottlenecks

Design and Coding the Test Scripts

Once tool is identified and a plan is in place to explore the possible bottlenecks, the scripts for performance testing must be designed and developed. The code will be written in the language supported by the tool. e.g. JMeter, a load testing tool supports Java. Many tools support record and playback. After a little tweaking in the recorded script, the tool can be used for end-to-end performance testing of the application.

Executing the Scripts

The performance testing script is executed through the tool and various parameters are noted componentwise. Parameters could be response time, throughput, number of concurrent users the application may support, query processing time, delay due to network etc.

Analyze and Report

Reporting and analysis of the execution result is a vital part of the performance engineering. The result may be presented in forms of graphs, charts, metrics, or tables. This equips stakeholders with the information about the gap between expected and actual performance trends in the application. The team involved in developing the application may address those areas which are choking the performance. The extent to which performance issues must be combated depends on time, budget and severity of the issue.

Closure

Closure involves delivery of all the artefacts of the performance engineering exercise. Artefacts include plan, test scripts, report, risks, risk mitigation plans etc.

We will dig further into how to address these stages of performance engineering at a minimal cost and most efficiently. Keep a tab…

Agile Performance Engineering

noreply@blogger.com (Priya Ranjan) — Mon, 25 Jan 2010 16:46:00 +0000

Performance engineering is complex process. Thousands of dollars spent in fixing poorly performing applications. The performance bottleneck and pitfalls of the software product can not be combated at one go, but incrementally.

With growing complications and need for time to market the software products, traditional models did not deliver the desired result to address performance issues of the product. Agile methodology emerged to address the rapidly changing business requirements and deliver shippable application incrementally. Flexibility and shortest possible time to take products to market are the main targets.

Applying Performance Engineering through Agile methodology is pragmatic for following reasons:

a.    Entire performance criteria is not known at the beginning of the development
b.    Performance criteria changes in the course of development
c.    Tracing and fixing performance issues at the earlier stage of the development helps prevent cascading the issue
d.    Agile can incorporate changes incrementally and in advance stage of the development
e.    Stakeholders are aware of any performance choke in the product not only after the completion of the development

Keep a tab on this. You’ll see how we can break performance engineering tasks suitable to Agile methodology of software development.

Five Frogs Sitting on a Log

noreply@blogger.com (Priya Ranjan) — Fri, 22 Jan 2010 05:29:00 +0000

One of my favourite questions when I evaluate testers for my organization goes like this:

There are five frogs sitting on a log. Four of them decide to jump off the log. How many would be remaining on the log.

Before we talk about the answer, let me put some thoughts on this question. As a tester, we come across multiple documents such as requirements, change requests, checklists, test plan, test cases, test reports etc. Few of these documents come to you for review and action; few others are generated by you. You must understand the documents well, weeding out all the ambiguities and assumptions. When you produce some document, it should be done with diligence and utter clarity, leaving no scope for any assumption.

Having said this, the question is custom made for testers. Isn't it?

Well, you must have got the answer by now.

No?

Ok. It is “Five”. Because they have decided, did not act yet. Right?

Agile Usability Testing

noreply@blogger.com (Priya Ranjan) — Thu, 21 Jan 2010 05:31:00 +0000

Usability is the ease with which a product can be used by people. For a software product: smooth navigation through User Interfaces (UI), ease of workflow and design of the product gives the best satisfaction to the target audience.

Usability testing is evaluating product from the users' perspective. The task is to identify the problems in the User Interface and workflow (of the product), which makes users' job difficult while working on the product. If a user faces difficulty while performing a task, it means the usability has some issues that need to be fixed. These issues occur because the developers and designers of the product have limited understanding of the end user's perspective. In product companies, there is a separate usability team that takes care of the ease of usage of the product for the desired end user.

The Challenge

If we follow the classical models of software development we may find it difficult to address usability issues, because we perform system testing -- including usability testing -- towards the end of the cycle. If the usability issues are identified at later stage, fixing them may require revamping the entire architecture of the product.

The Solution

The usability testing, inherently, should go throughout the life cycle of the product development. Usability tests can be formative, exploratory or early prototype. These provide best result when the tests are done incrementally, rather than after completion of the entire product.

Agile methodology is applied when a product development requirements change frequently and, the shippable product needs to go to the market regularly and rapidly. The UI of the product needs to evolve incrementally to provide the best user experience. Agile incorporates any requirements changes or fixing issues iterationwise – one after another.

Early usability tests are by and large qualitative. The attempt is to understand the branding impact of the product design, overall system design, content organization and high level navigational structure. At the later stage, the users’ behaviours are measured against established standards, more complex scenarios are tested and overall completion tasks are evaluated.

The Conclusion

The idea behind proposing this solution is to let you become sensitive towards the incremental efforts required for usability design, development and testing. Agile has the virtues to incorporate frequent changes in usability and test them.

How to Incorporate Manual Testing in Agile

noreply@blogger.com (Priya Ranjan) — Wed, 20 Jan 2010 18:05:00 +0000

Agile Methodology is applied when a product development requirements change frequently and, the shippable product needs to go to the market regularly and rapidly. Inherently, testing in Agile should be automated with the help of unit testing, regression test suit, performance test scripts and smoke tests with the continuous integration at check-in of the releasable code. It does not necessarily mean that a team with only manual testers won’t make the product development a big success. Let me share some thoughts on how manual testers can actually make the methodology a big success.

The Challenge

System testers will wait for the entire code being checked-in before they can execute manual test scripts. Considering Scrum (my favourite one!) as the method you are following in the project, the Sprint lasts for four weeks (say). The challenge is that three weeks developers work on the code and fourth week testers test it, letting the developers idle in the fourth week. This may not be acceptable to your management, as they dislike keeping resources idle, of course.

The Solution

In the iteration planning meeting, product owner shall prioritize tasks based on their mutual exclusion and collective completeness. Means, there must be some tasks which finish in the first week and it does not have any dependency on any other part of code coming in the later stage of the release. This part of the code can be checked-in and manual testers can start integration/ system testing on it from the second week itself. Iterate the same process for the entire sprint.

Additionally, developers must not have full week’s task in the 4^th week. They can utilize rest of the week in addressing the defects raised by the testers and reviewing the current Sprint’s tasks.

You may follow the sprint schedule as below:

Week 1: Iteration Planning (day 1) done by the entire team, coding done by the developers, test scripts are prepared by the testers.

Week 2: Developers switch over to 2^nd week’s tasks after delivering the first week’s code. Testers start manual testing on the 1^st week’s code.

Week 3: Developers switch over to 3^rd week’s tasks after delivering the 2^nd week’s code. Testers start manual testing on the 3^rd week’s code.

Week 4: Developers complete the 4^th week’s tasks and resolve all the issues raised by testers. Testers complete manual testing on the 3^rd and 4^th week’s code.

The Conclusion

Testing to improve the quality of the product is prudent. In Agile we can perform both – manual as well automation testing. Each of them has its own virtues. Automation helps in unit, regression, performance, mundane and repetitive testing. Whereas, testing of complex scenarios, usability and exploratory testing can be best done through manual process. Functional testing automation can only be successful if the UI (User Interface) of the product is stable. In case of unstable UI, ROI (Return on Investment) of functional automation is really high. There are chances that you would not get the value addition of functional automation in Agile because the requirement may change drastically.

Understanding the prudence of manual testing and its value, try the above method and let me know if your experience.

Testing an Elevator Made Easy

noreply@blogger.com (Priya Ranjan) — Tue, 19 Jan 2010 15:36:00 +0000

This is one of my favorite questions for the testing interviews. Those who give me most of the scenarios are most likely to get through. Well, after posting this in my blog I may change my question. But I felt very compelling to share this question with the community.

So, here is the question: Give me some scenarios that you will be testing for an elevator.

(I recommend you read this post till the end)

Most of the prospective team members come-up with following scenarios:

1. Door Open/ Close functionality of the elevator should work fine

2. The elevator takes you to the desired floor, based on the button you press for the respective floor

4. Elevator arrives with a suitable buzzer (eg. Third Floor)

5. Elevator door opens/ closes within the specified time

6. Elevator remains at the last destination till there is any trigger to call the elevator to any floor

7. If there is a stop button the elevator, it should stop the elevator at the nearest floor

8. The speed of the elevator is as per the specification

Most of the candidates are able to answer till this point. If I ask for more they may/ may not come up with following scenarios.

9. When power goes off the elevator should stop immediately, if there is no power back-up and one of the following should happen:

(i) There should be an emergency light in the elevator

(ii) There should be a buzzer to raise an alarm to the security

(iii) There can be a phone and should be functional

(iv) If there is no emergency light or phone, there will be darkness in the elevator. So the buzzer should glow in the dark

Huh… What next?

10. Verify the capacity of the elevator in terms of weight (for example 1000 Kg). One of the following should happen:

(i) The elevator should not go up/ down if the weight limit is surpassed

(ii) A buzzer should ring to raise the alarm that weight limit has crossed

That’s it! No, not yet. I look for even more.

11. You must have noticed that the manufacturer specifies the capacity of persons (for example 15 Persons). Why is that? Any guess?

Is it because of space issue? No.

Did manufacturer guess the average weight of the person and specified based on that the cumulative weight and person’s capacity? Well, no. Because the moment it crosses the weight limit, the elevator won’t move. So you need not do any mental calculation.

Ok. No more rewards for guessing.

There is limited air available for breathing and the ventilation is very limited. People boarded in the elevator will be breathing and it might choke the container if more number of people than specified is boarded. The situation may become even worse when the power goes off and those people are stuck in it.

That’s it! Please let me know if you come across more such scenarios.

How to Approach Test Estimation

noreply@blogger.com (Priya Ranjan) — Mon, 18 Jan 2010 09:07:00 +0000

Test estimation is not an easy task. Various schools of thoughts suggest varied strategies of estimation. A number of techniques are available for task estimation. Before we talk about any of the estimation technique, which is out of the scope of current post, we should talk about the activities that need to be kept in mind while estimating testing effort.

Majorly, the activities can be categorized under Test Planning, Requirement Analysis, Test Case writing and/ or scripting, Test Case/ Script execution, Training, Defect Reporting and Tracking, Regression and Retesting and, Reporting. Then we should incorporate following possibilities in the real life scenarios: possibility or parallelization of tasks, dependencies and roadblocks and, risks. Let us dig further into each of them.

Test Planning

This is start point of any testing project. Here, we include items to be tested, environment needs, resource availability and the timeframe. This is a task done by a team leader or the manager of the project. Depending on the complexity this task may take few hours to few days of effort.

Requirement Analysis

This task is performed by every member of the team. How long this will take, depends on the volume of the requirement document or the change request. It also depends on how much level of clarity the document has. In case of unclear or ambiguous document, there would be several discussions within the team to clarify each of the user scenarios.

Test Case/ Script Writing

This is a huge effort and depends on the amount of modules considered in the scope of the current iteration. In case of automation, tool selection and suitable coding efforts are required. For automation, you need specialized personnel for the job.

Test Case Execution

Execution of manual test cases or automated scripts is most critical activity of a tester. You always avoid the bug leakage at the production. For that the team needs ample time to execute the entire test cases/ scripts. Apart from this, a suitable bandwidth must be given to the team for exploratory testing.

Training and Environment Set-up

The team may need training on the testing tools and the product. The effort and time for this also needs to be estimated. In case of an ongoing project with the fixed team the training requirement can be ruled out, whereas, for a new team it is a major effort. Environment set-up takes good amount of time, depending on the technologies involved.

Defect Reporting

Finding defect and logging into the defect tracking tool is also an effort, which is mostly ignored while estimating. The defect report should be clearly explained with the steps to reproduce and the target environment.

Regression and Retesting

Once the defect is fixed, tester needs to retest the issue and regress the adjacent areas of the application. The amount of time needed varies from one defect to another. In some cases, testers need to run the entire smoke test after the defects are resolved.

Reporting

The whole exercise of testing is not successful till a nice report is presented to the management and the customer. Report is a snapshot of the whole exercise and it says the number of test cases run, defects logged and the current health of the product.

Having known all the items to consider for the test estimation, you need to be sensitive for the amount of work that can be done in parallel and others in sequential mode. Also, while one should identify the risk (ie. unforeseen circumstances arising during the iteration). Broadly, you should consider following while estimation:

Scope of Parallelization

Few of the tasks can be done in parallel and others can’t. For example, test planning and requirement analysis can be clubbed together. Similarly, test execution and defect reporting, by nature, goes hand-in-hand.

Dependencies and Roadblocks

In order to carry-on the testing smoothly, you should offset all the dependencies and roadblocks. The idea is to identify the in advance and take a proactive step so that testing does not affect.

Risks

There must be proper strategy for the risk identification and its mitigation. All the identified risks should go to the test plan document and their mitigation strategies must be discussed with the management and client.

Phew! Please let me know if you feel I should have included more in this.

Critical Bugs in a Web-based Banking Product

noreply@blogger.com (Priya Ranjan) — Sun, 17 Jan 2010 20:06:00 +0000

Banking products are highly secured. The money transaction, precise calculations, updation at the backend (i.e. database), clear instructions about the steps to be performed for a certain action, security, 24X7 availability of servers, performance and usability are highest priority when it comes to design and develop a banking product.

Transaction:

Transactions must be secured and must follow atomicity. The session must not be broken in the mid of a transaction. It must be capable to rollback if the transaction is not complete. The user must be updated clearly about the state of the transaction. for example, if the transaction is going-on the landing page should state the appropriate waiting message.

Calculation:

Banking is involved with huge amounts of money at stake. If the calculations are not precise and accurate to the multiple decimal points, the end users may get wrong money in their account.

Database:

Every entry at the UI level should reflect in the DB. If the updation doesn't happen or updation is wrong, it may cost high to the product.

Instructions:

These products are used by various nature of customers -- some well informed, whereas others are novice. The instructions written at various stages should keep in mind all the kinds of user of the product.

Security:

Security must be maintained at both levels -- server as well as browser (client). Security profile changes from browsers to browsers. The developer should remain sensitive towards each of them.

Compatibility:

As with any other web based products, banking products are also needs to be compatible with all the major browsers and other environments.

Usability:

Navigation should be user friendly, so that even a layman can use the application without any training.

Availability:

Availability is one of the most important criteria. Any downtime may result in high cost for the stakeholders of the product.

Performance:

Certain transaction may be used by huge number of users at the same point in time. Or few transaction may take huge amount of time that may result in session expiration or loss of connection from the server. Performence aspect must keep both of these in mind.

These are only few of the indicators, which will help you in acing interviews.

Bug Reporting: Why Do Developers Reject a Bug

noreply@blogger.com (Priya Ranjan) — Sun, 17 Jan 2010 05:20:00 +0000

Testers often come across this frustration of bugs not getting accepted by the development team. It takes huge effort and rounds of negotiation before both of them come to a same page. What causes this debate? How can we minimize it? How can this overhead be avoided? Let us explore.

Developers would not accept a bug because of following reasons:

1. It is not a bug!

Here, either tester or the environment is at fault. Tester, because he might have missed certain gray areas of the requirement and analysed the functionality wrongly. Environment, because some configuration or plug-in required to run the application might be missing.

2. Ambiguous requirement!

Here, both tester and developer have their own understanding about the expected functional behaviour of the product. The requirement document is does not neatly outlines or able to explain the issue in contention.

3. Deadline is close!

When project deadline is close, everybody is in hurry to release the product. If developer has huge pile of issues to be fixed, they may reject less critical bugs and would address only the critical ones. Yet, it is management call as to what to be omitted and what not.

4. The product is ok with this bug!

Developers may come with a fancy argument that customers never complain about such issues and we should also not pay attention to such issues. For example, any cosmetic bug to improve the look and feel of the product.

5. Previous versions are running with the same issue!

This is ironical but unfortunately very prevalent argument we hear that customer has never complained about this issue and the product is already running fine.

6. Follow the process!

Developers are biased towards their modules. So they follow the right steps to reach to the result. However, testers try to crack the application with their negative testing as well. Developers, in this scenario, often complain that testers did not follow the process, which the customer is already trained on. So it is not developer's job to fix the bug if the desired steps are not followed.

So, after listening to one of these arguments what approach should a tester take. Should they rework on their own testing strategy, develop negotiation skills, get more idea about the product or talk to the management. Actually, a tester can do all of them or mix of multiple strategies. How? Here we go:

1. Testing strategy: If there is a bug which is not being accepted by developer, a tester should relook the environment, test documents, procedure and business requirements. There might be something lacking in one of these components. So, they better rework now rather than getting pointed out in future about own fault and experience embarrassment.

2. Negotiate: If there is issue with the slippage of deadline due to too many issues, testers may need to negotiate with leads and managers to defer the deadline in order to release quality software. Better late than never! A product with bugs will impact business more than delaying the release.

3. Analyse the requirement documents: If there are ambiguities with the requirement document, tester should point them out to the concerned stake holders and get them resolved.

4. Keep logging bugs: Many a times, testers get carried away after seeing a bug and tend to discuss with development team rather than logging the bug in the bug tracker tool. This is deviation from the process. If tester is convinced about the bug, she/ he should log it. In the worst case we have a flag called “Rejected” in the bug tracker tool, right?

5. Gain more knowledge about the product: As discussed above, there are occasions when testers have limited knowledge about the product. As a result they may not find the right bug or they may unnecessarily raise wrong bugs. To avoid this threat they should gain more knowledge about the product. I believe, testers should know about the functional aspect of product more than a developer of the product.

To sum up, testing is a collaborative approach and testers should take the charge to collaborate with all the stakeholders, including developers. However, every stakeholders need to remain cautious because bug leakage at the production costs really high. A stitch in time saves nine!