Questions

Can you describe an ideal employee?

What are the skills and attributes you value most for someone being hired for this position?

What would you consider to be the most important aspects of this job?

Posted in Uncategorized | Leave a comment

世界上最远的距离 – Khoảng cách xa nhất trên thế giới này – 黄丽冰 – Hoàng Lệ Băng

http://nhactq.blogspot.com/2012/11/khoang-cach-xa-nhat-tren-gioi-nay-hoang.html

世界上最远的距离 – 黄丽冰
The furthest distance way in the world – Huang Li Binh
Khoảng cách xa nhất trên thế giới này – Hoàng Lệ Băng

世界上最远的距离
The furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是生与死的距离
is not the way from birth to the end.
Không phải giữa sự sống và cái chết

而是我站在你面前
It is when I stand in front of you
Mà là khi anh đứng trước mặt em

你不知道我爱你
but you don’t understand I love you.
Nhưng em không biết rằng: anh yêu em

世界上最远的距离
The furthest distanceway in the world
Khoảng cách xa nhất trên thế gian này

不是我站在你面前
is not when I stand in front of you
không phải khi anh đứng trước mặt em

你不知道我爱你
you don’t know I love you
Em không biết rằng: anh yêu em

而是爱到了痴迷
It is when my love is bewildering the soul
Mà là cả hai đều yêu đến quá si mê

却不能说我爱你
but I can’t speak it out
Nhưng lại không thể nói ra

世界上最远的距离
Thefurthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是我不能说我爱你
is not that I can’t say I love you.
Không phải anh không thể nói ra: anh yêu em

而是想你痛彻心脾
It is after missing you deeply into my heart
Mà là nhớ em đến đứt ruột lìa gan

却只能深埋心底
I only can bury it in my heart
Nhưng chỉ có thể chôn sâu trong đáy lòng

世界上最远的距离
The furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是我不能说我想你
is not that I can’t say to you I miss you
Không phải anh không thể nói: anh nhớ em

而是彼此相爱
It is when we are falling in love
Mà là hai ta yêu nhau

却不能够在一起
but we can’t stay nearby
Nhưng lại không cách nào đến với nhau

世界上最远的距离
The furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是彼此相爱
is not we love each other
Không phải khi hai ta yêu nhau

却不能够在一起
but can’t stay together
Không thể đến được với nhau

而是明知道真爱无敌
It is we know our true love is breaking through the way
Mà là biết rõ rằng tình yêu là vô dịch không gì sánh bằng

却装作毫不在意
we turn a blind eye to it
Nhưng lại vờ đi như không có chuyện gì….

世界上最远的距离
So the furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是树与树的距离
is not in two distant trees
Không phải là khoảng cách giữa cây và cây

而是同生长的树枝
It is the same rooted branches
Mà là cành cây lớn lên trong cùng một gốc cây

却无法在风中相依
but can’t depend on each other in the wind
Nhưng lại không cách nào dựa vào nhau trong gió

世界上最远的距离
The furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是树枝无法相依
is not can’t depend on each other in the wind
Không phải cành cây không cách nào dựa vào nhau

而是相互了望的星星
It is in the blinking stars who only can look with each other
Mà đó là những ngôi sao sáng đang trông ngóng về nhau

却没有交汇的轨迹
but their trade intersect
Nhưng lại không có giao điểm trên quỹ đạo

世界上最远的距离
The furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是星星之间的轨迹
is not in the blinking stars who only can look with each other
Không phải là đường dẫn giữa các ngôi sao

而是纵然轨迹交汇
It is after the intersection
Mà ngay cả khi quỹ đạo có các giao lộ

却在转瞬间无处寻觅
but they can’t be found from then on afar
Nhưng cũng không thể tìm thấy trong thoáng chốc

世界上最远的距离
The furthest distance way in the world
Khoảng cách xa nhất trên thế gian này

不是瞬间便无处寻觅
is not the light that is fading away.
Không phải là trong thoáng chốc không thể tìm thấy

而是尚未相遇
It is the coincidence of us
Mà là chưa gặp gỡ

便注定无法相聚
is not supposed for the love
Đã định sẵn chẳng thể đến được với nhau

世界上最远的距离
The furthest distanceway in the world
Khoảng cách xa nhất trên thế gian này

是鱼与飞鸟的距离
is the love between the bird and fish
Là khoảng cách giữa cá và chim bay

一个在天
One is flying in the sky,
Một ở trên trời,

一个却深潜海底
the other is looking upon into the sea.
Một còn lại, lặn sâu dưới đáy biển

世界上最远的距离
The furthest distanceway in the world
Khoảng cách xa nhất trên thế gian này

是鱼与飞鸟的距离
is the love between the bird and fish
Là khoảng cách giữa cá và chim bay

一个在天
One is flying in the sky,
Một ở trên trời,

一个却深潜海底
the other is looking upon into the sea.
Một còn lại, lặn sâu dưới đáy biển

一个却深潜海底
the other is looking upon into the sea.
Một còn lại, lặn sâu dưới đáy biển….

Lời dịch: Twei ♡…..

作曲:李大东 / Tác khúc: Lý Đại Đông
作词:泰戈尔 / Tác từ: Rabindranath Tagore

Posted in Uncategorized | Leave a comment

Performance Testing, Load Testing, Stress Testing

http://agiletesting.blogspot.com/2005/02/performance-vs-load-vs-stress-testing.html

http://www.softwaretestingstuff.com/2011/09/performance-testing-vs-load-testing-vs.html

Performance testing – It is performed to evaluate the performance of components of a particular system in a specific situation. It very wide term. It includes: Load Testing, Stress Testing, capacity testing, volume testing, endurance testing, spike testing, scalability testing and reliability testing etc. This type of testing generally does not give pass or fail. It is basically done to set the benchmark & standard of the application against Concurrency / Throughput, Server response time, Latency, Render response time etc. In other words, you can say it is technical & formal evaluation for responsiveness, speed, scalability and stability characteristics.

Performance Testing vs Load Testing vs Stress Testing - ExamplesLoad Testing is subset of performance testing. It is done by constantly increasing the load on the application under test till the time it reaches the threshold limit. The main goal of load testing is to identify the upper limit of the system in terms of database, hardware and network etc. The common goal of doing the load testing is to set the SLAs for the application. Example of load testing can be:

Running multiple applications on a computer simultaneously – starting with one application, then start second application, then third and so on….Now see the performance of your computer.

Endurance test is also a part of load testing which used to calculate metrics like Mean Time Between Failure and Mean Time to Failure.
Load Testing helps to determine:

  • Throughput
  • Peak Production Load
  • Adequacy of H/W environment
  • Load balancing requirements
  • How many users application can handle with optimal performance results
  • How many users hardware can handle with optimal performance results

Stress testing – It is done to evaluate the application’s behaviour beyond normal or peak load conditions. It is basically testing the functionality of the application under high loads. Normally these are related to synchronization issues, memory leaks or race conditions etc. Some testing experts also call it as fatigue testing. Sometimes, it becomes difficult to set up a controlled environment before running the test. Example of Stress testing is:

A banking application can take a maximum user load of 20000 concurrent users. Increase the load to 21000 and do some transaction like deposit or withdraw. As soon as you did the transaction, banking application server database will sync with ATM database server. Now check with the user load of 21000 does this sync happened successfully. Now repeat the same test with 22000 thousand concurrent users and so on.

Spike test is also a part of stress testing which is performed when application is loaded with heavy loads repeatedly and increase beyond production operations for short duration.
Stress Testing helps to determine:

  • Errors in slowness & at peak user loads
  • Any security loop holes with over loads
  • How the hardware reacts with over loads
  • Data corruption issues at over loads
Posted in Uncategorized | Leave a comment

A Field Guide To Mobile App Testing

http://mobile.smashingmagazine.com/2012/10/22/a-guide-to-mobile-app-testing/

Posted in Uncategorized | Leave a comment

Defect priority

Source: http://softwaretestingfundamentals.com/defect-priority/

Defect/Bug Priority Definition, Classification:

Defect Priority (Bug Priority) indicates the importance or urgency of fixing a defect. Though priority may be initially set by the Software Tester, it is usually finalized by the Project/Product Manager.

Priority can be categorized into the following levels:

  • Urgent: Must be fixed in the next build.
  • High: Must be fixed in any of the upcoming builds but should be included in the release.
  • Medium: May be fixed after the release / in the next release.
  • Low: May or may not be fixed at all.

Priority is also denoted as P1 for Urgent, P2 for High and so on.

NOTE: Priority is quite a subjective decision; do not take the categorizations above as authoritative. However, at a high level, priority is determined by considering the following:

  • Business need for fixing the defect
  • Severity/Impact
  • Probability/Visibility
  • Available Resources (Developers to fix and Testers to verify the fixes)
  • Available Time (Time for fixing, verifying the fixes and performing regression tests after the verification of the fixes)

ISTQB Definition:

  • priority: The level of (business) importance assigned to an item, e.g. defect.

Defect Priority needs to be managed carefully in order to avoid product instability, especially when there is a large of number of defects.

 
Posted in Uncategorized | Leave a comment

Defect Severity

Source: http://softwaretestingfundamentals.com/defect-severity/

Defect Severity or Impact is a classification of software defect (bug) to indicate the degree of negative impact on the quality of software.

ISTQB Definition
  • severity: The degree of impact that a defect has on the development or operation of a component or system.

DEFECT SEVERITY CLASSIFICATION

The actual terminologies, and their meaning, can vary depending on people, projects, organizations, or defect tracking tools, but the following is a normally accepted classification.

  • Critical: The defect affects critical functionality or critical data. It does not have a workaround. Example: Unsuccessful installation, complete failure of a feature.
  • Major: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
  • Minor: The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module.
  • Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.

Severity is also denoted as:

  • S1 = Critical
  • S2 = Major
  • S3 = Minor
  • S4 = Trivial
CAUTION:

Defect Severity is one of the most common causes of feuds between Testers and Developers. A typical situation is where a Tester classifies the Severity of Defect as Critical or Major but the Developer refuses to accept that: He/she believes that the defect is of Minor or Trivial severity.

Though we have provided you some guidelines in this article on how to interpret each level of severity, this is still a very subjective matter and chances are high that one will not agree with the definition of the other. You can however lessen the chances of differing opinions in your project by discussing (and documenting, if necessary) what each level of severity means and by agreeing to at least some standards (substantiating with examples, if necessary.)

Posted in Uncategorized | Leave a comment

Scenarios

A scenario is a description of a person’s interaction with a system.
Scenarios help focus design efforts on the user’s requirements, which are distinct from technical or business requirements.
Scenarios may be related to ‘use cases’, which describe interactions at a technical level. Unlike use cases, however, scenarios can be understood by people who do not have any technical background. They are therefore suitable for use during participatory design activities.

When are scenarios appropriate?

Scenarios are appropriate whenever you need to describe a system interaction from the user’s perspective.
They are particularly useful when you need to remove focus from the technology in order to open up design possibilities, or when you need to ensure that technical or budgetary constraints do not override usability constraints without due consideration.

Scenarios can help confine complexity to the technology layer (where it belongs), and prevent it from becoming manifest within the user interface.

How do you write scenarios?

To write a scenario, you need a basic understanding of the tasks to be supported by the system. You also need to have an understanding of the users and the context of use.
Scenarios can be derived from data gathered during contextual enquiry activities. If you do not have access to such data, you can write scenarios based on prior knowledge or even ‘best guess’, provided the scenarios will be subject to review by users prior to being used as a basis for making design decisions.
To write a scenario, describe in simple language the interaction that needs to take place. It is important to avoid references to technology, except where the technology represents a design constraint that must be acknowledged.
Include references to all relevant aspects of the interaction, even where they are outside the current scope of the technology. Such references may include cultural and attitudinal issues. For example, the fact that Jane is continually interrupted by telephone calls may be just as relevant as the software platform she uses.
After you have written a scenario, review it and remove any unwarranted references to systems or technologies. For example, the statement ‘the customer identifies herself’ is appropriate, whereas ‘the customer types her 4-digit PIN’ is not (unless the PIN is a non-negotiable system constraint). You should also have the scenario reviewed by users to ensure that it is representative of the real world.

How do you use scenarios?

Use scenarios during design to ensure that all participants understand and agree to the design parameters, and to specify exactly what interactions the system must support.
Translate scenarios into tasks for conducting walk-through activities and usability tests.

Example

The following is a sample scenario describing a customer withdrawing money from an automated teller machine (ATM).

It’s Friday afternoon and Joe is flying to Sydney. He doesn’t have enough money for a taxi to the airport, and he’s running late.
He goes to the local ATM and identifies himself.
He specifies that he wants $100 from his savings account. He’d like the money in $20 notes so that he can give the taxi driver the correct change.
He doesn’t want a printed receipt, as he doesn’t bother keeping track of transactions in this account.

Note that this description specifically avoids references to transaction cards and PINs. This leaves open the possibility of considering a variety of identification and authorization regimes.
Be prepared to review scenarios based on feedback from users. In particular, be prepared to modify or even abandon any unrealistic or unrepresentative scenarios.

Posted in Uncategorized | Leave a comment