Showing posts with label Knowledge. Show all posts
Showing posts with label Knowledge. Show all posts

Wednesday, March 13, 2013

BACB = 2 – Legacy Application

In information technology, legacy applications and data are those that have been inherited from languages, platforms, and techniques earlier than current technology.
Most enterprises that use computers have legacy applications and databases that serve critical business needs.
Typically, the challenge is to keep the legacy application running while converting it to newer, more efficient code that makes use of new technology and programmer skills.
In the past, much programming has been written for specific manufacturers' operating systems. Currently, many companies are migrating their legacy applications to new programming languages and operating systems that follow open or standard programming interfaces.
Theoretically, this will make it easier in the future to update applications without having to rewrite them entirely.




Courtesy: some site when I searched on this term.

Tuesday, March 27, 2012

Being Practical = Being Human ?

  1. I always wanted a Quality Analyst to be well-educated in scientific research.
  2. They should have a great interest in Math and other related calculations.
  3. They need to max-up with lateral thinking and have an agile mindset.
  4. When they are busted off, the sound need to thunder other’s ears.
  5. They should substantiate their individual characters before all expects to knowledge that out.

Monday, December 26, 2011

CAR in IT!!!

Question: What is CAR?
Answer: Chuck Away the Requirements.

- Understanding of the proposed requirements.
- Pointing out the gaps and raising queries.
- Quick assessment & certification of a feature.
- Determining if an idea is achievable or not.
- Test coverage for that feature.


Wednesday, May 4, 2011

Wanna be a Good Tester?

1) Programmers should not test their own code.
2) Go beyond requirement testing.
3) When Regression testing started, use the previous bug graph/Defect tracking tool.
4) Analyze code changes are done properly for testing purpose. If not don't accept the build.
5) Keep developers away from test environment but never hurt them.
6) Testers need to be right from software requirement and design phase.
7) Share your best testing practices/experience with your testing friends.
8) Think of positives and negatives while going into an application.[Technically and Non-technically]
9) Before testing, Learn to analyze the whats your plan.
10) Test cases needs to be available to developers prior to coding, so that they can't blame you.
11) Write clear, descriptive, unambiguous bug report.
12) Increase your conversation with developers so that you might get a new direction to test the application/modules.
13) Understand how programmers think and do the other way.
14) Ask them questions to client/developers/QA managers. It might be silly but don't hesitate. Some questions can be a turning point of your project/product.
15) Avoid keep all your communication in the mode of verbal.
16) Think like an end user. Listen to end user more and developers less.
17) Learn to say NO when quality is insufficient. Deliver with quality.
18) Increase the learning curve in automated test tool programming.
19) Know your application and domain.
20) Don't be diplomatic.