Trans: về quá trình mà tụi mình ứng dụng ATM vào development proccess của Empower ------- tiếp

theo
mình sẽ nói cụ thể về những mindset của AT mà tụi mình đã tìm hiểu và áp dụng.

a. Testing throughout (continuous testing) OVER testing at the end

 Issue:
 In current process, testing is a phase and often start at the end of the sprint
 We all know that the cost of fixing defects increases as we progress through the delivery
pipeline. There will be a lot of time wasted investigating the issue(s) and trying to
work out the root cause of a failure.
 In agile testing mindset, it encourages everyone to consider testing is not a phase, it’s an
activity. Testing activity should start from the very beginning
 we should ensure that we build the right product and build it right from the beginning.

Trans: Khi apply dc mind set này thì sẽ giảm dc rủi ro do quá nhiều issue vào cuối
sprint. Vậy làm cách nào để test từ lúc define + coding? Hay nói cách khác những
testing activities nào có thể thực hiện dc khi feature cần test chưa tồn tại?

b. Preventing Defects OVER Finding Defects

 Question: What is the purpose of testing?
 Traditionally people think that the goal of testing is to find bugs. In fact, some
organisations even measure tester productivity based on the number of bugs they
find (or don’t find).
 Example -> "How many points are there on this star?” --> Often people make
assumptions about requirements and implement those assumptions before clarifying
them. The assumptions are only clarified once the software is tested, and the bug is
then found.
 Agile testing aims to prevent bugs by seeking to eliminate all assumptions and
unknowns before starting to code. The goal is to make sure everyone from the
customer to the developer and the tester have exactly the same understanding of
how something should work.
 The best way to prevent bugs is to ask questions, especially stupid questions. Ask
questions that everyone thinks the answer to is obvious.

c. Building the Best Software over Breaking the Software

 Traditionally, QCs like to break stuff -> The problem with this mindset is that it creates a
divide between the developers and QCs => Developers build it, then QCs try to break
it.
 The agile mindset is that QCs should be helping to build the best system possible.
 The best way to do this is to figure out how to test the system from a user point of view
and then share that with developers before they start coding. Chances are high if
you do this, devs might actually build a system to make those tests pass.
Không viết kịp test cases trước khi code
d. Exploratory Testing over Scripted Testing
 Note:
 It not means that ET to be replace ST --> actually, this works great in
combination with traditional test cases and regression testing, as well as with
automated testing
  Consciously or unconsciously each and every tester would have done
exploratory testing at some point in their career.
 Why adopt exploratory testing?
 Scripted-testing:
a. Tester develop detailed test scenarios then = transform into test cases.
b. Scripted tests provide rigid guidance based on intimate knowledge of the
software application under test and are expected to produce a well-
defined set of outcomes.
 Huge products & domain + multiple scrum teams -> leaving testing teams in the
difficult position to quickly get used to the new functions & features
 Agile development -> deal with ever and fast changing requirements -> Teams
often don’t have the luxury anymore to carefully plan test strategies and tests
for all new features in advance.
 Effort to maintain test cases is huge
 What is exploratory testing?
 Khác với cách approach theo scripted testing, Đây là cách approach mà chúng ta
bắt đầu test + explore feature ko dựa trên 1 bộ test cases có sẵn, mà là đồng
thời trong lúc test + explore -> học dc domain + phân tích dc feature đó và các
feature liên quan + viết test script
 Có 1 điều cần lưu ý là mindset này ko có nghĩa là dùng Exploratory testing để
thay thế scripted testing mà thực tế là khi test theo test case kết hợp với
exploratory testing thì sẽ tăng dc test coverage.
e. Communication & collaboration OVER process & tools
f. Team Responsibility for Quality over Tester’s Responsibility
2 Mindset này khuyến khích sự giao tiếp và hợp tác giữa hơn là làm theo quy trình 1
cách cứng nhắc và quá dựa vào các tools
Vd 1: Proccess: khi muốn confirm lại requirement thì sẽ làm = cách comment vào
ticket trên jira/confluence, chờ BA/ Clients/dev/qc vào xem rồi put comments -> tốn
thời gian chờ đợi
Thì thay vì quá cứng nhắc như vậy, có thể cùng phân tích và thảo luận trực tiếp với
nhau -> tìm ra giải pháp sau đó input vào ticket trên jira cho mục đích tracking
VD2: issue production -> ko nên có mindset tìm ra ai làm ra con bug đó - tại QC test
thiếu hay dev code thiếu? mà cả team nên cùng nhau tìm ra cách giải quyết vấn đề
hơn là tìm ra ai chịu trách nhiệm cho vấn đề đó