Tuesday, 23 May 2017

When should a tester engage in testing?

Test Early
Image Credit: https://cdn-images-1.medium.com
- Why should I hire testers at an early stage of a project and not just during the testing phase?
- Why should I let my testers test early?
- How can I hire and retain testers?

- How testers can evolve as PRODUCT ENGINEERS?

- And finally, why software testing is not a boring job?

Here is an attempt I made to address these questions.
As far back as my memory goes, I have been an advocate of testers involving themselves in the SDLC right from the beginning of a project. I have questioned when no testers were invited to the Architecture Review Board meeting at a previous firm that I earlier worked with.
I strongly wish that testers start contributing to a project from its discovery phase. Right from when the decision is made to build the software. This means that we do contribute to building the product right from the beginning and are not mere time wasters of programmers (coder/designer) who have already spent a considerable amount of time learning about the product, data modeling, coding, unit testing and deploying the code to the test server. And who then will have to pass on all the (or filtered) knowledge to a tester just before or during the testing cycle. Does it annoy you as a programmer?
Point to ponder here: Is this the reason why programmers are paid more as compared to the testers? Let me restate it for the testers: Is this the reason why the testers are paid less as compared to the programmers?
Moving on: How can I as a tester contribute from the beginning of a project?
Here are some solutions on how testers can collaborate with the client / Product Owner, programmer, designer, SEO engineer, the security analyst and contribute to each phase of software development.
Requirement Gathering Cycle
When the client/product owner shares the requirement, resolve to this:
As a tester, I want to refine these requirements based on quality criteria so that I will not contribute to cost, effort and time wasted at the last phase of a project.
And do this Share clarifications log with the client with the assumptions, clarifications, and suggestions to enhance the requirement.
The clarification log can consist of columns in a sheet with these details:

|Query |Clarification by the client / Product Owner |Priority| Implemented in sprint|
Example: The user is able to download the report. 
As a tester, you can question:

Query |By user do we mean a guest user or a logged in user in this context?
Clarification by the client / Product Owner | Both the guest user and the logged in user
Priority | Low / Medium / High 
Implemented in Sprint | Sprint number

Above is an example of the clarification(log) which we maintained throughout the product lifecycle by the whole team in a startup I worked at. The programmers then become better equipped to add both the scenarios of making the report available for a logged in and a guest user.
Understand and refine the requirement/s when we receive it so that as a tester you can start contributing to the quality of the product and build credibility for yourself right from the early stages.
Design Cycle
Develop skills required to test the design / wire-frames. Some references are below:
Test for user flows/navigation, user behavior in the design cycle. Do not wait until the end of functional testing, to begin with, User Interface and User Experience testing. We are responsible for a user forming good habits when they use the software built. Let us make every click count :)
Development Cycle
Test the code that is being developed for missing validations, known vulnerabilities and bugs, ask for access to the code, database and learn what is being implemented as part of a fix and what is the impact of the fix. This helps us as testers to learn about the fix and the impact early on. And help identify a bug during the coding cycle and in fixing it then rather than wait for the fix to be made, unit tested and deployed on to the test server to be tested and then for the bug to be logged in the bug logging system to be fixed and re-tested.
This to me sounds like a waste of valuable time for all involved.
Testing Cycle
Now that a lot of time has been invested by you in testing at different cycles of the project, utilize the testing time effectively to test the system post-integration. Take time to learn about effective bug logging, interactions with the application, it’s users and let us invest time to gather user feedback and enhance the product suitably.
Release Cycle
Proceed confidently to the release cycle. Take time to test the release notes in dev/test/beta phase. Check for version numbers, fixed bugs section, whether adding this information creates an impact, can we do away without adding the trivial details. Those users who will read the release notes (which is not equal to the number of downloads) are unforgiving if there is nothing new that they can learn post reading the notes. Add value to bug logging and enhancing the product quality at this stage too.
Maintenance Cycle
Use this time to work on those low priority bugs and get it fixed and re-tested along with the other bugs found by the team or a user feedback/suggestions/user reviews that you read.
Invest time earned to learn, take testing courses, give talks, attend webinars and conferences, invite users to test and to gather another test idea. Up-skill to remain relevant in the ever-changing and ever-growing industry.
Investing early efforts to test can help address major problems which we are facing as testers.
1. No time to test.
2. Building credibility early on.
3. Knowing that this credibility eventually gets translated to respect and testers being treated equally with the other roles in an organization.

My question for you today is: Do you recognize valuable respected testers around you? 
If yes, make them your mentors today. They are waiting for you too :)

Wednesday, 10 May 2017

Few pointers to the translator

Certain translations that I came across triggered me to add some recommendations to the translator (someone who works on translations) who is yet to recognize or who undermines the value that they create by adding translations.

I reckon that it is essential for a translator:
Click on the image to view it in an enlarged form.
  • to possess language skills (reading, writing, speaking)
  • to have knowledge of the tools used and 
  • to develop a sense of onus and service to the community.

In the above example:
The author, Girimane Shyamarao has written a book titled: 'I / Myself, Children and Education' but the translation roughly is made to as you see 'I have children and education'. Such slip can be avoided if we meticulously learn the language, the meaning/s of the words used and in a contextual manner.

Some recommendations are now part of the guidelines that I had earlier created when I was involved in translating some educational project for Khan Academy. Thanks to my mentor Julian Harty for encouraging me to volunteer to translate.

A few lessons learned are shared below in the form of a mindmap.

Click on the image to view it in an enlarged form.
Or refer the images below.

If this write-up inspires you to take up translation work, then do create an account with Khan Academy here: https://www.khanacademy.org/ and volunteer to contribute.

Saturday, 6 May 2017

Socially Challenged By Social Engineering

Socially Challenged By Social Engineering - A study on Social Engineering trends in corporate culture.

Troy Hunt had advertised about the new Ethical Hacking course availability on Twitter, and since then I had wished to opt for Pluralsight learning (where this course was made available.) I got ample opportunities to implement the lessons I was learning this week.
A few scenarios that were opportunities in disguise for me to exercise the lessons learned are as follows:
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 1

The first attempt — Creating a sense of urgency.
A co-worker lets say ‘X’ who had met the team twice and had spent a considerable amount of time to get to know the work we do, had wished to seek some more information. And it came as an email request. This information which needed to be shared, yes was secure information.
What seemed obvious at first but suspicious next because there was a sense of urgency in the email sent. “Need this information by end of the day”. It did not though say who was the consumer of this information.
While I made a genuine effort to fetch the information, it occurred to me that — Why is X asking me this information? (When X knew someone else in the team who had spent a lot of time with X and had built a rapport already as compared to me.)
So, I cross-checked with all the others on the team. I inquired, “Did any of you get a similar request to share this information?”. The answer was ‘No’. I registered this.

The Second attempt — Introducing an unknown character.
My next suspicion was, X had made an indirect attempt to seek information via a new supposedly a ‘girl’ before sending this email request. This girl was unknown to me. I wondered ‘who could this be’ when I got the request from this stranger. There was no attempt made by X to introduce the ‘new girl’ to me. This was the giveaway move. Because when X knew me, ‘why’ make an attempt to introduce a stranger to seek this information. What was X thinking? (Now that X has realized what he did and has spoken to me about it, I will attempt to know the why.)
Interesting at the same time suspicious to know why to introduce a ‘new girl’ when X who knew me, could have directly contacted me.
Next day, the ‘new girl’ started pinging me (and again with a sense of urgency) to gain this information which by now was already asked over an email by X. ‘New girl’ then told me that person ‘Y’ wanted this information. I did not know who Y is nor I was introduced to Y before or during the conversation. I clearly replied, I do not have access to this information and as I have replied to the email, let us wait for the authority to grant us the access. And I included Y in the email who was the ‘CONSUMER’ of this information.

The third and the fourth attempt: Cause fear and threaten.
Rest assured, I bid the new girl bye benevolently and logged off. Then X who obviously is aware that I have not given the new girl any information so far, calls me on my phone and it is evident from the start of the conversation that he is not in the right frame of mind. X then tried the third mode: To cause fear in me to gain access to the information. When that did not work, X then uses the fourth mode: threatens me by conveying that ‘I will go to the highest level of escalation’. I am calm and composed as I knew that I am not the authority to give X this information even if I had access to it.

To brief, Person X’s tries/attempts to gain information are as follows:
  • Create a sense of urgency for reasons (valid/invalid).
  • Introduce an unknown person (a girl, don’t know why?) — This being the incorrect move for obvious reasons. X had undermined himself as the first POC to reach out to me and had caused me to have my first suspicion. Please take note how this gullible new girl was victimized in the entire process.
  • Cause fear which then culminated as a threat.
  • Know and seek information from the right sources.
  • Quote valid reasons for seeking the information.
  • Inform who is the end user of this information so that it can be sent directly to the consumer and not to the others who should not have access to this information.
  • If the seeker is the end user then it can be helpful so the mediators do not gain access to this information.
  • Learn and know how to talk to anyone and professionally.
  • Educate the gullible, they need help so that they are not a part of the terrorizing culture.
This scenario not just helped me to implement what I was learning but also led me to another knowledge source. When I was at a bookstore recently, my eyes lit up when I saw this book 'Maatu Hegiddare Chenna'? authored by Girimane Shyamarao (ಮಾತು ಹೇಗಿದ್ದರೆ ಚೆನ್ನ, ಗಿರಿಮನೆ ಶ್ಯಾಮರಾವ್) which roughly translates to 'How words spoken/uttered must be?' It is a good read for anyone who wishes to be a good speaker.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 2

corporate social engineeringA co-worker ‘A’ was made an easy target for wrongdoings of similar patterns from his past and the authorities were trying to action against A for the same. I wrote to A about the allegations that were made.
A was taken aback and replied with proofs of what was happening.
I probed further, as I had spent a lot of time setting things right with A. This probe revealed that these were false acquisitions and was not done to offend anyone in the process. But A did reveal that he had only faulted with me and not with the others, assuming that I will forgive but the others wouldn’t. I rested this case but was glad that I inquired to get the proofs when there were false acquisitions being made on A. When I reported the authorities about the false acquisitions, the authorities understood while they also exhibited suspicion that A could be lying.

  • Information coming from a senior needn’t always be true/correct. Please know this and investigate, especially in a terrorizing culture.
  • Know that an impersonator usually disguises as someone with authority, is trusted, is a senior, is legitimate, is respected. This doesn’t mean that you fear them or fall prey for it. Instead genuinely question and learn about the intentions of the impersonator.
  • Learn from the past mistakes and know when to stop helping/investigating.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 3

This is a case of:
  • An attempt to please a person with authority.
  • Fear of senior/s.
  • Not learning from the past mistakes.
Some give away passwords in plain text when merely asked to share only the username, this scenario occurred when a senior with a sense of urgency asked for information from a new joinee. Newbies are unnecessarily petrified, help them out and create a safe environment rather than instilling fear.
Do not leave mobile devices/laptops unattended, that can cause anyone in the vicinity to gain easy access to the system. Have strong passwords (policies) and be aware of the fact that there could be a threat lurking around. Educate and be better equipped to address security threats in the form of social engineering.

  • Educate the new employees.
  • There is nothing to be feared, but only to be understood - Quoting Madam Marie Curie.
  • Instill a positive and safe environment to question and to learn from all.
  • Encourage learning and create a culture to reward learning.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
Final thoughts
  • It works isn’t sufficient. Know that SECURE systems are as much important and necessary. For any reason, security should not be of lesser priority. Introduce Secure Development Life Cycle at all stages of software development. Katie Moussouris introduced the term Secure Development Life Cycle at the NullCon Conference. She can assist with further learning about how to implement this along with any of the other SDLC stages.
  • Be aware of known vulnerabilities and address the security aspect of the system that we build and test.
  • Share professional information wisely and with the right consumer.
  • Do not share personal information where it is absolutely unnecessary.
  • Do not encourage personal information seekers.
  • Beware of what you share on open source mediums and free tools. Know about OSINT — Open Source Intelligence. Know nothing is free, your data is what you trade for using open source apps/free tools.
  • Socially challenged is what we become if we fall prey to social engineering.
Edited (April 2018) to include:

Optional reading/listening
If it's free you are the product, with IOT even if you pay you are still the product - Surya Mattu