Triple T

Finishing point of task is complex to report; as there is no specific time period to test the application, there is just completion time specified (module end/release date).

If some specified time is likely given from managers, there could be a few minor functional items omitted at that point of time taking in explicit major functionalities alone in the account.

Overall test execution will be specified in days but generally in a module base testing, it will be mentioned only in hours; as it’s easy to track-in. In some cases, the time specified for a module in job card will be adjustable.

If handful functionalities are there then it can be easily analyzed and tested well before the scheduled time. Task estimate is always a recurrence procedure.

In our test estimation, time consumption happens (double the time from the initial estimation) because of slippages (build delays & iterations) from incorrect estimation.

Apart from meetings, a project task is generally estimated half a day (or) a day (or) in hours. I can observe that we all have a pattern to manage our teams but strategy is identical.

Question: So what's "Triple T" ???
Answer: Triple T >>> "Task Taken Time"...

Testing always depends on Task and Time to make a software look like a Triplet...

... EntrepreneurShip ...

>> Always construct a To-do list.
>> Contact the Literal people.
>> Identify where the Currency comes from.
>> Learn how to study a Funds Flow Statement.
>> Mind map your Thoughts and the Changes.
>> Realize your Commitments.
>> Be conscious about the Nuts.
>> Tune your individual Growth very well.
>> Verify your Bank Account regularly.

Cool References:

https://www.entrepreneur.com/howto
https://www.entrepreneur.com/popular
https://www.entrepreneur.com/lists

Bug Bugger Buggest

I got a title name, all of a sudden on reading my team mate’s status message on Facebook and thought of writing a blog related to it. Before writing a blog with regards to that title, I confirmed no blog had that title but a blog had. That too in the year 2006 itself, it was written.

Title which occurred in my mind: Bug Bugger Buggest. But I’m happy, that I saw the title in one of the famous testing blog and the content was also nice.

URL for that blog post: Bug Bugger Buggest

Courtesy: Pradeep Soundararajan

How to be with Development Team?

1) Be neutral with your views.
2) Distribute the bitter flavor in a sweet-coated capsule.
3) Aim to go up against your valuable points at the requirements phase.
4) Sustain a sugary language while discussions.
5) While partying, involve freely with them.
6) Pointlessly, don’t exchange a lot of rigid expressions.
7) In vital circumstances, administer the stuffs in an apt way.
8) Sharing the sensible thoughts (or) suggestion.
9) In a roundabout way, shoot the blunders committed by them.
10) Make an effort to avoid miscommunication & get a good name from them.