Q & A with James Bach
I had the pleasure of speaking with James Bach when he visited Vietnam last summer. He is a father and a teacher who enlightens people about metacognition in software testing. His knowledge covers many areas of software testing, from context-driven testing, heuristics and tester careers, to the secret life of testers. If you have an opportunity to learn from him, you will absolutely agree with me on how talented he is.
- How do you ensure the quality of a Co-located Agile Project?
James: You are going to need a lot of planned communication, because communication will not happen naturally when people are far away. I suggest daily conference calls. Distributed projects take strong leadership to get people to come together. I also suggest that key people should periodically visit each other, instead of relying only on electronic communication.
(“Co-located Agile project means Agile team members are located in different locations or multiple agile teams are working on different parts of the product from different locations.”)
We all know that in an Agile environment, high speed and high quality are the priority. People tend to work without taking a break, but since quality is measured based on the project and team characteristics, the human factor is key in ensuring project quality. This means that effective communication and sharp minds could influence the success of the project. James’s opinion brought about some ideas about enhanced communication in co-located Agile projects.
First, effective communication is determined by the language, product, tool/technology, and process knowledge of the team, which all have to be synced. In order to communicate effectively across distance and time zones, distributed teams need to speak the same “language”. Language not only refers to speaking terms such as English, German, or French, but also to product terms and tool/technology features or processes, which each team will have to be at a similar level of understanding in order to speak and understand each other.
In order to synchronize, extra steps need to be taken. Teams need to ask concise and valid questions in order to clarify requirements or requests and to review the outputs before it is released. The equality of knowledge between each distributed team should allow them to make decisions on internal matters, implementing the ‘self-management principle’. One team should not have tell other teams what and/or how to complete a task.
Secondly, applying suitable communication tools and methods also played an important role in the success of team communication. There are plenty of options to choose from such as direct communication (Face-to-face or Video calls) or indirect formats (Email, Forum, or Text chat). There are other popular and useful communication tools to consider, including: Skype, Slack, Confluence, GoToMeeting, or Google Drive, which easily support communication and collaboration between onshore and offshore teams. Those methods and apps can help eliminate the distance in time zone and location.
Additionally, for better communication effectiveness, scope of work needs to be reasonably arranged to fully support clients properly and provide a smooth connection. It is advised to schedule regular onshore/offshore visits to build relationships with team members and instantly respond to release, milestone, or technology changes.
- How would you define testable code? What are your criteria?
James: All code is testable. Some code is more testable than others. Testability in code just means how easily you can test it. Code is more testable when it is observable and controllable. Ask for function-level logging and scriptable interfaces. Also, code is more testable when it is simple and when it is decomposable. Decomposability is the ability to separate the components and test them in relative isolation.
To specify, there are many simple ways to define testable code, such as: code logic, code naming conventions, and project structure/architecture. Testable code always includes the ability of extension, easy maintenance, re-usability, and upgradability. Burak Guzel of EnvatoTuts lists 15 best practices for writing readable code.
- What type of skills does a tester need to move into the DEVOPS world?
James: I don’t know that much about the DEVOPS world. But that world doesn’t welcome testers. It welcomes developers. So the first required skill is programming. Then you have to look for the tools to support your testing work.
There are some tactics that testers need to pick up in order to move into DEVOPS:
- Live site testing: Testers have to test the product in production, after it is released.
- Collect and analyze feedback from users in the field. React quickly to any emerging concerns among the users.
- Advocate for testability. It’s critical that the product be built with testing in mind.
James makes valid points. Testers need to improve the ability to understand coding, scripting, build-production, tools, and operation systems such as Linux and Windows.
- How do you decide what type of information should be included in a final report to the client? What type of information is useful and what is not?
James: There is no perfect report. There is only the report that gives values to clients.
Here is some advice:
- Build credibility (by being credible).
- Know the context of your tests (test framing).
- Never use a number that is out of context (e.g. no test case counts).
- Highlight general test activities (put test in the right context).
- Highlight product risk (put bugs in the right context).
We can build the final report with three levels:
+ Level 1: Facts and truth about bugs and observations
+ Level 2: How do you get those facts? How to test those facts?
+ Level 3: How do you know if the test is good? Why is the test good enough or not?
- How do you estimate the effort of testing in a project?
James: There is no magic spreadsheet that tells you how long testing will take, but good estimation starts with visualization. Can you picture the testing process in your mind? Many testers have trouble doing that. But if they are not clear what testing will look like and feel like, they also won’t have any idea how long it will take.
Along with that comes a list of other questions that with answers, could help estimate the effort of testing in a project:
- How much time is really needed for testing?
- How long would it take to finish testing?
- What is the least amount of time we could allocate to testing?
- How much testing is needed to assure a high quality solution?
- How many test cases will be needed?
- How many testers are required?
- What testing skills are required?
- How much will testing cost?
- Do we need to test them all?
We thank James for taking the time to answer our questions. His depth of knowledge and experience broadened our knowledge of testing and it was a great opportunity to learn from him.
Thank you very much James!
