Sunday, December 18, 2011

Test Case Prioritization

I heard many testers, including me, complaining most of the time: “So many Tests and They expect us to do in so less time. That’s Unfair!!!!”. This is the most common problem, faced in our software industry, that management expects 100 percent testing in less time.

You must have heard a phrase “TimeBox the testing”. This is a time management technique in which you can complete the most important tests in a given time and deliver a high quality product. Always prioritize your tests to achieve time-boxing in testing.

One major task before prioritizing your tests is to work out plans addressing these two concepts:


  • ·        Identify necessary features that are a MUST.
  • ·        Identify the risks associated with the features which will not be tested.

Whenever you make a test case, you must have noticed a “priority” column. This is the easiest way to assign priority. Mostly companies follow three-level priority categorization scheme:

Low: Allocated to the tests, which if not executed, will not cause big upsets.
High: Allocated to all tests that MUST be executed in any case.
Medium: Allocated to the tests which can be executed, only when time permits.

However, this categorization scheme is not mandatory; you can customize it according to your company’s requirement. While setting priority, always keep in mind that you have to set the priority according to criteria which suits your company’s needs. I was going through a research in which analysis was done for prioritized and non-prioritized case with the help of Average percentage fault detection metric. In that research, it was proved that the number of bugs found per minute are greater in case of non-prioritized test cases as compared to prioritized test cases.  

Before prioritizing test cases, always consider these things:
·        Criteria which suits your company’s needs.
·        Where a failure would be most severe Test
·        Where a failure would be most visible
·        Always ask customer what is most important to him.
·        Areas which are more complex and where changes are more frequent.
·        Areas which have created most problems in the past. 

Sunday, May 23, 2010

Responsibilities of a Technical Writing Analyst


Most of you might have heard people speculating “What this technical writing is???”
Do you think it is a rocket science??? Well, not really….

Technical writing, a form of technical communication, is simply about putting technical information into easily understandable language. It can help reader solve a particular problem that can be related to computer hardware and software, chemistry, the aerospace industry, robotics, finance, consumer electronics and biotechnology.

It should be kept in mind that 'Technical Writing' is different from creative and other types of writing in many ways. Technical writing can include presentation materials, training materials, procedures, scientific papers, user manuals, help files, SRS (Software Requirements Specifications), maintenance manuals etc. Being a technical writer, you can serve as a part of a team conducting usability studies to help improve the design of a product that still is in the prototype stage. You have to edit technical materials and oversee the preparation of illustrations, photographs, diagrams and charts. You must work not only with engineers or programmers but often must deal with quality assurance and marketing personnel.

Basically the term 'technical' refers to knowledge that is not widespread, that is more the territory of experts and specialists so it is not writing about a specific technical topic but about any technical topic of any domain.

The first rule of technical writing is "Know your audience." A Technical writer is challenged to write about highly technical subjects but in a way that a layman or a non-specialist could understand so you should write in a manner that is adapted to the reader‟s needs, level of understanding and background. Remember you are a go-between one group of people with specialized knowledge and another group with no knowledge. Let's put it in this way that “You should plan to write in such a way that even Grand dad can understand”

Technical writing isn't like other IT professions. You don't need to pass an exam or become certified. There's no terrible out-of-pocket expense in this field. Most of what you need to know you have already or you can get on your own!

You must posses the following individuality if you want to make it your career:
  • You need a degree -- or at least a great deal of experience in the field (or fields) about which you're writing.
  • Obviously, you need to be able to write well. At a minimum, this involves having a good vocabulary and a strong command of grammar, spelling and punctuation.
  • You need good people skills. Most of the time you have to deal with your supervisors, programmers and engineers and these people often don't have time to answer your questions but you must have the skills to organize time for communication and clarifying all your questions from them.
  • Once you are done with collecting information, you must know how to organize the collective information. Arrange the information into a suitable order.
  • You need excellent Internet and surfing skills.
  • Fast and accurate typing speed can be a PLUS; as you often will be working on a deadline
Besides this, a few technical skills can also add value:
  • Word processor (usually Microsoft Word) and other software associated with publishing, such as Frame Maker or Adobe Publisher.
  • Develop and write online help and online documentation using a software application, such as RoboHelp.
  • Have some understanding of graphics, including the ability to work with pictures (resizing, changing color balance, etc.) and other design elements.
  • Work onsite or with external printing houses to handle document production, CD duplication, packaging, etc.
If you see Technical writer as you career, you can move up into management of other writers. You could grow into a senior technical writer position, handling complex projects or a small team of writers and editors. The next step up could be a documentation manager handling multiple projects and teams. You can also gain expertise in a specific technical domain and branch out into related forms, like software quality or business analysis. This field is in demand nowadays in a large amount of the technology companies as they are constantly struggling to find effective ways to help potential customers understand the advantages or the operation of their new products.

If you are a technical writer, don't forget that you are performing an extremely useful task in current market. In today's IT industry, a Technical writer is somewhat like a power transformer stepping down high power electrical current to less intense voltages. Thus, as a technical writer, you are helping people to utilize more fully the powerful computing technologies now available.

Things to be taken care off while writing:

  • Concentrate on having well structured documents while writing. The structure of an article plays a very important role in conveying your message accurately. It helps the readers in clearly understanding your points and building their interest in your document.
  • Take great care with the spellings and the grammar. Develop an interest for the reader, don‟t make them get bored.
  • Write clearly using simple words which your audience understands.
  • Avoid too long sentences and unnecessary repetition.
  • Never use passive voice where you can use active voice.
  • Speak directly to the user.
  • Maintain focus and only give information related to the task in hand.
It's all about learning; If you want to succeed in this field, you need an appetite for learning; a real hunger to know and understand how things work!

Impact of Requirement bill on requirement process

There is a famous saying “Great minds think alike”. When many great minds are gathered to create new software, two rarely thought exactly alike where as only a collaborative relationship between software team and customer can lead to success. It is very often that problems arise because of unclear understanding of what requirements are and who the customers are. Usually customer expects the software team to figure out what they need without a lot of discussion and necessary documentation. Similarly, the development team believes that they know better and they can do better without customer’s involvement.

So, a Requirements bill serves the best purpose to clarify key misconceptions and to create a healthy and strong relationship between customer software during requirement engineering process. Here our focus of discussion is Requirements Bill of rights and responsibilities for Software Customers. Bill of rights is the expectations of customer while interacting with software team and bill of responsibilities includes the responsibilities the customer has to the software team. This bill can play a vital role in helping customer to understand the requirement gathering process and what the requirement analyst needs from him.

Before starting the project, customer and software team must review the requirement bill of rights and responsibilities. Companies should not hide the requirement bill; each and every thing must be clear before project kick-off. This understanding can reduce friction later, when one party expects something the other isn’t willing or able to provide.

Requirement bill has a lot of positive impacts on customers as well as software team during requirements gathering process. A few of them are listed below:

  • Software team can design or develop the software according to the customer’s needs and desires.
  • Both software team and customer understand the reality that it is impossible to know the entire requirement early and no doubt they can be change. And so they will have the ‘change factor’ in mind and will consider the sign-off just the concept of establishing baseline of the requirement agreement. This factor lessens expensive rework and schedule slippage.
  • Customers don’t get frustrated with the requirement engineering process if they are well aware of the requirement bill. They come to know that it is an excellent investment and less painful if they understand and respect the techniques and working style of the software team.
  • By presenting ideas and alternatives, analyst can suggest improvements in the existing software that the new software could provide that the users haven’t even envisioned.
  • Analyst can modify customer’s requirements to allow the developers to reuse existing software as they might know of software components that can address some need described by customer. Adjusting customer’s requirements when sensible reuse opportunities are available can save time that would otherwise be needed to build precisely what the original requirements specified.
  • Customer and software team can make timely decisions because software team/analyst can provide customer to make many choices and decisions to resolve many issues and customers who are authorized to make such decisions must do so promptly when asked.
  • Specific characteristic are explored by the analyst who make the software easier and pleasant to let the customers accomplish the tasks accurately and efficiently.
  • The customers respect analyst’s ideas as they know that only he/she can provide different feasible options against the requirements asked by them.
  • Desired project outcome is achieved because of clear communication.
  • Greatest value is delivered at the lowest cost.
Many times software is compromised by a lack of understanding or focus on the core functionality. It is a gigantic work to keep the software away from incompetence or inefficiency but it can be possible if the requirement bill of rights and responsibilities are shared between both the software team and customers before the start of every project.

Requirements from the Customer’s Perspective

If you are working in a software company, have you ever thought “What a customer expects from you?”

The most concise and precise answer could be quality product, reasonable price, speed, efficiency, accuracy, integrity, reliability, courtesy, commitment, helpful attitude and a personal interest in his/her patronage. In short, customers expect more and more.

Customer’s expectation is a major challenge as they can grow, shrink, change shape or direction any time. It is quite possible that what you perceive is entirely different than what your customers have perceived it which is not unusual. It is just the difference of thinking between two humans. Keep in mind that if customers view you as unresponsive, then you are unresponsive in THEIR eyes…..the reverse can also be true!

Mostly customers don’t know what exactly they want, and if they get it, they will change their minds. I saw many IT managers complaining about indecisive and demanding customers. The reason behind, mostly people convey the things in terms of what they know and what they like. There is an old saying “I’ll know it when I see it” is literally true in terms of customer’s unrealistic expectations….Therefore, always clarify what they want and what they expect.

I heard complaining one of my friends (who recently opened his software company) that his customer wants him to do what initially was out of scope from the project. Moreover the customer wants it to be done without extra payment. Think what could be the reason behind? Just because he didn’t formally approve any document from the customers against the requirements. So, always develop a common understanding between you and your customers.

Why today’s customers have become incredibly demanding? Because, now customers have more choices than ever in today’s competitive software industries; if a software company can’t meet their expectations, they will go anywhere else. To gain customer’s interest, confidence and trust, you must learn the power of managing customer unrealistic expectations.

Requirement analyst plays the main role at this stage. Being a requirement analyst, don’t overpromise, make things realistic and achievable. Consider yourselves business people/service providers rather than software engineer or requirement analyst. Align yourself with your customers’ needs and explain your services in their terms, not yours. Keep commitments and overestimate how long it will take to deliver like tell them that the software would be ready on Friday, knowing that it would be ready on Wednesday. Nothing can be managed without communication. Continually, let the customers know about the progress but don’t overcrowd. Make frequent short deliverables and involve customer at each delivery. If you don’t do this you, it can lead to the traditional IT complaint, “We gave them just what they asked for, but it wasn’t what they wanted.”

Don’t wait for your customers to contact you, it is your responsibility to keep them up to date, customers hate it when they don’t know what’s going on!!! Review your work or get external person to review your work. Remember, Fresh eyes can see what you can’t.

Master these tactics and keep the customers rolling in!!!